[K12OSN] Life after LTSP

[Jeff Siddall]

On 11/08/2010 03:27 PM, Robert Arkiletian wrote:
> In my opinion,  the days of LTSP are numbered. For a few different reasons.

Yes and no.  See my comments inline.

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

Yes, hardware is petty cheap but even the most power efficient desktop
systems are about 5 X the power of a typical thin client.  Over the life
of the client that can exceed the hardware cost.  Plus any fanless
system is still a slow systems, and LTSP can make those slow fanless
clients feel like fast noisy desktops.

Thin clients aren't any more expensive _if_ you don't buy expensive
models!  I still buy my TCs in parts and assemble and it can be done for
low $100s, which is pretty reasonable.

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

Yup, these are somewhat difficult, but ultimately a clock cycle is a
clock cycle and if your client is using 6 cores on your server it is
probably faster than the one or two cores on their client.

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

Fully agree.  Video is the real problem child for LTSP.  I run dedicated
video apps (VLC) as localapps but flash inside a browser (ex: YouTube)
just doesn't work well on LTSP.

> 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 chipset). 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 way of doing things.
> 
> http://www.markshuttleworth.com/archives/date/2010/11
> http://wayland.freedesktop.org/http://wayland.freedesktop.org/

Yeah, that is an issue, though I expect X won't just disappear in the
real near term.

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

Yes, this is better than distributed fat clients but not much since you
need hardware for all the clients in the server.  Agreed that having a
set of tools to manage multiple VMs would help keep administration
manageable.

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

This seems to be the best option out there today if LTSP has some
serious issues in a particular environment (ex: see item 3 above).

Ultimately I think a hybrid environment is probably required for most
organizations.  If you can use LTSP it is the lightest weight -- both
for hardware and administration.  After that DRBL keeps the admin
benefits but requires full desktop hardware on the client side.  VMs
keep the client light (presumably) but have serious server side hardware
and administration requirements.  NX fits is there close to LTSP too.

The right solution is whatever works in a given environment.

Jeff