New Direction for LTSP: Diskless Remote Boot

David Van Assche dvanassche at
Wed Sep 10 08:57:39 BST 2008

Hi Robert,
   This is the reason we thought about doing drbl-like stuff within
ltsp. It doesn't really make sense to merge 2 technologies, and it is
no rocket science to make diskless workstations on the server. Here is
the general idea, which I've been using for our multimedia stations
for a while now:

There is a --workstation plugin there to download that will make it
real easy to work from, though one needs LDAP and NFS to really make
the solution work. There is ongoing work on a new plugin that does a
bit more than that, synching user/group lists with the server and
such... but I'm still wondering whether local apps is not a better
approach, since with it, you don't overload the local machine with
everything, you get to pick and choose...

David Van Assche

On Wed, Sep 10, 2008 at 6:32 AM, Robert Arkiletian <robark at> wrote:
> 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 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.
> 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
> 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
> C++ GUI tutorial
> --
> edubuntu-users mailing list
> edubuntu-users at
> Modify settings or unsubscribe at:

More information about the edubuntu-users mailing list