Linux-Advocacy Digest #358, Volume #28 Fri, 11 Aug 00 23:13:04 EDT
Contents:
Re: Linux = Yet Another Unix (R.E.Ballard ( Rex Ballard ))
Re: Anonymous Wintrolls and Authentic Linvocates - Re: R.E. Ballard says
Linux growth stagnating (Christopher Browne)
Re: Anonymous Wintrolls and Authentic Linvocates - Re: R.E. Ballard says
Linux growth stagnating (Christopher Browne)
Re: Windows stability: Alternate shells? (Leslie Mikesell)
GUI-Kernel Integration or Lack Thereof (Christopher Browne)
kernel httpd (Christopher Browne)
----------------------------------------------------------------------------
From: R.E.Ballard ( Rex Ballard ) <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.alpha
Subject: Re: Linux = Yet Another Unix
Date: Sat, 12 Aug 2000 01:50:08 GMT
> [EMAIL PROTECTED] says...
> > Saul Goldblatt <[EMAIL PROTECTED]> wrote:
> >
>
> Oh I hear from them every day. They are
> ones that are trying to run Lotus
> Notes under Wine and it fucks up every time.
Sounds like you need to either upgrade to Domino and support
SMTP forwarding, put up an internal SMTP gateway for Linux
users, or start suggesting VMWare. I've seen all three solutions
work quite well. I've also seen some companies put users on a
domino/web front-end that gives them access to the Lotus databases
from a web browser.
> My phone lights up every
> morning with these yo-yo's trying to run Linux.
And you said nobody run's Linux :-).
Call IBM/Lotus. Maybe they can give you some solutions :-).
> > And "flooding the entire network with packets" requires
> > the user to go out
> > of his/her/its way to screw up.
>
> No it doesn't. All it requires is for
> them to install Linux with default values.
Actually, this is absolutely true. The default values will
essentially force Linux to put all packets into the local interface.
The bottom line is that you really wouldn't want someone who is
self-installing to ignore the reccomendations posted practically
everywhere that say "check with your network administrator".
You can used DHCP to get an IP address, netmask, and gateway,
but you need to know a REAL DNS server.
Essentially, the defaults are deliberately set up to force the
user to get help if he needs it, and to make such a fuss that
the administrator will provide help even if the user didn't ask
for it.
Better to have red lights go off in your ethernet switch than to
have your gateway shut down as a suspected denial of service
attacker.
An installer who knows what they are doing will check for the DNS
of an existing machine. Someone who just want's to "follow the prompts
and used the defaults" (many installs have the option of selecting
"use all defaults") to avoid all those extra questions. If you use
this, you're supposed to have a defaults file or floppy that sets
defaults to appropriate values -- Just like NT and 95 have.
--
Rex Ballard - I/T Architect, MIS Director
Linux Advocate, Internet Pioneer
http://www.open4success.com
Linux - 42 million satisfied users worldwide
and growing at over 5%/month! (recalibrated 8/2/00)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: Anonymous Wintrolls and Authentic Linvocates - Re: R.E. Ballard
says Linux growth stagnating
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Aug 2000 01:59:49 GMT
Centuries ago, Nostradamus foresaw a time when Christopher Smith would say:
>
>"Nathaniel Jay Lee" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> There was a time when NT was criticized heavily for 'integrating' the
>> GUI into the kernel itself because of the possibility that it would
>> de-stabilize the system. Unfortunately, the same people that criticized
>> it then are now clamouring for Linux to do the same thing because of
>> 'how well it works on Windows'. Frankly, if that's their idea of
>> something working *well*, I'd just as soon they used what they consider
>> to work well and leave Linux alone.
>
>The GUI isn't "integrated" into the kernel. It just runs in ring 0 with the
>kernel. *Big* difference.
>
>It was done for performance reasons - much like the kernel mode NFS
>and http daemons for Linux. In a workstation, it's a valid tradeoff,
>since graphics speed is important. In a server it's not necessary,
>but as long as you just stick with the standard VGA driver (which you
>should always do) the chances of it causing problems hover slightly
>above zero.
One of the legitimate criticisms of X _is_ that "doing _anything_
requires multiple context switches;" unfortunately, moving graphics
into the kernel only eliminates _some_ of those context switches.
If display requests are grouped together so that multiple things cross
the process boundary at once, it doesn't _too_ much matter if there's
an extra context switch to go, thus:
User Process -----> Kernel -----> X Server
rather than...
User Process -----> Kernel -> X In Kernel
The situation with NFS and httpd is _somewhat_ different; both
represent vastly simpler subsystems that thus don't pull _nearly_ as
much complexity into the kernel.
On the other hand...
... I refuse to use knfs, as it is _decidedly_ less stable than
user-mode NFS. I had a system hang three times last year due to
problems with knfs and was entirely unhappy with that.
... I doubt that many people will use khttpd; it doesn't support
things like CGI, and really only benefits people if they're running
_seriously_ high volume servers.
The only way further such services should _realistically_ be permitted
to head into the kernel would be if there was some reasonably serious
set of "design by contract" analysis tools to validate in automatic
fashion (none of this mere "looks good, it's going in") a goodly
degree of correctness in an Eiffel-like manner.
--
(concatenate 'string "cbbrowne" "@" "acm.org")
<http://www.hex.net/~cbbrowne/linux.html>
Rules of the Evil Overlord #175. "I will have my fortress exorcized
regularly. Although ghosts in the dungeon provide an appropriate
atmosphere, they tend to provide valuable information once placated."
<http://www.eviloverlord.com/>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: Anonymous Wintrolls and Authentic Linvocates - Re: R.E. Ballard
says Linux growth stagnating
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Aug 2000 01:59:54 GMT
Centuries ago, Nostradamus foresaw a time when Donovan Rebbechi would say:
>On Fri, 11 Aug 2000 08:29:57 -0500, Nathaniel Jay Lee wrote:
>>This is the stuff I find scary. I don't mind the idea of 'modularizing'
>>the graphical interface into the kernel (as I believe some of the early
>>efforts are underway to do so), just don't make it something that is
>>*forced* on me.
>
>This brings back memories of the dreaded kernel NFS server. <shudder>
I had dreadful enough experiences that _I_ want nothing to do with it.
It seems to me to be one good reason to compile your own kernel so as
to make sure you don't have any spurious things that RHAT or SuSE
decided they thought you should have compiled in...
--
(concatenate 'string "cbbrowne" "@" "acm.org")
<http://www.hex.net/~cbbrowne/linux.html>
Rules of the Evil Overlord #175. "I will have my fortress exorcized
regularly. Although ghosts in the dungeon provide an appropriate
atmosphere, they tend to provide valuable information once placated."
<http://www.eviloverlord.com/>
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Subject: Re: Windows stability: Alternate shells?
Date: 11 Aug 2000 21:07:37 -0500
In article <8n296j$i0k$[EMAIL PROTECTED]>, tom <[EMAIL PROTECTED]> wrote:
>One of the reasons you folks seem to prefer Linux is its "stability",
>as opposed to Windows apparent lack thereof, whatever this may mean
>specifically.
>
>I've seen a number of websites where people claim that various
>alternative shells (e.g. LiteStep & GeoShell) are more stable than
>Windows' Explorer. No doubt there's more to the issue of stability
>than the shell which, as I understand it, is simply a way to issue
>commands and run programs. How much can Windows be improved along
>these lines -- anyone have any experiences?
The way to improve windows stability is to only run one
program in production on a machine, never load any new
software at all (including updates to windows or the
one program you run) without testing on another machine
and be prepared to reboot even for a simple program
update.
>And on a slightly different topic, if I go to Best Buy this weekend to
>pick up a version of Linux to try, any suggestions as to which one for
>a Linux newbie? I'll never give up my Free Agent, but I'm kind of
>nostalgic for the Stone Age when I had my first internet account, a
>Unix shell on Primenet running tin, pine, and pico; thought I might try
>to get something like that going on my computer. (Actually my first
>internet experience involved AO-hell, but let's not get into that. :)
Try Mandrake first for a desktop machine. It's pretty far from
the stone age, but you'll find all the old tools under the
covers if you want them.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.system
Subject: GUI-Kernel Integration or Lack Thereof
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Aug 2000 02:12:08 GMT
Centuries ago, Nostradamus foresaw a time when [EMAIL PROTECTED]
would say:
>Nathaniel Jay Lee <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Ah, let the people be heard!
>>
>> This is the stuff I find scary. I don't mind the idea of 'modularizing'
>> the graphical interface into the kernel (as I believe some of the early
>> efforts are underway to do so), just don't make it something that is
>> *forced* on me.
>
>Now implementing the frame buffer in the kernel was a good idea since
>it can present a more or less uniform method of handling the
>graphical screen across most Linux platforms. However, very much
>more graphics support in the kernel is not good. The more of the GUI
>that is in the kernel, the more the systems stability could be
>compromised.
This is an example of a situation where there is just _ample_
opportunity for flaming by the clueless, but where there's
considerable ambiguity even for those that _do_ have a clue.
Consider:
Probably 3 years ago, the GGI folks proposed pushing a whole _LOT_ of
graphics stuff into the kernel.
They were rightly lambasted by the kernel folk for a number of
reasons:
1. They were proposing embedding a whole lot of functionality into the
kernel "KGI" portion of GGI.
Bad, for all the robustness reasons, as well as because this makes
the kernel bigger, and thus means that less stuff can get swapped
out.
2. They assumed that their code base needed to be integrated in "right
now, because we're cool dudes, and this needs to be done."
Which isn't how things are done. ReiserFS has been waiting for
_months_ after pushing hard for entry into the kernel at the start
of this year.
The GGI code base _wasn't nearly mature enough_ at the time.
3. The GGI code base was, at the time, _pretty bad code_. They were
doing major surgery on the console code, and a fair bit of it was
definitely not pretty code.
If it's not readable, and if it's not compatible with the many
other architectures that were of some importance even then, that
doesn't fly.
However, it wasn't _all_ bad, and there are some interesting
counterobservations.
4. They _did_ have things split out into "kernel stuff" and "user mode
stuff." It _wasn't_ a matter of having the whole "GUI in the
kernel."
The Framebuffer code that has since gotten integrated into the
kernel may be a bit less than the GGI folk had hoped for, but I
expect not _dramatically_ so.
5. Didn'tcha know that there _ALREADY WAS_ GUI code in the kernel?
One of the major areas of "surgery" in GGI related to changes to
the console code.
Remember, what is console support, other than a (perhaps
rudimentary) GUI?
-> It involves drawing stuff on the screen;
-> It includes a font renderer and a font manager;
-> It even includes a "higher level library," in the form of
emulation of "some VT100 superset."
It may only get _used_ to splatter text on the screen, but that
doesn't make it any the less a GUI of sorts.
<http://howto.tucows.com/LDP/HOWTO/Framebuffer-HOWTO-3.html>
describes how the Framebuffer concept was downright _useful_ in
unifying the way consoles are accessed on different platforms;
there had been quite different code on IA-32 as compared
particularly to m68k.
6. It seems to me that putting some set of Useful Hardware
Abstractions into the kernel _IS_ a legitimate thing to do.
Having the kernel provide a "structured" way to push commands to
the graphics hardware rather than having "user world" manage the
hardware as typically happens with X seems like a reasonable idea.
The Linux Framebuffer provides this, and seems to be a pretty
appropriate abstraction to have in the kernel. See:
<http://howto.tucows.com/LDP/HOWTO/Framebuffer-HOWTO.html>
<http://go.163.com/~bricks/linux/program/framebuffer.html>
I could see going _somewhat_ further in having _some_ more
structure provided. X is certainly _NOT_ implemented in a manner in
keeping with Unix Philosophy in that it does not export any of its
hierarchy as a set of "filesystem-like" things.
The Plan 9 window manger, rio, provides a hierarchical
filesystem-based way of accessing windows.
<http://plan9.bell-labs.com/magic/man2html/1/rio> Whether or not
this ought to be in the kernel is certainly a legitimate question.
On the one hand, I agree that anyone seriously considering the kind of
GUI integration that Windows NT has for Linux has _got_ to be smoking
crack, particularly with the degree of interest in Linux for _EMBEDDED
COMPUTING_, where there's typically NO GRAPHICAL DEVICE AT ALL.
On the other hand, baldly assessing _all_ changes that have _anything_
to do with graphics that happen in conjunction with the kernel as
being diseased _also_ indicates that the "assessor" has smoked too
much crack, because it just isn't necessarily so.
The thing that _is_ seriously "diseased" is the quality of the
interfacing of graphical devices to PCs. The recent flamewars that
have erupted surrounding the ability to, in a few instructions, nuke
partition tables on IDE drives, provide no new news of "lack of
robustness of PCs." The fact that SVGA boards sit on PCI and AGP
buses with intense access to RAM means that they have a _tremendous_
ability to LOUSE THINGS UP if they aren't carefully used.
If a SVGA command queue can be managed by a little portion of the
kernel, thus making "managed access" the norm rather than the
exception, that can at least _help_.
Thus:
- Windowing system in kernel: BAD.
- Framebuffer in kernel: Probably good.
- Font manager in kernel: BAD.
- Tagged SVGA command queue, parallelling tagged SCSI command queue:
Probably a VERY good thing.
>The computer rag that I was talking about was sitting with the
>newspaper and magazines at the barber shop. I didn't pay any
>attention to it at first, but the barber did. He didn't read the
>article but just took the headline on the cover as his issue of the
>day. The headline was as well as I can remember, "Linux says 'Get
>lost Geeks and hello *real* people' --Linux take learns lessons from
>Microsoft and accepts Windows style full GUI intergration".
Keep in mind that the quality of other aspects of news reporting are
probably often of similar quality...
>So I read the two page article and found it to be nothing more than
>an amplification of the USENET thread that had participated in. The
>author accepted everything that was suggested by the otherside of the
>thread. The opinions and observations of myself and others that had
>the same opinions and views were dismissed as the "foolish crack
>dreams of the Geeks who ruined Linux since the 1960's". The article
>never did admit the source of the information within it, but I knew
>it was not a coincidence. It contained a few unattributed but exact
>quotations from my postings and others in that thread.
... And if the code is written by the "Geeks who ruined Linux since
the 1960's", then _that_ trumps any blathering that reached your
newspaper.
See obligatory Linus Torvalds quote below. :-)
--
(concatenate 'string "cbbrowne" "@" "ntlug.org")
<http://www.ntlug.org/~cbbrowne/linux.html>
"The Linux philosophy is laugh in the face of danger. Oops. Wrong
One. 'Do it yourself.' That's it." -- Linus Torvalds
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: kernel httpd
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Aug 2000 02:19:46 GMT
Centuries ago, Nostradamus foresaw a time when Gary Hallock would say:
>Nathaniel Jay Lee wrote:
>> I can answer that 'what the heck...' question you pose. They did it for
>> benchmarks plain and simple. They wanted to show just how good 'Linux'
>> is at serving web pages all by itself (compared to NT) and so did it
>> with a kernel based http server. I don't know of any site on the
>> Internet that uses the kernel http server, and hope to god that no one
>> ever does. But I have seen a few 'in shop' sites use it (for intranet
>> hosting). Even this to me doesn't seem right if you are using Linux on
>> a host. I run the intranet site on the same box that runs the main
>> fileserver/printserver/whatever else I need and haven't seen a
>> significant impact on performance.
>
>Someone please correct me if I'm wrong, but I seem to remember that
>that kernel http server could run in kernel or user mode and that the
>performance tests that showed Linux running 2-3 times faster than W2K
>were running in user space.
I don't see the "khttpd" as being _all_ that huge a problem, so long
as it's kept "tough enough to install" as to scare away the idiots that
don't know what they're doing.
_IF_ you have a server that gets _SO MUCH_ traffic that "khttpd"
will make a significant difference, _then_, and _ONLY THEN_, would
it make sense to go through the effort of:
a) Installing it,
b) Making sure it's properly installed, and finally...
c) Configuring whatever "trampolines" need to sit in front to
protect it from evil requests.
IF you've got a server servicing up _huge_ amounts of static
content, this may very well be a worthwhile optimization.
The important thing is for users to make use of Michael Jackson's First
and Second Rules of Optimizations, namely:
#1: Don't optimize.
#2: Don't optimize. (Yet.)
Having kttpd installed "by default" strikes me as being a _DISASTER_.
And WORTHLESS, because there's no reason to expect it to resolve any
bottlenecks for the "default" sort of system.
--
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/lsf.html>
"Are [Linux users] lemmings collectively jumping off of the cliff of
reliable, well-engineered commercial software?" -- Matt Welsh
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.advocacy) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Advocacy Digest
******************************
