10 ms·
Whatever happened to the Hurd? – The story of the GNU OS
- 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.
- 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.
- 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.