KernelTrap Talks WIth GNU/Hurd Developer Neal Walfield

An Anonymous Coward writes: "One of the GNU/Hurd developers, Neal Walfield, was recently interviewed by KernelTrap. Nice read."

Comments

Very interesting

[Gangis]

Yeah, it's a good read. I think anyone who develops using GNU/Hurd should read it. It provides an insight into what he does.

It is

[uchi]

It's a good read. I guess most of you by the time you read this will have read it. Everything he says in here has been told elsewhere, but this time it comes from the horses mouth, so I guess its authorative.

Re:It is

[cmowire]

True.

I think the thing that Hurd is really lacking is a Linus or Theo-like figure with an established cult of personality.

And it looks like Neal's got some hope. He's reasonably pragmatic (important) and can use humor effectively (as in the comment that he hasn't done drugs)

Of course, the problem with Mach is that there's five people working on it, and it's not ready for a mess of people to start hacking on it. It has some interesting ideas, and some really cool directions that it could go in. Somebody's going to have to do some leadership and start setting it on a course from R&D to a real production project sometime.

Re:It is

[Anonymous Coward]

I think the thing that Hurd is really lacking is a Linus or Theo-like figure with an established cult of personality.

Yeah, and interest. Linux took off because there was a bunch of geeks on usenet who were interested in it. The HURD, while it does offer some interesting ideas, and would be a good thing if it ever reached a usable state for the averge geek, has virtually no support. I have to think part of that might be due in part to the RMS affiliation, but that's only a small part of it. Anyways, I think the HURD has a snowballs chance in hell of ever being anything more than a project being hacked on.

Interesting

[Anonymous Coward]

He doesn't deny that the performance sucks, but he feels the added flexibility will be worth it.

What do I doubt this?

Re:Interesting

[Anonymous Coward]

Any sort of microkernel architecture has very little
chance of surviving on any Intel-based
architectures, as context switching is just too
damn expensive (well over 500 cycles to do it
properly). If drivers and other speed-critical code
can't live all within the same context, there's no
way you can get viable performance out of it.

Re:Interesting

[Z4rd0Z]

By the time the hurd is stable and featureful enough for everyone to use, we'll all be using 20GHZ machines. At that point, it may be worth the loss of speed.

Re:Interesting

[Anonymous Coward]

Hurd is right now below 500 cycles for a context switch - eat your words! :)

Look - context switches aren't anything special and what's involved is part of an OS design. Giving a static figure like 500 cycles is silly :)

Re:Interesting

[Waffle Iron]

By the time the hurd is stable and featureful enough for everyone to use, we'll all be using 20GHZ machines.

Its true; betting on Moore's law has been proven to be a winning strategy. Ask Bill Gates.

It makes me think of Windows 95. When I first installed it on a 486/33, it seemed huge, bloated and slow. If I run it now on a PIII/800, it seems to be fast, lean, stripped down and almost elegant. I guess context is important.

Re:Interesting

[aardvarkjoe]

It makes me think of Windows 95. When I first installed it on a 486/33, it seemed huge, bloated and slow. If I run it now on a PIII/800, it seems to be fast, lean, stripped down and almost elegant.

I'm not quite sure that's true. Win95 seemed bloated and slow on the ancient 486/25 I first used it on ... and yet, it's _still_ bloated and slow on new machines. One would think that it would be quick as lightning, and yet I still "click the start button ... drum fingers for a second..." Same really goes for both KDE and GNOME. On the flip side, Blackbox was lightning fast on the first machine I installed Linux on (a 486/66, IIRC), and it seems just as fast on my machine today.

Best explanation I can come up with is that there hasn't been any increase in processor speed in the last 5 years. I'm convinced that they hit a wall around the 386 or so, and have simply been rebranding the same chips every year or so, trusting that we'll convince ourselves that things really are going faster.

Re:Interesting

[duffbeer703]

I've noticed this too.

Fortunately, I have been wearing a tinfoil hat which reflects the government mind-control ray away!

Re:hurd = turd

[phobix]

Read the article. Hurd is not a kernel. It is a set of servers.

They should change the kernel

[XBL]

to Linux. Now, I know they want a microkernel, etc, but I think that the Linux kernel can be built to meet their need much more than Mach, or whatever else they want to use in the future.

These guys also need to consider device drivers. If they want their OS to become popular, it's going to need to support a wide variety of hardware. Linux already offers that.

I really like the ideas of Hurd, but they are not being proactive enough in getting more developers on board. This reminds me of the Atheos guy, who'd rather write the OS himself. One of the best things about Linux is that a lot of people are working on it, and BSD also has a wide developer base.

Hopefully HURD will become more relevant than that OS from MIT. I'm looking forward to trying that out and make some comparisons ;-)

Re:They should change the kernel

[Anonymous Coward]

FYI: the MIT OS was a hoax, BTW.

Re:They should change the kernel

[Anonymous Coward]

Do you know what you are talking about?

I guess not, because you fell for the MIT OS hoax.

You can't put Hurd over a heavyweight Linux kernel. Hurd's dameons, plus a sutable microkernel, is functionally equivelent to the Linux kernel.

Re:They should change the kernel

[Anonymous Coward]

Dude you are dumb as hell... sarcasm... duh

Re:They should change the kernel

[Anonymous Coward]

Did you read the interview? Didn't the guy specifically say that they can use linux drivers as is? (even though they are using micro-kernel; as long as device driver interface is same/similar it's not all that difficult).

Re:They should change the kernel

[jallen02]

*chuckle* I rather think that was a thinly veiled jab at how long HURD has been in development.

Jeremy

Re:They should change the kernel

[maxpublic]

Well, except that the AtheOS guy is much further along than the 'team' doing Hurd....

Max

Using the HURD in production

[Walter Bell]

My employer likes to stay on the leading edge in the operating systems field, and makes it a point to try to integrate up-and-coming technologies into our server farms. It should come as no surprise, then, that our team does use a HURD machine as a file/web/application server.

The HURD machine has been surprisingly stable since we set it up last year. We may have had a few instances where it would get into an undesirable state and need rebooting, but by and large its downtime has been attributable to hardware upgrades and power interruptions. Its integrated userspace/kernel space has provoked us to write some very interesting programs on that box that we would not have been able to create with an ordinary UNIX or clone.

What's interesting about the HURD is that, despite its departures from many UNIX conventions, its developers are striving to form a clean upgrade path from Linux to HURD. Likewise, many HURD features (like POSIX b.1 capabilities) have made it into Linux in recent years. It's too early to tell, but perhaps the future holds a merging of Linux with HURD in a couple of years.

~wally

Re:Using the HURD in production

[Anonymous Coward]

I don't know about you guys, but my Troll Detector is going haywire right about now.

Re:Using the HURD in production

[krogoth]

A merging would probably be beneficial. Linux and HURD both have unique and useful features (Linux's biggest advantage being the very large number of open source developpers backing it), and I would love to see them together in one operating system. Of course, those who are tired of RMS's "GNU/Linux" should buy one-way tickets to Mars if there's any word on this from the people who control them :) Then again, Linux HURD doesn't sound to bad...

Re:Using the HURD in production

[Anonymous Coward]

I'm not so sure. He claims to work at Nasa, where they do all sorts of crazy stuff for research purposes. Of course if it was a business his boss should be fired. But it's plausible that they would have a Hurd box at Nasa.

Re:Using the HURD in production

[ecki]

Hmm, mine isn't. Care to elaborate?

Re:Using the HURD in production

[Anonymous Coward]

%80 of the /. public seems to think that troll==anything they don't like. In this case, that might have been posting for karma or lying. But, upon cursory examination of Will's account, it seems unlikely that he'd do either.

And even so, karma or lying, he wouldn't be a troll.

Re:Using the HURD in production

[Hitokage_Nishino]

The problem being that Linux is largely monolithic in design while HURD is almost completely modular.

Besides, Linus hates the HURD design.

Re:Using the HURD in production

[Anonymous Coward]

that really says something about hurd when people think its a troll that would use hurd in production.

Re:Using the HURD in production

[Anonymous Coward]

Your 'troll detector' is going off because you are a stupid dumb fuck.

Re:Using the HURD in production

[Anonymous Coward]

A merging would probably be beneficial.

The Linux and Hurd design philosopies seem to be very, very different. Almost incompatible in fact (the architectures that is). So merging the two seems highly doubtful.

But that's ok, they seem to be trying to make the Hurd system API as compatible as possible, so you should be able to chose the flexibility of the Hurd micro-kernel or the performance of the Linux monolithic-kernel and still run most of the same applications. And isn't choice the most important part of the *nix culture?

Re:Using the HURD in production

[Anonymous Coward]

So much modular that Linux could run as a user mode process. ;)

Re:Using the HURD in production

[Eil]

Agreed. You might as well hope for a FreeBSD / Plan9 merge or something on that order.

Don't forget, people, that Linux is a kernel, not an operating system. The interview mentioned that certain code from Linux was used in Hurd, but a merging of the two is simply not going to happen.

That aside, with the GPL, Linus has very little to say should someone try and merge Linux and Hurd. :P

Re:Using the HURD in production

[Hitokage_Nishino]

When talking about merging both the projects and mindshare, Linus has a lot to say. Sure you can fork Linux and merge it with HURD, but unless you gather much support you are only merging them in the technical sense.

Re:Using the HURD in production

[Anonymous Coward]

No, he is a troll. He may be in karma whore mode at the moment but his post reveals several clear troll tendencies. Just the use of language is a strong indicator, but here are some real giveaways:

many HURD features (like POSIX b.1 capabilities) have made it into Linux in recent years.

Its integrated userspace/kernel space has provoked us to write some very interesting programs on that box that we would not have been able to create with an ordinary UNIX or clone.
perhaps the future holds a merging of Linux with HURD in a couple of years.

If you know anything at all about the HURD or even just enough about POSIX or Linux, it is clear that those are all typical troll statements.

Also, wcbell@nasa.gov is not a legitimate address.
Also, the group he claims to be a member of no longer exists,

Also, just look at his previous and future posts to find numerous contradictions, plus an unfortunate tendency to "know someone" who works in the field (which by itself does not necessarily indicate a troll, but at least indicates an annoying person).

microkernel == too slow on x86

[Anonymous Coward]

