The Hurd

[Frank Heckenbach]

Jeroen Dekkers wrote:

> On Fri, Mar 29, 2002 at 03:16:20AM +0100, Frank Heckenbach wrote:
> > 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 use the Hurd and some people I know also use the Hurd. It's still
> under development.

Which is exactly my point. I know that some people (but not so many
yet) use the Hurd. In Marcus' words that's "nobody".

I also know that the Hurd is still under development. Extending
Marcus' usage of "dead", this means it's not born yet.

> > 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).
> 
> Doing everything in user-space with very fast IPC should give you
> about the same performance, I think it could be even faster. Read the
> papers on the tu dresden, L4KA and sawmill websites for more info.

I'm no expert on this matter, but from what I've read I'm quite sure
that IPC is not the issue. It's about context switching etc.,
AFAIUI.

Frank

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