An architectural overview of the GNU Hurd | Hacker News Reader

An architectural overview of the GNU Hurd

gnu.org

75 pointsvezzy-fnord16 comments

These days you're better off with Minix 3. It's documented much better, with a book to boot, it's a much better microkernel than Mach, and it has a lot of activity around it.

Though I agree the Minix 3 microkernel is more elegant than GNU Mach, the Debian GNU/Hurd distribution has >80% of the package base building and largely running, which means it has a higher software selection.

The Hurd's documentation is pretty good for a project of limited manpower, just scattered.

Because strictly speaking the Hurd is only the userland servers, there's plenty of opportunities to work on porting and hacking them. The Debian GNU/Hurd might get USB and sound soon with NetBSD's rump kernel drivers phasing out the DDE framework in Mach, for instance.

Is this happening? (the dde->rump switch?) I know there was a talk about it at Fosdem a while back, but I havent heard much since.

What if.... there was an effort to replace the Mach kernel with Minix3?

Or if Debian decided to do a Debian GNU/Minux3 release?

Minix is basically ABI compatible with NetBSD, so going from a Debian/kNetBSD port to Minix would be easy. There was one once, way back https://www.debian.org/ports/netbsd/ but its dead.

Not sure it makes a lot of sense though.

Doesn't Minix 3 have pkgsrc from NetBSD available? I don't know how many package actually built, so that might be a limiting factor.

> it has a lot of activity around it

This is not remotely true, and it sort of gives away an ignorance of either project. (I'm actually fairly ignorant of Hurd myself, but I'm familiar enough with MINIX to know that the comments about it are pretty far off target...)

I also find it odd that you specifically mention MINIX's documentation, because it's arguably the weakest point of the whole project. Even as for the book, if someone thinks they're going to be able to pick up the latest edition of Operating Systems: Design and Implementation in search of documentation for either MINIX-the-project or MINIX-the-software, they will be sorely disappointed. The fact that the book is now about a decade out of date is one reason for the latter. There are a number of reasons for the former.

I've written some (recent) comments that go pretty in-depth on the subject. E.g., https://news.ycombinator.com/item?id=9736214

Again, I can't imagine that anyone with a current, even-cursory-level understanding of MINIX would hold the requisite opinions to make the comments that you've left here.

Are there any decent postmortems of Hurd? Not to imply that it's dead. In retrospect, what was a good idea, what was a bad idea, and what are the main architectural weaknesses of the kernel as it stands today?

There's "the critique", as it's called: http://walfield.org/papers/200707-walfield-critique-of-the-G...

The paper was written in response to the porting effort of the Hurd away from Mach to L4, and realizing the latter didn't pan out well for object-capability systems.

Same people later wrote an experimental microkernel specifically for the Hurd called Viengoos, but that too fizzled out.

They're really proud of filesystem tricks that Plan 9 was doing in 1994 (see the "transparent ftp" thing)

Hurd translators don't have to export virtual file systems. They go beyond that into being generic object servers and are also used to implement things like a regular Unix TCP/IP stack (pfinet), Unix process semantics like pids, sids, wait()ing, parent-child relationships, groups (proc), authentication (auth) and so on.

They're more similar to Spring's name server mechanism, being general object brokers as opposed to file object brokers in particular, as is with 9P/Styx.

Hurd has been in development since 1990. Revisions of the linked page go back to 1996. I'd have to do more digging to figure out when Hurd transparent FTP was actually implemented.

The GNU/HURD was doing it in '94 too.

... well maybe not '94 specifically but the first check-in for the ftpfs code is from '97.

http://cvs.savannah.gnu.org/viewvc/hurd/ftpfs/ftpfs.c?root=h...

Why do you find that so repugnant that it moves you to write resentful comments about it? The entire point of researching and publishing computer operating systems is to discover and share new methods and ideas. I doubt that the Plan 9 authors published dozens of papers and gave countless lectures in order to discourage others in their field from building on their work. They didn't discuss their ftp filesystem multiple times in their publications in the hopes that nobody would ever implement anything like it ever again. That the Hurd authors profitably exchanged ideas with another operating systems group is beneficial to everyone and shouldn't fill you with spite.

Credit / acknowledgement of related work would be nice, and not just because it's the right thing to do. It's good for readers who aren't aware of the related work. It's good for readers who are aware of it (so they can understand the differences, or so they merely know that this author is aware of that author's work). It's also very good for the project's own future maintainers to be aware of similar efforts, especially those that tend to publish what works and what doesn't.

You mean like the many breakthroughs being made in Linux that are actually mainframe ideas?

Reply on news.ycombinator.com