[K12OSN] Life after LTSP

Tue Nov 9 03:07:36 UTC 2010

On Mon, Nov 8, 2010 at 12:59 PM, Jeff Siddall <news at siddall.name> wrote:
> 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.

I am going to measure my clients power usage tomorrow. I have Dell
Opitiplex dual core Celeron e1400 (2Ghz) cpu with Intel Q43 chipset.
and 2GB ram. Wondering if anyone has measured the power usage of a
true thin client (eg. Atom) system.

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

Flash is on it's way down as youtube switches so html5/webm. Apple is
helping flash die too.

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

I agree X will be around for a long time.

>> 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
>
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
>

-- 
Robert Arkiletian
Eric Hamber Secondary, Vancouver, Canada