Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins

Hurd Traffic #50 For 31 May 2000

By Zack Brown

Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?
Are you without a nice project and just dying to cut your teeth on an OS you can try to modify for your needs?
Are you finding it frustrating when everything works on minix? No more all-nighters to get a nifty program working?
Then this post might be just for you :-)
-- Linus Torvalds, 1991

Table Of Contents

Mailing List Stats For This Week

We looked at 68 posts in 253K.

There were 39 different contributors. 16 posted more than once. 6 posted last week too.

The top posters of the week were:

1. Fixing UNIX Legacies

14 May 2000 - 26 May 2000 (21 posts) Archive Link: "Re: /home/user/var ?"

Topics: Apt, Bootloaders, POSIX

People: Tomasz WegrzanowskiMarcus BrinkmannNiklas HaglundAdam Sampson

In the course of discussion, Tomasz Wegrzanowski argued that the Hurd was
a place where UNIX design mistakes are fixed o be used wider. We have already one big success - GRUB bootloader did spead very widely and will very probably overnumber LILO in next two years (my biased idea),
and added at the end of his message,
Remember that Debian GNU/Hurd is quite independent distribution, only using the same packager and package base, and some infrastructure and we should make Debian GNU/Hurd as good as we can, not as Linux-like as possible, because no-one would like use Debian GNU/Hurd if it were just Debian GNU/Linux emulator over Mach microkernel.
This sparked a big discussion. Marcus Brinkmann replied,
Note that this message has not reached the collective consciousness. (Advocating this is a good thing, IMHO).
Someone pointed out that the Hurd's appeal, or rather Linux's lack of appeal, was that Linux was getting too Windows'ish, with feature-creep branching directly out of the kernel. For the poster, the Hurd offered a way out of this, by providing a micro-kernel that would not have to be rebooted each time a new feature was implemented. Niklas Haglund extolled this, with:

This is exactly why I'm interested in the Hurd. Ideally I'd like all hardware drivers etc. to be implemented as separate servers and to have a minimal kernel (something like the L4 kernel). Then I could hopefully upgrade the drivers for the serial port by doing an

apt-get install pc-serial-driver-server

Also, development of this server could happen separately to the rest of the kernel.

Adam Sampson also replied to Tomasz's statement about fixing UNIX design mistakes. He said this was:

something I'd like to see being done more. [This should be sufficient advance warning that whatever follows is likely to be mildly incoherent. It's late at night and I've had a long week, so bear with me.]

Not that Unix has any particular problems with what it's designed to do. But we could certainly make use of a slightly wider viewpoint; most of the new work being done in the free OS world at the moment seems to be cloning what the commercial Unices or Windows can do.

I think that the real problem is that there isn't much documentation or chance to experiment with other OSs. The typical free OS developer (like me) has probably used a couple of versions of Unix (or clones), Windows, and that's about it. In many cases, this is because we have the opportunity to use anything else; most of the other environments---such as ITS, Multics, TOPS-10, TENEX, VM, VMS, Genera, NeXTStep, Plan 9 etc.---will only run on expensive, obsolete or difficult-to-emulate hardware, and the software is rarely available. There's also little available documentation about any of these systems ( being a rare exception---well worth a visit).

The Unix bias here does tend to limit the sort of ideas we come up with. For instance: one of the easily-available bits of documentation about ITS is a paper about what ITS called "PCLSRing", which pretty much blew me away when I first read it. Under Unix-like systems, if a system call gets interrupted, it will return an error code, so it's necessary to write programs that are capable of restarting failed system calls. Under ITS, when a system call was interrupted, ITS would modify the arguments to the call so that it would continue where it left off, and reset the PC so that the call would be executed again with the new arguments when the interrupt handler returned. It makes userspace code much simpler. But there's no way that that would ever get implemented in any of the existing free OSs, because it's completely different to Unix.

Take a look at some point at some of the features that RMS was thinking of back in 1985 in the GNU manifesto. Although many of them have been implemented in the GNU tools or in other free software (such as long filenames, journalling, filename completion and terminal independance), there are a few interesting ones that, while available in the early 80s, aren't common today: such as file version numbers.