Any sort of microkernel architecture has very little
chance of surviving on any Intel-based
architectures, as context switching is just too
damn expensive (well over 500 cycles to do it
properly). If drivers and other speed-critical code
can't live all within the same context, there's no
way you can get viable performance out of it.

Re:microkernel == too slow on x86

[selectspec]

Let's be frank. It's too damn slow on any CPU. I think Mach (and Hurd) are really great projects, but they appear to be fundementally flawed (messaging+context-switch). I'm very disappointed that the interviewer didn't go into any details on the well-known problems associated with micro-kernel design. Also, I've never heard a really good comparison of the micro-kernel approach vs. the monolithic design with loadable modules (I'm sure there is one; I just haven't heard it). I'd really like to hear the Hurd developer's comments on these issues.

Re:microkernel == too slow on x86

[Espen Skoglund]

Strange. Last time we did measurements here (L4Ka), we ended up with 99 cycles on a 450Mhz PIII to send a message from one process to another. If one has communication within a single task the numbers are an order of magnitude lower (i.e., about 15 cycles).

Re:microkernel == too slow on x86

[Anonymous Coward]

So is this the same guy who trolls every BSD related post and does the "BSD is dying" post, or a new troll?

Re:microkernel == too slow on x86

[Pseudonym]

My first comment is that "performance" means different things to different people. To some it means "throughput", that is, the amount of work that the system can do just prior to being overloaded. To some it means how well it can handle overload. To some it means low latency, that is, that the system can respond to an important event quickly. Which one is important for you depends on what you're doing.

Secondly, you're basing your assumptions on "microkernels" like Mach, which dates from around the same era as the original Windows NT. That's an "old style" microkernel. Back then, we thought that the only advantage of using microkernels was flexibility, so kernels didn't have to be very "micro".

Nowadays we know that merely reducing the kernel's domain of influence doesn't buy you much. You also need to simplify your kernel to realise performance gains. You do lose something (cost of context switch etc) but you also gain lots too, so it's not so much of a penalty, but rather it's a tradeoff.

For example, consider this: Linux often has to suspend a task deep inside a system call. If you call read() on a block of disk which is not in the buffer cache, say, you need to suspend until the block is read in from disk. A monolithic kernel may have to do this for a hundred reasons, depending on which modules are loaded. So a context switch consists of dumping registers on the kernel stack then switching stacks.

Now consider a microkernel. You already know in advance what operations you may have to suspend on, and that number is quite small. (In the read() example, you only suspend on IPC while the server responsible for disk I/O does the hard work.) So you can separate the "front half" of each system call from the "back half". You can come up close to the surface and then context switch if necessary. (Note: You have to do this anyway on a modern system, because a higher priority task may have unblocked during the system call.) Once you've done that, each thread doesn't need its own kernel stack, which makes the context switch a little cheaper, saves memory, makes thread creation cheaper, and the kernel can be made re-entrant, delivering an IRQ in the middle of delivering another IRQ, thus improving latency. It also means you don't need to hack around the problem of signal delivery while suspended. (BSD does this by ensuring that the "front half" of every system call is idempotent, and thus possibly less efficient than it could be.)

So you can see that focussing on the cost of context switching alone can be misleading.

Plus, of course, keep this in mind: if raw throughput was our most important criterion, we wouldn't have virtual memory.

Re:microkernel == too slow on x86

[Sloppy]

"Blahblah is to slow" arguments are lame. Microkernels are too slow. Java is too slow. 3D graphics are too slow. GUIs are too slow. Virtual memory is too slow. Accessing files over a network is too slow. Calling the OS instead of directly banging the hardware is too slow. *yawn*

Upgrade your 386SX to a new Athlon, dude. (Or better yet, a dual Athlon -- one less context switch ;-). Then nothing is too slow anymore. You can run CPU-bound stuff continuously at 87.5% utilization and your computer will still be just as fast as what you had 6 years ago, which was already overkill.

500 clock cycles, with 2 billion clock cycles per second, that works out to... a good-looking excuse to blame things on the next time you get fragged in Quake.

What's really funny is that you'd dare to say that something with a slight performance decrease has a "very little chance of surviving on Intel-based architectures." And yet just last week, I saw someone at my office spending way too much time, struggling to copy a bunch of files with MS Windows' explorer shell. I guess Windows has very little chance of surviving too. Unless .. wait .. unless maybe people don't care? Could it be?!?

Re:microkernel == too slow on x86

[Baconator]

My first comment is that "performance" means different things to different people. To some it means "throughput", that is, the amount of work that the system can do just prior to being overloaded. To some it means how well it can handle overload. To some it means low latency, that is, that the system can respond to an important event quickly. Which one is important for you depends on what you're doing.

Indeed. Latency is a critical issue in many kinds of processing, especially multimedia. MacOS X, a Mach-based system, delivers superior audio latency under stress. There's a really good whitepaper on this topic here (in PDF... sorry)

Re:microkernel == too slow on x86

[Anonymous Coward]

Ok. So you're telling me QNX is slow? Proof it.

Re:microkernel == too slow on x86

[Anonymous Coward]

That sounds awesome. Someone *has* to make a new windowing system designed around that kernel from scratch. It is a necessity.

Re:microkernel == too slow on x86

[Anonymous Coward]

F-f-f-f-Photon!

Re:microkernel == too slow on x86

[Anonymous Coward]

Still sucks compared to amiga messaging-by-reference. 4 cycles, and no data copying!

Anyone Know Where this guy went to College?

[Win-Developer]

I graduated UMASS Lowell with a Neal Walfield recently so I was curious as to whether it was the same person.

Re:Anyone Know Where this guy went to College?

[jallen02]

Yep, same guy.

Not to be an ass but behold the power
of google :)

http://www.google.com/search?hl=en&q=UMASS+Neal+Wa lfield+HURD

Jeremy

Hurd Speed

[Elwood P Dowd]

Hmm... He says HURD is slower than it should be, and it will get better. I was under the impression that it was doing some high-order operations, and that was why it was going to be slow. Eventually with high-order operations, don't you sortof hit a brick wall in optimization? For example, I thought they were using the very expensive (computationally) Mach messaging system for some of their features. Is this the case? Is their switch to L4 going to improve this issue, since Mach's speed issues are related to operation order? Iduno. I guarantee that I'm less educated in this subject than the majority of /. readers, so can someone elucidate?

Re:Hurd Speed

[dollargonzo]

i guess this will drive the directfb people nuts. they are complaining about how X is slow, (when the problem is actually xfree), and upon hearing this they shall say: we dont need another slowdown..."we need to specialize, not generalize!"

Re:Hurd Speed

[Ivan Raikov]

I believe QNX has a philosophy similar to the Hurd -- most of the traditional OS facilities there are moved in user space. Nevertheless, QNX is a leading hard real-time operating system with a very small footprint and elegant architecture.

Which makes me really excited about implementing real-time software in Hurd.

Re:Hurd Speed

[aheitner]

(caveat: I think microkernels are silly firewalls in code that should be correct and trusted)

There are going to be speed problems with any microkernel-based OS -- OS X is not necessarily exempt either.

Basically, if you spend a lot of time copying data between address spaces of different chunks of the kernel, you're going to pay for it. If you have to switch address spaces to switch kernel tasks, you're going to pay for it (in cache misses).

Even in a monolithic-kernel OS (which will always be superior, if you assume the parts of the kernel are well-enough written that they can be trusted by other parts of the kernel), you have some cost moving data from userspace to kernel space. You can get around that in clever cases -- Linux does this with zerocopy networking, passing sets of (physical) pages around and dumping them directly to the card driver.

As Linus once said "Mantra: `Everything is a stream of bytes'. Repeat until enlightened." In other words, any obsessiveness that gets in the way of moving streams of bytes around extremely efficiently is not good architecture. Message passing (and separate address spaces for kernel "server" modules) fall into this category.

Re:Hurd Speed

[smunt]

But HURD is Free Software.

Re:Hurd Speed

[Pseudonym]

First: You don't need to spend any more time copying data between address spaces in a modern microkernel OS than in a monolithic-kernel OS unless you've designed it badly. For example, it's lunacy to put your disk driver and file system driver in different address spaces. Performance-conscious microkernels do what monolithic kernels do: use dynamically loaded objects. The difference is that the disk server dynamically loads the filesystem it's going to use, or the network server loads the NIC driver and protocol implementations. There's no reason at all why a microkernel OS can't use zero-copy networking. (I think that BeOS even did zero-copy sound in some situations. Digitised data would come in off the soundcard and go straight into the mixer. Try doing that in Linux without hacking the kernel.)

As for context switches, true, you have to do more of them, but you get performance gains elsewhere as a result, as I have noted previously.

If you need a microkernel mantra, here it is: "It's not a penalty, it's a tradeoff." Repeat until enlightened. :-)

Re:Hurd Speed

[Pseudonym]

Mach is an old-style microkernel. It comes from the same era as Windows NT.

QNX/Neutrino is a modern microkernel which comes from the same era as BeOS.

There's no comparison. Mach is big and tries to do too much, even for a microkernel. But it comes from an era when we throught that the most important advantage of microkernels was flexibility. We now know that by making them very "micro" they can give performance too.

You won't find hard real-time in Hurd any time soon. Not as long as they're using Mach and allow use of Linux device drivers, anyway. Hard real-time needs to be designed in everywhere, from the driver to the kernel to the application.

The world does need a free real-time general-purpose OS, you're right. Real-time is becoming ever more important even in server applications (e.g. ATM routing, streaming media). You won't find it in the Hurd, but there are one or two projects happening in relative secrecy at the moment. Watch this space.

Re:Hurd Speed

[Elwood P Dowd]

gee, not offtopic at all. (*THIS* post is offtopic.)

Re:Hurd Speed

[Elwood P Dowd]

Hmmm. I thought that they were doing exactly that. A lot of copying between servers by using the Mach messaging system. Maybe not between the filesystem and the disk drivers, but I'm sure some of those servers do a lot of communication. Now, I have *no* idea if any of that communication is something that would have to be copied in a monolithic kernel. Perhaps all of it would. I realize that Mach messaging was a well thought out tradeoff, and I don't think that it's a bad idea for the HURD. They certainly took their time thinking about it :) I'm just curious if further optimization is really going to improve their speed a lot. I can't imagine that Neal would say it's going to improve if it isn't, so I imagine that some of my post is just plain incorrect. Is the messaging going to slow them down, or not?

