[K12OSN] Life after LTSP

Tue Nov 9 04:57:27 UTC 2010

The Foxconn NetBox-nT410 I'm using with Ubuntu 10.10 LTSP as a
thin-client pulls between 13 and 14 watts while in use.

On Mon, 2010-11-08 at 19:07 -0800, Robert Arkiletian wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/k12osn/attachments/20101108/9543ecff/attachment.htm>