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 11-08-2010, 07:34 PM
Robert Arkiletian
 
Default Life after LTSP

In my opinion, the days of LTSP are numbered. For a few different reasons.

1)
hardware is so cheap now. You can buy a brand new power efficient and
fast desktop system for about $200 (not including monitor). Thin
clients are actually *more* expensive now.

2)
programs like flash and java based apps don't work and will never work
well in an LTSP environment because they are multithreaded and utilize
all cores on the server. So no matter how powerful a server, running
many flash or java apps bring it to it's knees. Things were better
when all apps were single threaded. As time goes on this will only get
worse as cpu makers are increasing cores not mhz, so software makers
are adapting by making apps utilize all cores. Local apps is a
solution in the right direction but it brings with it other problems
like using fuse (ltspfs) and other issues. The other problem with
local apps, in an ltsp client, is that usually true thin client cpu's
are weak (eg. Atom). The concept of Local apps is 180 degrees to what
LTSP is about.

3)
Things get even worse when you run video full screen because the data
is being decoded (high cpu hit) at the server, then pushing *large*
decompressed data across the lan. It just doesn't scale well.

4)
If Ubuntu is successful with their move to Wayland display server
(away from X), LTSP may not even work as Wayland has no network
transparency as X does. Not sure if having X as a client itself on top
of Wayland will work with LTSP. My guess is it will be troublesome
because the client will need Wayland up first before X (which btw
means it will also definitely need an opengl capable video chipset+driver). I
suspect that unless the LTSP project goes back to the way they did
things in LTSP 4, where they pretty much managed and built the chroot
as a seperate distro, I think Wayland is going to break LTSP with the
Muekow (LTSP5) way of doing things.

http://www.markshuttleworth.com/archives/date/2010/11
http://wayland.freedesktop.org/http://wayland.freedesktop.org/

So what do we do? Personally, I think there are at least a couple solutions.

1)
Spice. The new remote VM technology that is in Fedora 14 and RHEL6.
The management gui needs to get better in Fedora, but that's coming.
Server requirements will be higher than ltsp as each desktop will have
a VM running (not just a desktop and apps). But advantage will be
complete customization per client and heterogeneous (windows+linux)
environments ( at the expense of ease of administration, unless there
are nice gui tools to manage multiple vm's simultaneously )

2)
DRBL. This is the route I have taken. It's similar to ltsp boot
process via pxe but ALL processes run locally. Only the filesystem is
remote via nfs. There is no need for special plumbing for sound or
local devices. Everything works like a stand alone system. Except the
first time to launch (not run) apps is slightly longer since the
binary needs to be downloaded into local ram from the network before
it can be run. One user can't hog ram or cpu. Full class of full
screen video and flash, no problem. I even have had an entire class of
students simultaneously install and run Ubuntu in a Virtualbox VM on
top of the diskless client OS. Local apps with LTSP cannot do this.
Although I do have dual gigabit nics for the lan and hardware raid 10
for the server. Each client can have it's own nfs mounted /etc and
/var so there can still be customization per client.

--
Robert Arkiletian
Eric Hamber Secondary, Vancouver, Canada

--
edubuntu-users mailing list
edubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
 
Old 11-08-2010, 07:44 PM
Robert Arkiletian
 
Default Life after LTSP

On Mon, Nov 8, 2010 at 12:34 PM, Robert Arkiletian <robark@gmail.com> wrote:
> In my opinion, *the days of LTSP are numbered. For a few different reasons.
>
> 1)
> hardware is so cheap now. You can buy a brand new power efficient and
> fast *desktop system for about $200 (not including monitor). *Thin

Forgot to mention I mean a *diskless* desktop system.

>
> 2)
> DRBL. This is the route I have taken. It's similar to ltsp boot
> process via pxe but ALL processes run locally. Only the filesystem is
> remote via nfs. There is no need for special plumbing for sound or
> local devices. Everything works like a stand alone system. Except the
> first time to launch (not run) apps is slightly longer since the
> binary needs to be downloaded into local ram from the network before
> it can be run. One user can't hog ram or cpu. Full class of full
> screen video and flash, no problem. I even have had an entire class of
> students simultaneously install and run Ubuntu in a Virtualbox VM on
> top of *the diskless client OS. Local apps with LTSP cannot do this.
> Although I do have dual gigabit nics for the lan and hardware raid 10
> for the server. Each client can have it's own nfs mounted /etc and
> /var so there can still be customization per client.

