New Direction for LTSP: Diskless Remote Boot

[Vu Nguyen]

Hi Robert and Edubuntu developers,
I second these ideas, I am willing to assemble the thin client myself to
save money and still have the decent CPU and RAM if the apps run on those
client.
Cheers.


On Wed, Sep 10, 2008 at 2:32 PM, Robert Arkiletian <robark at gmail.com> 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 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.
>
>
>
> --
> 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/
>
> --
> edubuntu-users mailing list
> edubuntu-users at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/edubuntu-users/attachments/20080911/97c8e073/attachment-0001.htm