Re:Hurd Speed

[jallen02]

They mentioned in the article they were moving to a more "modern" microkernel and that they HURD OS was not tied to a specific microkernel...

perhaps there is hope?

Jeremy

Re:Hurd Speed

[Pseudonym]

Just to clarify, aheitner's assertion was not that Hurd or Mach's IPC is slow, but that any microkernel-based OS will be slow compared with a monolithic kernel-based OS. I don't know enough about Hurd to comment specifically, but there are plenty of modern microkernel-based OSes which are competitive in this area (e.g. L4, BeOS, QNX).

Re:Hurd Speed

[jbailey999]

One of the biggest speed problems we face right now is how expensive fork is. Everytime something forks, all the ports (and send rights) have to be copied from one task to another (Many many RPCs for that). If that's followed by an exec (which then has to clear it) it's quite expensive.

The solution for that is to use posix_spawn (in the latest posix drafts). This signals that a new task can be setup cheaply. Hopefully when bash, make, and gcc use that, we'll see a huge improvement in speed.

So far raw execution speed seems fine. I don't use X (since mostly my machine just sits and compiles binaries), but even when it's going full tilt, it's quite usable on a PII/233mhz. (Multiple ssh sessions, irc)

Re:Hurd Speed

[Elwood P Dowd]

That was exactly the answer I was looking (and hoping) for.

Re:Hurd Speed

[Baconator]

What about Fiasco? It claims to be a "Real-Time" kernel.

And is BeOS really a real-time OS? I've never heard it described that way. If so then it's a damn shame that Apple nixed it for a Mach-based system.

Re:Hurd Speed

[ralphbecket]

You're assuming that an OS has to work in multiple address spaces. This is not true. There is no reason why you can't share a single address space between all processes, each having their own access rights. Once you have such a thing, processes communicate via shared memory without the need for *any* kernel involvement. Check out the Nemesis OS work done at Cambridge University.

Re:Hurd Speed

[Pseudonym]

Fiasco will be fantastic when it's finished, although I think using OSKit is a mistake except in the short term. However, a "real-time kernel" won't help if your drivers and servers aren't also low-latency. Beware of Linux drivers in particular. They almost all assume that interrupts are disabled during execution of the interrupt handler. Excising that will be hard.

Re:Hurd Speed

[SerpentMage]

What is interesting to note is that the original design of Windows NT with its servers was abandoned in NT 4.0. And from what I know in XP it does not even exist. While HURD did sound very interesting and many of its concepts sounded good I think speed is still an issue.

Many people say, computers get faster. Sure I agree, but software gets slower as well. The real question is if the software gets slower faster than the CPU or not? For example while C++ as a GUI is hard to program, C++ gui's are miles faster than any Java GUI. On top of that C++ GUI's are nicer than Java's. Hence why Java has not made it on the desktop.

Folks sometimes you need the speed!!!!

Re:Hurd Speed

[renoX]

AFAIK BeOS has not a microkernel.

L4 is fast, but I believe that it has some limitations on the number of threads, size of messages, etc..
These limits were made to go faster..
The port of Hurd over the L4 microkernel is complicated due to these restrictions..

Re:Hurd Speed

[volkmar]

The limitations are going away in the upcoming L4 Version 4 API without hurting the performance. Actually, intra-AS IPC is going to be 10 times faster (~15 cycles).

Re:Hurd Speed

[Anonymous Coward]

It doesnt matter if you change access rights or change the entire memory space ... you have to flush the TLB in both cases, and that hurts.

There is no reason why you cant just allow several processes to share a memory space and access rights when you trust them though. Its about choice, if you want you could put everything which sits in kernel space with a monolithic OS in the same memory space under a microkernel OS too making context switches near costless ... but at least with a microkernel OS you have the choice to put a driver in a memory space its free to corrupt without destroying the rest of the kernel.

Re:Hurd Speed

[Espen Skoglund]

Basically, if you spend a lot of time copying data between address spaces of different chunks of the kernel, you're going to pay for it.

First, if you've designed your system in a way that you have to copy large amounts of data between time critical components, you've been doing a terrible job at the design board. Why not share/map the data between different components instead? Second, copying data in and out of the kernel is usually completely unnecessary. The kernel can simply copy the data from one address space to another (no extra copy cost and cache polution by having a temporary copy buffer inside the kernel).

If you have to switch address spaces to switch kernel tasks, you're going to pay for it (in cache misses).

Now, why do you assume that you're going to pay for it in cache misses. True, there may be some cache misses incurred by context switches, but a properly designed kernel can get this down to 12 misses or less (i.e., the kernel touches 12 cache lines doing an IPC between two address spaces, cache lines which may flush out some of the working set of the applications).

Re:Hurd Speed

[Anonymous Coward]

hey goof! osx is not a microkernel in that sense.
there is no division of address space between the mach layer and the bsd layer. in fact, ALL versions of nextstep/openstep have been the EXACT SAME WAY.

Re:Hurd Speed

[Pseudonym]

What is interesting to note is that the original design of Windows NT with its servers was abandoned in NT 4.0.

Well, some of the servers are still there, but yes, you're right. NT until version 3.51 used to be an old-style object-oriented microkernel OS not unlike Mach (only better than Mach). Now it's a kind of a bastard child of microkernel and monolithic kernel, retaining some of the benefits and most of the drawbacks thereof.

Re:Hurd Speed

[k4m3]

On top of that C++ GUI's are nicer than Java's

Yuk... since when the look of the GUI depends on the coding language ? Try to do a GUI in Java with the Qt extension, and then proove me the same made in C++ is nicer...

I am not a kernel hacker ...

[PoiBoy]

but I play one on Slashdot. :-)

Seriously, having read the interview it seems like Hurd does some interesting stuff removing features that are part of the kernel in other unix systems and moving them into userspace.

The real question, though, is whether we need an entirely new operating system to gain these features or whether they could instead be implemented into the standard Linux kernel. Unless they can really get a large group of people starting to develop and use it, it may go the way of the buffalo. By working on getting their changes into Linux, however, they would have a much larger userbase to start from.

Re:I am not a kernel hacker ...

[Anonymous Coward]

It isn't "an entirely new operating system", it's a replacement for the kernel.

Re:I am not a kernel hacker ...

[brunes69]

By most definitions, especially the couse I took on "Operating Systems", the kernel pretty much is the operating system.

Re:I am not a kernel hacker ...

[smunt]

> implemented into the standard Linux kernel.

Nope, that'll undermine the greatest thing of hurd. The ability to do lots of things as a regular user.

What we need is a standard for device-drivers, so you've got one source for *BSD's, Linux and other OSes. And one binary for all OSes running on some microkernel.

Software just needs good design.

Re:I am not a kernel hacker ...

[BLAG-blast]

By most definitions, especially the couse I took on "Operating Systems", the kernel pretty much is the
operating system.

Well, ask for your money back and take another course....

To make it simple, the kernel is the "operating" part and the "system" is all the bits that manage your password, let you login, run shells, etc.

I'd better microsoft would love to sell kernels seperate for the OS....

Isn't GNU/HURD redundant?

[Trepidity]

Since HURD is the official kernel of the GNU OS project, isn't "GNU" or "GNU OS" a sufficient name for the operating system?

Re:Isn't GNU/HURD redundant?

[fsmunoz]

I don't think so. From RMS himself (in some list, can't remember which, about the name 'Debian GNU/Hurd'):

GNU and GNU/Hurd are two names for the same system; the latter name emphasizes the fact that the kernel is the Hurd. It is useful to emphasize that when making a contrast with GNU/Linux. In this context, we want to make that emphasis.

Enough said.

fsmunoz

Re:Isn't GNU/HURD redundant?

[brunes69]

Didn't you know? There's already a GNU OS. It's also been called "Emacs" in some circles.

Re:Isn't GNU/HURD redundant?

[Anonymous Coward]

Nope. A few months back, RMS finally declared Linux the official kernel of the GNU project. That was the final nail in HURD's coffin.

Re:Isn't GNU/HURD redundant?

[XBL]

Reminds me of Microsoft's slogan for Windows 2000:
"Built on NT Technology"

Re:Isn't GNU/HURD redundant?

[csbruce]

Since HURD is the official kernel of the GNU OS project, isn't "GNU" or "GNU OS" a sufficient name for the operating system?

But "HURD" is a much cooler complex metaphor than "GNU OS".

Re:Isn't GNU/HURD redundant?

[Anonymous Coward]

Didn't you know? There's already a GNU OS. It's also been called "Emacs" in some circles.

MS DOS is, quite possibly, the worst text adventure game ever.

Re:Isn't GNU/HURD redundant?

[smunt]

Where did he say that?

I don't think GNU needs an official kernel. You should be able to choose your kernel for the GNU operating system.

Re:Isn't GNU/HURD redundant?

[smunt]

For the GNU OS, GNU OS is sufficient. But to emphasize your GNU System runs HURD, you refer to it as GNU/HURD.

GRUB/HURD/GNU is just as valid.

Re:Isn't GNU/HURD redundant?

[Arandir]

But the kernel is the operating system!

Re:Isn't GNU/HURD redundant?

[Arandir]

In this context, we want to make that emphasis.

Who is this "we" he refers to? Did he have a mouse in his pocket? RMS is referring to Debian, but he is not a spokesman for Debian, so using the word "we" is bizarre.

Who is using it?

[SquierStrat]

I'm still trying to figure out who exactly uses Hurd??? The microkernel stuff is very interesting, but who is using it? What's it's device compatibility? binary compatibility? I think the idea of servers having no privies is interesting, if definitely provides for a better security model, but how many NICs does it work with? I see that it has linux driver compatibiltiy glue but that still doesn't mean it works with all of the drivers...all in all, it is probably a great server platform but for desktops/workstations, is doesn't sound to hot. At least that is my take/opinion on it. I've not actually used it, so my opinion is worth a grain of salt, but hey...think what you want.

Re:Who is using it?

[bytes256]

