Live data from Hacker News

Whatever happened to the Hurd? – The story of the GNU OS

linuxuser.co.uk

61–70 of 93 posts

Re: Whatever happened to the Hurd? – The story of the GNU OS

#61

Can someone explain to me if the problem with Hurd was that the basic idea was impossible, or it was the way they went about it? i.e. was it the relentless restarting of the project that was to blame, or did they keep restarting because every way they approached it turned out to be impossible?

This XKCD[0] explains the issue with Hurd perfectly, more-or-less echoing the ideas rogerbinns expressed. Note the mouseover text, which makes the observation that the Hurd loop is the loop in which you "code right" and the Android loop is the loop in which you "code fast".

[0] https://xkcd.com/844/

Re: Whatever happened to the Hurd? – The story of the GNU OS

#62
post #25

Earlier quoted context omitted.

Microkernels were an immensely popular idea in academia (Mach, Minix, …) when Hurd was begun; I don't think the fundamental problem with them — performance is horrible — had been made obvious yet. Microkernel design is probably a good idea, but the message passing overhead kills actual microkernel implementations. I've heard the Windows NT kernel described as being designed like a microkernel architecture (separate m…

> I don't think the fundamental problem with them — performance is horrible — had been made obvious yet. On the contrary, the idea that performance of microkernels is "horrible" is the current received wisdom, believed by the majority of programmers without critical examination, and based on very performance-poor early microkernel designs like Mach. The truth is that modern microkernel designs like L4 can perform IPC…

But why POSIX? There's only so much lipstick any one pig can take.

Re: Whatever happened to the Hurd? – The story of the GNU OS

#63
post #62

Earlier quoted context omitted.

> I don't think the fundamental problem with them — performance is horrible — had been made obvious yet. On the contrary, the idea that performance of microkernels is "horrible" is the current received wisdom, believed by the majority of programmers without critical examination, and based on very performance-poor early microkernel designs like Mach. The truth is that modern microkernel designs like L4 can perform IPC…

But why POSIX? There's only so much lipstick any one pig can take.

For compatibility (see my other comment). I'm certainly not arguing that POSIX should be the "native" or only API.

Re: Whatever happened to the Hurd? – The story of the GNU OS

#64
post #49

> Linus Torvalds had begun his project to write a UNIX-like kernel for the IBM 386. IBM 386? What in the world is an IBM 386?

As someone who's in his 20s and first got interested in programming as a kid by trying[1] to install Linux on his 386... I don't know how to react to this.

On the other hand, it's ridiculous to think of how far things have come since then... people who complain about Linux usability and driver issues in 2012 really don't know what they missed!

[1] and failing!

Re: Whatever happened to the Hurd? – The story of the GNU OS

#65
post #24

Earlier quoted context omitted.

Is this comparable to eLua? http://www.eluaproject.net/home/overview EDIT: I found this on YouTube: https://www.youtube.com/watch?v=W_aXsutL4rQ I was interested in this a while back, but never took the plunge. Seems you can run it in an 'emulator' on i386.

Well, kind of but not really. Xen isn't really bare metal in any sense of the phrase. It's just at a similar (but different) level of abstraction. In an embedded system you will need to have device drivers, respond to hardware interrupts, etc. On Xen you make hypercalls. So eLua and these projects are similar in, say, the same way that a typical RTOS is similar to running Linux on AWS. They both have kernels, but the…

Thanks for the explanation. I was really hoping to find something like the SqueakNOS project

http://www.artima.com/weblogs/viewpost.jsp?thread=239339

ROS calls itself a 'meta-operating system', I guess the definition of an OS is sort of blurry!

Re: Whatever happened to the Hurd? – The story of the GNU OS

#66
post #16

Earlier quoted context omitted.

I thought XNU was considered a micro-kernel because of the Mach part.

It's not a microkernel; it just happens to implement the Mach APIs.

More specifically, OS X and iOS run what is essentially a fork of Mach 2.5, a version of Mach that came out before the BSD code was split out of the kernel into userspace (that happened in Mach 3).

A few "merges" (to use source control terminology) of newer Mach stuff into xnu (the OS X kernel), but the BSD-in-userspace stuff never came over.

Re: Whatever happened to the Hurd? – The story of the GNU OS

#67
post #26
post #16

Earlier quoted context omitted.

I thought XNU was considered a micro-kernel because of the Mach part.

To quote that bastion of Jimmy Wales: "Although Mach is often mentioned as one of the earliest examples of a microkernel, not all versions of Mach are microkernels. The project at Carnegie Mellon ran from 1985 to 1994, ending in apparent failure with Mach 3.0, which was finally a true microkernel. Mach and its derivatives are in use in a number of commercial operating systems, … most notably Mac OS X using the XNU op…

I was one of the last Mach people at CMU. The BSD emulation on Mach 3.0 was implemented by stubs that made IPCs to the BSD emulation server, which then made additional Mach API calls to implement the UNIX semantics. This design was generally half as fast as an in-kernel implementation (e.g. Mach 2.5 or a commercial UNIX kernel). In the mid-90's we figured out how to make up the performance gap by refactoring the BSD emulation to put some code in the same address space as each application (ie in the libc .so), which allowed you to avoid the RPC to the emulation server in most cases (eg http://dl.acm.org/citation.cfm?id=168639). So I don't think it's fair to say that microkernel implementations of UNIX are inherently slow; instead I would argue that the simpleminded approach to UNIX emulation was the real problem.

None of this technology made it into a mainstream Mach distribution because the band broke up: Rick Rashid and his staff and students went off to work at Microsoft Research. Brian Bershad took over the project and then moved to University of Washington. It was also becoming clear in the mid-90's that the OS didn't really matter much anymore, since the big money was being made in Internet applications. So most of the hackers who might have worked on new operating systems during this time ended up working on application servers and web apps instead.

Re: Whatever happened to the Hurd? – The story of the GNU OS

#68

Can someone explain to me if the problem with Hurd was that the basic idea was impossible, or it was the way they went about it? i.e. was it the relentless restarting of the project that was to blame, or did they keep restarting because every way they approached it turned out to be impossible?

Linux had a working version when the FSF had a longterm vision. There is nothing impossible in their design and more complex systems such as Windows or Inferno/Plan9 exist. In the case of Windows imagine how many hours were spent in its design. When Linux came out it worked and everybody was shocked, Hurd was never able to do this.

Re: Whatever happened to the Hurd? – The story of the GNU OS

#69
post #49

> Linus Torvalds had begun his project to write a UNIX-like kernel for the IBM 386. IBM 386? What in the world is an IBM 386?

The first IBM computer to use a 386 was iirc the ps/2 model 80. There were also some clones out in short order, most notably the Olivetti and the Apricot.

Re: Whatever happened to the Hurd? – The story of the GNU OS

#70
post #25

Earlier quoted context omitted.

Microkernels were an immensely popular idea in academia (Mach, Minix, …) when Hurd was begun; I don't think the fundamental problem with them — performance is horrible — had been made obvious yet. Microkernel design is probably a good idea, but the message passing overhead kills actual microkernel implementations. I've heard the Windows NT kernel described as being designed like a microkernel architecture (separate m…

> I don't think the fundamental problem with them — performance is horrible — had been made obvious yet. On the contrary, the idea that performance of microkernels is "horrible" is the current received wisdom, believed by the majority of programmers without critical examination, and based on very performance-poor early microkernel designs like Mach. The truth is that modern microkernel designs like L4 can perform IPC…

What about minix 3? It implements all of POSIX, and it's a true microkernel. The kernel process is apparently only 4-5K LOC which I have been meaning to take a look through.

Their papers have pretty detailed performance measurements. I recall that they pass fixed-length messages between processes for efficiency (to avoid buffering). And they said it takes approximately 500ns to send a message on a 2.2GHz Athlon, which is in the neighborhood of a malloc().

I don't know how the overall performance is. Minix 3 appears to be targeted at lower end devices, e.g. they mentioned OLPC. I don't think they have things that you would want for servers, like multicore support. I don't think anyone uses it for those types of applications. But it does implement POSIX and it is a microkernel. And from what I gather the codebase is relatively modern -- they said it is related to Minix 2 in name only.

http://www.minix3.org/documentation/index.html

Post reply on HN