[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] A New direction for LTSP: Diskless Remote Boot



I just wanted to add my voice to what Doug said here.

It was specifically because I could use the currently existing (and at
the time, very old) hardware without any investment other than burning
a couple of CDs and my time educating myself about LTSP that I was
able to, very quickly, bring life to a old, dead, computer lab.  I
know I would have never been able to receive the approval for even
$100 to try out this new 'Linux' thing. I would have been told "why
waste the money -- just put it into Windows."  It was because I was
able to do it at no cost, that the funding was approved for the $2000
server (5 years ago) for LTSP.  And this lab still runs now, with old
hardware, and not in a developing world, but in Canada at a non-profit
organization serving the kids.

I would urge you not to forget about that large user-base in a similar
situation who's first introduction into this brilliant solution comes
from the no-barrier entry fee.

Thanks
Joseph



On Wed, Sep 10, 2008 at 8:56 AM, Doug Simpson
<simpsond leopards k12 ar us> wrote:
> HEAR! HEAR!
>
> 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
>
> Doug
>
> Doug Simpson
> Technology Specialist
> De Queen Public Schools
> De Queen, AR
> simpsond leopards k12 ar us
> "A Dollar Saved is a Dollar Earned"
>
>
>>>> Rob Owens <rob owens 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
> experiment".
>
> 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.
>
> -Rob
>
> 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.
>>
>> 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.
>>
> ********************************************************
>
> 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
> version.
>
> ********************************************************
>
>
> _______________________________________________
> K12OSN mailing list
> K12OSN redhat com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
>
> _______________________________________________
> K12OSN mailing list
> K12OSN redhat com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]