Plus you get the benefit of managing only one system, like LTSP.


--
Robert Arkiletian
Eric Hamber Secondary, Vancouver, Canada

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

Mon Nov 8 22:30:02 2010
Return-path: <gentoo-dev+bounces-43375-tom=linux-archive.org@lists.gentoo.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Mon, 08 Nov 2010 21:47:36 +0200
Received: from pigeon.gentoo.org ([208.92.234.80]:39300 helo=lists.gentoo.org)
by s2.java-tips.org with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.69)
(envelope-from <gentoo-dev+bounces-43375-tom=linux-archive.org@lists.gentoo.org>)
id 1PFXgm-0003G5-9Q
for tom@linux-archive.org; Mon, 08 Nov 2010 21:47:36 +0200
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 76D291C1C8;
Mon, 8 Nov 2010 20:45:09 +0000 (UTC)
X-Original-To: gentoo-dev@lists.gentoo.org
Delivered-To: gentoo-dev@lists.gentoo.org
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id C34C71C19F
for <gentoo-dev@lists.gentoo.org>; Mon, 8 Nov 2010 20:43:50 +0000 (UTC)
Received: from [192.168.178.58] (e178104015.adsl.alicedsl.de [85.178.104.15])
(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
(No client certificate requested)
by smtp.gentoo.org (Postfix) with ESMTPSA id E59AA1B40A8
for <gentoo-dev@lists.gentoo.org>; Mon, 8 Nov 2010 20:43:47 +0000 (UTC)
Message-ID: <4CD860EE.3090808@gentoo.org>
Date: Mon, 08 Nov 2010 21:43:26 +0100
From: =?UTF-8?B?Q2jDrS1UaGFuaCBDaHJpc3RvcGhlciBOZ3V54buFbg==? <chithanh@gentoo.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101030 Gentoo/2.0.10 SeaMonkey/2.0.10
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] mercurial.eclass: change clone destination
References: <4CD51E71.3020308@gentoo.org> <4CD6BACB.7080603@gentoo.org> <20101108041756.GB632@comet>
In-Reply-To: <20101108041756.GB632@comet>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Donnie Berkholz schrieb:
> On 16:42 Sun 07 Nov , Petteri Räty wrote:
>
>> On 11/06/2010 11:22 AM, Krzysztof Pawlik wrote:
>>
>>> Hello,
>>>
>>> I'm sending this patch for discussion, what it changes? The change is to where
>>> the final clone of repository will be placed, it used to be ${WORKDIR}/${module}
>>> (where module usually is the last component of source URI) to ${WORKDIR}/${P}
>>> (essentially ${S}). This has few effects:
>>> - ebuilds using mercurial.eclass don't need to set S any longer
>>> - mercurial.eclass behaves more like git.eclass
>>> - it breaks all existing ebuilds using this eclass
>>>
>> Which means that the doing the chance is not allowed as eclasses must
>> remain backwards compatible.
>>
> Is that really still the case now that full environments have been saved
> for a number of years? Clearly breaking things is unacceptable, but I
> could envision someone simultaneously updating the eclass and all
> consumers.
>

What you maybe could do is wait for a new EAPI to show up, and give all
users of the new EAPI the new eclass behaviour. That way, existing
ebuilds would not break. The old EAPI support could be deprecated and
removed after a reasonable amount of time has passed.


Best regards,
Ch*-Thanh Christopher Nguy?n
 
Old 11-08-2010, 07:52 PM
Belinda Lopez
 
Default Life after LTSP

You would be surprised how many requests for thin-client type systems
I'm seeing on the horizon. Thin-clients are a very viable solution for
both developed and developing countries. In developed countries it's an
easy way to implement a campus wide computing solution at a low cost.
In developing countries you simply do not have the infrastructure to
support full desktop solutions; think electricity and network savings.
And now with all this "cloud" marketing, there is a renewed effort by
many companies to offer thin-clients with all the storage in the cloud
(google docs anyone). LTSP is just one of many thin-client solutions.

cheers,

Belinda

