44 ms·
Whatever happened to the Hurd? – The story of the GNU OS
- DanBC 14y agoCan anyone tell me how computing would be different today if micro kernels had taken off? If everyone working on Linux had been working on Gnu Hurd?
- klrr 14y agoThen everyone would have ran BSD. (J/K) Micro kernels are very hard to debug.
- meaty 14y agoMicrokernels are easy to debug. Compared to say an SOA platform with 200 service endpoints, a database with about 2000 tables, integration with 15 other providers with XML, CSV, SFTP and some wierd shitty non standard binary protocol. All written entirely by the lowest bidder without unit tests because they knocked the budget up. Oh and with a toolchain which barely works and no VCS system past an old corrupt source safe database full of compiled DLLs which there is no source for any more. I've done both and am currently stuck doing the latter - I'd rather poke one of my eyes out and debug a microkernel if I had a choice.
- gioele 14y ago> Micro kernels are very hard to debug. Microkernels are not harder to debug than monolithic kernels. I'd even say that they are easier to debug, much easier. (Personal experience in debugging both.) The problem with microkernel-based OSes is, as Linus Torvarlds aptly put it, that they turn well understood memory-protection problems into not-so-well-studied IPC problems. (The actual quote is «They push the problem space into communication, which is actually a much bigger and fundamental problem than the small problem they are purporting to fix.») The microkernel is not the real problem here, the big issue is debugging faulty IPC sequences between the servers that implement the OS services. A problem that is almost non-existent in monolithic kernel. HOWEVER, current monolithic kernels are facing growth problems now because of two aspect: we want fancy remote storage accessed as easily as local storage (do you want to mmap a file stored in a RAID setup implemented with SATA-over-ethernet disks?) and the fact that the process model is too leaky and so we need stronger containers like VMs (that are becoming as much leaky abstractions as the current processes). All these new features require communication between various components that were previously though and implemented as independent. This means that the IPC problems are now creeping into the world of monolithic kernels.
- zanny 14y agoThe way you word it, (and from my personal bias) it seems like people kicked the can on getting IPC right down the road. I like how plan9 handled it - one socket layer to rule them all, call into other programs over sockets, and let the filesystem handle the translations. I think in this modern era of extreme hardware juice, this could easily work. And work better than what we have. Then again, I think shared memory is a harder problem to solve than using IPC through some buffered file metric. The synchronization becomes a pain in the butt, even if you manage a smidgen more performance out of the ordeal, it isn't very reusable, so it is only a situational tool. I feel like module injection a la Linux should have been a situational tool as well (at best), but we ended up putting everything in the kernel, and we keep adding more (KMS, KVM, DMI2, etc).
- kabdib 14y agoThere were a number of microkernel efforts at Apple in the 80s and 90s. - Pink (later known as the money-burning party Taligent) had a 'new kernel' that was message-passing. They spent a lot of time working on RPC efficiency. - The Newton used a message-passing kernel. Not the most efficient thing in the world, but there was MMU support to do some interesting page sharing / fault dispatch policy stuff, so you could get IPC-like behavior with faults. Basically hobbled by a 20Mhz processor with minimal cache, and not very much RAM at all. Btw, I didn't notice the Newton being very hard to debug (except that all of our debugging was printf, or you stared at the disassembled output of CFront).
- jacquesm 14y ago> Micro kernels are very hard to debug. Absolute nonsense. Micro kernels are much easier to debug than macro-kernels. The reasons are obvious to anybody that has spent more than an afternoon working with both, a microkernel is so small that the chances that your problem is in the kernel are minute compared to having your problem in user space. That means that all your luxury debug tools are available to debug the vast majority of your problems. After the initial write the kernel code of a microkernel system is hardly ever touched. A good microkernel will limit itself to do the most limited subset that will still allow the system to function and will move everything else to regular processes.
- slurry 14y agoNot very different, since we're basically doing microkernel-y things anyway using various kinds of virtualization. It would probably be more elegant to just run Hurd or whatever instead of for example running multiple JVMs on top of multiple Linux instances on top of a hypervisor (yes, this happens), but them's the breaks.
- dietrichepp 14y agoWell, people are still working on the problem. You can run some runtimes directly on Xen, like the JVM and Haskell. http://labs.oracle.com/projects/dashboard.php?id=185 http://labs.oracle.com/projects/dashboard.php?id=185 http://readwrite.com/2010/11/30/haskell-virtual-machine http://readwrite.com/2010/11/30/haskell-virtual-machine
- nacker 14y agoIs this comparable to eLua? http://www.eluaproject.net/home/overview http://www.eluaproject.net/home/overview EDIT: I found this on YouTube: https://www.youtube.com/watch?v=W_aXsutL4rQ 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.
- dietrichepp 14y agoWell, 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 environments are vastly different.
- nacker 14y agoThanks for the explanation. I was really hoping to find something like the SqueakNOS project http://www.artima.com/weblogs/viewpost.jsp?thread=239339 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!
- emiliobumachar 14y agoStallman, the FSF and the free software ideals would probably be much more widely known. Many (most?) users of GNU/Linux call the whole OS "Linux" and honestly think Torvalds started the whole endeavour.
- sneilan 14y agoIt sank like a turd.
- vacipr 14y agoFor those interested, Debian is planning on releasing a Hurd variant just like they did with kFreeBSD. http://www.debian.org/ports/hurd/index http://www.debian.org/ports/hurd/index
- nasalgoat 14y agoAn oft-quoted phrase that applies here is "the enemy of good is 'better'". Clearly RMS wanted his idea of perfection, and almost 30 years on, perfection remains out of reach while "good enough" rules the world on Linux. An important lesson to learn.
- slurry 14y agoIt's easy (and legitimate) to blame the failure of Hurd on poor design and management choices. I think it's also instructive, though, to observe how no "better than Unix" project has really attained any success. Some of them have delivered more workable code than Hurd, but Plan 9, Inferno, Amoeba - none of them have really caught on.
- InclinedPlane 14y agoInterestingly unix derivatives are now some of the most popular operating systems for modern devices, as iOS, Mac OS, and Android are unix/linux based.
- tonfa 14y agoI thought XNU was considered a micro-kernel because of the Mach part.
- erichocean 14y agoIt's not a microkernel; it just happens to implement the Mach APIs.
- mhjacobson 14y agoMore 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.
- klrr 14y agoNote: RMS think Linux is "good enough" and Linux-libre is part of GNU, so Linux will be used for the in-development official GNU "distro".
- AndrewDucker 14y agoCan 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?
- loeg 14y agoMicrokernels 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 modules with clear APIs), but with direct function calls instead of message passing. I don't know if the Linux/BSD kernels are much different — I've poked at all three, and at a high level they look very similar.
- mcartyem 14y agoThe message passing overhead issues have been successfully addressed. http://ertos.nicta.com.au/research/l4/ http://ertos.nicta.com.au/research/l4/ http://ssrg.nicta.com.au/publications/papers/Heiser_08lca.slides.pdf http://ssrg.nicta.com.au/publications/papers/Heiser_08lca.sl...
- AndrewDucker 14y agoThanks for that. The PDF and http://en.wikipedia.org/wiki/L4_microkernel_family http://en.wikipedia.org/wiki/L4_microkernel_family were both fascinating. I then read a bit about an attempt to port Hurd to L4, which floundered for reasons which are beyond my understanding.
- deleted 14y ago[deleted]
- zanny 14y ago
- frozenport 14y agoI think there is another story: Not that many people where working on GNU.
- zanny 14y agoThe story mentions this. The industry had a working Linux and jumped on board. It is like how the industry jumped on C++, or x64, javascript, or unicode. The small imperfections in form of these tools didn't, at the time of their inception, justify the more massive immediate workload of trying to completely replace them with no backwards compatibility for something without the blemishes. Competitors weren't mature enough to step in, so the imperfect progressions of tried methods took the reigns rather than bolder, newer ideas, that meant shifting some of the inertia of the industry. I think that might be one of the lesser appreciable legacies of 80s - 00s in software. We have tools that are now really showing their flaws but we built the empire on cracked bricks and the unstable foundations force us to throw more man hours and effort into keeping the whole thing standing than if we just started with a fresh foundation when the better alternatives presented themselves, even if they would have taken some more work. I still really wonder where we would be if we had a C++ with a clean grammar and Python level readability. Where we didn't try to layer interpreters and JITs over convoluted C ABI compatibility.
- chipsy 14y agoI recommend the "STEPS Toward Expressive Computing Systems" reports for more current-day thoughts on OS redesign (available here http://www.vpri.org/html/writings.php http://www.vpri.org/html/writings.php ) Basically, by designing exactly the necessary language for each layer, they've reduced the code requirements to reach useful applications by multiple orders of magnitude. I honestly wouldn't be surprised if the results of this project eventually creep into industry.
- qznc 14y agoI would be surprised if the results of this project eventually creep into industry. It sounds great to write vector and font rendering in a few hundred or thousand lines of code. On the other hand, others have been writing orders of magnitude more code in orders of magnitude more time. I cannot believe that has been due to a wrong choice of language or approach. I much more believe it comes from supporting real-world standards and requirements. Loading fonts from various formats, lots of configuration, supporting more and more of Unicode, doing all that optionally with hardware support. That is the tedious part. It is not about how to implement Bresenham's line algorithm most elegantly.
- drivebyacct2 14y agoSo if things like Arch Hurd exist... Are we just missing the user interest in Hurd or are there usability problems with it or?
- mcartyem 14y agoIt's not enough to build something that's better. You also need to sneak it in like a Trojan horse into a user's fortress. You can't easily launch a frontal attack on Linux. One of the most valuable opportunities with mobile is that current technologies can become irrelevant. A big success for L4 is that it made it into mobile phones.
- wtracy 14y agoAFAIK a lot of it is due to issues as simple as Linux having more device drivers than Hurd.
- derleth 14y ago> 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?
- kcbanner 14y agohttp://en.wikipedia.org/wiki/IBM_386SLC http://en.wikipedia.org/wiki/IBM_386SLC
- derleth 14y ago> http://en.wikipedia.org/wiki/IBM_386SLC http://en.wikipedia.org/wiki/IBM_386SLC Very interesting. Thank you.
- deleted 14y ago[deleted]
- chimeracoder 14y agoAs 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!
- jacquesm 14y agoThe 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.
- lucian303 14y ago“My first choice was to take the BSD 4.4-Lite release and make a kernel. I knew the code, I knew how to do it. It is now perfectly obvious to me that this would have succeeded splendidly and the world would be a very different place today." So true. It's unfortunate AT&T/Unix System Laboratories kept the BSD kernel code locked up in a lawsuit. Would have loved the article to have had a deeper insight into that as Stallman had already chosen to abandon Hurd by the time Linux came around. It wasn't just that Linux was available, it was that BSD wasn't. It's too bad that the last few years have seen a decline in FreeBSD / other BSD OS's especially as it is an amazing operating system still light years ahead of GNU/Linux is many areas. Not to mention that it's one unified OS rather than hundreds of GNU/Linux distros. One can only imagine what would have happened had the BSD code not been tied up in lawsuits. I bet they would have gone with the mature BSD kernel, leading to a better OS, and Linux would probably be a footnote in history if that. Interesting how inferior technology wins a lot more than it loses. That said, I still love GNU/Linux. :)
- lvillani 14y ago> Not to mention that it's one unified OS rather than hundreds of GNU/Linux distros. I admittedly haven't used any BSD enough to make a well informed opinion but I was under the impression that BSDs are fragmented at the OS level (i.e.: different kernels), while Linux is fragmented at the distribution level (i.e.: default collection of software, file-system layout, etc). I imagine that, in addition to there being different kernel flavors there are also distribution level differences (e.g.: there are subtle differences between FreeBSD's rc.conf and NetBSD's) so I'm not sure which approach is better or worse, but I tend to lean on the "one kernel, several distributions" camp.
- lucian303 14y agoThere is no OS level fragmentation. Sorry that makes no sense in the BSD world. FreeBSD is an OS. OpenBSD is an OS. etc. That's not fragmentation. They are different OS's. It's like saying there's fragmentation between Windows and OS X. GNU/Linux is one OS with hundreds of distros. That's fragmentation.
- 14y ago
- gus_massa 14y agoI think that this article underestimate the ability of Linus Torvalds to manage the Linux developers community. Leadership, dispute resolution, technical choices, compatibility or new features, and teven flamewars. It's very difficult to be a BDFL. The idea is that if Linux were not available, the open source community would have been working in Hurd and not in Linux. But without Linus perhaps the community could not exist (new member leave after a few quarrels) or all the effort is lost in complete rewrites.