Somehow, I don't think the GNU folks give a rat's ass about binary compatibility. With free software, really all you need is POSIX compliance. (If you want binary compatibility out the yinyang use BSD.) Also, the HURD team can theoretically port Linux and BSD device drivers, the source code is all there. In fact, the OSKit from the University of Utah does just that. The number of users is actually less important for long term survival than the number of maintainers, which as far as I can see is the only real problem the HURD team will run into.

Re:Who is using it?

[smunt]

Dude, for Desktop/WS any OS will do.

It's just that powerusers like a flexible system, which GNU provides.

Huh?

[Hitokage_Nishino]

Why does he keep saying that only root can mount filessytems? Sure that's the default mount behavior, but certainly not the rule.

Re:Huh?

[ArsonSmith]

in linux there are some suid and configuration exceptions but they all imply getting root in some form usually suid.

He is saying that users can mount any file system to any place they wish (giving they have the permission).

Linux does have some of this ability comming though with gnome's vfs. but this is not quite the same thing.

Re:Huh?

[Anonymous Coward]

They have to pretend the Hurd has something it can do that Linux can't

Re:Huh?

[smcv]

On a Linux kernel, to mount a file system, you need root priviledges. No getting round that.

Ordinary users can mount certain filesystems because /bin/mount is suid root, so it runs with root's priviledges. The way it's implemented is that if the owner of /etc/fstab (i.e. root) has specifically marked a device/mount point combination as "user" or "users", ordinary users are allowed to mount it. On a desktop Linux box, removable drives (CD, floppy, etc.) are usually tagged as "user".

This is for two reasons - security (if J.Random User mounts a specially prepared disk with a suid root shell on it, you have trouble) and stopping users from annoying each other (if I decide I want to mount something over /usr/bin, anyone else using a multi-user system will be very annoyed). The "user" marking automatically switches off certain permissions, to avoid the security hole mentioned, while the device can only be mounted where root said it should go (e.g. /cdrom) so nobody can mess with the important bits of the filesystem.

AFAIK, in Hurd a user can mount something over /usr/bin if they so wish, and it only affects them - everyone else sees the "real" /usr/bin. This is cool, if potentially rather confusing, because a user can arbitrarily rearrange the filesystem how they want it (as long as they still have access to /bin/mount and /bin/umount :-) without inconveniencing anyone else.

Not much new stuff

[roguerez]

The whole micro-kernel idea exists in MINIX, with user-space FS, MM etc..

The authentication part looked nice, but I thought I saw a contradiction when he first spoke of the safety of the system because the authentication daemons ups priviliges and second talks about a user-owned authentication daemon which is secure because cracked passwd's cannot be used on daemon's outside this users' space. This would imply that the public authentication server is hackable also in a way that authentication tokens can be had illegally.

Nevertheless I like the removal of root access necessity for a lot of stuff.

Re:Not much new stuff

[Anonymous Coward]

This would imply that the public authentication server is hackable also in a way that authentication tokens can be had illegally.

No, it's more like a public key system. You can get issued keys from anyone you like but only certain keys issued are useful.

I think all he meant was that in Linux I can write software that will let people run programs under me. I could (I have) wrote a system ontop of that so that I might adminstrate my processes and try to lock-down what people can do. I don't give them a command line - I just let them use my web groupware software. It's no biggie.

Re:Not much new stuff

[jtdubs]

When he spoke of user-owned authentication daemon's being secure because the cracked passwords are unusable other places that's exactly what he meant.

A user-owned authentication daemon is not just user-owned. It could also be user-written. You can't guarantee the security of something a user writes. So, it can be cracked, possibly. And, you can get passwords and tokens from it, possibly. However, they do you no good in any other authentication daemon.

The main, global, authentication server for the OS should be very damned secure.

Justin Dubs

Re:Not much new stuff

[roguerez]

I don't think you understand my point. Which is that the authentication system still is vulnerable to attacks where tokens are illegally obtained. Therefore a buffer overflow will not make you root because the server is running as root, but it might give your root (or any other users) password, which has the same effect.

Re:Not much new stuff

[jtdubs]

It would not give a root password. It would give a root token. That token, however, would only be valid on that one authentication server, so it would only make a difference if you wanted to do horrible things to programs that use that authentication server as their primary authentication server. Regular programs would still default to the system's authentication server which would laugh at your supposed root token.

Re:Not much new stuff

[roguerez]

I'm still not getting through.

You would get a root token on the SYSTEM'S authentication server, therefore granting you root access to the complete system.

The authentication scheme can prohibit you from becoming root by overflowing the authentication server and 'becoming it' because it doesn't run as root. It doesn't prevent you, however, from overflowing it and getting the root token after which you can abuse that one accordingly. Therefore this scheme only partly solves UNIX' inherent security problems.

Re:Not much new stuff

[Hast]

No, because there can be several authentification servers running. You would only get root at the user level one. (Hooked to a FTP or WWW server perhaps.) So the hacker could at most be able to do damage there.

However, as the servers (FTP/WWW) now instead of running priviliged are as default "no user" they have zero permissions on the system. So even if you overflowed a server and got shell you wouldn't be able to do anything with it. (Except trying to authenticate yourself with the auth. server. (local to the FTP/WWW server) And you would most likely fail at that, otherwise you wouldn't have hacked it, would you?)

So all and all it's a pretty good (and elegant) solution.

Re:Not much new stuff

[roguerez]

No.

You will still be able to overflow the authentication server and the the authentication token for root. Please explain why you would only get root "at the user level one", whatever you mean by that.

Re:Not much new stuff

[roguerez]

Should read: "and get the authentication token for root".

Oh Lord, How Long?

[fm6]

Is the assertion that Hurd isn't "production grade" official? Or just the consensus of its users? Or just the opinion of the interviewer?

Better hope it's the last one. Anything else reflects very negatively on Project GNU's ability to make actual friggin progress. They've been working on Hurd since 1991!

Re:Oh Lord, How Long?

[rubberducky]

I don't know what you gathered from the interview, but if y'd ask me, I think I was might impressed by the ideas in the interview. Hurd, to me, seems like an excellent idea.

As far as GNU's ability to deliver is concered, what about that editor you use (emacs). What about tools like make, flex, yacc, et all? Get real, GNU has done delivered too much to the computing community; and for free.

Honestly, getting the hurd up 'n running has been not as important since we already have Linux. After Linux, there was no urgent need for a Free OS (what GNU was really all about at that time).
As far as having a robust OS is concerned, we already have Linux. Whatever Hurd is going to be, it is going to be well thought out and based on good and new ideas that markedly better than conventional UNIX. Hurd is not there to replace Linux, but the project exist solely to get a new kind of OS out.

Read the interview. It's good.

Re:Oh Lord, How Long?

[gorilla]

Actually they've been working on it longer than that. In 1987 they started "negotiating with Professor Rashid of Carnegie-Mellon University about working with them on the development of the Mach kernel". 1991 is only when they started working on a detailed plan. It still took them until 1994 before they got to the milestone of "it boots".

Re:Oh Lord, How Long?

[Arandir]

Honestly, getting the hurd up 'n running has been not as important since we already have Linux.

And thus you get the biggest cop-out in all of free software history. GNU was founded to create a specific unix-like operating system called "The GNU System". They were getting really close to finishing it, when along comes Linux. So they decided not to complete The GNU System, but instead to rename Linux to GNU/Linux. They could have done the honorable thing and conceded that someone else beat them to the punch. But instead they have spent the better portion of a decade trying to convince everyone that they actually succeeded. Until HURD is stable there will be no stable GNU System.

HURD vs Plan9

[line-bundle]

I have been looking at plan9 from bell labs recently. Has anyone here used both hurd and plan9 enough to give advantages of each?

Re:HURD vs Plan9

[Anonymous Coward]

PLan 9 is a whole OS, Hurd is well Hurd. Basically on plan 9 *everything* is a file and accessable as such...even thinks like the mouse coordinates/buffer.

Re:HURD vs Plan9

[spitzak]

Actually I think Plan9 is a very good idea, and may be a much better aproach to making a microkernel. You could consider Plan 9 to be doing "message passing" but the set of messages is limited (to 17, I think). Ie there is a "read" and a "write" and a "walk" and several others. Each of these "messages" has a very fixed set of arguments, ie some have a big block of memory that needs to be sent to the message reciever, some the other way around, some return a new message pipe, etc. Since there is this limited set of types of messages they can be each hand-coded for maximum efficiency.

This limited set of "messages" also makes it trivial to insert filters between components. In Mach I believe any kind of filter will have to interpret the entire message description structure, right?

Stability

[ortholattice]

From the interview: The GNU/Hurd, as a desktop system is quite usable, albeit, a bit slow. In terms of stability, there are not many major crashers. Which is to say, an uptime of over a week is quite possible.

In this age of MS-think, that means it's time to release it!

That said, I would not recommend using the GNU/Hurd on a server. At least not yet.

Hmm, that never stopped our friends in Redmond.

(Seriously, though, an interesting interview.)

Wine?

[rasactive]

Can somebody please explain what it meant when the HURD coder said something about having wine, but not other non-prescribed drugs. I think it would probably be helpful to a number of people.

Re:Wine?

[fsmunoz]

Neil's comment about wine&drugs is a reference to some of the tasteful and ontopic remarks made by Linux on this article in the kernel mailing-list.

The important parts:

(...)
Trust me. The people who came up with MAP_COPY were stupid. Really. It's an idiotic concept, and it's not worth implementing.

And this all for what is a administration bug in the first place.

In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people.

Linus

Charming.

fsmunoz

Re:Wine?

[rasactive]

Never mind. I clicked on the link.

Re:Wine?

[Anonymous Coward]

Wow... I knew Linus was capable of being a jerk back in the days when he was flaming Tanenbaum. I had hoped he'd outgrown that.

Re:Wine?

[Anonymous Coward]

I think that Linus is making a contrast between himself and RMS. Linus doesn't use drugs and made Linus with a little help from his friends. RMS, if he doesn't use drugs, argues strongly for legalization, and RMS et al are still stuck in alpha/beta mode with HURD.

Just my own observations.

Hurd=.......

[Anonymous Coward]

Herd Of Unix Replacement Daemons.

It is not an OS, or a kernel as most people understand them. It is a a HURD.

Can someone answer my stupid questions?

[Anonymous Coward]

