I think there is another story: Not that many people where working on GNU.
Whatever happened to the Hurd? – The story of the GNU OS
31–40 of 93 posts
Re: Whatever happened to the Hurd? – The story of the GNU OS
#32Can 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?
Stallman, 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.
Re: Whatever happened to the Hurd? – The story of the GNU OS
#33Earlier 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…
The message passing overhead issues have been successfully addressed. http://ertos.nicta.com.au/research/l4/ http://ssrg.nicta.com.au/publications/papers/Heiser_08lca.sl...
Those slides made my head hurt.
The problem it tries to bring up is that there is a subset of processes running in the Linux Kernel as either baked in functionality or KOs that can avoid context switches and IPC calls by being baked into the same executable.
In practice, you can share memory. In practice, a code base as large as Linux actually ends up having a lot of TLB flushing whenever it alternates between the very different sections of binary that dictate behaviors of the core kernel and devices.
It doesn't help that the self fulfilling prophecy is that by fine tuning a baked in service into Linux means that a lot less effort is made trying to make it an efficient interface.
I am obviously biased, I think microkernels are a good idea. I don't know if its unix or not, but I don't like having one binary that will inject itself with extra linkables when needed that manages every device, the network stack, the sound API, manages the filesystem, manages memory, and manages processor scheduling. Most of this stuff doesn't need the kernel mode special processor registers, in practice a well designed system shouldn't require anything more than a fixed memory page reference to the device that the kernel will handle mapping (I can't think of a way to build a kernel without virtual memory, virtual files, and virtual processing baked in at the ground level, and 2/3 of those really do require special processor permissions).
Re: Whatever happened to the Hurd? – The story of the GNU OS
#34I think there is another story: Not that many people where working on GNU.
The 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.
Re: Whatever happened to the Hurd? – The story of the GNU OS
#35So if things like Arch Hurd exist... Are we just missing the user interest in Hurd or are there usability problems with it or?
Re: Whatever happened to the Hurd? – The story of the GNU OS
#36Earlier quoted context omitted.
The message passing overhead issues have been successfully addressed. http://ertos.nicta.com.au/research/l4/ http://ssrg.nicta.com.au/publications/papers/Heiser_08lca.sl...
Thanks for that. The PDF and 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]
Re: Whatever happened to the Hurd? – The story of the GNU OS
#37Earlier quoted context omitted.
Then everyone would have ran BSD. (J/K) Micro kernels are very hard to debug.
> 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 sp…
The 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).
Re: Whatever happened to the Hurd? – The story of the GNU OS
#38Earlier quoted context omitted.
The message passing overhead issues have been successfully addressed. http://ertos.nicta.com.au/research/l4/ http://ssrg.nicta.com.au/publications/papers/Heiser_08lca.sl...
Those slides made my head hurt. The problem it tries to bring up is that there is a subset of processes running in the Linux Kernel as either baked in functionality or KOs that can avoid context switches and IPC calls by being baked into the same executable. In practice, you can share memory. In practice, a code base as large as Linux actually ends up having a lot of TLB flushing whenever it alternates between the ve…
You might not be biased. It's hard to ignore Wombat demonstrating context-switching costs that are up to 30 times lower than native Linux.
The status quo of kernels is reminiscent of the status quo of programming languages in the 90s. Where people programmed in faster, static languages and looked down on dynamic ones. I wonder what we will think of monolithic kernels in 50 years from now.
EDIT: A binary injecting itself with multiple code (linkables) might not be bad. It's much like what a macro does to a program. You turn one flag on and the source gets populated with the appropriate code.
It is lack of a dynamic way of injecting it that can bite you. The inability to easily change what was injected.
Re: Whatever happened to the Hurd? – The story of the GNU OS
#39So if things like Arch Hurd exist... Are we just missing the user interest in Hurd or are there usability problems with it or?
It'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.
Re: Whatever happened to the Hurd? – The story of the GNU OS
#40Earlier quoted context omitted.
Then everyone would have ran BSD. (J/K) Micro kernels are very hard to debug.
> 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 sp…
There 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).