The Hurd

[Jeroen Dekkers]

On Fri, Mar 29, 2002 at 05:12:56AM +0100, Frank Heckenbach wrote:
> 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.

The Hurd has an increasing number of users. Does libc5 has that?

AFAIK libc5 isn't under development anymore. If I'm right all main
authors stopped with the development of it. I think you can consider
it pretty dead then. All of the major distribution don't use libc5
anymore, there is one major distribution which has the Hurd.

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

That can be pretty fast. On the i386 a context switch costs pretty
much, but on other processors it's even less if I'm right. Because 10
years ago microkernels were slow everybody thinks they are slow
today. But they are fast today!

Jeroen Dekkers
-- 
Jabber supporter - http://www.jabber.org Jabber ID: jdekkers at jabber.org
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: jeroen at openprojects
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.fsfe.org/pipermail/discussion/attachments/20020329/754f2571/attachment.sig>