Education
Canonical
belinda.lopez@canonical.com
dinda@ubuntu.com
IRC: dinda
Office: Galveston, Texas
--
Ubuntu - Linux for Human Beings
http://www.ubuntu.com
http://www.edubuntu.org
http://www.canonical.com
---------------------------




On 11/08/2010 02:44 PM, Robert Arkiletian wrote:
> On Mon, Nov 8, 2010 at 12:34 PM, Robert Arkiletian<robark@gmail.com> wrote:
>
>> In my opinion, the days of LTSP are numbered. For a few different reasons.
>>
>> 1)
>> hardware is so cheap now. You can buy a brand new power efficient and
>> fast desktop system for about $200 (not including monitor). Thin
>>
> Forgot to mention I mean a *diskless* desktop system.
>
>
>> 2)
>> DRBL. This is the route I have taken. It's similar to ltsp boot
>> process via pxe but ALL processes run locally. Only the filesystem is
>> remote via nfs. There is no need for special plumbing for sound or
>> local devices. Everything works like a stand alone system. Except the
>> first time to launch (not run) apps is slightly longer since the
>> binary needs to be downloaded into local ram from the network before
>> it can be run. One user can't hog ram or cpu. Full class of full
>> screen video and flash, no problem. I even have had an entire class of
>> students simultaneously install and run Ubuntu in a Virtualbox VM on
>> top of the diskless client OS. Local apps with LTSP cannot do this.
>> Although I do have dual gigabit nics for the lan and hardware raid 10
>> for the server. Each client can have it's own nfs mounted /etc and
>> /var so there can still be customization per client.
>>
> Plus you get the benefit of managing only one system, like LTSP.
>
>
>


--
edubuntu-users mailing list
edubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
 
Old 11-08-2010, 09:55 PM
Jordan Erickson
 
Default Life after LTSP

Robert,

I agree with you on your points, but I think you're missing a couple of
things in regard to the bigger picture -

1) Thin clients run at 8-30W of power. Your version of a "power
efficient and fast desktop system" will consume much more than the
average thin client, even if the box says "green" all over it.

2) Flash and Java honestly aren't LTSP's problem. The LTSP devs have
done an AMAZING job at trying to accomidate these types of issues with
proprietary/power hungry softwares, but the fact of the matter is, just
because Flash and/or Java doesn't perform perfectly all the time under
LTSP doesn't mean LTSP isn't a viable solution (Maybe not for your
specific setup though?). Quite the contrary, maybe we should be putting
more pressure on Adobe/Oracle if we want these things to work better as
well? (And on a personal side-rant, Flash is horribly resource intensive
on a standalone workstation, so it really has little to do with LTSP as
a technology - It eats up plenty of CPU on my home PC).

3) Not sure what kind of scenario you mean by scaling full-screen video.
I can run a bluray fullscreen to my LTSP client (not a localapp) with no
lag. Of course that *is* one station and not 50 - but put together some
multicasting magic and I don't see how it could really be a problem, at
least for playing a single video at the same time. If you need to do
many separate videos fullscreen at the same time, a simple
vlc/totem/mplayer localapp will fix that problem straight away. If
you're talking about flash, see #2.

4) Ubuntu != LTSP... Enough said? =)


Just my $0.02!


Cheers,
Jordan