1> Are there any features that make HURD a better solution than the Linux kernel for say a desktop OS?

2> Will Hurd have an Xfree port soon? Will existing drivers be easily portable?

3> What about window managers and environments. How hard would it be to bring KDE/Gnome and some window managers to hurd?

Re:Can someone answer my stupid questions?

[fsmunoz]

There is an XFree port NOW! It's right there on the interview... X works, window-managers work (WindowMaker, BlackBox, etc).

GNOME and KDE need pthreads (again, right there on the interview) before anything mroe can be attempted.

fsmunoz

Re:Can someone answer my stupid questions?

[bytes256]

1> Are there any features that make HURD a better solution than the Linux kernel for say a desktop OS?

that's something best left to opinion

2> Will Hurd have an Xfree port soon? Will existing drivers be easily portable?

Read the article...they already have XFree working on HURD...XFree runs on OS/2, of course it will run on a POSIX system

3> What about window managers and environments. How hard would it be to bring KDE/Gnome and some window managers to hurd?

Gnome will obviously get ported...think about it...Gnome has RMS endorsement...besides window managers are generally portable across UNIXes

Re:Can someone answer my stupid questions?

[Anonymous Coward]

1> Are there any features that make HURD a better solution than the Linux kernel for say a desktop OS?

Desktop OS? Well - what's that? A GUI with email + web browser + the net + office package?

Well your network connection could be operated from your user account securely - there's no need to be root to use the modem (and sure, you can set up exceptions under Linux, but it's not finegrained and it's dangerous and that's the point).

The rest probably wouldn't change. Please define what you mean by a desktop OS and I might be able to respond more.

Re:Can someone answer my stupid questions?

[smunt]

Looking at, your questions, I'd see hurd is not ready for you.

Maybe when there is a fancy menu-install.

The HURD could be in public use today

[Jack Wagner]

When I was doing some contractor work for a huge *nix shop (think purple)I met a fellow who told me an interesting tale. It seems this huge *nix company (think purple) had actually spent a week with RMS and some of the HURD developers to talk with them about using the base code from the HURD for a project they were kicking about. The company would have been willing to give back some of the code, under a community type BSD license, which would have brought the HURD up to a Version 1.0 level. Now bear in mind I got this story second hand but the guy who told me was a very reputable source who had been part of the compiler team for years there. He let it slip out while we were discussing the flaws in the BSD threading model and once the cat was out of the bag he spilled his guts.

Anyways, the long and the short of it was that RMS threw a giant hissy fit about the license so they never did business together. It seems that RMS can't see the forrest for the trees sometimes. Instead of giving the community a rock-n-roll new kernel, he decided to cut off his nose to spite his face.

Yours,
-Jack

Re:The HURD could be in public use today

[Anonymous Coward]

(comic book guy voice) Worst troll ever!

Re:The HURD could be in public use today

[Anonymous Coward]

dude, Walter Bell is kicking your butt!!

Re:The HURD could be in public use today

[Arandir]

RMS didn't want to use a BSD license because then there would be no "incentive" to contribute back to the project. I can imagine his thought processes now, "but if I accept this contribution from you under the BSD license, what's to prevent you from improving your contribution without contributing your improvement back to your contribution?"

Alexandre Dumas: The Man in the Iron Codpiece

[Anonymous Coward]

Is this the place that gives free party "favors" for every Big Mac "served"?

What a joke.

[Anonymous Coward]

The developers are hardly making masive progress. The last release was in 1997!! I think the Hurd is going to go the same way as 1001 other 'nice in theory' kernels.

Maybe not as crazy as it sounds

[kingdon]

Although a Linux kernel has tons of functionality that you wouldn't use if you were running the Hurd on top of it, there would be potential advantages (SMP, running on a lot of hardware, etc). However, there are (at least) two factors which I suspect might stop this show: IPC speed and memory footprint. (1) The hurd uses a lot of interprocess communication calls between one of the hurd servers and another (or between a user application and a server). Therefore a good microkernel will try to make IPC very fast. Without having looked at Linux benchmarks in this area, I don't know how it stacks up, but I doubt it has gotten as much attention as in your average microkernel. (2) Would the Linux kernel use a lot of memory on unused functionality? (This one might be less of a big deal, although I don't happen to remember things like whether Linux swaps out kernel pages which aren't getting touched).

avoiding flamebait

[kingdon]

And the cool part is that the interviewer was trying to get him to start some kind of argument. But instead of getting defensive or fighting back with something he didn't like about Linux or whatever, he just sidestepped it, and humorously too. Well done.

Re: Device drivers

[SpringRevolt]

If I understand correctly, the Hurd will, in future be moving to a new microkernel called OSKit-Mach. OSKit-mach is based (as you may guess) on OSKit and OSKit (which is distributed and maintained at the University of Utah) contains Linux device drivers. As you may know, the (vast?) majority of Linux code is actually the device drivers - so most of Linux is now available for users of the Hurd.

So in answer to your point: they have considered the device drivers.

Merging?

[mmol_6453]

One reason I like Linux is that it is a great alternative to any other OS I've ever used. But I want there always to be something else I can switch to if too many problems arise;

Example:

I've grown quite fond of Linux, but 2.4.12 and 2.4.13 scared the crap out of me: the license checking was enforced, which made it impossible for me to use the NVidia kernel driver.

My computer, which I got for Christmas '00, came with an NVidia TNT2. I don't have the money to buy an expensive replacement to something I got for free. Isn't that the case with most Linux users?

Re:Merging?

[bconway]

What are you talking about? The nVidia kernel drivers are released under the GPL, and they work just fine on any 2.4 kernel.

Re:Merging?

[mmol_6453]

insmod failed to load the nVidia module, saying that it would "taint the kernel"...

And that same code compiled and worked fine with 2.4.14.

Re:Merging?

[Anonymous Coward]

The module loads just fine. Just don't take any
bug reports to lkml.

Re:Merging?

[Paul Jakma]

flamer...

insmod /will/ load non-GPL compat modules, but it will mark the kernel as tainted.

read the man page for insmod.

Re:Merging?

[mmol_6453]

Maybe this will clear up my point a bit.

What I'm trying to say is that there should always be an alternative if the quality of something isn't satisfactory. Sure, I was probably wrong about insmod puking on the nv module.

But what open-source solution can I switch to if I decide Linux doesn't work for me anymore?

Re:Merging?

[Arandir]

Just what does "tainted" mean? Is is a euphemism for "politically incorrect"? Does it mean that you have violated the GPL, but that you really haven't violated the GPL since you are going this on your own private computer with no intent to distribute a RAM image?

I recall the time when installing Windows on top of DRDOS or OS/2 would give you bogus error message to discourage non-M$ products. Maybe this "taint" message has the similar purpose to discourage non-RMS-approved products.

Re:Merging?

[Paul Jakma]

"tainted" in this context means the kernel has had code loaded into it that the kernel developers can not support.

Eg, you load a vendor binary-only module (eg NVidia DRI module), the kernel developers can not debug any problems a user may have with that kernel as they do not have the source. Only NVidia can debug the problem fully.

It's not a matter of principles, it's a matter of practicality.

Difference in philosophy

[Pseudonym]

Nope. The Linux developers are hell-bent on sticking to their monolithic design. Even if you could develop the Hurd as a set of patches, they would never make it into the "standard Linux kernel". (Curious use of the word "standard", BTW.)

The rift of Hurd vs Linux is like vi vs emacs. Vi and Hurd are meant to be a small tools designed to work in conjunction with other small specialised tools, the whole being greater than the sum of the parts. Emacs and Linux are meant to be "all features under one roof".

Actually, that's a good way of looking at your question. Asking "can't you just implement these features in Linux?" is like asking "why do you need all those POSIX commands like diff(1); can't you just implement that in Emacs?" The answer is "yes", but would you want to?

Re:Difference in philosophy

[spuk]

I would say Emacs follows Hurd philosophy: a small kernel (Lisp interpreter; yes, Lisp is small), that serves as base to implement a lot of modules that interact together via a known protocol.

Re:Difference in philosophy

[Gaccm]

If anyone here has read Linus'es book, just for fun, he talks about why he hates micro kernels. Basicly, because while theoreticly superior, they become a lot less effecient because data has to be passed around to a whole bunch of different parts. In fact Heres a link of Linus and microkernels.

Re:Difference in philosophy

[slashdot_commentator]

I think vi vs emacs is way too generous an analogy. With either way, you're capable of doing the same task (editing ascii files). Linux is a HELL lot more capable as an operating system than Hurd, in stability, efficiency, and capability.

I like the ideas in Hurd, but the bottom line is that it is an experimental OS for theory geeks. Its going nowhere until it moves to the L4 kernel, and starts to look more pragmatically at its execution time, stability, and application environment.

Re:Difference in philosophy

[Pseudonym]

I've read it, and I think he's wrong. A well-designed modern microkernel OS system should do no more copying than a monolithic kernel does (and it does, say, between user-space and kernel-space).

I suspect that Linus was talking about old systems like Mach, Minix and Windows NT, and not modern systems like QNX, L4 or BeOS. If so, his mistake is understandable.

Re:Difference in philosophy

[Pseudonym]

Emacs users don't just edit ascii files. They also compile code, read news and get therapy from Eliza. :-)

Linux is a HELL lot more capable as an operating system than Hurd, in stability, efficiency, and capability.

I dunno about "capability". I'll agree with the other two, though. The stability and efficiency are mostly because of its longevity, of course. "Get it working then get it fast."

Re:Difference in philosophy

[slashdot_commentator]

Emacs users don't just edit ascii files. They also compile code, read news and get therapy from Eliza. :-)

No, EMACS is a shell that calls other programs to compile code, read news, and get therapy...


Linux is a HELL lot more capable as an operating system than Hurd, in stability, efficiency, and capability.

I dunno about "capability". I'll agree with the other two, though. The stability and efficiency are mostly because of its longevity, of course. "Get it working then get it fast."

There are hundreds of software packages which you can pop into a Linux system and it will run. You can't say the same thing for HURD. Linux is more capable (of running useful software). Longevity!?!? HURD is OLDER than Linux.

Re:Difference in philosophy

[Tepic]

From the article:

That said, approximately half of the Debian Woody archive has been compiled for the Hurd. This includes most development tools and noteworthy programs such as XFree86.

