FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Edubuntu User

 
 
LinkBack Thread Tools
 
Old 09-10-2008, 04:32 AM
"Robert Arkiletian"
 
Default New Direction for LTSP: Diskless Remote Boot

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@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
 
Old 09-10-2008, 07:57 AM
"David Van Assche"
 
Default New Direction for LTSP: Diskless Remote Boot

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:

https://help.ubuntu.com/community/UbuntuLTSP/LTSPFatClients

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@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@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
>

--
edubuntu-users mailing list
edubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
 
Old 09-10-2008, 09:48 AM
 
Default New Direction for LTSP: Diskless Remote Boot

Hello

There was a simular thread at debian-edu concluding with following
posting: <http://lists.debian.org/debian-edu/2007/07/msg00140.html>

In short: There are usecases for both technologies but for mixed
environments the LowFat client of LTSP is the less invasive approach.
For example when terminal server is established and there is a need for
more powerful clients (multimedia) or it would be a waste of server
power if better client hardware arises.


gerhard


Robert Arkiletian schrieb:
> 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.
>
>
>


--
edubuntu-users mailing list
edubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
 
Old 09-10-2008, 04:10 PM
"R. Scott Belford"
 
Default New Direction for LTSP: Diskless Remote Boot

On Tue, Sep 9, 2008 at 11:48 PM, <gerhard.oettl.ml@ogersoft.at> wrote:

Hello



There was a simular thread at debian-edu concluding with following

posting: <http://lists.debian.org/debian-edu/2007/07/msg00140.html>



In short: There are usecases for both technologies but for mixed

environments the LowFat client of LTSP is the less invasive approach.

For example when terminal server is established and there is a need for

more powerful clients (multimedia) or it would be a waste of server

power if better client hardware arises.
I agree with most of what Knut says.* Keep in mind, though, that his analysis of DRBL is 14 months old.* Software moves fast.* DRBL is a *great* solution for older hardware.* It is a great solution for newer hardware.* Install the most common linux distros, install DRBL, and you have thin client services.* The biggest problem with Edubuntu is its diminishing support for older hardware.* I can boot a 486 with DRBL.







gerhard
--scott

--
edubuntu-users mailing list
edubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
 
Old 09-11-2008, 05:22 AM
"Vu Nguyen"
 
Default New Direction for LTSP: Diskless Remote Boot

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@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@lists.ubuntu.com

Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users



--
edubuntu-users mailing list
edubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
 
Old 09-12-2008, 04:07 AM
"Krsnendu dasa"
 
Default New Direction for LTSP: Diskless Remote Boot

2008/9/11 R. Scott Belford <scott@hosef.org>

I agree with most of what Knut says.* Keep in mind, though, that his analysis of DRBL is 14 months old.* Software moves fast.* DRBL is a *great* solution for older hardware.* It is a great solution for newer hardware.* Install the most common linux distros, install DRBL, and you have thin client services.* The biggest problem with Edubuntu is its diminishing support for older hardware.* I can boot a 486 with DRBL.


What distros do you use for these low spec machines?

--
edubuntu-users mailing list
edubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
 

Thread Tools




All times are GMT. The time now is 11:46 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org