Robert Arkiletian wrote:
> In my opinion, the days of LTSP are numbered. For a few different reasons.
>
> 1)
> hardware is so cheap now. You can buy a brand new power efficient and
> fast desktop system for about $200 (not including monitor). Thin
> clients are actually *more* expensive now.
>
> 2)
> programs like flash and java based apps don't work and will never work
> well in an LTSP environment because they are multithreaded and utilize
> all cores on the server. So no matter how powerful a server, running
> many flash or java apps bring it to it's knees. Things were better
> when all apps were single threaded. As time goes on this will only get
> worse as cpu makers are increasing cores not mhz, so software makers
> are adapting by making apps utilize all cores. Local apps is a
> solution in the right direction but it brings with it other problems
> like using fuse (ltspfs) and other issues. The other problem with
> local apps, in an ltsp client, is that usually true thin client cpu's
> are weak (eg. Atom). The concept of Local apps is 180 degrees to what
> LTSP is about.
>
> 3)
> Things get even worse when you run video full screen because the data
> is being decoded (high cpu hit) at the server, then pushing *large*
> decompressed data across the lan. It just doesn't scale well.
>
> 4)
> If Ubuntu is successful with their move to Wayland display server
> (away from X), LTSP may not even work as Wayland has no network
> transparency as X does. Not sure if having X as a client itself on top
> of Wayland will work with LTSP. My guess is it will be troublesome
> because the client will need Wayland up first before X (which btw
> means it will also definitely need an opengl capable video chipset+driver). I
> suspect that unless the LTSP project goes back to the way they did
> things in LTSP 4, where they pretty much managed and built the chroot
> as a seperate distro, I think Wayland is going to break LTSP with the
> Muekow (LTSP5) way of doing things.
>
> http://www.markshuttleworth.com/archives/date/2010/11
> http://wayland.freedesktop.org/http://wayland.freedesktop.org/
>
> So what do we do? Personally, I think there are at least a couple solutions.
>
> 1)
> Spice. The new remote VM technology that is in Fedora 14 and RHEL6.
> The management gui needs to get better in Fedora, but that's coming.
> Server requirements will be higher than ltsp as each desktop will have
> a VM running (not just a desktop and apps). But advantage will be
> complete customization per client and heterogeneous (windows+linux)
> environments ( at the expense of ease of administration, unless there
> are nice gui tools to manage multiple vm's simultaneously )
>
> 2)
> DRBL. This is the route I have taken. It's similar to ltsp boot
> process via pxe but ALL processes run locally. Only the filesystem is
> remote via nfs. There is no need for special plumbing for sound or
> local devices. Everything works like a stand alone system. Except the
> first time to launch (not run) apps is slightly longer since the
> binary needs to be downloaded into local ram from the network before
> it can be run. One user can't hog ram or cpu. Full class of full
> screen video and flash, no problem. I even have had an entire class of
> students simultaneously install and run Ubuntu in a Virtualbox VM on
> top of the diskless client OS. Local apps with LTSP cannot do this.
> Although I do have dual gigabit nics for the lan and hardware raid 10
> for the server. Each client can have it's own nfs mounted /etc and
> /var so there can still be customization per client.
>
>



--
edubuntu-users mailing list
edubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
 
Old 11-08-2010, 10:10 PM
Lee Harr
 
Default Life after LTSP

> In my opinion, the days of LTSP are numbered. For a few different reasons.

I've been using LTSP for years with great success
in my small lab, but I have been eyeing a system
like this for a while:

http://www.userful.com/

(It's a single computer with multiple video cards,
multiple keyboards, multiple mice, etc)

Anyone have any experience with that?



--
edubuntu-users mailing list
edubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
 
Old 11-09-2010, 12:45 AM
Robert Arkiletian
 
Default Life after LTSP

On Mon, Nov 8, 2010 at 2:55 PM, Jordan Erickson
<jerickson@logicalnetworking.net> wrote:
> Robert,
>
> I agree with you on your points, but I think you're missing a couple of
> things in regard to the bigger picture -
>
> 1) Thin clients run at 8-30W of power. Your version of a "power
> efficient and fast desktop system" will consume much more than the
> average thin client, even if the box says "green" all over it.
>

Hi Jordan,

I think you are correct and this is a valid point. The cost of
electricity is important. This is something I would like to definitely
investigate further. I have a kill-a-watt device I will take to work
tomorrow. My clients are Dell Optiplex 760 with Intel Celeron E1400
(dual core 2.0 Ghz Allendale cores) with Intel Q43 chipset ( X4500
video chip). I will measure power consumption at the login prompt
(*not* including monitor) and post back. But I'm wondering if someone
with a true thin client system (Dual core Atom) can do the same and
post back.


> 2) Flash and Java honestly aren't LTSP's problem. The LTSP devs have
> done an AMAZING job at trying to accomidate these types of issues with
> proprietary/power hungry softwares, but the fact of the matter is, just
> because Flash and/or Java doesn't perform perfectly all the time under
> LTSP doesn't mean LTSP isn't a viable solution (Maybe not for your
> specific setup though?). Quite the contrary, maybe we should be putting
> more pressure on Adobe/Oracle if we want these things to work better as
> well? (And on a personal side-rant, Flash is horribly resource intensive
> on a standalone workstation, so it really has little to do with LTSP as
> a technology - It eats up plenty of CPU on my home PC).