From Debian's website:

Debian GNU/Linux ... comes with more than 3950 packages

While I would agree that Linux is more capable in total software packages, I think the HURD also has hundreds of software packages that you can pop on and will run.

I don't think its as bad as you make it sound.

Re:Difference in philosophy

[Anonymous Coward]

I used to agree with him, but then out came these Ghz processors while I'm using only 10% of that...

A few notes from a Hurd user

[Anonymous Coward]

I've got a GNU/Hurd machine right next to me compiling Emacs as I write this, but I'm no expert. Take the following with a salt shaker, if you like :)

A few people have mentioned trying to merge Linux with the Hurd. For many reasons, this probably won't happen, and would probably detract from some of the advantages the Hurd's design offers.For example, Neal Walfield mentions in the interview that there's a fellow who's succeeded by himself at porting substantially the Hurd to the PowerPC architecture. He took OSFMach from the MkLinux project, modified slightly the four core servers and libc, and had a system capable of running bash, fileutils, and I think some other standard apps. This feat confirms the portability of the Hurd's design, which might not be as easily accomplished with the Linux kernel. I don't know Linux's internal arrangement very well, but I have read comments of Linus's to the effect that kernel development shouldn't be easy. While writing Hurd servers or an implementation of Mach isn't particularly easy, it looks as though the portability and modularity promises of the microkernel advocates may be borne out. In addition, at least one fellow has succeeded at running Lites, the BSD single-server, alongside the Hurd on a machine running Mach. In principle it should be possible to run the MkLinux single server in a similar way atop Mach, perhaps concurrently with the Hurd. This would be similar, according to the Hurd's developers in a recent list discussion, to the virtual server capabilities discussed last week someplace

The Hurd accomplishes this while remaining POSIX compliance, sufficient to make the user experience indistinguishable from standard *nixes. At first my biggest disappointment with the Hurd was that nothing much seemed different. All the standard utilities were there, I got X working (though I don't use kde or gnome -- just windowmaker), and found myself somewhat surprised that most of what I need to do I can get done with my GNU/Hurd machine. This seems to have been accomplished by about ten or so kernel developers plus maybe fifty application porters over a long time; naturally if the user and developer bases were larger, things would be farther along.

My GNU/Hurd system is, however, slow. I haven't done any careful tests, but it feels sluggish at times. File access and network operations are fairly slow, similar operations are noticeably faster with Linux. There's a lot of driver support missing [e.g. no sound :( ], which will be a problem for the foreseeable future.

Anyway, it's not quite there yet, but things are coming along, both feature- and performance-wise. It's worth trying out, if you've got a spare pc with a gigabyte of disk or so.

need a delopment release

[quarterbooty]

i would certainly like to give hurd a try on a spare machine around here; it sounds neat on paper. i think the hurd developers should make some sort of a release, though. i do understand that when they make an "official" release they want it to be good and not turn people away. but, to an extent, i think this mindset has hurt hurd's progress. didn't he say there were only like 5 core developers? i bet if they made a couple development or alpha releases, they would get some more developers on board. i realize people could get the code from cvs now, but an announced release would get posts on freshmeat or slashdot even which would generate some publicity. the last official release was back in 1997. i bet there are many who don't even know that hurd exists.

Re:need a delopment release

[smunt]

Hmmm, there are install-cd's made once in a while. You can get them at ftp.gnu.org.

I think the next one is planned for 7Dec.

Re: Production Grade

[SpringRevolt]

I would say that the current GNU/Hurd system is about as stable/everyday-useful as slackware was when it came on 12 floppies (without X11) and using linux 1.3.x some time in the mid 1990s.

At the time, as soon as I discoved slackware, I thought it was great and switched to it right away for "production" work.

The trouble that now we use linux with stability and featurefulness and it's easy to look at the Hurd with jaded vision.

So it's relative. GNU/Hurd as it is now would have been considered fine for production work if in 1995. Not to mention that GNU/Hurd now has Debian infrastructure... Is that good enough? For some, I'd say yes.

Anyway, it's way more stable than Win98 and is getting better much faster that it used to.

Role on woody+1.

I'm shocked!

[Anonymous Coward]

Shocked!, I say, to find ANOTHER duplicate story on OSNews and Slashdot.

What a couple of leech sites you guys have become. Nothing original at all here, if there ever was to begin with. You should have lists of pr0n site links too. At least then VA could be making some money.

did you catch the ISO release

[Anonymous Coward]

A couple weeks back there was a Slashdot posting about (for the first time ever?) an ISO made of Debain GNU/Hurd. Previously, in order to install the Hurd, you more or less HAD to have Linux installed already (and you would then "cross-install" the Hurd), but the ISO changed this. Do a Slashdot search for the Hurd. The ISO is carried on all Hurd mirrors anyway.

Why????

[be-fan]

This isn't a troll, I'm just trying to get a handle on why exactly the HURD exists.

1) Is it because its all GPL?

2) Is it because its a microkernel?

3) Maybe a new, improved microkernel? Not MACH.

4) Security?

5) Performance? Yea right.

6) Ease of use? Isn't that up to KDE and GNOME?

7) Translators, Namespace unification, RPC? Been there, done that.

So, exactly why does HURD exist? What does it bring to the table that hasn't been seen dozens of times before? (Besides allowing non-root users to mount partitions!)

Re:Why????

[Bomb Regardless]

Uh, maybe because it's all of that in one OS? I can't exactly use Plan 9's namespace stuff along with Be's translators on top of EROS right now.../p

Re:Why????

[Anonymous Coward]

The combination of 1 and 2|3 is the main reason for it.

But a GPLed QNX clone would sure rock.

Re:Why????

[Anonymous Coward]

1) A debian port exists for HURD. Actually, Linux is not all GPL since Linus allows binary drivers into Linux. HURD, OTOH, forbids them.

2) As for L4, the article states that Hurd is being ported to L4.

4) Microkernels, by their design, are inherently more secure than regular kernels since they allow you to do more in user space with less privilege.

5) QNX is *also* a microkernel. The main problem about QNX is that it's not free software.

7) Amoebo is also a microkernel, so it should be possible to port it to HURD so that it co-resides with it. As stated in the article, you can have multiple authentification services, device manager, file systems, etc. Just *try* and do that with Linux.

I think that answers your questions.

Re:Why????

[spuk]

Sorry, but your question is dumb ...

Besides Hurd having most of what you said in one place, I could ask: why does Linux exists? It's an implementation of a very old idea, and in fact, other implementations of the same idea have at least the same quality and are also open source/free (i.e. *BSD).

Re:Why????

[rubberducky]

Maybe a new, improved microkernel? [tu-dresden.de] Not MACH.

Read the articly first. There is much talk and work in progress on porting the hurd to L4 (the link you point to). (Look at the the archives for l4-hurd@_SPAM_gnu_NOT_.org mailing list).

Hurd is really a wholly different way of writing an OS. Note that I am not saying that it is better or worse, it is just different. Enough reason for the project to exist? You point to several different places where interesting technologies used in the hurd are mentioned. Why not integrate them into a specific OS?

Re:Why????

[mikec]

You will get a lot of answers to this, but all of them will be rationalizations. The real reason the HURD exists is inertia. When the project started, it was really pretty interesting and to some extent ground-breaking. They were attempting to take cutting-edge research and build a real system. Unfortunately, after languishing for as long as it has, and developing as little mind-share as it has, the HURD is just not very interesting anymore. The cutting-edge research has moved on. In fact, it's pointless from a practical point of view and uninteresting from a research point of view.

Re:Why????

[dvdeug]

It is sort of absurd to point to a half dozen largly experimental systems and point out that Hurd's features can be found in them. (Why does C++ exist? Algol68, PL/1 and Simula have all the features C++ does.)

The Hurd is aimed at being a Free, POSIX, usable system, unlike BeOS and QNX (not Free), Minix (a teaching system), Eros (a experimental system) and Plan9 (not Free, and not POSIX.) As for L4, the article points out that the Hurd can be ported to L4, it's just that nobody has put in the elbow grease yet.

Re:Why????

[mindriot]

Think about how Linux first came into existence. Just for fun. People just like hacking and playing around with stuff, there doesn't necessarily have to be a good reason for it at first. Most important scientific discoveries came out of originally 'useless' research.

Re:Why????

[Anonymous Coward]

This isn't a troll, I'm just trying to get a handle on why exactly the HURD exists.

I'm trying to get a handle on why exactly you exist. My theory is that the people who created you thought they'd enjoy doing it, I'm sure it wasn't for the great practical benefits you've brought to mankind. I think the makers of Hurd are enjoying that too, maybe not as much but with more hope for a useful result :)

Re:Why????

[be-fan]

How is HURD that different? What benifet does it provide the user that hasn't been seen elsewhere? HURD is, at best, a research OS. It has neither the mindshare nor the technological advances to become mainstream. If you compare it with other research OSs, its not very interesting even then. Sure everyone has a right to work on what they think is interesting, but people also have the right to call a particular project pointless and redundant.

Re:Why????

[be-fan]

Not really. Even if you have an L4 HURD that is complete and stable, do you really have anything more than a stable, secure UNIX system? Those are a dime a dozen these days! The microkernel will not make it super-stable or super-secure, and competing OSs (which have the maturity of code that marks a stable/secure system) will be ahead of it in these respect for at least a decade or more. There is nothing in the HURD to justify its existance; it provides nothing to the world that doesn't already exist. Maybe that's fine for a research project, but IIRC, research projects are supposed to try new things!

define "superior"

[Anonymous Coward]

Is "superior" just "faster" to you? If so, why not just say "faster"?

Microkernel gets you two benefits: flexibility and security. The first one is obvious: if I'm a student at Lame U (Go-o-o Lamers!), I don't have to wait for the sysadmin to install things like filesystems; I can install them myself.

Security is more interesting, and Neal did get into this a bit. Consider your favourite insecure FTP daemon (I've come to the conclusion that ALL FTP daemons are horribly insecure -- what is it about FTP daemon coders that they can't figure out buffers?). Under monolithic kernel, FTP daemon is run as "root" and then transforms to luser. Under microkernel, FTP daemon is run as "nobody" and then transforms to luser. When Joe 15-y34r-0ld cr4x your box, he is going to end up as either "root" (under Linux) or "nobody" (under Hurd). I know which one I'd choose.

