[K12OSN] A New direction for LTSP: Diskless Remote Boot
simpsond at leopards.k12.ar.us
Wed Sep 10 12:56:42 UTC 2008
The very reason I started with K12LTSP was the fact that I *could* use old hardware and make it usable again.
As it progresses, though, it is getting harder and harder to use the older hardware. One of the key selling points early on was that you could use the same hardware for the clients for many years and just upgrade the server/software and use it for many years. This is not turning out to be the case.
For example, I used to use a 486-dx33 with 28MB RAM as a client for my grandyounguns and it worked very well up until FC3. From then on, it because unusable. Granted, a 486 is pretty archaic, but it *was* usable is my point.
Now it is hard to even get PII computers to work if they don't support etherboot natively, or if they don't have specific network cards in them. And forget trying to run any client with less than 64MB RAM.
So, as it turns out, the client-side hardware will still need to be cycled every few years anyway. . .
But, kudos to the guys that are developing this wonderful system called K12LTSP, and the LTSP project(s) in general.
JMHO - YMMV
De Queen Public Schools
De Queen, AR
simpsond at leopards.k12.ar.us
"A Dollar Saved is a Dollar Earned"
>>> Rob Owens <rob.owens at biochemfluidics.com> 9/10/2008 7:14 AM >>>
I agree with most of your arguments in principle. For me, DRBL could be
a potential alternative to LTSP.
However, the Atom-based unit you mention uses a 65 watt power supply (I
didn't see specs on the actual power consumption). That's small
compared to a traditional desktop, but it's huge compared to the 6 watt
thin clients I'm using.
$150 (plus some money for RAM) doesn't seem like much to me to spend on
this Atom-based unit, but I live in a developed country and have a good
job. In lots of other parts of the world, $150 is unaffordable. Those
places need to be able to use a 200MHz P2 with 32MB of RAM as a thin
client. Heck, back when I started using LTSP, I needed to use a P2 as a
thin client because I couldn't afford to buy something for my "little
That brings me to another point. LTSP is enticing and is easy to try
out because you can do it without spending any money -- you simply use
some old junk. If it required a $200 or more investment just to try it
out, would we see the same level of adoption? Granted, in the developed
world $200 isn't much, but I still think it could be a barrier to
adoption. Plenty of people will "try out this linux thing" if it
doesn't cost anything, but how many people would buy a $150-$200
diskless workstation in order to "try out this linux thing". That
diskless workstation won't even run Windows XP if their little linux
experiment fails, so that would be money wasted. I think many people
won't take the chance, and that would be a shame.
So I guess I'm saying that DRBL-like capability would be a great
addition, but I would hate to see the main focus of LTSP turn away from
low-spec thin clients.
Robert Arkiletian 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.
> 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.
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If you are not the addressee, any disclosure, reproduction,
copying, distribution, or other dissemination or use of this transmission in
error please notify the sender immediately and then delete this e-mail.
E-mail transmission cannot be guaranteed to be secure or error free as
information could be intercepted, corrupted lost, destroyed, arrive late or
incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message which arise as a result of e-mail
transmission. If verification is required please request a hard copy
K12OSN mailing list
K12OSN at redhat.com
For more info see <http://www.k12os.org>
More information about the K12OSN