OSNews

I think GNU/HURD is the biggest free/open source project that actually serves research purposes and is not just implementation of well known principles. That's great.

Who gave a crap about Linux in 1991? Look at what has become. I'm a Linux user and _I_ want it. If it works well I might even switch one day. Why is it so bad there are other options to choose from?

Assuming that you are a "linux user" and not a "linux programmer", I think the point is that one day you'll make the switch without even realizing it (except, hopefully, an increase in stability, security, and efficiency of the use of your system resouces). That is definitely a good thing :-)

And, if you're a linux programmer, you'll probably make the switch as well; you'll just realize it as you're doing it...

Yes, there are people who want it. The HURD has several architectural merits, mostly deriving from its multiserver architecture. Security through the multiserver model, and flexibility through translators is frequently mentioned, but there is more. Consider L4/HURD's hierarchical pager model. This model gives much more flexibility with regards to virtual memory, and enables new techniques to optimize system performance. For example, traditional VM systems don't interact well with garbage collectors. You could have a "GC-aware" pager that would be assigned to certain processes, while having a regular pager assigned to processes without a GC. A system that flexible is too complex to put in a kernel, but becomes palatable when put in userspace.

Linux, from a conceptual standpoint, is hardly elegant. It works, but its not clean. Consider the implementation of FUSE in Linux, or hotplug or udev. The Linux developers realize the benefits of putting things in userspace, but because of Linux's underlying design, they have to take an ad-hoc approach.

I realize there must be some things that actually are better/more usefull than what is available now, but wouldn't it be much more convenient to put that force into Linux. It took Linux 14 years (maybe less) to become something useful (and Linux has a far broader community supporting it) and it took HURD like 15 years to even run a program on it. Even if it does get finished, history teaches us that what is better is not neccessarly more used. How many years did it take Linux to replace old Unix? And to think about all the drivers they would have to rewrite.

Don't get me wrong, I love people to experiment and make something better/advanced but in this case it looks to me that Stallman has an issue with Linux and wants his own OS.

The 30+ year old design of *nix has fundamental design flaws that are too deep to fix. There's only so much you're going to be able to tack onto the old infrastructure before it becomes totally unworkable. The Hurd (started in 1985, BTW) is one of several attempts to fix those fundamental design flaws. It has little if anything to do with RMS's feelings toward Linux.

Sorry that should have said 1990. GNU was started in '85. The point still remains that the Hurd predates Linux's existence.

Remember: "GNU's Not Unix". Linux is a unix clone, essentially. HURD is very different. As far as GNU is concerned, Linux was never more than a stopgap.
HURD has grown larger than Stallman, and I for one look forward to the day when it takes its rightful place among top-of-the-line OS's. I'd like to see both HURD and Linux prosper.

There is no way to put this stuff into Linux without rewriting it. Gradually moving stuff out of a monolithic kernel to make it a microkernel sounds like a good idea in practice, but the experience of Mach shows that doing things that way is a sure path to terrible performance. As the G2 microkernels show, the only way to get a high-performance microkernel is to start with a tiny core with really fast IPC (like L4), and build a userspace with the performance characteristics of a microkernel in mind.

That should read "good idea in theory", not "good idea in practice".

Also another question, how well will hurd play with Xen?

Not at all, unless something has changed very recently.

I'm pretty sure it plays fine with qemu and bochs, though.

To a degree, L4/HURD obviates the need for Xen. The L4 project is working on virtualization methods, and there is always L4/Linux.

Well I read the actual article more closely and they may be making a move to run linux device drivers in a virtual machine with minimal performance impact.

This would be a great start to getting Hurd support and perhaps enough to attract users & developers.

http://l4ka.org/projects/virtualization/drivers.php

[quote]Its been in development for 12 years and has not produced anything yet. Its time to give up on the failed experiment.[/quote]

I'm sure people told Eddison the same thing after he failed about 10,000 times. I wish them the best of luck.

Plan 9 isn't nearly as interesting as the Hurd. It isn't even really a microkernel!

Personally, I prefer the approach Plan 9 took, but I don't ever see it going mainstream. As I see it there are two main resons for this. The first is the lovely little "sue Lucent for any reason and we revoke your usage rights" clause in Plan 9's license. The second is the fairly steep learning curve associated with the OS.

The Hurd also has the advantage of using familiar software. Plan 9 was created with the explicit purpose of leaving all the old *nix cruft behind.

The Hurd also has the advantage of using familiar software. Plan 9 was created with the explicit purpose of leaving all the old *nix cruft behind.
---------------------

That's exactly why I would like to see a push to Plan 9 rather than work on the Hurd. However, since that isn't happening I will take the Hurd because it is an improvement.

I just looked over the Lucent Public License V1.02, and there's nothing in there about revoking usage rights for litigation for any reason against Lucent. What it does say is that if "a Recipient institutes patent litigation against a Contributor" they revoke your rights to any of the patents in Plan 9. You also lose the right to use anything that happens to be patented in Plan 9. You also can have your Plan 9 license revoked if you fail to comply with the terms of the license, but that is fairly standard.

Mea Culpa, my wording was a bit misleading. It does indeed only cover patent litigation, but that's still a bit too vague for comfort. Say you find yourself pursuing a lawsuit with a contributor over a patent completely unrelated to Plan 9. Under the terms of the license you lose the right to use any patented components of the OS.

