[K12OSN] Future LTSP direction: Local Apps
robark at gmail.com
Thu Mar 22 03:40:18 UTC 2007
I just got back from visiting Kamloops school district here in Canada.
Their goal is to switch their entire district to Linux diskless
clients and they are doing it. However, they are not using 100% LTSP.
They use bits of ltsp to pxe boot their clients and mount / over nfs
and they use NIS or LDAP for auth but they DO NOT use XDMCP or ssh to
shoot the display over the network. Everything runs locally. Every new
client is an AMD Sempron cpu with 512MB (easily powerful enough to run
everything locally). The clients are almost the same price as many
thin clients. About $250 CAD. They are actually using a modified
Muekow ltsp implementation built in house inside a virtual private
Kind of like a super chroot environ that requires a patched kernel.
(Not a virtual machine like Xen or VMware)
The clients are still diskless. But since everything runs locally
there is no traditional problems associated with ltsp. Like having an
entire classroom (30 clients) watch a full screen youtube video
(flash). Or fullscreen quicktime/mpeg4 video (remember you are
streaming [over nfs] the highly compressed video file in exchange for
cpu power required to decompress it). Or have a Beryl 3D enabled
student desktops. Or 30 kids playing GNU/Chess. Good luck doing these
things with traditional thin client ltsp. I don't care if you have a
dual Opteron, it's still going to fall to it's knees. The nfs server
at Barriere Secondary serves the entire school: approx. 115 clients.
Local devices like USB sticks: no problem, each client is running a
full blown OS. No need for ltspfs. All clients run Xvnc so support for
the district techs (who by the way are all highly qualified certified
Linux/BSD gurus) is a snap since they can fix things remotely.
LTSP 5 has this ability as it uses the distro packages instead of it's
own and is much easier to implement local apps. In my mind, this is
the future of ltsp. Kamloops is just ahead of the curve because they
realized that if their initiative was to be successful they didn't
want any of the limitations of ltsp while still having the advantages.
Clients are diskless centrally managed appliances. Plug it in and it
works, advantages that ltsp has always had.
Some may say apps take longer to load over nfs. This may be true but
if you configure your network properly you can address this. Gigabit
switch backbone. Port trunking. Another solution I like, use multiple
gigabit nics in your nfs server on different subnets connected to
separate switches as described here.
Thereby, creating dedicated bandwidth for different parts of a school
and preventing bottlenecks.
In any case, once an app is loaded it's fast and if you happen to
shutdown the app (say Firefox) and start it again the machine does not
take nearly as long to launch it again because apps are cached locally
in the memory of the client machine (remember the 512MB).
The only down side is power consumption as compared to real thin
clients. However, having said this I know that most people running
ltsp are using old hardware as thin clients which are not energy
efficient. However, I believe the advantages outweigh this issue
especially when you have to compare them to stand alone Windows labs.
Having said this, those AMD Semprons are actaully a pretty efficient
Part of the reason local apps have not gained as much momentum in ltsp
circles is that the raison d'etre of ltsp was that you didn't have to
purchase new clients. Simply re-deploy existing old boxes (As I and
many others have done) as thin clients. So after a few years and ltsp
was seen as a viable solution people kept the "Run it on the server"
ideology. Even though the price difference between new real thin
clients and relatively powerful diskless clients has almost
My last point, the nfs servers in Kamloops are actually hybrid
servers. They actaully have scripts to determine how powerful a client
is at boot time then decide how many apps (all or some) will run
locally. So the nfs server is also a traditional ltsp server. This, I
believe, is a stop gap measure until all their clients are replaced
with new ones.
Eric Hamber Secondary, Vancouver, Canada
C++ GUI tutorial http://www3.telus.net/public/robark/
More information about the K12OSN