[ale] New Twiki topic LinuxInGASchools

Charles Marcus CharlesM at Media-Brokers.com
Tue Aug 13 14:45:17 EDT 2002


> From: Jeff Hubbs [mailto:hbbs at attbi.com]
> Sent: Tuesday, August 13, 2002 1:49 PM
>
> 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.

OK, I'm not trying to be difficult, but it looks liek you are...

Should LTSP also check and see if you have a telnet server running and port
23 open?

How about having LTSP check your IP Tables and see if there are any security
issues there?

See my point?  I'm not trying to be rude, just trying to get you to see that
you are correct, but arguing apples/oranges.

There are a *lot* of things the implementer of *any* production Linux
environment must address, but that doesn't mean that each app must address
*all* of the separate issues.

Your original post suggested that the fact that KDE would allow any user to
reboot the server was an *LTSP* problem - all I did was point out that it
was indeed a problem, but a *KDE* problem *not* an LTSP problem.

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

And again, this is *not* an LTSP issue, it is a *KDE* issue.  The *only*
thing I was *ever* arguing was your assertion that somehow this was a
*failing* on the part of LTSP.  *IT* *IS* *NOT* !  That is all I'm saying.

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

This is getting ridiculous - yes, they *are* irrelevant - TO THE QUESTION -
as to whether or not they are the fault of LTSP.  They are *very* relevant
*to any production Server environment*.

This conversation got started because you made the statement that *LTSP* had
serious problems because *KDM* would allow any user to reboot.

Is this a serious issue?  Yes!  Is it an issue of LTSP? *NO!!!!!!*

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

This is probably the only paragraph I disagree with completely.  There is
absolutely no way for the LTSP developers to determine all of the possible
ways people mighht wanna use LTSP.  There are some things that are simply
the domain of the System Administrator, plain and simple.

What if you install LTSP and KDE hasn't been installed yet?  There are just
too many variables.

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

OK, well, lets talk semantics then.  Give me a break.  A *good* system
administrator *also* performs the functions of what you have just termed the
'System 'Designer'.

This conversation is getting more and more ridiculous.

All I wanted to point out was that a misconfigured KDM is *not* the fault of
LTSP.

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

As I have previoulsy stated, so whats your point?  Why do you insist on
taking something I say and twisting it around?  When I say "thus-n-such
configuration is preferred", you turn around and reply as if I said "You
MUST use thus-n-such".

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

Oh, I see!  You're one of those people who just like to argue for the sake
of arguing.  I was *agreeing* with you, dunderhead!  ;)  Though you snipped
the part where you said you would add RAM as your first priority.

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

Well, hopefully you catch them *before* they bought all those Dells - thats
the goal.  But if you don't, then you do what you can do.  What *else*
**can** you do?

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

No, but they may be able to see the advantage to spending a lot on one or
two servers and little to nothing on the workstations as opposed to buying
50 or 100 new workstations.

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

When did I ever suggest such an attitude??

> but other than that, what is there about LTSP that just
> pounds the drives??

I was, of course referring to large installations.  You get 50 or 100
students on one of these, and I guarantee you the drive speed will be a
factor - not as much as RAM, but it all adds up.

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

You say this as if there is something wrong with the profit motive?
*Everyone* operates on the profit motive, *all* of the time.

Regardless, what does that have to do with it?  Just because you spend a lot
on the server has nothing whatsoever to do with whether or not you mark it
up when you sell it to the school.

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

>> There are morons everywhere you go, no?

> There is no shortage of morons *everywhere.*

Careful - I could take that as an insult - or were you in fact calling me a
moron?  Trust me, you don't wanna open *that* can of worms.

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

Makes no difference - Win4Lin is not 'quasi-emulation' either.  It is real
Windows, running under Linux - it requires a Windows Full Install CD.

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

No kidding?  Look, *you* were the one insisting that 'Windows on the Clients
is inevitable' - now you turn it around and complain that my alternate
solution will still require licenses??

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

It wouldn't be you fighting them on it, it'd be the Win4Lin folks.

Look:  I agree with everything in the above paragraphs (except the one I
specifically disagreed with) - but none of it has anything to do with the
fact that you seem to think that the fact that KDE/KDM comes misconfigured
on some distros in its default configuration is somehow the fault of LTSP -
IT IS NOT.  PERIOD.  If you cannot understand this, then *you* are a moron
and I have nothing further to say on the subject.

Charles


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






More information about the Ale mailing list