I agree that Plan9 has some interesting things to offer. (Most importantly it shows how filesystem servers, i.e. translators, can actually be used to build applications; while the Hurd still concentrates on the low-level system stuff...)

However, the Hurd is much more interesting in other regards. For one, it doesn't borrow from Plan9. Both systems were designed at about the same time. The fact that they both came up with similar concepts (file system as generic namespace, translators etc.) can be seen as some kind of reassurance that the concepts aren't that absurd after all :-)

Plan9 isn't really a microkernel. It puts filesystems in userspace, but that's about it. (Note that this is possible even with Linux nowadays...) Otherwise, it's a totally monolithic system. None of the enormous flexibility and convenience of the Hurd approach.

Also, Plan9 has no POSIX compatibility, which makes its application much harder. Hurd allows using POSIX compatibility, but also going beyond POSIX seamlessly.

Furthermore, Plan9 has some very specific concepts built deeply into the system (central storage/backup etc.); the Hurd is much more flexible in regards of application areas.

And that doesn't even cover the additional advantages of the upcoming Hurd/L4. (Resource management etc.)

All in all, while I consider Plan9 superior to traditional Unix systems, the Hurd goes much farther.

Also, Plan9 has no POSIX compatibility, which makes its application much harder.

That isn't entirely true. Plan 9 does provide the APE (ANSI/POSIX Environment) subsystem to help facilitate the porting of apps.

Actually, they got KDE running on Hurd

http://lists.debian.org/debian-hurd/2005/06/msg00056.html

One could say much the same thing about your tiresome trolling.

Why is that a problem? I have the computing power of around twenty Cray 1s on my desktop, so letting a huge monolithic mainframe server kernel take 0.1% of my cpu time is of little consequence.

Maybe, maybe not. It will depend on how (and where) the specific driver is implemented.

> One of my Linux annoyances is the need to recompile drivers every time the kernel is upgraded.
> Does HURD suffer from this issue?

Yes, the present Hurd implementation on Mach sadly suffers from the same problem. The upcoming Hurd/L4 will allow for an independant driver framework however :-)

It says two things:

1) HURD doesn't have nearly enough people working on it;
2) HURD's design has changed since it was conceived.

Mach wasn't a good design, I don't think anybody will argue that anymore. But the HURD isn't Mach, the HURD is a multiserver built around Mach. The fact that Mach didn't work out doesn't mean there is anything wrong with the rest of the design. The thing is, back when the HURD was envisioned, Mach was the state of the art. Since then, the second-generation microkernels have come out, and have fixed the basic design flaws of Mach and its ilk. The fact that HURD has gone towards L4 doesn't malign the design of the HURD, it just shows that the team is willing to take new knowledge into account in order to make the design better.

The HURD predates Linux. In the world of Free software, the advantage was the HURDS. In addition to having started first, it had the credibility; the mindshare if you will. (Who in the world knew who Linus Torvalds was back in 1991? But GNU was an established "brand".) And the HURD fumbled.

Freax, uhhm, Linux, came from behind and blew HURD away when HURD held all the high cards. Now what makes anyone think that the HURD is going to do any catching up?

Enterprise Level? I think you have to have at least a 1.0 release to be Enterprise Level. And a few features, too.

OK, they have an implementation of shared memory. How's their SMP? Unix has been doing SMP since the late 1980's. Linux since the mid 1990's. How's HURD doing on SMP in 2005? Does it exist? Is it scalable? How many processors does it scale to? What subsystems are still serialized, negatively impacting SMP performance? These are questions that Linux started dealing with over half its life ago. Has HURD even gotten to them yet? Despite the fact that the HURD started first?

I'm glad that the HURD's developers have an interesting and rewarding project to work on. But let's keep things in perspective.

The HURD is a pie in the sky idea that didn't thrive.

> OK, they have an implementation of shared memory. How's their SMP? Unix has been doing SMP since the late 1980's. Linux since the mid 1990's. How's HURD doing on SMP in 2005? Does it exist? Is it scalable? How many processors does it scale to? What subsystems are still serialized, negatively impacting SMP performance?

If that's all you are thinking about, the Hurd certainly isn't for you, at least not for the next 10 years or so. Hurd is for people that are able to look beyond such details like raw performance, who see the enormous advantages of getting beyond the limitations of a monolithic kernel. Performance is a side issue that still can be fixed at some point. (The foundations are certainly there.)

No. I'm not just thinking about details like raw performance. I'm looking at what the HURD has been able to accomplish in 15 years. We're talking basic features here, not just performance. And it is simply unimpressive. And not from just a technical standpoint. The HURD has been unable to generate much developer interest. You seem to see them blazing trails and going Where No OS Has Gone Before. But there are other OSes out there that are microkernel. They decided to do it and they just did it and it didn't drag on for 15+ years. (The microkernel is really such an old concept. It's hard to believe people still consider it to be avant-gard.) Where are the throngs of enthusiastic developers who see its wonderous potential?

Call me when the HURD is a real contender. Until then, it is simply a research project that I'm sure gives its developers much joy. My disagreement is more with people who are prematurely implying that it will be victorious before it has proven itself in any way, shape, or form.

What can I do, TODAY, with the HURD, that I cannot do with an existing monolithic kernel?