[ale] New Twiki topic LinuxInGASchools

[Jeff Hubbs]

Comments also in-line...

On Tue, 2002-08-13 at 08:28, Charles Marcus wrote:
> Comments in-line...
> 
> <snip>
> 
> > Yeah!  LTSP, if nothing else, can be used as a study case for a more
> > elegant solution or it can be implemented as-is with modifications; I
> > took a shot at getting LTSP to work (diskless P/90 client) and found
> > that any KDE user can shut down the server (a non-starter, for sure!).
> 
> This is trivial to fix, and not even worth mentioning...

That was but *one* serious security flaw I found - one that would kill
all user sessions at once but could even be triggered by accident by a
well-meaning user.  I didn't even *begin* to explore what others may be
in there.  My point was that LTSP takes a single-headed GUI desktop
system and makes it multi-headed, multi-user, etc., and due attention
must be paid to the fact that there are limits and restrictions that
have to be determined and enforced.  That's not as trivial as you appear
to be making it sound, and it's also not trivial to create and sustain
the kind of configuration control necessary to ensure that those
controls are in place and properly configured each and every time you
generate a server.


> > and the level of machinery on hand runs the gamut.  The sticking point
> > is going to be creating useful server hardware, but it's pretty clear
> > that the range of PCs that people are casting off for being
> > too slow for
> > use with Win2K and WinXP are the ones that begin to make good servers.
> 
> Maybe entry level servers, but if you want a server that can handle 30, 40,
> 50 or more clients, it will have to be much more powerful - as always,
> depending on what the clients will be running.

Yes - it will all depend on what you're trying to do.  I know that with
multiple instances of Mozilla running on one machine, that first
instance takes a big chunk of RAM but subsequent instances do not.  I
can't say that I've done this on an LTSP rig with 50 clients, no, but
what I have already observed on single machines and my one-client LTSP
rig suggests that with some apps, you may be able to bear a
counterintuitively large load on a piddly server.  Also, recall what I
said about the typically bursty CPU usage of desktop apps and how those
bursts from many different users can interleave with very little
perceptible collateral impact up until you start really having no idle
CPU time left.


> 
> If you want to be able to use these low powered servers, then we will have
> to become proficient with how to configure the Clients that are capable to
> run local apps, to relieve the load from the server.  The low-powered
> clients can run their apps on the server.

Sure, that can be pursued, but know that you're instituting an
additional "product line" for client machines with a configuration that
has to be maintained.  If you've got dozens of client machines and they
all have lots of RAM and fast disk, then it's worth considering to take
advantage of that.  But, as I've indicated before, would you be
relieving a server of load that it can actually bear without too much
strife?

> 
> > It's the server side - whether for LTSP or just file serving - where
> > things get tricky.
> 
> RAM and HD speed are the two most critical things on an LTSP server.
> 15000rpm SCSI drives and maxed memory are always preferred, but not always
> sellable to the Customer.

In this context, as long as I'm not counting on heavy, heavy disk I/O,
all I care about regarding disk is capacity and RAID.  I figure that one
may simply not have a CHOICE of even 10,000RPM drives; one may have to
simply work with what's available.  I feel more strongly about getting
as much RAM as possible; more RAM means less swap and that eases up on
the drive situation, whatever it happens to be.  

> 
> > Any and all infrastructure hardware MUST MUST MUST go on a
> > UPS.  THAT's
> > where the money that would go for MS licenses should go.
> 
> Goes without saying for *any* server installation.
> 

Well, you'd be surprised.  I've worked in places where the IT folks just
didn't believe in them.

> <snip>
> 
> > I feel that WinXX on the client side is inevitable.
> 
> I totally disagree.  Although you are correct that there are many apps that
> are available for WinXX that are not for Linux, this does *not* mean that we
> can't use Linux for the Clients.

Perhaps I should have said SOME WinXX on the client side is inevitable. 
I would tend not to push the issue because when new COTS software is
found by the user community to serve their needs, it is very likely to
be Win32 software.  Yes, you can decide to take on the emulation or
quasi-emulation concept every time, but you're likely to lose as much as
win, and the user community probably won't settle for that.  If
integration/infiltration of the status quo is desired, then WinXX and
Mac clients have to be presumed from the get-go with Linux clients
coming into play *when they can* without causing an ongoing sticking
point.  With Linux clients, your biggest problem area is going to be
accommodating new user requirements in both hardware (hey, I just got
this new cool WinScanner!) and software.

> 
> The best solution for this particular issue is the use of a
> Linux/Win4Lin/Tarantella server, which can then serve up Win9x sessions to
> the LTSP clients - even over a WAN.  It works *really* well - the Win4Lin
> guys will even let you connect to a Demo server to see it in action for
> yourself.  All you need is a browser that supports Java.

I'd like to see that; haven't yet.

> 
> Two things...
> 
> 1) For low-powered servers, be sure to *not* use a full Desktop
> environment - use something like icewm, which is extremely fast and stable
> and uses very little memory/resources.  KDE is nice, but a memory/resource
> hog, and will kill a low-powered server in a large environment, and

I have no objection here.  I have a dual P/133 here that is much more
usable with icewm and its ilk.


> 2) Rather than use the vanilla LTSP stuff, use the stuff from the guys who
> are pioneering the use of LTSP in schools already (why reinvent the
> wheel?)...
> 
> www.k12ltsp.org

Fair enough.


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.