Agreed. I hope flash dies. With html5/webm on Youtube and Steve Jobs
boycotting flash for mobile gizmos, it's already happening.

>
> 3) Not sure what kind of scenario you mean by scaling full-screen video.
> I can run a bluray fullscreen to my LTSP client (not a localapp) with no
> lag. Of course that *is* one station and not 50 - but put together some
> multicasting magic and I don't see how it could really be a problem, at
> least for playing a single video at the same time. If you need to do
> many separate videos fullscreen at the same time, a simple
> vlc/totem/mplayer localapp will fix that problem straight away. If
> you're talking about flash, see #2.

Multicasting. Always wanted to play with that.

--
Robert Arkiletian
Eric Hamber Secondary, Vancouver, Canada

--
edubuntu-users mailing list
edubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
 
Old 11-09-2010, 07:01 AM
"Odin Nsen"
 
Default Life after LTSP

I agree with Robert. We had 800 LTSP clients at our school, and are now moving them over
to DRBL. But we are going to do both systems for a while. DRBL is good for the "new"
used machines with >1GB RAM and >P4 1Ghz CPU. We can also use "old" used machines from
the local companies with LTSP that they give to the school. The users are aware of the
difference between LTSP and DRBL - and they can see what kind of machine it is.

> hardware is so cheap now. You can buy a brand new power efficient and
> fast desktop system for about $200 (not including monitor). Thin
> clients are actually *more* expensive now.

In Norway the situation is a bit different. A new machine costs about $500 (without
monitor) - so we use "used" machines that costs about $130. They are good enough for
DRBL, and overkill for LTSP.

> 2)
> programs like flash and java based apps don't work and will never work
> well in an LTSP environment because they are multithreaded and utilize

This is one of the main reasons to use DRBL. We never got localapps to work as good as
we wanted.

> 3)
> Things get even worse when you run video full screen because the data
> is being decoded (high cpu hit) at the server, then pushing *large*
> decompressed data across the lan. It just doesn't scale well.

Go DRBL! :-)

The main bottleneck with DRBL is that some of the old clients only have 100Mb nics. We
try to swap it with a 1Gb nic - or by clients with Gb nics.

> Although I do have dual gigabit nics for the lan and hardware raid 10
> for the server. Each client can have it's own nfs mounted /etc and
> /var so there can still be customization per client.

We have good experiences with SSD-disks (and double/tripple GB-nics) - we don't need
large disks and /home rests at the rather large file servers (not the DRBL-servers).



Odin

--
edubuntu-users mailing list
edubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
 
Old 11-09-2010, 01:30 PM
"Jonathan Carter (highvoltage)"
 
Default Life after LTSP

Hi Robert

On 08/11/2010 15:34, Robert Arkiletian wrote:
> In my opinion, the days of LTSP are numbered. For a few different reasons.
>
> 1)
> hardware is so cheap now. You can buy a brand new power efficient and
> fast desktop system for about $200 (not including monitor). Thin
> clients are actually *more* expensive now.
>
> 2)
> programs like flash and java based apps don't work and will never work
> well in an LTSP environment because they are multithreaded and utilize
> all cores on the server. So no matter how powerful a server, running
> many flash or java apps bring it to it's knees. Things were better
> when all apps were single threaded. As time goes on this will only get
> worse as cpu makers are increasing cores not mhz, so software makers
> are adapting by making apps utilize all cores. Local apps is a
> solution in the right direction but it brings with it other problems
> like using fuse (ltspfs) and other issues. The other problem with
> local apps, in an ltsp client, is that usually true thin client cpu's
> are weak (eg. Atom). The concept of Local apps is 180 degrees to what
> LTSP is about.

I use Flash and Java as local apps and they work quite well, even though
it's just an Atom. I guess it also depends on your definition of "what
LTSP is about". I doubt you'll get lots of people to agree on that. For
some it's about cost cutting, for some it's about ease of administration
and for some it about the sheer speed you can set up an environment up
in... and probably a lot more reasons that I can't think of right now.
IMHO it's perfectly valid to provide a solution for people who have very
powerful thin clients, too.