What this means is to have versioning built into the filesystem, rather than done as seperate programs (a la RCS). This was available under ITS. The commercial version-control system ClearCase does this (by using a custom FS); you can see the most recent version of a file by using its filename ("foo"), or previous versions by using "foo@@/version". (The @@ directories don't appear in directory listings, by the way.) This would be very nice to have in a free OS, particularly for config files and similar; a Hurd server which allowed you to apply versioning transparently over an existing filesystem would be a sensible implementation.

Another idea would be combining the debugger and shell. This would mean that when a program segfaults (like w3m just has on me), I would be in the debugger immediately, and could find out what was wrong and fix it. (LISP and Smalltalk systems often do this, and Hurd's suspend-on-crash server has similar functionality.)

This is just one example; I'm sure there are plenty of other features in "forgotten" OSs which would be useful to us. So, essentially, my plea is that if you've got any information about interesting (or not-so-interesting) things in other OSs, then try to make it available to others to pick ideas from.

Marcus Brinkmann replied:

Well, of course there are more facettes to it than just lack of ideas (or "forgotten lore" :). Quite convincing arguments can be derived from the amount of existing code base and developer knowledge. If you have a cool OS but no software to run on it, and no developers who have the time to learn doing things the new way, the success becomes less likely.

This is why the Hurd is so cool and different! It enables evryone to work in a common environment (POSIX), but *also* to extent/overwite/modify the pieces he wants. This is only(?) possible in a multi-server environment.

In other words: There is nothing in the Hurd that stops you from implementing your supercool filesystem server, or user management server, etc, and plug it into the Hurd. And we would very much like to see that happen.

The Hurd as it is is the "default Hurd appearance", as a POSIX compatible operating system with some extras. I think nobody will deny that this is an excellent choice as a ground base. From here everyone can go in different directions. You don't need to convince the Hurd developers that it is a good idea. You don't need to try to get them to do it for you. That's the Hurd we are talking about after all.

2. CVS Access

21 May 2000 (3 posts) Archive Link: "CVS Browsing"

People: Marcus BrinkmannSujit MathewJeff Bailey

Sujit Mathew complained that the Hurd pages on Sourceforge were not uptodate, and Marcus Brinkmann clarified: has the current source. The site on sourceforge is not an official part of the GNU Hurd (at least the Hurd project. I don't know the status of the hurddoc pages by Jeff Bailey).

You were certainly not looking at all files, were you? The last check-in was at 14th of May 2000 (libdiskfs/sync-default.h and other)

3. Hurd Meetings

23 May 2000 (6 posts) Archive Link: "Re: Hurd conference in Paris - delayed"

People: Thomas PoindessousNeal H Walfield

Thomas Poindessous announced that the Hurd conference in Paris had been officially cancelled, due to the short time constraints. He said they'd try again next April. Neal H Walfield gave some encouragement, and Tony Bassette said that anyone going to the Libre Software Meeting this summer, should get together for some Hurd discussion. He later gave a pointer to the site's home page. Neal said he'd be there, though he didn't know if anyone else would be. Jurgen A. Erhard also confirmed that he'd be going.

4. 'dpkg' Dependency

23 May 2000 (4 posts) Archive Link: "cross-install's dpkg dependency"

People: Marcus BrinkmannDaniel Burrows

Daniel Burrows objected to the requirement that 'dpkg' be installed, in order to run the 'cross-install' script. It interfered with installing the Hurd from non-Debian systems. He suggested that they just script up something to unpack the .deb files in a simpler way, but Marcus Brinkmann and Juho Ostman both pointed out that 'dpkg' was needed to maintain the package database as well. Marcus explained:

This was the first approach, and it is not worth our time. Beside unpacking the files, you also need to keep the dpkg database files up to date, and handle configuration files correctly.

For people who can't get at dpkg, there is the tar ball install.

Note that cross-install is only a temporary solution until there are boot disks.

However, if you really think this is worth some work, I would suggest that you write some instructions how to make install dpkg on non-Debian systems so that cross-install works there.

5. File Locking

27 May 2000 - 28 May 2000 (3 posts) Archive Link: "Samba"

Topics: POSIX

People: Roland McGrathKevin Musick

Kevin Musick tried to compile 'Samba', but the configure script complained that there was no support for file locking, and that Samba would therefore be unsafe. He asked for some explanation, and Roland McGrath replied,
There is not much in the way of file locking available in the Hurd, and in particular we do not have facilities that match the POSIX semantics for fcntl locking, or (I think) the BSD semantics for flock. The specified semantics are not very elegant from a component-model perspective, and thus nontrivial to design Hurd protocols to properly support. We (the core Hurd developers) have discussed some ideas for new Hurd RPCs for locking, but never fully resolved on a plan and the main issue is that noone has had the time to make it a priority thing to work on. If there is active interest by someone who will do the implementation work, then I think we can manage to dig up our thoughts on the issue and figure out a good way to go about it. But I don't know when any of the core Hurd developers might have the time to actually do such an implementation.







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.