New Direction for LTSP: Diskless Remote Boot

[gerhard.oettl.ml at ogersoft.at]

Hello

There was a simular thread at debian-edu concluding with following 
posting: <http://lists.debian.org/debian-edu/2007/07/msg00140.html>

In short: There are usecases for both technologies but for mixed 
environments the LowFat client of LTSP is the less invasive approach.
For example when terminal server is established and there is a need for 
more powerful clients (multimedia) or it would be a waste of server 
power if better client hardware arises.


gerhard


Robert Arkiletian schrieb:
> Hello list,
> 
> I know local app support is in the works BUT
> 
> I'm wondering if anyone else is thinking it would be a good idea to
> have an option (or even a distro) which runs EVERYTHING on the client.
> Much like DRBL http://drbl.sourceforge.net/. The reason for my
> suggestion is that I feel the days of Terminal Servers are numbered.
> With the advent of Intel Atom like cpus, it now becomes possible to
> retain the energy efficiency of previous generation thin clients AND
> have enough cpu muscle to run a full desktop. As time goes on these
> cpus are only going to get faster. They are already fast enough and
> very affordable.
> 
> http://www.newegg.com/Product/Product.aspx?Item=N82E16856167032
> 
> The benefits of LTSP are ease of administration, maintenance,
> affordability and energy efficiency. With Diskless remote booting
> these advantages are retained. But the traditional problems and
> difficulties in development of LTSP: remote sound, local devices
> (ltspfs), cpu hogs (flash), full screen video (network bottlenecks and
> sound sync),  security (ssh tunnels,  X  latency), X caching pixmaps
> in local ram (firefox, OOo killing X).... they ALL disappear.
> 
> One new problem does arise. The time to initially launch an app may be
> slightly increased. Since the app must be loaded from a remote disk,
> the network replaces the SATA cable. However, ram is so cheap, if you
> stick in 1GB on a client ($20), the 2.6 Linux kernel utilizes most of
> the ram by caching app memory. So if you launch FF, close it, then
> launch it again, it is much faster second time around. The slowest and
> most demanding event in a DRB lab would be boot time. However, this
> can be scheduled in a cron job (with WOL) to occur just before school
> opens in the morning. Problem solved.
> 
> Fortunately, these new little boxes are shipping with 1000Mbps nics.
> In addition, full gigabit port switches are much more affordable than
> when they first came out. So for the future, as network switches get
> upgraded, this issue should dissapear. FAST disks on the server and a
> fat pipe to the switch would be optimal. SSD drives in the future may
> hold promise.
> 
> The setup I describe above has been successfully implemented for an
> entire school district. Here
> http://www.sd73.bc.ca/district-operations.php/page/linux-in-education/
> 
> Most people who started using LTSP did so by re-using old computers (I
> still use PII's) as make shift thin clients. The cost of upgrading an
> entire lab was ONLY 1 server. It made sense. I still happily use
> K12LTSP today.
> 
> But look at hardware technology/affordability today. I am in line for
> funding at the end of this school year. I am most likely going to buy
> a whole lab of Atom based systems much like the one linked above
> (hopefully the next gen). I wish I could install a Fedora or Ubuntu
> DRB distro.
> 
> I hope LTSP developers and distros see this perspective. If others on
> this list agree or disagree please speak up as I want the general
> consensus to be known.
> 
> 
>