A new direction for LTSP: Diskless Remote Boot

[Robert Arkiletian]

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/

LTSP was a solution for a problem that existed 10 years ago. 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.

-- 
Robert Arkiletian
Eric Hamber Secondary, Vancouver, Canada
Fl_TeacherTool http://www3.telus.net/public/robark/Fl_TeacherTool/
C++ GUI tutorial http://www3.telus.net/public/robark/