Anyway, long post short -- faster != superior.

random thoughts

[Anonymous Coward]

Actually I'm thinking maybe the reason Linux took off so well is because Linus has/had no plans for it. On his inital posting, where he provided a link to the 14 lines of code (okay, exaggeration) that was Linux, it was kind of like "uhh, ya, here's something I did because I have no life. Do whatever you like, I don't care." To the developers, because there was no plan or reason to it, Linux was an unformed blob of clay, and its future would be completely determined by them.

The Hurd, OTOH, seemed to have been created with a purpose in mind, and it had a plan the second it was created. It was going to be microkernel, it was going to use Mach, and it was going to have all these cool features and do this and this and that. Before a line of code had been written, really, its future had been set in stone. Maybe not quite as interesting.

Hird

[Anonymous Coward]

The Hurd is a Hird, not a Herd. The 'i' stands for 'interfaces', not 'enterfaces'.

So Linus doesn't like microkernels...

[nadador]

therefore they are bad.

Right, right.

As others have noted, there's no way for a microkernel to be as speedy at flipping bits around as a monolithic kernel, copying between address spaces and everything. Apple attempts to mitigate some of those costs by keeping all their Mach threads in one address space, IIRC, but even with that speed up there's still some overhead.

But that doesn't mean that microkernels suck.

Apache doesn't serve static pages as fast as other web servers. It doesn't serve dynamic content as fast as some servers. But people use Apache for other reasons, things like configurability, extensibility, and support. And because the only thing you *can't* do with an Apache module is make babies.

Microkernels are interesting to computer scientists because they allow abstraction in the kernel, and God only knows that there's no word that computer scientists like more than "abstraction". Microkernels, for all there faults, are just plain prettier. And as research continues into microkernels and how to mitigate their many flaws, there might come a time when the extra processing they require might be worth it. Maybe all the abstraction and objectiness will be worth it to some system designer in the future.

At some point, there may be people who will be willing to trade some latency and throughput for extensibility and configurability in their kernels. They might be willing to trade some clock cycles for the ease with which they can implement different security policies, ala HURD. The point is that not everyone needs the same kernel, and not everyone needs the same kind of kernel.

And competition is good for them both. The HURD developers are incouraged to speed up the kernel, thanks to Linux. Linux kernel hackers will eventually desire some of the design niceties of the HURD kernel, they just won't admit it on the LKML.

Re:So Linus doesn't like microkernels...

[mandolin]

And because the only thing you *can't* do with an Apache module is make babies.

Well it's certainly not for lack of trying..

(nice post.)

Re:So Linus doesn't like microkernels...

[jallen02]

I really don't think we need the details of such an endeavor.

Jeremy

Re:So Linus doesn't like microkernels...

[einhverfr]

And because the only thing you *can't* do with an Apache module is make babies.

See, not much too it!

Actually, Apache DOES make child processes, so in a way, it DOES make babies... ;)

Re:So Linus doesn't like microkernels...

[AbsoluteRelativity]

That is a good point, here is another way of looking at your point, software is an "abstraction" of hardware. And if you notice both have similar properties, hardware is faster then software (Video cards are an example of that), software is more flexible and configurable then hardware. So monolithic kernels are like hardware, fixed but fast, and a microkernel is like software, slow but dynamic. Eventually software will become more abstract itself, so that you can do Runtime Application Developement, or rather be able to develope your application while its running, just pause a component or two, change em and then unpause them, no restarting the application.

Re:So Linus doesn't like microkernels...

[Peter Harris]

Eventually software will become more abstract itself, so that you can do Runtime Application Developement, or rather be able to develope your application while its running, just pause a component or two, change em and then unpause them, no restarting the application.

You can do this in Python. Slightly beside the point, I know. But actually there is the same trade-off between dynamically and statically compiled software.

The usual reason to accept the slower execution is a faster development cycle. I'm not sure the same tradeoff is such a good idea for an OS - most people run applications a lot more often than they hack the kernel.

Re:So Linus doesn't like microkernels...

[Daengbo]

And because the only thing you *can't* do with an Apache module is make babies. -- But it does serve up lots of porn, and that makes some babies.

Re:So Linus doesn't like microkernels...

[Anonymous Coward]

But it does serve up lots of porn, and that makes some babies.

WTF were you doing during sex ed class? porn does not make babies.

Re:So Linus doesn't like microkernels...

[AbsoluteRelativity]

Well the other way to view it is priority, which can also be incorporated. That is the applications/components you use the most but dont change that much, get compiled deeper in the system to get more performance. That is kind of the reasoning behind reconfigurable hardware or FPGA (Field Programmable Gate Array), it would be nice for most often used applications to be so optimized they become closer to hardware then software. But its a matter of priorities, and balancing the available resources. It becomes the typical trade off between memory consumption or performance consumption, memory and LUT (Look Up Tables) being ways to increase performance with out which raw calulations must be done decreaseing performance.

Bring back Multics and VME

[alext]

A completely impractical assumption (and, incidentally, one that is spectacularly incompatible with Open Source, at least, open source written in C).

When was the last time you used a kernel that was really monolithic, one that had been built, supplied and tested as a unit, by a common engineering team? The fact is that all modern systems are supplied in untestably complex configurations, which if reliability is not to be compromised, must be able to protect themselves from problem components.

If the design choice was really between copying memory and passing pointers that allowed the receiver to stamp all over the sender's address space then life would be rather depressing. However, in the absence of hardware features like capabilities and Multics-style protection levels, there is a solution in the form of a safe, intermediate language such as Java bytecode. This way, you only have to trust your VM/JIT compiler for basic address-space integrity.

Slow? Well, device drivers probably shouldn't be the first part of Linux to be bullet-proofed in this way, but for serious components (think KDE applications currently using DCOP etc.) the VM can easily outperform native code, because it can optimize the execution path *across* separately loaded components, and eliminate null procedures such as unused access checks, RPCs for local objects etc.

Linux (and Linus, by the sound of it) need to wake up to the power of VMs. MS apps will soon no longer be tied to x86, Java is still growing, while efforts that could be used for Linux (Perl/Python and a few LISP engines) are niche environments, to say the least.

Anybody that believes Linux is still going to grow when it possesses zero inbuilt protection and requires apps to be manually recompiled for every platform variant is living in cloud-cuckoo land.

--
alex

Re:Bring back Multics and VME

[Anonymous Coward]

I have to agree 100%. Gone are the days when pure performance was all that mattered. If only we could build a system that is nigh invulnerable (SPOON!) in both stability and security, even with scads and scads of code written by different people. Right now, microkernel OS's are the best way to get there.

kernel trap showing off their clue

[Anonymous Coward]

Neal Walfield: As I already alluded to, the Hurd is not a kernel; it is a set of servers. We do, however, use two main parts of the Linux kernel: In GNU Mach, some glue code has been written to allow the use of Linux Device drivers. We have also used Linux's implementation of TCP/IP in the pfinet server.


Guess what Mr Interviewer? It _still_ isn't a kernel, just like the last time you asked!

GNU deserves a lot of respect, but...

[furboo]

insisting on ``GNU''/Linux and ``the'' Hurd are examples of misplaced priorities.

Re:GNU deserves a lot of respect, but...

[Anonymous Coward]

Agreed. If RMS and Co. would spend more time hacking and less time bitching about whose name should be on Red Hat's box maybe the HURD (HIRD UnReady, Dummy! HURD Is Really /dev/null) would be in shrink-wrap at Best Buy. How many years has it been?

Besides, who the hell wants to run a system with such an awful-sounding name? Doesn't exactly roll off the tongue gracefully.

Yes, this is a troll. Why do think I'm an AC?

Microkernels and Monokernels

[einhverfr]

Hi all;

I think that micro and monolithic kernels each have their place. For my PC, though a monolithic kernel probably meets my needs best. Also, I will be referring to monolithic kernels as "monokernels" even if this is not technically correct ;)

Microkernels beat out monokernels often when it comes to Really Big Servers and Supercomputers, in part because SMP is much more difficult to do on monokernel designs I suspect that this is why UNICOS/mk is a Microkernel (of course, it is from Cray).

As Linus once said "Mantra: `Everything is a stream of bytes'. Repeat until enlightened." In other words, any obsessiveness that gets in the way of moving streams of bytes around extremely efficiently is not good architecture. Message passing (and separate address spaces for kernel "server" modules) fall into this category.

Exactly, but your considerations for that 64-proc supercomputer or mainframe are different than your considerations for your 1 proc workstation, aren't they? Microkernel may be more efficient for the former, but monokernels are more efficient for te latter.

Re:Microkernels and Monokernels

[Anonymous Coward]

You wrote:
Microkernels beat out monokernels often when it comes to Really Big Servers and Supercomputers, in part because SMP is much more difficult to do on monokernel designs I suspect that this is why UNICOS/mk is a Microkernel (of course, it is from Cray)

I read a review a while back which showed that Solaris scaled best on big iron (16-64 CPUs).
TruUnix64 (AKA DEC Unix, AKA OSF/1), which is based on Mach, faired worse at above 8 CPU.

Re:Microkernels and Monokernels

[Anonymous Coward]

I will be referring to monolithic kernels as "monokernels"

Call it "megakernel", since mega is the opposite of micro.

The kernels in XP and the new MSServer.Net rock!!!

[Anonymous Coward]

Look here.

Let me be clear, Windows .NET Server is the single biggest Windows server release of all time. I have been blessed to have seen a Release Candidate for Beta 3 and it is truly awesome!!! I cannot believe that I can now use IM to talk to my coworkers without going through a firewall. We are now free to collaborate and communicate. I have been pounding away with Visual Studio.NET RC1 since the PDC and now with this new server code, my mind is swimming with possibilities. I am churning out code and UML documents like there is no tommorow, all based on .NET. I wish to thank Bill GAtes for the .NET vision and the MS legal team for making it a reality. Messages passing is the future and at least hurd has some vision. Linux is old and not integrated into the internet like Windows will be with .NET.

Re:GNU IS SHEIT CMOPARED TO XP PROFESINOAL - BYU M

[Anonymous Coward]

Look here.

