5 ms·
what we _actually_ needed was radical surgery like object-oriented operating systems or microkernels or exokernels or orthogonal persistence (or all of the abov
by vezzy-fnord 11y ago
what we _actually_ needed was radical surgery like object-oriented operating systems or microkernels or exokernels or orthogonal persistence (or all of the above!)
Do we not?
I watched your interview, but I don't recall you saying anything about research ideas. You even made a jab against Spring which rubbed me the wrong way.
An orthogonally persistent microkernel-based operating system, even another Unix, would be great. Which is why I'm looking at MINIX 3 and Hurd as interests. The latter has its anachronisms, but it's still a step forward.
- nextos 11y agoI think we need a functional userland (like nix) and a microkernel (like minix), at least. Sadly we will get a userland full of container-ized apps (via systemd) and a monolithic kernel (still linux). Worse is better.
- igravious 11y agoWe've had the microkernel versus monolithic kernel debate _over_ and _over_. I'm not against research but I've yet to see a convincing argument that microkernels are better. If you decouple the logical bits of the kernel from each other all you'll get is greater impedance and message passing overhead. And for what? A "clean" architecture? Sometimes perfect is the enemy of the good, and I think that applies in this case. We've also got the tools to make monolithic kernel development scale now. Basically, I'll believe it when I see it.
- vezzy-fnord 11y agoWe've had the microkernel versus monolithic kernel debate _over_ and _over_. I'm not against research but I've yet to see a convincing argument that microkernels are better. Sure, if all you do is read Linus Torvalds ranting. If you decouple the logical bits of the kernel from each other all you'll get is greater impedance and message passing overhead. Debunked many times, as early as 1992 in fact: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.16 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.1... Microkernels have come a long way since Mach. And for what? A "clean" architecture? You clearly have no idea what the advantages are. Basically, I'll believe it when I see it. You're seeing it in the billions of L4 deployments worldwide in wireless modem chipsets. You're seeing it in QNX being everywhere. But then again, you might not see it, because you are willfully ignorant.
- tedunangst 11y agoHow many of those L4 deployments end up running 90% of their code in the "Linux" or "posix" process?
- kragen 11y agoThat might still be an argument in favor of microkernels if the Linux process can't crash the machine or cause it to miss hard-real-time deadlines. Or if you can use it to confine malicious code in the Linux process.
- tedunangst 11y agoFair, but when people talk about "real systems" built with micro kernels, as often as not, it could also describe Linux on xen with a watchdog restart. It's not especially compelling evidence that micro kernels are practical. Want to convince me that micro kernels are the bomb? Tell me about a system where no single service exceeds 40% of the code/runtime.
- kragen 11y ago"Unikernels" is the misnomer being promoted by MirageOS for applications compiled to run on Xen, which they are currently doing on Amazon EC2 hosts alongside Linux instances. There are EC2 hosts that host a number of instances, including "unikernels" and Linux instances, and although I don't have details, the pricing on the smaller burstable instance types makes me think that some of the EC2 hosts are hosting actually quite a large number of instances, in which no instance exceeds 5% of the code or runtime. Is that what you're talking about?
- tedunangst 11y agoNo. What I mean is a micro kernel pace maker where 40% of the code is the beep beep service, and 30% is the meep meep service, and 30% is the bop bop service. As opposed to 99% of the code in the Linux service and 1% of the code in the realtime watchdog restart service. Calling EC2 a micro kernel success story also seems like quite the definitional stretch.
- luckydude 11y agoSo they can be better. QNX is the one example I know of that is better. It's also the only microkernel that is actually micro. When I was looking at it the whole kernel, all of it, fit in a 4K instruction cache. Most "micro"kernels aren't micro at all, they are bloated crapware. QNX was not like that, they actually had a micro kernel and it worked. I ran 4 developers on an 80286 (no VM) and it worked just fine. Far far better than the VAX 11/780 that had more memory and more CPU power. The VAX was running 4.1 BSD.
- bcantrill 11y agoWell, radical surgery was needed -- it just wasn't at the level of the operating system interface, but rather much deeper in the implementation. For example, ZFS post-dates this rant and certainly represents a radical rethink of filesystems -- but it did this without breaking extant applications. That extant applications were (and are) a constraint on the problem is something that's entirely unappreciated by mid-1990s OS research, which was hellbent on throwing out existing abstractions rather than building upon them. Finally, in terms of Spring: based on the fact that you are implicitly defending it, I would guess that you never had to run it. As one of the very few outside of Sun inflicted with that flaming garbage barge, I can tell you that it was not at all a pleasurable experience -- and that whatever novelty it represented was more than offset by its horrifically poor implementation. If I ever harbored any illusions about Spring, they certainly didn't survive my first encounter with a machine running it...
- kragen 11y agoI imagine it wasn't that pleasant being one of Jenner's cowpox inoculees, either. But that was an important step towards eradicating smallpox nine generations later. And the electricity I'm writing this with is produced by a steam engine descended from those that blanketed London in deadly smog for ten generations. Lots of beneficial innovations go through an early stage where they're counterproductive or unpleasant.