[K12OSN] Life after LTSP
robark at gmail.com
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.
>> 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.
>> 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.
>> 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.
>> 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.
> 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.
>> 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
>> 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.
> K12OSN mailing list
> K12OSN at redhat.com
> For more info see <http://www.k12os.org>
Eric Hamber Secondary, Vancouver, Canada
More information about the K12OSN