Hurd Traffic #82 For 1 Mar 2001

Editor: Zack Brown

By Paul Emsley  and  Zack Brown

Mach 4 ( | Hurd Servers ( | Debian Hurd Home ( | Debian Hurd FAQ ( | debian-hurd List Archives ( | bug-hurd List Archives ( | help-hurd List Archive ( | Hurd Reference Manual ( | Hurd Installation Guide ( | Cross-Compiling GNUMach ( | Hurd Hardware Compatibility Guide (

Table Of Contents


Want to help write KC Debian Hurd? See the KC Authorship page (../author.html) the KC Debian Hurd homepage (index.html) , and the Thread Summary FAQ (../summaryfaq.html) . Send any questions to the KCDevel mailing list. (

Mailing List Stats For This Week

We looked at 123 posts in 459K.

There were 48 different contributors. 19 posted more than once. 9 posted last week too.

The top posters of the week were:

1. CORBA Replacement For MIG

7 Feb 2001 - 19 Feb 2001 (42 posts) Archive Link: "MIG->Corba"

Summary By Zack Brown

People: Eray OzkuralOgnyan KulevIgor KhavkineJeff BaileyMarcus BrinkmannWerner KochIngmar SchusterBrian May

Mridul Jain asked about the feasibility of a CORBA replacement for MIG (Mach Interface Generator). Brian May strongly supported this idea, since CORBA was a well-known standard, but Eray Ozkural cautioned:

Make sure it doesn't turn out to yield a Java level performance. ;)

That standard called Corba was not tailored for microkernel message passing.

But he added that it sounded like a worthwhile challenge, and Ognyan Kulev remarked, "IMHO CORBA can be as fast as Mig, even faster." And Igor Khavkine added, "CORBA is only a source level standard. It is not restricted to IIOP or any other message passing protocol, the so to say "backend" can be changed according to need. For example regular IPC on the same machine can be done through the Mach message passing facilities, like MIG does now, however the same code that uses CORBA can easily be adapted to use IIOP for remote machines by changing the "backend". The details depend on the ORB (object request broker)." Eray reminded folks not to get into flames, and went on:

So, you're saying that a well optimized ORB can be just as good as MIG. That raises two other questions:

  1. Is CORBA going to be as slow as MIG?
  2. Is MIG slow enough?

What I mean is really: Be pragmatic. Is this new layer of abstraction worthwhile and will it not introduce any performance penalty or a limitations?

For instance, do you really need to write hurd servers in different languages? How useful/suitable would a server written in "perl" be? These are the kind of questions one should consider before writing a big amount of code. Such effort would require some justification of the benefits before doing so.

Well, you could try to use XML all throughout Hurd to store all configuration data. But the result would not be totally desirable. :) (Sorry, I couldn't resist the joke, that reminds me of Mozilla)

Even companies who are so involved with political statements (sun/ms) don't try to do that (corba or xml) at the kernel level AFAIK.

In fact, I wouldn't do it if it wouldn't make any major improvement over MIG. Not that I know a great deal about MIG or CORBA. I don't. But I've written quite a number of parallel programs so I can predict how much bloat a message passing system can bring. The distributed case is something to consider of course, because that was what Mach was supposed to accomplish and without considering it there isn't much benefit in writing a microkernel in the first place.

Though, I see your point. It's the same thing that the orbit has been promising. The case of programs running on the same machine and in same address space will be so well optimized that it will be like making an ordinary IPC and a procedure call respectively.

But on the other hand, perhaps what you're thinking of accomplishing through making CORBA available is taking advantage of object oriented development. In that case maybe writing a great C++ wrapper around existing code would be good enough? Don't forget that it really doesn't matter for the machine whether you're using CORBA or MIG as long as you're using Mach message passing. And if the target for the revision are developers, consider how easier will it make the life of a HURD developer instead of how buzzword compliant it will be.

Jeff Bailey remarked in reply to Eray's second paragraph above, that a Hurd server written in Perl could be very useful, explaining, "I want to adapt the Entropy Gathering Daemon to use the perl TrivFS stuff to provide /dev/random and /dev/urandom on Hurd." But Marcus Brinkmann replied, "I have a different plan, ripping of the entropy pool mixer from gnupg into an entropy server. egd can then just write its data into /servers/entropy (as can any other program that thinks it produces some entropy). I am currently discussing the details with Werner Koch, and will follo wup with a proposal soon, followed by an implementation if everything goes well." Elsewhere, other folks agreed that writing servers in other languages would be a good option to keep available.

Elsewhere, Marcus also added that performance was not really an issue, and that MIG fell short in several ways and needed to be either extended or replaced. He said, "If something generally accepted like CORBA can be it, even better." Ingmar Schuster felt that performance really was an issue, since they were dealing with such an important interface, but Marcus replied, "Of course, but any message passing only adds a constant overhead to a single message. Performance increase can also be achieved by adding new interfaces, which remove the need to send several messages (by replacing them with a single message). I think this is what is planned for fork. Faster computers make the constant overhead for single messages negligible. Also, AFAICS, there is no reason why any message interface generator should be significantly slower or faster than any other."

The discussion proceeded in a friendly vein.

2. Japanese Translation of The GNU Hurd Reference Manual

17 Feb 2001 - 19 Feb 2001 (5 posts) Archive Link: "hurd-ja.texi"

Summary By Paul Emsley

People: Marcus BrinkmannJeff BaileyOKUJI Yoshinori

mihi~star reported that he had translated the GNU Hurd Reference Manual into Japanese and that it could be found at ( . Because this was the first translation, it was not decided how this document should be integrated into the distribution. Marcus Brinkmann remarked, "There are various issues, like storing, building and keeping up-to-date." Jeff Bailey added, "If I remember right, okuji is the head of the JA translation team. He'll be able to point you at the right people, anyway." And OKUJI Yoshinori followed with, "Precisely, I was the maintainer of GNUjdoc. IIDA Yoshiaki <> is the current maintainer, and I'm now one of the contributors. See <>, for more information. Also, you can contact the project with the address <>."

3. Status Of Hurd Bug Tracking System

17 Feb 2001 - 20 Feb 2001 (4 posts) Subject: "Cosmetic glibc 2.2.2 and hurd cvs patches."

Summary By Zack Brown

People: Mark KettenisMarcus BrinkmannArkadi E. Shishlov

Arkadi E. Shishlov had some patches, and asked whether it was best in general to submit them on the list or to a bug tracking system (BTS) of some kind. Mark Kettenis thanked him for the patches, and speculated, "If you only post them to the mailing list, they might get lost. Entering them into the Debian BTS should be enough to avoid that. And now we also have (the GNU sourceforge site) where you can enter bug reports for the Hurd." But he added that Arkadi should also let folks on the mailing list know about bugs and patches, whatever the "right" method turned out to be. Marcus Brinkmann brought folks uptodate with, "A few weeks ago, Loic told me not to use the BTS for now, so I disabled it."

4. Script To Help Build The Hurd And Related Tools Under Linux

17 Feb 2001 - 18 Feb 2001 (2 posts) Subject: "Script to build Hurd, LibC, cross GCC."

Summary By Zack Brown

People: Arkadi E. ShishlovJim Franklin

Arkadi E. Shishlov announced, "Just put together a script to help build Hurd, Libc, and cross GCC on Linux host. It is available at Jeff, can you add it to your hurddocs HOWTO page?" A pleased Jim Franklin replied, "thank you for this url. It is just what I was looking for to help in my next effort on the hurd." eot

5. Installing g++ Woes

18 Feb 2001 - 21 Feb 2001 (4 posts) Archive Link: "libc6?!!!"

Summary By Paul Emsley

People: Marcus BrinkmannVadim ChekanSantiago VilaBen Collins

Vadim Chekan couldn't install g++ (and hence libstdc++2.10-dev) on his D1 dist-based Hurd because of dependencies on libc0.2-dev. He wondered if he should force the installation of libstdc++2.10-dev, and Santiago Vila said that sounded safe. Marcus Brinkmann went on to say:

The broader problem is that dpkg doesn't cope with versioned dependencies on provided packages. Why it is so hard to fix that I don't know, but I was told that Ben Collins is working on that (for several months now).

There are several places where dpkg fails here with the Hurd archive, not only libstdc++2.10-dev.

6. Status Of dpkg

19 Feb 2001 - 23 Feb 2001 (2 posts) Archive Link: "Current "dpkg on Hurd" issues"

Summary By Zack Brown

Topics: Apt

People: Marcus BrinkmannWichert Akkerman

Marcus Brinkmann reported:

dpkg still does not deliver a functional dpkg for the Hurd. Here is a list of all out standing issues I am aware of. Most of them are known for a long time by now.

  1. #31620: Use of hard fixed errno ENOENT in some scripts
    Wichert says he would ask Jason if apt copes with a predependency on perl-5.6-base. If it doesn't, it should, but it makes sense to delay the change until apt can cope if it can't already, if that is not an infinite amount of time.
  2. #76941: archtable/ vs i386-gnu/i386-gnu0.2 should check for the prefix rather than an exact match. Same issue on some BSD systems, see
  3. #68783: Calls scripts in /var/lib/dpkg/info without the full path, breaking debconf. Wichert says he thinks it's a bug in the Hurd (it's not), but in any way the behaviour debconf relies on is not guaranteed by any standard. He said also he will add the work around (In my interpretation, a work around for debconf, although I think Wichert might mean it's a work around for the Hurd.), but it hasn't happened yet.
  4. Depends on sysvinit (>= 2.72), which is not available on the Hurd. A provides in some Hurd package is not good enough because dpkg can't cope with versioned dependencies on provided packages last time I checked.
  5. dpkg-shlibdeps and /usr -> . symlink.

Regarding Marcus' item 1, Wichert Akkerman replied, "Will fix, partially in perl partially by rewriting dpkg-dev things in python." For item 2, he said, "It works fine on FreeBSD and OpenBSD actually.. need to reread that." For item 3, he said he'd just fixed the problem in the CVS tree. For item 4, Wichert acknowledged that this was still a problem, and couldn't be fixed yet. Regarding item 5, Wichert said, "I'll reread that, I'm rewriting dpkg-shlibdeps now anyway" , and finally remarked regarding whether item 3 was a Hurd bug, "It's a definite non-UNIXism at the very least." There was no reply.

7. Status Of apt

21 Feb 2001 - 24 Feb 2001 (8 posts) Archive Link: "new apt source available"

Summary By Zack Brown

Topics: Apt

People: Marcus BrinkmannJeff Bailey

Marcus Brinkmann announced, "apt 0.5.0 is now in the Debian archive. Who is going to compile, test and upload it? It's the most requested package here, so you can earn yourself some fame and honour :)" Jeff Bailey reported:

The following packages needed upgrading:


perl was annoying to upgrade, as I had to butcher my status file to get some dependancies filled.

I have tested: apt-get source, apt-get install, and apt-get remove using the 'ftp' method. They all appear to work within normal parameters.

Anyone who has the 'oasis' machine in their sources.list can apt the packages that they'd like. If you need these, and can't wait until someone posts them onto the Debian machines, email me privately and I'll give you the path. I posted a machine once publicly, and had to move my box so that slashdot stopped hammering me.

Note that I have not signed these packages yet. It's escaping my brain how to do so now that they're on a different machine. I'll try and remember tommorow.

Marcus was fairly disappointed, and there was a brief discussion of the various problems.

8. runpath In The Hurd

22 Feb 2001 - 23 Feb 2001 (4 posts) Archive Link: "need some help"

Summary By Paul Emsley

People: Wichert AkkermanMarcus Brinkmann

Wichert Akkerman needed someone to run a few commands on a GNU/Hurd system. Marcus Brinkmann did so and said that in future Debian GNU/Hurd will use runpath for additional library paths.

9. SysV IPC

23 Feb 2001 (5 posts) Archive Link: "SysV IPC"

Summary By Paul Emsley

People: Roland McGrathIgor Khavkine

Igor Khavkine was trying to port jinit and found references to msgsnd(), msgrcv(), msgget() (SysV IPC API). SysV IPC is not currently ported to the Hurd. Roland McGrath commented: "If you change some program that uses msg*, I would not suggest porting it to native Mach IPC, since so few people ever use that, and the Hurd might not even use it forever. Probably whatever it does could be done perfectly well with unix-domain sockets (perhaps SOCK_DGRAM type)."







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.