Slashdot Mirror
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."
Now they can begin porting Duke Nukem: Forever!
Send email from the afterlife! Write your e-will at Dead Man's Switch.
That's the difference between OSS and proprietary companies. They can focus like a laser on what they want to develop and leave a lot of the infrastructural heavy lifting to those hippy anarchists in the open source scene.
It's win-win for them, because they get the benefit of a lot of what these groups produce, and often can improve upon it (BSD --> OSX). It's like having an unpaid R&D dept. working for you 24/7.
Hi Marcus,
How many people do you think will submit questions thinking that this is a Slashdot interview?
GNU made most of the core programs that Linux normally uses, and they are universally considered excellent. So why is it so hard for them to make a kernel?
Is it just loss of interest after Linux became popular?
# cat
Damn, my RAM is full of llamas.
This was in 1991...
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
The kernel is the last missing piece? What's the first piece, an integrated browser?
Damn, wrong button!
Get a free iPod Nano 4GB!
http://dilse.net/hurd.html
It's the device drivers, stupid!*
*The Hurd will go the way of other exotic and unused operating systems if these people continue to sit in their little dream castles and plan for world domination. It's like trying to row a Viking longboat without oars, trying to grill meat without a fork, or more to the taste of our slashdot crowd, trying to masturbate with one's hands tied behind one's back.
What a waste of time. What are they trying to accomplish by still working on the HURD?
Be fair: let us all know what you do in your spare time so we can sneer at you too.
The real Ralph Yarro posts as Anonymous Coward. Anyone else is an impostor.
I have no idea why Linux became more popular in the first place, considering that there was already BSD and the HURD, but it's current popularity has pretty much killed any chance HURD had. BSD still has enough adherants that it can be continuously developed, but HURD never did. All the programmers who a) have the expertise required and b) are willing to work for free, are working on either Linux or BSD. I think HURD offers interesting possibilities, but I don't think a stable HURD will ever see the light of day. The fact is, Linux is a free kernel, it works well, has reasonable driver support, and is here now. That will be a big obstacle for HURD to overcome.
Actually, the free developers are the one who focus like a laser on what they want to develop. At a Big Dumb Company(tm) the developers may not focus as sharply as the "decision makers". Here, the decisions are made by the developers and hence there is better focus on the goals. If it were universally agreed what the goal should be, everyone would focus. Since it's not a given, people will latch onto things others may think are unnecessary. My own experience shows that most people will not be convinced that an alternative is better until you show them. That means those interested in the Hurd must build it and show the rest of you. Only then should we decide.
You can't get 'too many' open source kernels. All right, the HURD is old, and development is slow. But at least it is another choice.
Consider the alternative if GNU project wasn't started by RMS... even Linux wouldn't have been around...
It's theoretically going to be much better. Revolutionarily so in fact. This is a deliberate design decision since the rise of linux: loads of experimental, potential "next big thing" ideas are going into hurd. Linux works, so hurd is trying to make something that's much better, rather than slapping together a working kernel and worrying about the architecture later which is what linux does.
I am trolling
Think of it more like OS research. Lessons learned from HURD can be applied to *BSD and Linux. Some already have.
Almost everyone who has started with a "pure" microkernel design has eventually moved away from it for performance and other reasons.
Many of the problems HURD was trying to address have either become irrelevant, determined to be non-issues, or have been solved. (The same can be said of things like IA64 or SPARC).
There are still interesting ideas in HURD that deserve research. However if they intend to challenge the enormous momentum behind *BSD and Linux, HURD is going to have to offer some truly astounding functionality / killer app or few people are going to use it.
"My own experience shows that most people will not be convinced that an alternative is better until you show them."
And hence academic research. Like Xerox Parc.
There is a pretty simple reason for that... The idea behind this naming scheme is credit given where credit is due. Linus and co. created Linux, GNU created the GNU stuff (gcc/bash/utils). Thus, GNU/Linux.
But the HURD is by GNU people, so you don't need to have any other credit given when you're mainly packaging it with the GNU tools.
Not that I call it GNU/Linux anyway. It cleaerly ought to be "GNUlix".
*is run over by rotten tomatoes*
What a waste of time. What are they trying to accomplish by still working on the HURD? Linux has already far surpassed it in every catagory (hardware support, software support, usability, performance, etc.) and is just as Free as the HURD, so what gives?
On the other hand, I guess I'm not the only one of this mind, as it obviously wouldn't have taken 20 years to get to the point where a program can finally run on it if everybody else with development skills didn't also believe it a total waste of their time.
From the interview:
Security and stability are tightly related issues, and they are major motivations for any microkernel based system. However, we feel that security does not need to translate to loss of freedom. With a bit of extra trouble, you can be secure and even increase the freedom of the user. This is what we want to do.
In the Hurd, the operating system is implemented as a set of servers, and each runs in its own address space. Of course there are some essential system services which better not crash, or the system will reboot immediately as a last attempt to salvage the situation. But for many other services, a crash is not fatal. If a filesystem server crashes (except for the root filesystem), you can just restart it (or it is restarted automatically by the system). Dead-locks require manual interaction, and you will have to kill the hanging server to remove it from the system and release associated resources.
The Hurd achieves its stability and security by protocols between components that require no mutual trust. So, although a user can add their own filesystem to the filesystem hierarchy, and the parent filesystem will redirect accesses through such a mount point to the user's filesystem, there is nothing the user's filesystem can do that can affect the rest of the system in a bad way. The Hurd servers are written in a way to assume the worst from a communication partner, namely that it is malicious, as an implication you get fault-tolerance for free.
"It's theoretically going to be much better."
This is why so many projects fail. They try too hard to create a mythical overdesigned piece of software that "works in theory" rather than create something that works and then improve it from there.
It's not about making a kernel that works - if it was, then, yes, Linux has done that. This is about the benefits of microkernel architectures, as opposed to monolithic kernels.
If nothing else, the HURD development will pave the way for other microkernels in the future. And they will come - you don't think we'll be running the Linux kernel for ever, do you?
No trumpets, no drums.
2. "unveiled the Hurd in 1990s, which is currently a functioning prototype" -- so, ~15 years (fifteen years!) later, it's still a "functioning" prototype!?
Operating systems develop slowly in their core design and philosophy, and that's no bad thing.
Linux literally exploded into existence, but its design is 80% identical to that of original Unixes so it enjoyed the immense benefits of inherent architectural stability. Linux knows where it's going, but the horizons surrounding the Hurd are very fuzzy indeed. It will take time.
Debian/HURD was "delivered" years ago, but due to limitations of Mach, was underwhelming. It was and is a fully functional OS, though. This new article is "We've gotten rid of our ancient Mach stuff and have ported to L4 which sucks less".
:-)
Theoretically, HURD servers could be ported to a cut down and modified for efficient message passing linux, even, though I don't think anyone has bothered to date.
But lessons from HURD design have been applied to various aspects of linux. The project is not a waste of time. Linux still doesn't have comparably powerful filesystems to HURD (or Plan9 or even AmigaOS...), though unionfs is slowly getting there. Without those that went before, linux would likely have made all the mistakes they made.
And hey, GRUB was written to suppot HURD needs, primarily. If it hadn't been for that, we'd all still be stuck with LILO
You may mock - but GCC was the only *free* compiler around that Linus could use, plus the GNU tools (bash, grep etc. etc.).
While we're on the topic of microkernels, wouldn't it be a good idea to gradually make the linux kernel less monolithic, finally turning it into a nifty microkernel based OS? Is there anything going on in this direction?
Could you please stop interviewing him and let Marcus get back to work? If you keep interviewing him, we're never going to see Hurd in a usable state.
It's not offtopic, dumbass. It's orthogonal.
Reminds me of the joke about the new bride who's thinking about getting an annulment for her marriage to a computer engineer.... "Every night he just sits on the edge of the bed telling me how great it's going to be."
This is why so many projects fail. They try too hard to create a mythical overdesigned piece of software that "works in theory" rather than create something that works and then improve it from there.
Ah, the grand old dispute between academics and business people. Linux wouldn't have existed without some quite theoretic early approaches (Babbage, Turing, von Neumann). After all - who cared about the early computers like Babbage's analytical engine? An abacus would be much faster for all relevant computations!
Without theoretic deep-dives like HURD, we would never know if microkernels are a possibility or not. Because it hasn't been proved to work yet. The HURD theorists suggest that microkernels are better than monolithic kernels. Let them explore it, make prototypes, and then someone will make a working kernel to play Duke Nukem Forever on.
Remember: a lot of research just discovers uselessness. It is important to know what's useless, so no-one have to take that path.
Roses are #FF0000, violets are #0000FF, all my base are belong to you
Well..it's important to have people out there trying to apply these theories...even if they fail. Otherwise, progress wouldn't happen.
BenCurry.net
i see many opst here and i wonder if y'all know that HURD has a key feature, namely:
>>it should become possible to replace a running kernel
in other words NEVER REBOOT AGAIN!
in practise this is still hard to accomplish: but at least people are working on it. and yes, to implement this takes time.
GNU/Hurd is still developed, because it has interesting capabilities, capabilities Linux will never have. IMHO, Hurd is the kernel of the future.
Btw, Hurd will be compatible with a lot of linux' device drivers (i heard all linux 2.0 device drivers were ported, but I could be mistaken) , and imho, device drivers aren't the main job of kernel developers, but of hardware makers. That is a bit unrealistic at this time, though, but it should be.
Many of the posts above say Hurd is a waste of time. I suspect the Hurd team just enjoys hacking. I really don't think they care if its a "waste" of time. They just love what they do. I think it's awesome to be so dedicated to your craft. Even if the Hurd never works... I bet they will still look back on the whole experience as something pretty cool.
My own personal experience: I worked on an 8 month student project that in many ways failed in the end. But I would never consider that a waste of time. I learned so much and had a blast doing it.
-bdb
No, not really. Unless they have very, very patient funding sources, academic projects can't survive indefinitely this way, either...
There's no infighting where you work?
Who do you work for and where can I send my resume?
I rarely criticize things I don't care about.
A microkernel design (while exceedingly elegant) was usually dismissed as being too slow (since the kernel was usually stuck sending tons of messages between these different services). However, we've proven time and time again that at a certain point ... performance becomes a secondary concern to maintainability and security/stability. Microkernels make that tradeoff and there are quite a few areas where this makes a lot of sense. Please read the original discussion between Linus and Tannenbaum circa '91 where they hash out WHY these things are different (it's a great read)
Well, unless we looked at the Amiga OS, QNX, or any of a large number of (actually working) microkernels in academia...
I am TheRaven on Soylent News
From: ast@cs.vu.nl (Andy Tanenbaum)
Subject: Re: LINUX is obsolete
"I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful you are not my student. You would not get a high grade for such a design"
To Linus Torvalds.
Don't any of those folks get the concept of R & D?
Think of the Hurd as a testing ground for cutting-edge OS ideas. Someday, it may result in an extremely scalable, secure and flexible operating system for servers that leapfrogs Linux, BSD, Solaris, OS X etc. Or it may languish as a mere experiment, providing valuable ideas and experience that trickle into existing operatings systems. Either way, everyone benefits.
In what way is Unix stuck in the past ? What defect, exactly speaking, threatens to kill it ?
Why ?
What flaws in Unix does a microkernel fix ?
Can you give examples of such insights which would make Unix better ?
Why ? Unix works, you said it yourself. What benefits does OOP (in the context of OS design) has that totally blow away the competition ?
Well, it is rather difficult for anyone to argue against the claim that they have done something without knowing it, because, if they had done it they wouldn't know it :).
Have you been reading Dilbert lately ?-)
Yes, there's certainly been a mass exodus away from Linux lately...
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Except that GNU was started for software freedom years before the open source movement existed. GNU was not about pushing anything "open source". Making a fork of GNU into a proprietary OS would definately not be considered any kind of advantage because such a program would deny software freedom to its users. Nor is the focus of the free software movement an issue of perfecting a development model aimed at rallying unpaid labor to work on one's program.
I suggest learning more about the difference between software freedom and what the open source movement is pitching.
Digital Citizen
I strongly agree with the OP. Even if HURD never competes with Linux, it's still important as a research project.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
Linux is slowly moving that direction, in a natural-selection sort of way. Initramfs and klibc ("early userspace") will allow things like root-on-nfs and in-kernel DHCP (which arguably shouldn't have been in the kernel in the first place) to move to userspace, but developers are already beginning to talk about using it to put things like partition table parsing and console terminal support into userspace as well. I'd guess that more people will start to see applications for early userspace once it's "complete" and distributions start using it (initramfs is already in the kernel; it's the anomalous rootfs that shows up in /proc/mounts).
Filesystems and the network stack are never going to move to userspace, though; Linus is dead-set against it, for the same reasons he always has been. If you were completely batshit, you could probably convince FUSE to run from initramfs, and get wholly userspace filesystems that way, but FUSE doesn't support any non-network filesystems, AFAIK.
"That's all I have to say about that" --Forrest Gump
This is why so many projects fail. They try too hard to create a mythical overdesigned piece of software that "works in theory" rather than create something that works and then improve it from there.
Like Netscape?
-1 Uncomfortable Truth
You can try Hurd/L4 right now by burning a bootable CD (iso) using the Gnuppix.
You can read the interview through its Coral cache or its MirrorDot cache . There is also a Google cache.
There is also a MirrorDot-cached PDF version of the interview that can be downloaded by clicking here.
Thanks
having adminned variously HP-UX, AIX, Irix, and Solaris boxes, one of the first things I did on a machine was install the gnu toolset. The proprietary stuff was years behind (Solaris was probably the worst) and getting almost anything modern to compile with them was a real bitch.
None of the OS X operating system (or its precedessor, NEXTSTEP) has ever been in Objective-C, unless you count the NEXTSTEP DriverKit (which has been redone in C++ for OS X, IIRC). All the Objective-C stuff has been above the operating system at the application level.
For those with Non German Language Disorder here a rough translation:
"Dilettants! Dilettants! - so are those called, who are doing a science or an art, out of love or joy for it, per il loco diletto, with disrespect by those, who do it for the gain, because they like the money that can be earned by it. This disrespect is founded in the mean conviction, that no one seriously does anything if not forced by misery, hunger or another greed. The public has the same mind and thus the same opinion: from here comes the full respect for "people of the craft" and his mistrust for dilettants. In reality for the dilettant the thing is the end, for the craftsman it is just means; only he will do a thing with full seriosity, who is immediately interested, and who is occupied by it out of love, does it con Amore. Those, not the paid servants, always started the greatest things."
VM is really a hypervisor, or "virtual machine monitor". The abstraction it offers to the application looks like the bare machine. So you have to run another OS under VM to get useful services.
The PC analog of VM is VMware. VMware is much bigger and uglier than VM because x86 hardware doesn't virtualize properly, and horrible hacks, including code scanning and patching, have to be employed to make VMware work at all. IBM mainframe hardware has "channels", which support protected-mode I/O. So drivers in user space work quite well.
QNX is a widely used embedded operating system. It's most commonly run on small machines like the ARM, but it works quite nicely on x86. You can run QNX on a desktop; it runs Firefox and all the GNU command-line tools.
QNX got interprocess communication right. Most academic microkernels, including Mach and L4, get it wrong. The key concept can be summed up in one phrase - "What you want is a subroutine call. What the OS usually gives you is an I/O operation". QNX has an interprocess communication primitive, "MsgSend", which works like a subroutine call - you pass a structure in, wait for the other process to respond, and you get another structure back. This makes interprocess communication not only convenient, but fast.
The performance advantage comes because a single call does the necessary send, block, and call other process operations. But the issue isn't overhead. It's CPU scheduling. If the receiving process is waiting (blocked at a "MsgReceive"), control transfers immediately to the receiving process. There's no ambiguity over whether the message is complete, as there is with pipe/socket type IPC. There's no trip through the scheduler looking for a process to run. And, most important, there's no loss of scheduling quantum.
This last is subtle, but crucial. It's why interprocess communication on UNIX, Linux, etc. loses responsiveness on heavily loaded systems. The basic trouble with one-way IPC mechanisms, which include those of System V and Mach, is that sending creates an ambiguity about who runs next.
When you send a System V type IPC message (which is what Linux offers), the sender keeps on running and the receiving process is unblocked. Shortly thereafter, the sending process usually does an IPC receive to get a reply back, and finally blocks. This seems reasonable enough. But it kills performance, because it leads to bad scheduling decisions.
The problem is that the sending process keeps going after the send, and runs until it blocks. At this point, the kernel has to take a trip through the scheduler to find which thread to run next. If you're in a compute-bound situation, and there are several ready threads, one of them starts up. Probably not the one that just received a message, because it's just become ready to run and isn't at the head of the queue yet. So each IPC causes the process to lose its turn and go to the back of the queue. So each interprocess operation carries a big latency penalty.
This is the source of the usual observation that "IPC under Linux is slow". It's not that the implementation is slow, it's that the ill-chosen primitives have terrible scheduling properties. This is an absolutely crucial decision in the design of a microkernel. If it's botched, the design never recovers. Mach botched it, and was never able to fix it. L4 isn't that great in this department, either.
Sockets and pipes are even worse, because you not only have the scheduling problem, you have the problem of determining when a message is complete and it's time to transfer control. The best the kernel can do is guess.
QNX is a good system technically. The main problem with QNX, from the small user perspective, is the company's marketing operation, which is dominated by inside sales people who want to cut big
I'm a little irritated with all the naysayers.
Linux hit a point of diminishing returns about 2 years ago. While it is a decent kernel, there is definitely an increasing need for something like HURD.
It is not a waste of time if it means I never have to press a power button because kswapd crashed again.
It makes me smile that the next big step for the hurd seems will be a move away from a (technically inferior) GPL'ed microkernel (GNU Mach) to a BSD Licenced one (L4Ka Pistachio), but to see the 2 greatest visions of free (BSD freedom and GPL freedom); which have occasionally been perceived as 2 completely seperate camps software feeding one another in this way is quite a lovely thing to behold. Don't know how RMS takes the the hurd's steps away from GNU Mach or GPLed OSKit Mach though - it might mean that the final brick of GNU performs significantly better when running on a BSD Licenced brick than on the equivalent GPL'ed brick :-)
Try NetBSD... safe,straightforward,useful.
Hurd, huh? Hey, how's that project going, anyway?
#DeleteChrome
1) What is good then?
2) GNU utils are broken? WTF? Whatever you say, they are certainly not very buggy.
# cat
Damn, my RAM is full of llamas.
In what way did I confuse anything in my post? I totally agree with Schopenauer.
Roses are #FF0000, violets are #0000FF, all my base are belong to you
You are stuck in a very narrow-minded definition of academic. Studies into "fire", for instance, didn't need much funding, and weren't very successful for a long time. Yet, they seemed to cope. Same thing with a lot of different academic areas of interest. They don't need any funding, they are driven by pure interest.
Roses are #FF0000, violets are #0000FF, all my base are belong to you
GNU's not unix, its an inferior work-alike that serves no purpose.
Serves no purpose? That's funny. Currently, it serves a lot of my needs. I believe that the purpose of the tools is to serve user's needs, but I might be mistaken. Enlighten me.
Roses are #FF0000, violets are #0000FF, all my base are belong to you
There's a spectrum of issues in the computing world, that range from computer science, which involves doing things where you don't know what the algorithms are to do what you want and have to invent them, to software engineering, which is building something which is extremely well known and understood.
Open source projects are on the whole better, or at least achieve success more quickly on software engineering problems than computer science problems. Writing a word processor is a software engineering problem. It's not like the concepts are not well understood and well documented all over the place, the trick is just building a solid and reliable instance of it. Because it's such a simple and well known problem you can bring in dozens to hundreds of programmers to work on it and there are few debates about how to do things, it's usually more an issue of prioritizing feature lists and bug fixes.
Linux is a software engineering project in the classic sense. Linus and others have been rebuilding Unix, which is extremely well understood. Everyone more or less understood and agreed on how Unix systems work. It's not a question of how to build a memory management algorithm with acceptable performance, but rather which existing algorithm has the best peformance. In general, Linux tends to spend more time debating between existing solutions than trying to find a solution to a problem. The reason that Linux has come so far so fast is that it's treading on extremely familiar ground and isn't really trying to do anything new from a computer science level.
Hurd is more in the area of computer science. They don't have thirty years of precedence going in their favor. While there has been plenty of work in microkernels, there's far less of work there than for Unix. The Hurd people are trying to make something new, rather than reinvent something that's familiar, which is a much easier task by far. So the fact that the Hurd people are moving more slowly is more an indication of the difficulty of the task.
Now the question is, why work on Hurd at all? Well, the answer to that is the answer to the question of whether or not there are things with a microkernel that you cannot do with a regular kernel, and whether these things are worth doing. It is entirely possible on a security level for Linux to hit a dead end, running into the limits of a monolithic kernel architecture. That if there is to be any progress past a certain point, that a rearchitecture is needed to switch to a microkernel architecture. I'm not saying this is the case, but I am saying that it is not an impossibility.
If that is the case, then Linus and others will need to do a major rearchitecture in a new release, or they need to switch over to an existing microkernel project that they feel is acceptable to them. Even if the Linux people decide to do their own microkernel architecture from scratch in that case, they will almost certainly be going over the entire history and the results of the GNU/Hurd project with a fine tooth comb for data on how to build a viable microkernel operating system.
To say that microkernels are slower than monolithic kernels is on some level unimportant. CPU speeds have slowed down somewhat but we're still improving the speed of systems. The question becomes are you willing to trade a performance hit for security. Would you rather have a fast system that is more vulnerable to nasty software or would you rather have a slower but more secure system? So the Hurd people are focusing on security since that is potentially the greatest strength of microkernels over monolithic kernels.
So look at the Hurd project, like a bunch of other projects as a research project. And yes, it's taking them a heck of a long time to get results but they're not in any particular hurry. It's like Linux versus Windows, Linux doesn't need to "win" next year. It just keeps on chugging and eventually grinds away at the opposition. Hurd just keeps getting better every year and maybe someday it will clearly surpass Linux in a few areas. Probably not anytime soon, but this isn't a race.
So no, Hurd isn't a waste of time. It's a research project and one that may be of significant importance to Linux down the road.
The old architecture didn't allow it because of some technical difficulty due to privilege separation. It's not arrogance, it's just that microkernel design fits some things better than others.
You confused a project which gets funded with a project which exists just for itself and for the fun and joy of it. Funding means an external support for something that can't leave out of itself. There are academic projects which can't survive without funding. Most academic projects can't today. But there are other projects in every academic circle that don't need any external support, because it is done by the academy members just for fun. The whole idea of an ancient academy was to solve the funding problem for the members without any connections to the actual projects running there. Either by choosing members who for sure could support themselves as a group (as in ancient Greece), or by having some wealthy entity paying regularily a fixed sum independently from the results of the academy (as in ancient Rome, namely the patrician Maecenas).
To "GNU/Linux" I personally prefer "Linux+GNU".
To "GNU/HURD" as a full OS? Just call it GNU, since HURD is part of GNU.
Moll.
What you hear in the ear, preach from the rooftop Matthew 10.27b
Without device drivers and network code swiped
from Linux, the Hurd would be nothing.
Plus, who do you think does most of the glibc and
gcc development? It's people using and supporting
Linux, generally caring little for the Hurd. The
so-called "GNU" project is built on the back of
Linux, and has been for well over a decade. (and
let's not forget the scraps of BSD code either)
If credit belongs in the name of the OS, then it's
time that GNU stuff be called Linux/Hurd. Better
yet, use "GNU/Linux" to mean that Hurd thing full
of Linux code.
Many of the posts above say Hurd is a waste of time. I suspect the Hurd team just enjoys hacking. I really don't think they care if its a "waste" of time. They just love what they do. I think it's awesome to be so dedicated to your craft. Even if the Hurd never works... I bet they will still look back on the whole experience as something pretty cool.
I agree it's cool, but I think Hurd deservs more credit. I sincerely think that Hurd has a better design, which is why it will eventually be successfull in the real world. Yes I know that there have been lots of better designs out there that never made it beond the lab or a small nitche - but this phenomina is a side effect of proprietary technology, not a natural occurence of design and progression. In the free (not as in beer) world, the technology that is better actually wins out.
I know of no show-stoppers that would prevent anything from working on Hurd that *IS* working on Linux now - even many of the modules. Hurd would simply make it easier to deal with the driver/interface space. Either Hurds main features will eventually make it into Linux (most likely), or the Linux base will eventually come to use Hurd more and more.
Surely the first running programme must have been the screenshot programme?
Atheism is a non-prophet organisation
Hurd/L4 probably won't be ready for release before L4 is considered too old, and so it has to be ported, again, to whatever's current then.
Was the port really more important that actually releasing a finished kernel? How much did that set things back?
Remember then Netscape pissed away their lead over IE by rewriting the project from the ground up?
We apologize for the inconvenience.
LISP is a functional language, not an object-oriented language. Of course, it is so configurable that it can be whatever you want it to be, but I don't think it is very accurate to call this Lisp-based system an "object-oriented operating system."
In the Hurd, the operating system is implemented as a set of servers, and each runs in its own address space. Of course there are some essential system services which better not crash, or the system will reboot immediately as a last attempt to salvage the situation. But for many other services, a crash is not fatal. If a filesystem server crashes (except for the root filesystem), you can just restart it (or it is restarted automatically by the system). Dead-locks require manual interaction, and you will have to kill the hanging server to remove it from the system and release associated resources.
Unfortunately, Hurd won't save us from hangs. Drivers can hang your machine, period. A good example of that is X.org. It runs in userspace, but touching the wrong register on the graphics card will block your PCI bus. Hurd won't be different - be it in userspace or not, if you touch the wrong register you machine will hang. With no oportunity of doing anything.
We already have userspace filesystems in linux - just check FUSE in the -mm tree, or the userspace drivers infrastructure someone posted a couple of weeks ago in the lkml. If "having everything in userspace" starts having sense (which won't have, at least with today's hardware) I'd rather work in porting linux drivers to userspace (like they already did in 2.6 with libusb) than using a OS like hurd, where developers have started doing something so wrong like letting apps to do their own mm.
Warning, your post is full of misconceptions. Lisp was the first ANSI-standardised object-oriented language, actually - CLOS? ringing any bells? And it is accurate to call symbolics lisp machines an "object oriented operating system" - why, Sonja Keene's book "Object Oriented Programming in Common Lisp" uses as its main examples throughout toy implementations of the object-oriented DOS bits from symbolics.
And it's not a "functional language". It's a multi-paradigm language. Actually, ML and Haskell people scorn lisp because lispers won't commit to the functional programming "one true path". You can do functional programming with type inferencing in lisp with a compiler like CMUCL or SBCL. But you don't _have_ to. And lispers, not being the nazis of the purist FP community, like it that way.
So I suggest you get on over to http://cliki.net/ and get clue. k thx bye.
Exploration driven by pure interest is the story of my life, Say. Of course I was referring to institutional academia and the realities thereof, one of which is the expectation that deliverables will be delivered. If the idea is that the Hurd will ultimately serve a broader user community, then the project has clients and would seem to fit that model.
Others have already pointed out how valuable research is, so I'll ignore that for now.
Hurd is also attempting to solve very real practical problems. Consider a typical UNIX network daemon:
(1) Must be started as root to listen on a privileged port
(2) Upon an incoming connection, must accept and then "drop privileges"
This causes mnay, MANY problems, that are very practical. If you took all the remote root security exploits ever in UNIX, and you subtracted those that involved a network daemon that needed to be run as root to listen on a privileged port, you'd be left with a rather secure system.
I just can't imagine why nobody recognizes a problem like that. You don't inherently need to run Apache/BIND/Sendmail with the privilege to overwrite the boot sector, but people ignore it as if "Oh well, it's a network daemon, of course it needs to be able to rewrite the boot sector. We'll just hope there are no bugs.".
Not only is this a security nightmare (which is only mitigated by the fact that UNIX is compared to windows rather than an ideal), but it's also got many performance implications. If you're measuring raw performance of already-written applications, a monolithic kernel will never be worse than a microkernel architecture. However, on a linux system, a lot of resources are traded in order to jump through hoops that don't need to be there, particularly for security. Maybe you don't really need to start that new process, and you can do everything you need in the current process. Sounds like a serious performance win to me, and not "my kernel avoids that 0.1% performance penalty you have to take on operation X".
For example, what about Apache, CGI and suexec? You really don't need all that when you could just be getting/releasing authentication tokens and using an apache module rather than starting a new process just so you can change privileges.
You can't separate the details of performance characteristics from capabilities. Capabilities may cost overhead, but may reduce algorithmic requirements.
Social scientists are inspired by theories; scientists are humbled by facts.
RMS had a reason, like it or not, and it got the name out there. Others don't have a reason so I suggest the age old tradition of those who are in control of a project getting to name it continues.
Call it gnu/linux if you want, but for a very long time gnu has had an OS, and they call it hurd. Linux is a seperate project and not run by gnu.
This is a classic logic fallacy in that you pick and choose the factors that support your argument. The PC didn't win because it was more "open." It won because it was cheaper than the $2000+ priced Macintosh, fueled by commodity PC-clones (remember the phrase "PC-compatible"?) that competed with each other and brought prices down each year.
Well, the Hurd contains lots of Linux kernel code. (it is also used with the X11 and BSD stuff that Linus likes to use) Therefore, by RMS's own logic, the Hurd stuff should be called Linux/Hurd.
RMS of course refuses. It's a one-way street with him. He don't mind gaining at the expense of Linux, but won't return the favor.
The Hurd group doesn't seem to have gotten the message on this. They seem to be going more in the direction of building a platform for OS hacking than getting the primitives right and rock-solid. The latter is the key to microkernel work. If the design is botched, it never recovers.
Once you get a microkernel right, it changes very little. Neither QNX nor VM has changed much at the kernel level in years. They don't need to; everything complicated is outside the kernel. New file systems, drivers, graphic systems, and GUIs are all user programs. This is how you get stability.
Why is it so hard for [GNU] to make a kernel?
Perhaps you don't realize the GNU is a project, not a team or person. Some of the most prominent projects were lead and significantly developed by Richard Stallman, but many other projects were developed by others then adopted by the GNU project, which was mutually beneficial to GNU (helps build the complete GNU system) and the project (increases visibility and contributions).
Here's some of the primary authors of projects (as I understand them): GNU Emacs Richard Stallman GNU C Compiler Richard Matthew Stallman GNU C++ Compiler Michael Tiemann/Cygnus Software GNU C Library Cygnus Software/Red Hat Software GNU Less Mark Nudelman GNU Bash Chet Ramey GNU Grub Erich Stefan BoleynThere is not a great deal of overlap between people and projects. People work on a project because they have skills in that area. They are seldom employed or commissioned by the Free Software Foundation or the GNU Project to do so.
You should also note that many "GNU" projects aren't even first-class GNU citizens. They use external infrastructure such as mailing lists and source repositories, and aren't always developed in the open.
As I see it, GNU is a project that provides an enviroment to encourage free software development, not an entity that produces a lot of software itself.
In any case, no matter the ancient history, the past decade of glibc development has been driven by Linux. Ulrich Drepper is even a Red Hat employee. Since the bulk of glibc development is for Linux, this so-called "GNU" or "Hurd" system ought to credit Linux in its name -- assuming you believe "GNU/Linux" is an appropriate name to saddle Linux with.
You don't work in contemporary American Academia, do you? The sciences and engineering disciplines are expected to do research that will generate money, so that the University can skim 50% overhead to keep English afloat, or build new dorms, or have the Dean laminated. Unfunded Fire research would be closed down if you didn't have a lead on a working product, and you'd be encouraged to go partner with industry on their "edible rock" project.
Someone hacking on the Hurd, and not getting money for it, or at least for some other project that he can redirect money to his Hurd project, is not going to last long enough to make any sort of contribution. American Industry butchered its research labs, the Gov't labs are turning towards Homeland defense and weapons again, and now academia is being told to do industrially useful work, rather than blue-sky.
Frankly, the best hope for some types of research are bored grad students and undergrads, pursuing their own projects out of their advisors' sight.
the more accurate the calculations became, the more the concepts tended to vanish into thin air. R. S. Mulliken
Even Tanenbaum admitted years after the original debate with linus said that he still felt the advantages of Microkernels were worthwhile for a mere 20-30% performance loss.
OSX is certainly slow compared to Linux, it does not even begin to compare. So if it is not linux, what monolithic system are you using for a basis of comparison?
OSX makes for a nice desktop system and the systems are not generally slow, but OSX hardly gets the performance out of that hardware that could be had with a proper monolithic system.
Mach RPC is built on top of Mach ports, but an RPC call is not a single kernel-level operation. So you have the scheduling problem.
Interestingly, although it's very obscure, the kernel call level below mach_msg_send actually does support a combined send/block/receive operation. As the MIT document points out, this "enables certain internal optimizations".
But when you read the GNU HURD tutorial on Mach IPC, you see the suggestion that a program intended to send an integer to another program and wait for a reply should do two separate operations. Somebody doesn't get this.
Also, for no particularly good reason, Mach usually uses the same buffer for both send and receive, so if you use the combined send/receive form, whatever you send gets clobbered by the reply. So using this tends to involve an extra copy.
Mach IPC is incredibly complicated, You have to fill in many data structures just to send something. The implementation is complicated, too. QNX has a nice, simple primitive:
You can probably figure out how to use that just from the definition. Even the reply value is what you think it should be: the receive count if it worked, -1 if it failed, with an error code in errno.
The name of the game here is getting the primitives right.
The Hurd folks aren't implementing L4. They are implementing about the first
serious multi-server system working on top of L4.
(Well, they have also filled some gaps in L4 that nobody else has bother to
implement so far, and provided some considerable input to the L4 folks, by
means of being the first serious multi-server system on top of L4 and observing
how things actually work out in practice...)
Thus talking about "pure microkernel" in the OP is somewhat confusing; it's
more about the system *above* the microkernel more consequently following the
ideal of a microkernel-based system, strict protection domains and all. If you
are really interested in what is so special about the Hurd, take a look at it's
design instead of making assumptions about all microkernel-based systems are
the same...
All my comments get moderated +-0, spotless.
AFAIK OpenBSD does nothing fundamentally new to achieve better security. All they do is try very hard not to let all those bugs slip by that can cause security problems due to the limitations of the traditional Unix design; it's kind of a brute force approach. In contrast, the Hurd design is *inherently* more secure; many security problems just do not emerge in the first place. Let alone all the things you can do with the Hurd not even possible with OpenBSD or Linux or other monolithical systems.
All my comments get moderated +-0, spotless.
AFAIK QNX is an example of a very popular multiserver system. Besides not being free, it has a very good reputation. I don't know how much of the theoretical benefits it actually delivers; but at least it proves a real microkernel-based system is actually possible and can do very well.
All my comments get moderated +-0, spotless.
Actually, Plan9 is mostly about taking "everything is a file" even further. (And the Hurd also, to that matter... Only that Hurd additionally has a radically different internal design.)
All my comments get moderated +-0, spotless.
It's not about defects. Of course it works; nobody will doubt that. It's about
what more you can do with it, and most importantly *how hard* it is to do
certain things.
The fundamental design of Unix was created in times when using a computer
mainly meant processing simple text data; when hardware drivers were hardly an
issue; when timesharing meant: dozens terminals attached to a single computer;
when networks were practically non-existant; when nobody dreamed of graphical
environments, multimedia; and so on.
Looking at stuff like KDE/GNOME, or any GNU/Linux distribution: They do not
follow the often-cited "Unix philosophy" even remotely. They can't. The
original Unix design is just too limited for that. When demands are changing
that radically, you have to extend the paradigms, bring in new ideas, so the
new stuff fits in again.
Of course, with enough effort, you can always fill the needs, somehow,
awkwardly. But how much simpler, nicer things could be for programmers, admins,
and often also the users, with some concepts at the core better suiting todays
requirements?
*That* is why we need innovative systems like the Hurd.
All my comments get moderated +-0, spotless.
> Linux has already far surpassed it in every catagory (hardware support,
> software support, usability, performance, etc.) and is just as Free as the
> HURD, so what gives?
Only that the Hurd doesn't focus on any of those categories. The Hurd focuses
on robustness, flexibility, convenience; on faciliating things that aren't even
possible on monolithical systems, or only in a very awkward fashion.
(Though should the Hurd ever really take off, I wouldn't be surprised if it
will best in the other categories too, in one or another case: The Hurd design
means that once the mechanisms are in place, it's actually *easier* to achieve
many goals.)
All my comments get moderated +-0, spotless.
I worked at a firm that made payroll and accounting software to various Unix flavours. When I got there, none of our machines even had a network adapter. IIRC we had DEC Ultrix, HPUX8, Solaris, AIX, SCO Xenix, and others. The code was sometimes out of sync from one machine to another, and the fixes and upgrades were rolled from machine to machine via removable storage.
Well, I networked the whole bunch, unified the source in NFS, and started to unify the build toolchain to gcc, autoconf, and others. Why? Because we had a lot of different tools, different makefiles, it was a living hell.
In the end of this project, we had one source tree, with 100x less #ifdefs, and even if our systems got bigger in some archs, they were at least 10x cheaper to maintain. Thanks to GNU.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
How is the IPC scheme under L4? Why isn't it comparable to QNXs?
Aren't the problems you mentioned just fixable in the scheduler?
Isn't it enough to boost the priority in the queue for recently-activated threads and to un-boost the prio for threads that recently activated other threads? The former are likely to receive CPU time soon, and the latter are likely to relinquish CPU soon, anyway?
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Yeah, I know. My objection isn't that "everything's a file" is a bad idea. My objection is that other, better ideas have come along, which UNIX by and large hasn't adopted. Plan9's evolution of the metaphor is just one example.
Some of us think Linux is already pretty far along the path to microkernel-hood.
SInce its a 15 year old operating system, at this point things like serial drivers being too slow to keep up with normal transfer rates and being unable to use drive partitions>2GB are fatal flaws.
I still have more fans than freaks. WTF is wrong with you people?
> The variety of different groups of
> people here is enough that you should
> be able to find some element that you
> like.
But vast numbers of people don't tend to distinguish themselves. They tend to homogenise, and then ATTEMPT to distinguish themselves (largely unsuccessfully). While every Linux user group is, indeed, different... they all LOOK the same from the outside. This makes it very difficult to figure out which one is going to have the smart and friendly people who can help you with your problems, and which one is the local chapter of the open source thumb-up-ass brigade.
> it's impossible to generalize
> about the entire group
It's impossible NOT to generalise. How can you productively discuss the community of Linux users without generalities? There are too many of us, as you've just pointed out yourself.
Microsoft cheerleader, blue flag waving, you got a problem with that?
hey, i've just got my first mod-bombing, i think! 3 post of mine in this discussion - which is quite old - were all modded down within a day of each other. i wonder who i pissed off? i wish i knew what i said... so i could repeat it more loudly and often!
i speak for myself and those who like what i say.