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

Tue Jun 5 13:36:32 UTC 2007

El mar, 05-06-2007 a las 01:35 -0700, vagrant at freegeek.org escribió:
> 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

I'm working all days to clean and make some doc off all code, I don't
test LTSP5 yet but TCOS hooks it's very similar tahn LTSP5...

LTSP will use debconf to configure thin client and TCOS use some
low-level configurations...

>  
> > 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

Matt was in this ITP, I don't insist too much waiting for Sevilla
meeting... and now I have a DD to sponsor packages

> 
> > 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.

It isn't very difficult with TCOS or PXES, but with actual LTSP build,
chroot is bigger to send with tftp...

> 
> > * Use system binaries, libs and kernel (no patches)
> 
> LTSP does this.

I know, but one yer ago LTSP don't use it.

> 
> > * 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?

Users don't matter how thin client boots

TCOS will try to make more equal using a Thin CLient like a normal
Computer (usb memory works, sound works and some minor things)

I repeat that I don't test new LTSP yet. I suppose that this things will
work in LTSP better than TCOS... (simply, I'm only one newbie developer
and you are more (in number) and more expert people)

> 
> > * 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?

Thin client boot, force loading modules with discover, and here we have
2 case:

* thin client have very old sound hardware and OSS driver is loaded
(isapnp from kernel do the hard work)

if /dev/dsp is found but /proc/asound not I start esd (with libesd0 not
alsa) and then pulseaudio over esd using a internal pipe. 
(PulseAudio don't work very well with OSS hardware and locks)

* thin client have a more new sound hardware which load with alsa,
pulseaudio do the rest. nothing more to configure.

In TCOS images I don't put by default all sound kernel modules, if thin
client don't have sound user (with TcosMonitor for example) can see
which modules are required (discover know how many)

This figure show some of this:

http://soleup.eup.uva.es/mario/get/1/dibujo.png

Orange line is LTSP < 5 sound works with esound.
Black lines is TCOS sound and maybe LTSP5.

> 
> > * Magic mount devices (using ltspfs and python)
> 
> we use ltspfs in debian/ubuntu ltsp. does TCOS do anything that makes it
> work better?

Only use same daemon (ltspfsd) and client (ltspfs) but the
client<->server comunication is very different.

I have made a small XMLRPC web server:
http://trac.tcosproject.org/browser/trunk/tcosmonitor/xmlrpc

This server have some methods to do things and retrieve info, one of
this methods read a udev.log based on this rule and script:

http://trac.tcosproject.org/browser/trunk/tcosmonitor/udev

In server, when user log in, same utils are launched:

For USB tcos-devices runs in daemon mode:

http://trac.tcosproject.org/browser/trunk/tcosmonitor/tcos-devices.py#L297

I mount devices in $HOME/Desktop/[$DEVICE_MODEL_OR_VENDOR | usbdisk-N]

(Oliver say to me that LTSP5 use /media/$USERNAME but this will be more
problematic, because $USER (by default) can't write in /media

For floppy and CDROM I made a small GUI to mount it:

http://soleup.eup.uva.es/trac/attachment/wiki/TcosDeviceManager/tcos-devices-5.png

>  
> > 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
> 

I try to say if i get ltspfsd sources and generate (for example)
tcos-ltspfsd package, NOT MODIFING YOURS!!!

Your work (which is more great) is your work.

Perhaps ltspfsd-tcos (a package with ltspfsd bin in /usr/lib/tcos)
without udev rules is all what I need.

You can build this package using ltspfs sources generating 3 packages
instead of 2.

> 
> 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.
> 

Comunication between clinet and server using XMLRPC not use any
encription and password go in clear, I suppose that is possible to build
xmlrpc with SSL support, It's a case to study soon.

> 
> 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.

Many people asked me to have a standalone client package (for example in
CGA of la Junta de Andalucia) all Guadalinex desktops are full-installed
hosts.

Perhaps something like: tcos-standalone with some utils will be enought
to normal and LTSP hosts (some time ago with LTSP4.2, I have a package
called ltsp-tcosmonitor will the utils to take control of a LTSP thin
client, but I delete it because with it initramfs-tools-tcos don't
fulfill Debian policy.

You can generate it with uncomenting ltsp line of this:

http://trac.tcosproject.org/browser/trunk/tcosmonitor/debian/rules#L47

You can see at this Makefile too:

http://trac.tcosproject.org/browser/trunk/tcosmonitor/Makefile.ltsp

> 
> 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.

I will work on a complete and technical introduction in wiki in theses
days...

> 
> 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,

Not so dificult... same sources (SVN) works with debian unstable, debian
etch, ubuntu feisty, ubuntu edgy, and ubuntu dapper.

Only a minor changes and a few if conditions are needed.

See at common.mk:

http://trac.tcosproject.org/browser/trunk/initramfs-tools-tcos/common.mk

"make test" will show all compile vars, it's soo ugly but works !!!

>  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.
> 

Some of this are not easy to understand, I have needed one year to
support localized kbmap :(

Some time with "strace" and fix missing files.

> 
> 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

I will try to test LTSP5 and search where can put TCOS good things (if
posible)

Cheers...

-- 
Mario Izquierdo
http://www.tcosproject.org
http://soleup.eup.uva.es/mariodebian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente
Url : http://lists.alioth.debian.org/pipermail/pkg-ltsp-devel/attachments/20070605/056c12f1/attachment.pgp 