Hurd Group Holds First Meeting

Marc Bumble (left), Bill White, and John Tobey (not pictured) had plenty of questions for our local gurus.

The Boston chapter of the Society of Hurd Enthusiasts and Experimenters (Boston SHEE) held its first meeting on Saturday, December 18, 1999 at MIT in Cambridge, Mass. On hand to answer questions were Roland McGrath and Thomas Bushnell, BSG, two of the principal kernel developers.

These are Bill White's comments from the meeting.

• [How did I ever get to be so old and fat? Can't we get one of those lenses that make everybody tall and thin, like when the credits from wide screen movies are shown on TV?]
• How did the name become SHEE? I thought Cambridge Hurd Users Group (CHUG) was the sentimental favorite? [I could go with SHEE, though. I could go with the Cambridge Mumblers for that matter. I could go for anything, I'm easy.]
  Editor's note: At the meeting, Bill indicated a complete lack of interest in how to name the group.
  
• The themes of the Hurd are extensibility and scaleablilty. In 10 years there will probably not be any current hardware running anywhere. The intention is that some of the ideas of the Hurd will live on in whatever system software people are running then. Few people have any serious notions of the Hurd displacing Linux for any applications soon. [Of course, no one would have had serious notions of version 0.96 Linux replacing Windows NT for anything, so sometimes the few are right.]
• Among the topics I have written down are these. Many of these have been discussed on the mailing list.
  • Managing limited resources seems to be a difficult problem, one which neither the research nor practice communities have adequately addressed. The Hurd does not address this either. Programs which run out of memory just crash. Sorry.
  • There is not tgz filesystem for the Hurd. One could be made from a zip filesystem for the underlying file, and a tar filesystem for the archive part.
  • The previous comment is a motif. The general form is: There is no mumble in the Hurd, but one could be built by factoring the problem into two or more sub-mumbles.
  • People seem to be using packaging systems to do things that filesystems should really do. For example, users want to put everything in /bin, but sysadmins want to put the binaries for each package in its own bin directory. Package systems mediate this gulf. However, current package systems are not a flexible or stable or robust as one might like. [This does not mean they are bad, just that they could be better, quite like everything in life.]
  • RPCs in the Hurd are done with old Soviet-style technology - MiG. The Hurd designers are not in principle opposed to redoing this using something else, say CORBA for example, but problems are:
    1. MiG is at least alright,
    2. MiG can be torqued to be quite useful in some special circs (no concrete examples were given)
    3. the existing code base might have to be significantly redone if MiG were replaced. This might take a lot of work, though it would not in principle be difficult. Doing it would allow for replacing some things which are currently perhaps suboptimal.

    Thomas looks on as Roland describes the Hurd.

  • The Hurd is in principle portable. Someone did a port for the MIPS architecture but that was long ago and in Japan. The person who did it has gone missing for a long time. The principle problems with porting the Hurd to other platforms are:
    1. Some libc issues, which have been solved for other platforms, and are pretty well known,
    2. Some mach kernel issues which Roland, at least, understands, and could be prevailed upon to work on in short order.
  • OSKit Mach now works great. There are some minor technical issues which Roland and Thomas need to bash out between them which keep it from being adopted by the main line, but it seems to work fine, and is, in fact, Roland's development environment. [Is this right? Am I remembering too much?]
  • Anybody who is serious about porting the Hurd should probably start with OSKit Mach, just because it has a good kernel debugger. OSKit has some history of being ported.
    Editor's Note: Find and read Roland's announcement about OSKit-Mach in the bug-hurd archive before you get any ideas.
    
  • Loadable kernel modules are not opposed in principle. Though Thomas has a theoretical opposition to them, he is not opposed to them. They are certainly technically feasible. The only reason they are not in the kernel now is that nobody who has the skill to implement them has had a compelling interest in the implementation.
  • Binary-only modules are just wrongheaded. If loadable kernel modules cause people to release binary-only modules, they are probably a bad thing. [This from Thomas, though I personally agree with him completely.]
  • It is in principle possible to make Linux binary modules usable in directly the Hurd, though no one has actually done the work. See the last bullet item for a reason not to do the work.
  • If someone wants to work on loadable module or Linux module support, it is probably better to start with the OSKit Mach kernel. This has some minimal support for loadable modules, and may have more in the future.
    Editor's Note: See the above note. Please. For the children's sake!
    
  • OSKit Mach has a spiffy kernel debugger, which Roland uses all the time.
  • Different people have different styles. Thomas debugs by reading code and thinking great thoughts. Roland bashes through things in Hurd. Everybody does things differently. Gdb works, but it takes some practice to learn the command set. Learning the command set is a very useful exercise. [Personally, I use printfs, and have had great difficulty with gdb on the Hurd. However, I intend to try to learn enough about gdb to make it work properly for me.]
• The next scheduled meeting is Feb 12 at 1500, probably at the MIT AI Lab Conference Room. An announcement and directions will be posted to the mailing list closer to the date. (subscribe at boston-hurd-request@gnu.org)