The Hurd

[Frank Heckenbach]

Marcus Brinkmann wrote:

> On Thu, Mar 28, 2002 at 05:47:23AM +0100, Frank Heckenbach wrote:
> > Marcus Brinkmann wrote:
> > 
> > > And, the past has showed that we are achieving our goals.  For example,
> > > nobody uses libc5 anymore,
> > 
> > Apparently you missed Alessandro's mail recently ...
> 
> I don't evenknow who Alessandro is.  A quick web search shows that you
> might mean that etlinux is still using libc5, but will swotch to multi
> libc5 in version 2.  And it will bring multi-platform support to it.
> Sure, libc5 might stil have some isolated uses (prprietary binary only
> programs that are not updated anymore, anyone?), I mean, that's why I
> updated the libc5 package for Debian potato before we released and libc5
> development finally died.  Every software has a time where it is used
> even after it is dead, this time has long appeared for libc5.
> 
> > Mind you, when you make such statements, don't be surprised when
> > others claim that nobody needs the Hurd. Both statements are true
> > ... for certain values of nobody ...
> 
> Well, feel free to tell me more about libc5.  But please be a bit more
> elaborate.  As far as I can see, the market for libc5 is pretty tight
> with glibc on the one side and dietlibc et al on the other.

Well, if you like to talk about "nobody" and "dead" and "markets"
for software, that's your choice. I don't like to see such terms in
connection with free software. But to say it in your words, there's
no market for the Hurd because nobody uses it. Maybe I'll try it
when it will be born.

> > > I don't want a graphics driver in the kernel.  I don't want any driver in
> > > the kernel, to be honest ;)  But having said that, I don't want a webserver
> > > in the kernel either.  But see, there is a webserver in Linux.  Does that
> > > make you wonder?  It should.
> > 
> > Actually, it did make me wonder when I read about it. The only
> > reason seems to be performance, and from the benchmarks it seems to
> > be much faster than any user-space webserver under certain
> > conditions.
> 
> Indeed.  The same logic makes you add an SQL server to the kernel.
> And graphic rendering software.  And just about anything because people
> want everything to be as fast as possible if you ask them.

As I said, many such requests are bogus because the performance
gains are marginal. But in this case (from what I've read -- I
haven't tried it myself because I have no need for it), the main
overhead in this case is shuffling the data from and to the ethernet
card (or whatever) through the network stack (provided most pages
are cached in memory so disk I/O isn't the main issue). This isn't
the case for an SQL server (where the disk I/O is often the
bottleneck which is limited by hardware speed), leave alone graphic
rendering (which is mostly CPU work with little I/O at all).

> In short, you can go back to DOS programming, if performance is
> your goal.

Except you don't call Dos because it's slow and 16 bit, i.e. you do
it bare bones ...

> > there are apparently some who need to
> > serve large amounts of static web sites. What would you suggest to
> > them? Buy more hardware? Write a user-space program that side-steps
> > the OS and talks directly to the hardware (welcome back to Dos ;-)?
> 
> Your analogy is flawed.  DOS doesn't have a user-space, so what is
> equivalent to DOS programming is putting it into the Linux kernel.

Sure, the analogy wasn't perfect. Dos has a kernel and user space,
but only formally, i.e. it's not enforced by any protection, whereas
under Linux (don't know about the Hurd) one has the protection, but
can sidestep it as root using iopl(). Assuming that someone who sets
up a major web server has or can get root privileges, this
difference is not essential in this context.

Frank

-- 
Frank Heckenbach, frank at g-n-u.de
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)