Hurd/L4 Developer Marcus Brinkmann Interviewed

wikinerd writes "A few years ago when the GNU OS was almost complete, the kernel was the last missing piece, and most distributors combined GNU with the Linux kernel. But the GNU developers continued their efforts and unveiled the Hurd in 1990s, which is currently a functioning prototype. After the Mach microkernel was considered insufficient, some developers decided to start a new project porting the Hurd on the more advanced L4 microkernel using cutting-edge operating system design, thus creating the Hurd/L4. Last February one of the main developers, Marcus Brinkmann, completed the process initialization code and showed a screenshot of the first program executed on Hurd/L4 saying 'The dinner is prepared!' Now he has granted an interview about Hurd/L4, explaining the advantages of microkernels, the Hurd/L4 architecture, the project's goals and how he started the Debian port to Hurd."

Comments

hurd is wank though

[Anonymous Coward]

Seriously folks - hurd is for nerds; serious cock nonsence.

A day late, a dollar short...

[flajann]

What a wasted effort. Hurd is not likely to go anywhere, and what would be the point? I'd much rather see that effort used to enhance Linux with more drivers and applications.

Oh well, some people are born to lose.

Re:GNU

[niittyniemi]

> Uhm... you're saying that the gnu tools and projects should be assessed by their coding style?

No, he's saying they should be assessed by how well they're coded.

One comparison: bash v *BSD sh

One's a statically compiled bloated piece of crap which you can't replace on certain systems without breaking the system.

The other's nearly half the size and isn't full of bugs.

Get this straight: Bash is a Mickey Mouse piece of code which has no right in calling itself a system shell. It ain't the only bit of GNU code which looks pretty sickly even under the most trivial inspection either.

Compare it to ksh and bash looks positively retarded. (Have they sorted out ansii escapes yet? Thought not)

Use GNU code for religious reasons but don't use it if you've got work to do or care about using good tools.

The one bit of GNU code that really bugs me: Emacs

What exactly is it? A Mayan calendar? An OS? Or a complete piece of garbage?

Come on you GNU hippies, Linux commies and RMS catamites!!! Mod a filthy FreeBSDer like me down .... I demand it!!! ;)

(Confession: I'm also a filthy vim user with a pile of karma to burn :)

License on Hurd shouldn't be pure GPL.

[waffleman]

Because if it is, the implication is that you cannot run a non-GPL'ed program on the Hurd. This is the same reasoning that led Linus to put precisely this exception in the GPL that Linux uses. I would *love* the Hurd to prosper, but if the maintainers want 1) people to take software licensing seriously AND 2) actually use the Hurd, then their license must not restrict user space to GPL only programs. This is especially important since Hurd is microkernel and things like, oh, the file system and the process server sit in user space.

As things stand now, even if Hurd were magically ready to go today, I would not write software for it because I would be restricted to the GPL. I don't mind the GPL, but I do mind the restriction.

Re:GNU

[tedrlord]

As someone with moderator points, I have to say that I'm actually interested in the problems you have with GNU tools, but since you demanded it, I had to go ahead and mod you down.

I have to thank you for giving me such a good idea. From now on, whenever I can moderate and find someone saying he will be modded down, I will do so. I like to be helpful.

Re:GNU

[CondeZer0]

Start here.

You can continue here.

That should get you going, then you can read The UNIX Programming Environment and The Practice of Programming

Re:GNU

[anothy]

Your experience seems quite one-sided...

i'm not sure what this means. i mean, i guess it's one sided in that it's only my experience, but that's pretty much inherent in being a single person's experience. for what it's worth, that experience comes from large financial institutions, a very large telecommunications company (Bell Labs), a very small software startup, a service company to mobile operators, and plenty of independent consulting to various people like software and microelectronics companies. my statements about my experiences have been more or less consistent.

...how do you explain that lots of people are using the GNU tools on "real" Unices?

that's a very good question. part of it, i believe, is that there is some benefit to having uniformity across platforms, even if the uniformity is below a level available on an individual platform. the gnu toolset certainly provides value in this area, and this becomes especially important as Unix systems become less and less differentiated.

Quite a bold claim, considering that they put that whole socket business in there, which was about the first thing to be ditched in Plan9...

you will note that i also said they got plenty of things wrong, too; sockets are a wonderful example. while their vision was certainly flawed, they at least had a relatively consistent guiding vision.

History proves you wrong.

well, no. the fact that they started more or less concurrently doesn't say anything convincing about who influenced who (or not). i am, however, currently unable to find the explicit references by GNU/FSF folks to that effect.

also, i think the HURD people did, in fact, understand Unix (at least at a high level) somewhat, although i'm inclined to agree with Linus on this one (a rare thing indeed) that their approach to implementing it is generally unconvincing. concerns about their microkernel (Linus' main objection) aside, they missed why files are the important abstraction level and they made huge sacrifices of simplicity in the service of other aims (including compatibility). while i'd agree with you (or what i think you're saying) about HURD taking a more ambitions and intentional approach to compatibility than Plan 9, i'd point out both that this has hurt their architecture somewhat and also that Plan 9's biggest compatibility problems come not from dealing with POSIX/ANSI, but with dealing with non-standard GNUisms.