> 3)
> Things get even worse when you run video full screen because the data
> is being decoded (high cpu hit) at the server, then pushing *large*
> decompressed data across the lan. It just doesn't scale well.

Indeed! You don't want to do full screen video on pure thin clients.

> 4)
> If Ubuntu is successful with their move to Wayland display server
> (away from X), LTSP may not even work as Wayland has no network
> transparency as X does. Not sure if having X as a client itself on top
> of Wayland will work with LTSP. My guess is it will be troublesome
> because the client will need Wayland up first before X (which btw
> means it will also definitely need an opengl capable video chipset+driver). I
> suspect that unless the LTSP project goes back to the way they did
> things in LTSP 4, where they pretty much managed and built the chroot
> as a seperate distro, I think Wayland is going to break LTSP with the
> Muekow (LTSP5) way of doing things.
>
> http://www.markshuttleworth.com/archives/date/2010/11
> http://wayland.freedesktop.org/http://wayland.freedesktop.org/
>
> So what do we do? Personally, I think there are at least a couple solutions.

Even if the chroot uses another distribution, there will still be
problems caused on the server side, ie. applications that don't use X at
all any more. I'm quite sure that this will trigger some LTSP
re-thinking indeed.

> 1)
> Spice. The new remote VM technology that is in Fedora 14 and RHEL6.
> The management gui needs to get better in Fedora, but that's coming.
> Server requirements will be higher than ltsp as each desktop will have
> a VM running (not just a desktop and apps). But advantage will be
> complete customization per client and heterogeneous (windows+linux)
> environments ( at the expense of ease of administration, unless there
> are nice gui tools to manage multiple vm's simultaneously )
>
> 2)
> DRBL. This is the route I have taken. It's similar to ltsp boot
> process via pxe but ALL processes run locally. Only the filesystem is
> remote via nfs. There is no need for special plumbing for sound or
> local devices. Everything works like a stand alone system. Except the
> first time to launch (not run) apps is slightly longer since the
> binary needs to be downloaded into local ram from the network before
> it can be run. One user can't hog ram or cpu. Full class of full
> screen video and flash, no problem. I even have had an entire class of
> students simultaneously install and run Ubuntu in a Virtualbox VM on
> top of the diskless client OS. Local apps with LTSP cannot do this.
> Although I do have dual gigabit nics for the lan and hardware raid 10
> for the server. Each client can have it's own nfs mounted /etc and
> /var so there can still be customization per client.

LTSP can actually do that. If you use the fat client desktop options
when building a chroot, you can have all your apps running locally just
like you would on DRBL. I've ran VirtualBox under LTSP Fat clients
running Windows XP in a computer lab and it worked just fine.

Either way, cheap devices are certainly going to change things
eventually. Everyone's walking with more and more powerful computers in
their pockets. All that they might need is a bigger keyboard and screen
to connect to in their classrooms.

I think it will cause a whole bunch of new challenges for schools and
software companies. How are commercial educational products going to be
licensed? Per school? Will students have to buy it theirselves? How will
software be managed and deployed? I know that I certainly wouldn't want
to give my school (if I had one) root access to my device to do stuff on
it without me knowing about it. My guess is that in a few years from
now, students will do most of their work on web enabled devices that
connect to their school's web services. I'm probably stating the obvious
with that, since it's already happening in many schools, but even then I
think there'll be some use for some desktops running in a diskless
environment.

My 2c

-Jonathan


--
edubuntu-users mailing list
edubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
 
Old 11-09-2010, 10:09 PM
Robert Arkiletian
 
Default Life after LTSP

On Mon, Nov 8, 2010 at 5:45 PM, Robert Arkiletian <robark@gmail.com> wrote:
> On Mon, Nov 8, 2010 at 2:55 PM, Jordan Erickson
> <jerickson@logicalnetworking.net> wrote:
>> Robert,
>>
>> I agree with you on your points, but I think you're missing a couple of
>> things in regard to the bigger picture -
>>
>> 1) Thin clients run at 8-30W of power. Your version of a "power
>> efficient and fast desktop system" will consume much more than the
>> average thin client, even if the box says "green" all over it.
>>
>
> Hi Jordan,
>
> I think you are correct and this is a valid point. The cost of
> electricity is important. This is something I would like to definitely
> investigate further. I have a kill-a-watt device I will take to work
> tomorrow. *My clients are Dell Optiplex 760 with Intel Celeron E1400
> (dual core 2.0 Ghz Allendale cores) with Intel Q43 chipset ( X4500
> video chip). I will measure power consumption at the login prompt
> (*not* including monitor) and post back. But I'm wondering if someone
> with a *true thin client system (Dual core Atom) can do the same and
> post back.
>

