[Pkg-ltsp-devel] Presenting me and TCOS project

[vagrant at freegeek.org]

On Mon, Jun 04, 2007 at 05:57:53PM +0200, MarioDebian wrote:
> I'm Mario Izquierdo from Valladolid (Spain).
> I met some of the people in this list some weeks ago in Sevilla
> (Olivert and Vagrant at least).

good to hear from you :)
 
> For others that don't know about my work, it's about a new thin client
> project called TCOS (Thin Client Operating System).

yes, i've been browsing the svn tree for the past few weeks:

https://forja.rediris.es/svn/cls-tcos/trunk
 
> The purpose of this mail is to colaborate with pkg-ltsp team, if
> possible, since TCOS has entered in Debian NEW queue:

ah, yes. the long wait. packages for LTSP are currently stuck in NEW as
well.

i also just stumbled upon your ITP request: 

http://bugs.debian.org/414412

> Why another thin client project?

...snip...

> To give full support and usability to those classrooms, we need a good
> sound support (our users are usually kids between 4-8YO) and an easy
> control panel. One year ago this specs didn't exist in LTSP and PXES
> projects so I started TCOS.
 
> So following that TCOS has this purposes:
> 
> * Not using NFS (if thin clients have more RAM than a configurable
> limit, e.g. 38Mb)

i think we could adapt LTSP to function in a similar way.

> * Use system binaries, libs and kernel (no patches)

LTSP does this.

> * KISS (avoid using shell)

do you mean Keep It Simple Stupid ?

what is simple to one person is complex to another- could you provide
more information what you mean here?

> * Better sound support

the sound support in debian's LTSP could use some improvement, and i
think ubuntu has actually demonstrated a good, solid way to accomplish
this (pulseaudio + alsa hooks). i think we need to document how to set
that up on debian LTSP.

how does tcos handle sound support?

> * Magic mount devices (using ltspfs and python)

we use ltspfs in debian/ubuntu ltsp. does TCOS do anything that makes it
work better?
 
> TCOS gets system files and generates a initramfs and a usr.squashfs file:
> 
> http://wiki.tcosproject.org/TCOS/Introduction

thanks, it is a nice overview.
 
> Another reason for this mail is beacuse of ltspfs packages.
 
> I used my own ltspfs packages before and now, when TCOS arrives in
> Debian, I must use Debian packages. ltspfsd package is prepared to be
> installed into NFS chroot and if it is installed in the server, maybe,
> some udev rules will break other things :(

...snip...
 
> Is there any possibility to split this package and put udev rules in
> another package?

ltspfsd is not meant to be installed on the server- for proper
functioning of ltspfsd, it needs the udev rules.

> If I try to upload a new ltspfsd package, the ftp-masters will kill me :-p

we probably would not be very happy if you took over our packages
without talking to us, either :P


the tcosmonitor stuff would definitely be great to have for ltsp as
well.  i haven't actually looked at the code, but your demonstration in
sevilla showed many useful features- some functionality similar to
"ltspinfod" that we've been lacking in the 5.0 implementations so far.
though some of the features seemed potentially a security risk- so that
would need some more review.


looking at the code in svn:

if we wanted to integrate TCOS into LTSP, i would want to change
initramfs-tools-tcos into two packages, the server-side components, and
the client-side. then we could install the client-side components into
the LTSP chroot and generate the TCOS initramfs there. this would at
least solve the ltspfsd udev problem.

there is quite a bit of code in initramfs-tools-tcos. it will take some
time to get an understanding of how it all works. a technical overview
of what different parts of the code do would be really useful.

my main concern is that the initramfs/squashfs generation copies
specific files into the images, and might be hard to maintain the
correct lists of files over several releases of debian and ubuntu. in
essence, it doesn't use package management, but manages features (X,
ltspfs, sound support, etc.) on a file by file basis. if the scope is
small enough, this may be manageable.


so, i don't know where to go from here. i think there are many things in
common, some differences in design, and a lot of code to look over.


live well,
  vagrant