Let me be clear, Windows .NET Server is the single biggest Windows server release of all time. I have been blessed to have seen a Release Candidate for Beta 3 and it is truly awesome!!! I cannot believe that I can now use IM to talk to my coworkers without going through a firewall. We are now free to collaborate and communicate. I have been pounding away with Visual Studio.NET RC1 since the PDC and now with this new server code, my mind is swimming with possibilities. I am churning out code and UML documents like there is no tommorow, all based on .NET. I wish to thank Bill GAtes for the .NET vision and the MS legal team for making it a reality.

To sum things up

[Waffle Iron]

The main points from the interview seemed to be:

The HURD isn't popular yet because

• It's still slow
• It's still buggy
• It's POSIX compliant in theory, but not as used by the real world
• Hardly anyone is working on it
• There hasn't been an official release in 4 years (that's 83 years in Internet time)
• There is no prospect of a date for any further official releases

OTOH, the HURD is cool because:

• It's a microkernel
• It has granular security

Except for the last three bad points, the HURD sounds alot like the Windows NT kernel. In fact, the biggest difference could be bad point #4 (since #5 and #6 flow from #4).

Maybe instead of reinventing the wheel, they should just use the NT kernel with the GNU runtime tools and release GNU/NT.

Re:To sum things up

[mandolin]

Maybe instead of reinventing the wheel, they should just use the NT kernel with the GNU runtime tools and release GNU/NT.

That's called cygwin, but maybe if certain people have their say, your wish will be granted :)

keep going...

[Anonymous Coward]

And what happens when your favourite Emacs Lisp routine does something is shouldn't? That's right, your entire Emacs environment suffers; there is no proper encapsulation. This is the monolithic approach: everything runs in kernel (Emacs) space.

Re:The kernels in XP and the new MSServer.Net rock

[Anonymous Coward]

obviously a trool, but i wish to respond point by point, until I get bored.

"Let me be clear, Windows .NET Server is the single biggest Windows server release of all time."

if by BIG you mean a lot of crap, you got a point. It's interesting to note however that Xp is NT version 5.1, a minor-version upgrade from Win2000 (NT v5.0)

I have been blessed to have seen a Release Candidate for Beta 3 and it is truly awesome!!!"

update your troll, the retail version(s) are out.

"I cannot believe that I can now use IM to talk to my coworkers without going through a firewall."

You can't use AIM thru a firewall? I know I can...

"We are now free to collaborate and communicate. I have been pounding away with Visual Studio.NET RC1 since the PDC and now with this new server code, my mind is swimming with possibilities. I am churning out code and UML documents like there is no tommorow, all based on .NET. "

UML eh? People really use that? I thought it was for managers to figure out what their coders can already see mentally...

"I wish to thank Bill GAtes for the .NET vision and the MS legal team for making it a reality."

thats my favorite line... not gonna give the developers and credit (blame?) The lawyers DO deserve a great deal of blame IMHO :)

"Messages passing is the future and at least hurd has some vision. "

it's okay on modern systems, but its not THE SHIT.

"Linux is old and not integrated into the internet like Windows will be with .NET."

not the best ending to a troll, but whatever :P

the GNU/Hurd is NOT a microkernel

[Anonymous Coward]

Its a bunch of servers that run ontop of a microkernel and "fill in the gap" between what would be provided by a microkernel and a monolithic kernel.

Something I perhaps don't understand...

[daveman_1]

If it is possible to implement the Hurd with any underlying microkernel, isn't it essentially possible to provide Hurd functionality with a macro-kernel as well? Layer your Hurd-servers around the macro-kernel as user space apps, disable much of the macro-kernel functionality, still suffer from not doing stuff in kernel space. This is possible isn't it? Wouldn't this allow for the "enhanced" security model which is at the heart of the Hurd? In other words, why does one have to re-invent the wheel to accomplish what the Hurd does, as well as work along side of existing systems, and not require a "compatibility" layer? The interviewer admits the Hurd suffers from a scalability standpoint. Also, isn't it possible to provide the security contexts the Hurd offers through projects for the Linux kernel, such as what NSA is working on with SE-Linux and SIDs? (known in the article as "tokens to perform specific tasks".) This is perhaps a different solution to the problem, but the result appears to be the same...

Better scaling and less forking

[hoggy]

A point I've not seen anyone make is that the Hurd scales better than Linux ever will, and I don't mean in terms of hardware, I mean in terms of development.

Vast wars already take place about what should or should not be in the Linux kernel. The rate of progress on all of these fronts together is approaching glacial. There is just no easy way for a small team to keep a grip on a monolithic kernel that is being pulled in different directions by different developers. It has taken years for a journaling filesystem to be accepted into the kernel.

The Hurd neatly sidesteps all of these issues by not requiring any of these things to be in the kernel. Useful functionality like reiserfs and tux can be developed and released without any requirement for them to be "accepted" by any controlling group. At the moment, the only way to do something similar with Linux is to release a patch. This makes Linux much more susceptible to forking.

In case anyone disagrees with me on the forking issue, consider that Linux already has a very high profile fork: RedHat. RH have been distributing a forked kernel for a long time. Admittedly they only patch the kernel in minor ways, but nonetheless they maintain an alternative version. This is because if their views on what they want out of the OS differ from the kernel admins they have no choice but to fork.

But a RedHat version of GNU/Hurd could be composed of whatever OS servers they choose without any patching. They could mix and match the kernel distribution in much the same way as they currently mix and match the userspace distribution. Because most of the Hurd kernel *is* a userspace distribution.

Re:Better scaling and less forking

[maxpublic]

Vast wars already take place about what should or should not be in the Linux kernel.

What crack pipe are you smoking? Linus decides what's going to be in the kernel - end of discussion. Most everyone who actually does a fair amount of development on the kernel agrees with him most of the time.

What a bunch of non-contributing morons have to say on the subject means absolutely nothing to the project itself. These folks have no say on what does or does not get included in the kernel - I doubt Linus pays attention to them, or even knows that they exist. Why should he?

The rate of progress on all of these fronts together is approaching glacial.

Please, the rate of progress in kernel development has done nothing but increase. In fact, recently a number of people would argue that the changes are coming too quickly, especially in a production kernel.

Max

Over-looked Feature

[scyta1e]

Gee, while I was reading about the different "advantages" of using the HURD, it remended me quite a bit of the type of talk body-mod enthusiasts use when they list the "advantages" of self-castration (you don't go bald, etc...). I don't want to come off as hostile, but am I the only person on earth that thinks that the only reason this project is still around is because of RMS' massive ego?

But Linus *does* like microkernels!

[kinnunen]

Read the Linus vs. Tanenbaum thread. While it is a comparison of Linux and Minix, it gives you a pretty good indication of how Linus feels (or felt at the time) about microkernels in general. Here is one quote (my bold): "True, linux is monolithic, and I agree that microkernels are nicer. With a less argumentative subject, I'd probably have agreed with most of what you said. From a theoretical (and aesthetical) standpoint linux looses." --Linus

The thing is, Linus does care about speed difference. A lot.

Just cause you can doesnt mean you have to

[Anonymous Coward]

It would be a trivial task to put several processes into the same memory space for efficiency if you have a microkernel OS.

I imagine being able to give a driver its own memory space during development would be a boon.

Long, long, long

[fm6]

I don't know what you gathered from the interview, but if y'd ask me, I think I was might impressed by the ideas in the interview. Hurd, to me, seems like an excellent idea.

Excellent ideas are a dime a dozen. World peace, an end to hunger, a home computer that a non-techie can install and administer -- these are all excellent ideas. But in the real world, you don't judge an effort by what it wants to do. You judge it by what it accomplishes. There's a word for this kind of gap between conception and reality.

As far as GNU's ability to deliver is concered, what about that editor you use (emacs). What about tools like make, flex, yacc, et all? Get real, GNU has done delivered too much to the computing community; and for free.

To my mind, EMACS represents a lot of what's wrong with GNU software. Lots of Wonderful Big Ideas, but little attention to practical design.

And I'm sorry, but the basic GNU software set is a disaster. I speak from personal experience. I've been hassling with their bugs for years. Ten or so years ago it was hassling with the official port of GNU source control to DOS -- done by somebody who didn't understand FAT filesystem semantics. Last year I had to sweat blood to deal with the reference counting bug in glibc. This bug was eventually fixed -- after glibc maintenance moved from GNU to Red Hat. What can you say about a team that takes so long to fix such a basic bug? Aside from the fact that it has Lots of Really Great Ideas?

Face it, GNU has "succeeded" only because you need it to do anything useful with the Linux kernel.

Hurd is not there to replace Linux

Well, of course not. Hurd as been around much longer, if you count its Project Mach origins. If Hurd had had its act together back when LT was a grad student, he probably never would have bothered to write the Linux kernel. Proably just as well...

Look, if Hurd is so wonderful and important, then you should want something serious to happen with it. That is not going to happen if all its supporters just stand around saying "cool!" And it's certainly not going to happen if nobody asks why this project has been chasing its own tail for so long.

Re:Long, long, long

[Anonymous Coward]

Ten or so years ago it was hassling with the official port of GNU source control to DOS -- done by somebody who didn't understand FAT filesystem semantics.

well, the FAT filesystem is fundamentally brain-damaged. MSDOS is so limited, and also so gratituously different to every other OS, that porting ANY of the GNU suite to it was quite an achievement.

On the other hand, the venerable Amiga (which had a semi-decent OS), ran a port of the GNU suite just fine via ixemul.library ...

What the hell are you talking about?

[misleb]

Did you even read the interview? Do you have any idea how Hurd works? Hurd is based on a microkernel. The Linux kernel is not a microkernel. Its a a monolithic kernel that implements much of what the Hurd is trying to replace/fix. Most importantly, Hurd is not just another Unix or Linux distribution. Its a whole new OS in and of itself. They admitted to using the TCP/IP code from Linux. They use ext2fs. The applications are not much more than ported Debian packages. How much more can they borrow from GNU/Linux without being GNU/Linux?

-matthew

Re: Production Grade

[MidnightLog]

Anyway, it's way more stable than Win98 ...

Wow. This quote should go in a book somewhere as an example of "damning with faint praise".

Re: Production Grade

[SpringRevolt]

Heh. That's not what I meant :)

xMach

[Arandir]

How does Hurd compare to xMach?