[ale] New Twiki topic LinuxInGASchools

[Jeff Hubbs]

> OK, I guess I should have been more clear... sorry.
> 
> This is not even an LTSP issue, it is a KDE issue in the way your Distro
> installs KDE by default.  If you had taken the time to check it out, ALL
> user sessions were like this, whether local OR LTSP sessions.

You'll have to excuse me; I could only afford to spend so much time
pursuing LTSP environments as a personal exercise, but no additional
time would be needed to know that a local KDE request to reboot would
result in, yes, indeed, a reboot.  

> 
> Again, it is not even an LTSP issue, it is a DISTRO/KDE issue - and it is
> simple to fix.

It is still a large-acale system issue which LTSP does not address and
does not seek to.  The implementer of a production LTSP environment,
however, must.  

> 
> > My point was that LTSP takes a single-headed GUI desktop
> > system and makes it multi-headed, multi-user, etc.,
> 
> Uhhhhhhh --- huh?
> 
> *All* Linux systems are multi-user by their very nature.  Yes, you can have
> a 'Desktop Environment', but the system itself is still very multi-user.

I'm more than well aware of that.  However, the fact remains that
distros and their implementations of window managers allow ordinary
users to do very untoward things if one instead thinks of the machine
being used as a "session server" whose operation must be protected from
user-initiated impacts.  Automatic mounting/unmounting of CD-ROM drives
is an example; one must either block that capability or redirect it to
the user's own system.  Disk quotas would have to be enabled and
maintained lest some joker goes nuts and fills up /home or some such.

> 
> > 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.
> 
> No, but LTSP is not KDE.  these are two sompletely separate applications.
> You do *not* need KDE to run LTSP.  It works great with Gnome, or any of the
> other dozens of Window Managers out there.

I'm more than well aware of this, too.  However...

> All of your points are true, but irrelevant.  The issues you are discussing
> are SYSTEM issues, and have to be dealt with the the SYSTEM ADMINISTRATOR.

...my points are hardly irrelevant.  Any LTSP-like environment that is
going to actually be proposed as a solid, viable, secure, robust, and
REPLICABLE solution has to have every last one of these issues addressed
in its BASELINE configuration, NOT as an "I'll twiddle this and I'll
twiddle that" matter but as an "this has ALREADY been designed,
twiddled, and set up the way it needs to be for production use prior to
installation" matter.  Receiving a litany of showstopping issues from
end users and responding with "I can fix that, I'm the SYSTEM
ADMINISTRATOR...I can fix that, I'm the SYSTEM ADMINISTRATOR..." isn't
going to make a very good impression.  The person who does the design,
does the testing, finds the problems, implements the fixes, and releases
working, good, solid "re-distributions" is the SYSTEM DESIGNER. 


> 
<snip>

> A key here is to *not* let the Server ever hit swap - if it does, the system
> will slow to a crawl for *all* users - this is the downside to centralized
> serving (single point of failure).

You may not have a choice.  You may be working with what you can get.  

> 
> > 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.
> 
> Agreed again.  RAM and Disk speed are far more important than CPU/Processor
> speed, although these are cheap enough that I wouldn't use anything less
> than a 1GHZ unless I absolutely had to.

The amount of money often is not the issue - it's the time and effort it
takes to justify ANY procurement and wend it through the system.  Try to
explain to some school-district bean-counter why a county needs even ONE
more computer of ANY SORT when they just got through spending hundreds
of thousands of Dells or whatever two years before.  The distinction
between "client" and "server" may mean nothing at all to the people with
decision-making authority and they may not have the patience or the
mentality to even care.  If you can get 1GHz or better, great, but don't
just expect it or decide you're not going to go forward if you can't get
it.

> 
<snip>

> > 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.
> 
> This ignores the FACT that LTSP servers can and do hit the disk drive very
> hard.

Mine did not, once the user apps were launched.  Between apps that share
memory fairly nicely like Mozilla and enough RAM such that the kernel
would allow a fair amount of disk cache, disk activity was sporadic.  If
users run disk-intensive apps, then, yes, an LTSP server running those
apps will likewise be disk-intensive, but other than that, what is there
about LTSP that just pounds the drives??


> 
> > 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.

> > Um, I believe that is what I said above?  I said 'preferred', no?  In other
> words, you should always *try* to sell the customer on one or two very
> high-powered Servers with redundant Power Supplies, Dual CPU's, Dual NICs,
> 15000RPM SCSI RAID - then work your way *down* from there.  Explain it to
> them that this is the *ideal* server, then work within their budget.  The
> fact is, for the cost of 3 or 4 reasonably powered workststaions, you can
> have this kick-ass server that can handle a hundred or more Clients, if
> properly configured.

That makes sense if there's an underlying profit motive on the part of
the pitcher, but I didn't think that that was the case here.  What can I
say - I *did* miss the meeting, after all.  

> >>> 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.
> 
> There are morons everywhere you go, no?

There is no shortage of morons *everywhere.*  

> 
> >>> 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.
> 
> Win4Lin is *not* 'emulation'.  You are running a real Windows session.  The
> only drawback it has is it only supports Win9x currently, although my
> understanding is this is gonna change in the next year.

That's why I said "emulation or quasi-emulation."  Wine and VMware are
not OS emulators in a strict sense.  Still, this does put one in the
position of needing WinXX licenses and dealing with WinXX's inherent
problems in addition to all the OTHER software problems.  Furthermore,
I'm not fully satisfied that this kind of usage is in keeping with MS'
OS EULAs and I would frankly not want to fight them on it regardless of
how right I thought I was,




---
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.