[K12OSN] Life after LTSP

[Charlie]

So realistically, DRBL is limited as well since it requires like
architecture on the server and client, as in you can't have a really
robust x64 based LTSP server and a x86 based client solution. Not much
use in running a high end server hardware system on a 32bit x86 OS.  

On Mon, 2010-11-08 at 12:27 -0800, 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.
> 
> 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.
> 
> 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/
> 
> 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 )
> 
> 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.
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/k12osn/attachments/20101110/035ae4b9/attachment.htm>