Got some numbers from my kill-a-watt meter:

Dell Optiplex 760 (running DRBL client)
e1400 dual core Celeron (Allendale 65nm) 2.0Ghz
Q43 Intel chipset
2 GB ram

gnome desktop + FF(google.ca) = 45W
gnome desktop + FF(youtube 720p fullscreen) = 60-65W (fluctuates)

A real dual core Atom thin client running LTSP ~ 19W
(I don't have an Atom based thin client to test. This is from some
googling ymmv)

Assume average usage is 49W for the Dell over a work day.

49-19= 30W difference (omitting monitor)

30W * 8hrs/day * 190 work days/school year = 45.6 KWh for 1 system/year

Assume a large school has 180 systems.

180 systems * 45.6 KWh/system/year = 8208 KWh/year for 1 school

At $0.08/KWh for electricity for public sector K-12 schools (this
varies where you live)
(see http://www.eia.doe.gov/electricity/epm/table5_6_a.html)

8208 KWh/year * $0.08/KWh = $656.64 / year/ school savings using fat
diskless vs thin client

Oh course this will vary depending on your own systems but it gives a
ball park. If a district has say 15 schools of this size that's almost
$10,000 savings per year for a district. But that's assuming you have
100% homogeneous systems (rarely the case).

If I have made any errors or omissions please correct me.


--
Robert Arkiletian
Eric Hamber Secondary, Vancouver, Canada

--
edubuntu-users mailing list
edubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
 
Old 11-11-2010, 05:44 PM
Robert Arkiletian
 
Default Life after LTSP

On Tue, Nov 9, 2010 at 6:30 AM, Jonathan Carter (highvoltage)
<jonathan@ubuntu.com> wrote:
>
> Either way, cheap devices are certainly going to change things
> eventually. Everyone's walking with more and more powerful computers in
> their pockets. All that they might need is a bigger keyboard and screen
> to connect to in their classrooms.
>
> I think it will cause a whole bunch of new challenges for schools and
> software companies. How are commercial educational products going to be
> licensed? Per school? Will students have to buy it theirselves? How will
> software be managed and deployed? I know that I certainly wouldn't want
> to give my school (if I had one) root access to my device to do stuff on
> it without me knowing about it. My guess is that in a few years from
> now, students will do most of their work on web enabled devices that
> connect to their school's web services. I'm probably stating the obvious
> with that, since it's already happening in many schools, but even then I
> think there'll be some use for some desktops running in a diskless
> environment.

Hi Jonathan,

I think you hit the nail on the head. Things are changing. I've been
a high school teacher for 14 years. Recently, I've been seeing more
and more students coming to school with their own laptops. This
transition to students having their own mobile devices has already
happened in colleges/universities.

Currently, the big push at the secondary level is getting wireless
access to the entire school. Focus is slowly shifting away from
traditional computer lab infrastructure to one where kids bring their
own mobile device (or maybe the school provides one). It brings up the
question: what about kids that can't afford their own laptops? Also,
who manages these systems? They don't belong to the school. We can't
touch them. About the only thing we can do is have a terms of use
agreement pop up when they connect and ask them to agree (maybe
register their name with their mac address) but that's about it.

Right now if an english teacher wants his/her students to access the
web they need to book a computer lab to use for that period. I don't
think that's going to be the case in the future. I remember when no
students had cell phones, now almost all do.

This also brings up the possibility of introducing ebooks. Publishers
of textbooks are already seeing this demand from post secondary
institutions. No more giant backpacks full of textbooks. In addition,
imagine instead of photocopying a handout for all students a teacher
just posts the handout to a website which all students access
instantly. Photocopying costs at my school are huge.

--
Robert Arkiletian
Eric Hamber Secondary, Vancouver, Canada

--
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:49 PM.

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