Life after LTSP

[Robert Arkiletian]

In my opinion,  the days of LTSP are numbered. For a few different reasons.

1)
hardware is so cheap now. You can buy a brand new power efficient and
fast  desktop system for about $200 (not including monitor).  Thin
clients are actually *more* expensive now.

2)
programs like flash and java based apps don't work and will never work
well in an LTSP environment because they are multithreaded and utilize
all cores on the server. So no matter how powerful a server, running
many flash or java apps bring it to it's knees. Things were better
when all apps were single threaded. As time goes on this will only get
worse as cpu makers are increasing cores not mhz, so software makers
are adapting by making apps utilize all cores. Local apps is a
solution in the right direction but it brings with it other problems
like using fuse (ltspfs) and other issues. The other problem with
local apps, in an ltsp client, is that usually true thin client cpu's
are weak (eg. Atom). The concept of Local apps is 180 degrees to what
LTSP is about.

3)
Things get even worse when you run video full screen because the data
is being decoded (high cpu hit) at the server, then pushing *large*
decompressed data across the lan. It just doesn't scale well.

4)
If Ubuntu is successful with their move to Wayland display server
(away from X), LTSP may not even work as Wayland has no network
transparency as X does. Not sure if having X as a client itself on top
of Wayland will work with LTSP. My guess is it will be troublesome
because the client will need Wayland up first before X (which btw
means it will also definitely need an opengl capable video chipset+driver). I
suspect that unless the LTSP project goes back to the way they did
things in LTSP 4, where they pretty much managed and built the chroot
as a seperate distro, I think Wayland is going to break LTSP with the
Muekow (LTSP5) way of doing things.

http://www.markshuttleworth.com/archives/date/2010/11
http://wayland.freedesktop.org/http://wayland.freedesktop.org/

So what do we do? Personally, I think there are at least a couple solutions.

1)
Spice. The new remote VM technology that is in Fedora 14 and RHEL6.
The management gui needs to get better in Fedora, but that's coming.
Server requirements will be higher than ltsp as each desktop will have
a VM running (not just a desktop and apps). But advantage will be
complete customization per client and heterogeneous (windows+linux)
environments ( at the expense of ease of administration, unless there
are nice gui tools to manage multiple vm's simultaneously )

2)
DRBL. This is the route I have taken. It's similar to ltsp boot
process via pxe but ALL processes run locally. Only the filesystem is
remote via nfs. There is no need for special plumbing for sound or
local devices. Everything works like a stand alone system. Except the
first time to launch (not run) apps is slightly longer since the
binary needs to be downloaded into local ram from the network before
it can be run. One user can't hog ram or cpu. Full class of full
screen video and flash, no problem. I even have had an entire class of
students simultaneously install and run Ubuntu in a Virtualbox VM on
top of  the diskless client OS. Local apps with LTSP cannot do this.
Although I do have dual gigabit nics for the lan and hardware raid 10
for the server. Each client can have it's own nfs mounted /etc and
/var so there can still be customization per client.

-- 
Robert Arkiletian
Eric Hamber Secondary, Vancouver, Canada