Some weeks after Neal Walfield implemented POSIX semaphores for libpthread, Marcus Brinkmann has now implemented SysV shared memory for the GNU Hurd in glibc, based on some earlier work done by Neal. This was probably the last commonly used POSIX feature missing in the Hurd, and having shared memory available will make several programs work much better.
Now I’m sure that Hurd will be ready next year.
I’m always happy to see the Hurd making forward progress.
Hurd is just a kernel that is completely useless except to Stallman so now he can say he has a complete GNU system that doesn’t depend on Linux. I feel sorry for the people that are working as slaves for Stallman.
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.
curious to see what hurd performance and stability will be like when the project matures to a higher level
I think you people shouldn’t underestimate this project. Even if we all follow it with a smile on our faces it still has some good bits. The entire Kernel architecture is far better than Linux’s and the expandability of Hurd will probably be far better than Linux’s as well. The monolithic approach of the Linux Kernel will reach an end one day. Too many drivers then the mixture of monolithic vs. modules and many more.
Hurd will always be useless because Stallman won’t allow binary drivers.
What is the point of Hurd? Are there even people that actually want it? AFAIK no one gives a crap about it except Stallman who uses it as an extension to his ego whenever someone mentiones Linux. Seriously though, is there even a point in developing this and not taking those resources into Linux?
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”.
Seems to me everyone in this thread bashing The Hurd is in serious need of some RTFD.
You’re totally right. Actually, Stallman has got nothing to do with HURD. Please, trolls, inform yourselves before bashing.
Hurd has been in development since 1993. It has failed to produce anything usable in 12 years. Nobody cares about Stallman and his toy kernel.
It needs copyright assignment so it can’t just steal code from Linux
With people trying to find better & cleaner ways of doing an OS. Probably the biggest hurdle will be trying to get accelerated 3d support out of current vendors.
Also another question, how well will hurd play with Xen?
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.
Hurd should be the perfect playground for future OS hackers. If you have a hankering to build a new OS, just pick which Hurd module to replace and you’ll still have the rest of the modules to plug in to make a credible operating system without a million new lines of code.
The problem with the Hurd is not architectural, it’s a lack of developers coupled with the constant discussion instead of just sitting down and coding.
I still think that it’s a fantastic OS, and will very likely switch to it as soon as a few more drivers become available.
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
Its been in development for 12 years and has not produced anything yet. Its time to give up on the failed experiment.
[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.
The deck of the Titanic looks much better now that you’ve rearranged the deck chairs!
“implemented SysV shared memory”
WOW, this has already been implemented in just about every U*IX (*BSD, Linux) system out there!
HURD will “probably” be usefull by the year 2010, which will really make it useless at that time LOL.
Everyone’s quick to mock HURD’s progress, but their largest impediment is that they’ve decided to make large project changes just when they get things togther.
HURD used to be based on Mach, and was getting pretty far along, when they up & changed to L4, and had to rewrite a massive portion of the codebase.
I glad to see progress on the Hurd. It would be great to have a microkernel architecture actually in use, but I have to ask why not Plan 9? Hurd borrows concepts from Plan 9, plus with Plan 9 you get a truly post UNIX operating system with all of the improvements that entails.
Frankly, the effort spent on the Hurd would be better spent on making Plan 9 a widely useable OS.
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.
Though all this seems like very basic stuff, it looks like they already have XFree86 and mplayer running. Given that those applications weren’t written with the Hurd specifically in mind, I’d say that’s quite a feat.
As for Linux: I don’t think its design is flawed, I think it’s realistic. Doing things the `right way’, like the Hurd claims to do, seems to take quite some time. I’m glad we can use Linux while waiting for the Hurd to finish
.
Actually, they got KDE running on Hurd
http://lists.debian.org/debian-hurd/2005/06/msg00056.html
While you can use Linux while you are waiting for Hurd, a lot of developers are working only at the Linux kernel, the result might be that you need to wait longer for Hurd then without Linux existing
good point. you should check your than/then issue. common to german speakers – and maybe others too
Riiiiight… Unfortunately way too many Americans *also* have this “than/then” issue. Not to mention “their”/”there”/”they’re” and “too”/”to” issues…
And don’t forget the “you’re/your” and “loose/lose” issues.
Hurd has failed and its time to move on.
One could say much the same thing about your tiresome trolling.
Linux is way overrated. It’s a HUGE MONOLITHIC MAINFRAME SERVER kernel. Not the best for a desktop.
One flaw in the kernel will bring the whole os down. I think this is what a microkernel prevents.
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.
One of my Linux annoyances is the need to recompile drivers every time the kernel is upgraded.
Does HURD suffer from this issue?
One of my Linux annoyances is the need to recompile drivers every time the kernel is upgraded.
Does HURD suffer from this issue?
————————————
I don’t know, but knowing Stallman, probably. He wouldn’t want to do anything that would allow for binary drivers and actually make the Hurd useful.
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 🙂
that you can transition easily to a new operating system while keeping backwards compatability.
So while we’re stuck in the dark ages of, “everything is a file”, we can graduate more towards like objects — think smalltalk and the like. Where things are more dynamic, plugable and specialized.
It’d be great when memory managers and schedulers will understand subtle nuances of a program, like it’s specifically allocating an object, or if something is explicitly of some data type rather than a blob of bits and this thread is a worker and can be dynamically scheduled via some standard interface.
I see people claiming that the HURD is a superior design. As has already been pointed out, development on HURD predates that of Linux. If 15 years of work is not enough to get out a functional 1.0 release, what does that say about the design?
I also see people claim that the problem is that they keep changing directions in midstream, swapping out microkernels, etc. So what does that say about the design?
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.
It’s ABI.
“I’d like to see both HURD and Linux prosper.”
Me 2, but I REALLY want to use the Hurd. I just hope it is finished before I die.
Is to pick a point on the learning curve and make a kernel that is well-documented, and an easy on-ramp to understanding an OS kernel.
Once the newbie mind is calibrated, stepping up to an enterprise-kernel like Linux might not be as hard.
Hurd’s design has much more potential of being enterprise-level in the following years then Linux’s design – however, only if it once would have caught up. That is a problem with the (current) implementation of the design.
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?
I appreciate the news flowing in about Hurd. Keep up the good work osnews.com!!
The microkernel is really an old concept, that is very true, and what are we using today? Still monolithic kernels. What is worse about it – those are still developed with a lot higher developer count.
it’s what can be done tomorrow with HURD. See, a scalable architecture like HURD, you can do greater things with greater ease.
Wondering when (if ever) it’s really gonna be usable. I mean, ok, 10 or 11 years ago PC’s were were not as widespread as today. Not as much different hardware to cope with as you have today. Hardware support will be a pain as it is with most other OSses. Linux is doing fine in that area, at least it’s the only OS (next to that other one) which has a wide range of hardware support.