Life after LTSP

[Jonathan Carter (highvoltage)]

Hi Robert

On 08/11/2010 15:34, Robert Arkiletian wrote:
> 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.

I use Flash and Java as local apps and they work quite well, even though
it's just an Atom. I guess it also depends on your definition of "what
LTSP is about". I doubt you'll get lots of people to agree on that. For
some it's about cost cutting, for some it's about ease of administration
and for some it about the sheer speed you can set up an environment up
in... and probably a lot more reasons that I can't think of right now.
IMHO it's perfectly valid to provide a solution for people who have very
powerful thin clients, too.

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

Indeed! You don't want to do full screen video on pure thin clients.

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

Even if the chroot uses another distribution, there will still be
problems caused on the server side, ie. applications that don't use X at
all any more. I'm quite sure that this will trigger some LTSP
re-thinking indeed.

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

LTSP can actually do that. If you use the fat client desktop options
when building a chroot, you can have all your apps running locally just
like you would on DRBL. I've ran VirtualBox under LTSP Fat clients
running Windows XP in a computer lab and it worked just fine.

Either way, cheap devices are certainly going to change things
eventually. Everyone's walking with more and more powerful computers in
their pockets. All that they might need is a bigger keyboard and screen
to connect to in their classrooms.

I think it will cause a whole bunch of new challenges for schools and
software companies. How are commercial educational products going to be
licensed? Per school? Will students have to buy it theirselves? How will
software be managed and deployed? I know that I certainly wouldn't want
to give my school (if I had one) root access to my device to do stuff on
it without me knowing about it. My guess is that in a few years from
now, students will do most of their work on web enabled devices that
connect to their school's web services. I'm probably stating the obvious
with that, since it's already happening in many schools, but even then I
think there'll be some use for some desktops running in a diskless
environment.

My 2c :)

-Jonathan