5 ms·

The machines are different. Multicore 64-bit chips are now standard for consumer PCs. RAM and persistent storage are faster and much more abundant. The architec

The machines are different. Multicore 64-bit chips are now standard for consumer PCs. RAM and persistent storage are faster and much more abundant. The architecture of the modern x86-64 is much more sophisticated than that of the 386 for which the earliest Linux was written. Vectorization, predictive branching, and asynchronous code are all front and center in the modern programmer's ecosystem. In short, hardware is more capable, and so perhaps now we can afford to take more opportunities to trade a little bit of overhead for abstractions that are more modular and robust.

RoseRose 3y ago
> In short, hardware is more capable, and so perhaps now we can afford to take more opportunities to trade a little bit of overhead for abstractions that are more modular and robust. We could afford that before, it's just that Linus didn't see the value and put his foot down. Which is definitely a choice.
taeric 3y ago
In a very real sense, the hardware has given a realization of microservice ideas, but at the hardware level. My WIFI card, the common and popular example, probably has more processing power than some of the early desktop computers back in the day. Certainly SSDs are getting much more complicated. They aren't general purpose, but I presume microkernel "services" would also not be general purpose?
- lmm 3y ago
  Often they are general-purpose. There's a blog from maybe 10 years ago of someone launching Linux on a hard drive (it refuses to fully boot because the hard drive doesn't have an MMU, but they get some familiar log output).
  - taeric 3y ago
    Yeah, I vaguely remembered that, but couldn't find the details in a quick search. So, sadly assumed I may have imagined it. :D
praptak 3y ago
Do we have more hardware isolation? There was a pretty strong argument against microkernels - a driver running in userspace can still bork the whole machine if the hardware being controlled can write to memory at arbitrary addresses.
- j16sdiz 3y ago
  we have more hardware isolation. they are seldom implemented correctly on firmware/mainboard level.
- bonzini 3y ago
  Yes, there's IOMMUs. On the other hand, datacenters have become so large that a 1% performance improvement can amount to millions of dollars in hardware and energy savings, so the extra cost of a microkernel might not be very welcome outside consumer devices.
  - effie 3y ago
    We did not yet have a big publicized hack of whole cloud infrastructure causing massive economic harm. When that happens (the buggy PC/Linux architecture running the world is ripe), more secure architectures will become commercially interesting despite the 1% performance penalty.
  - pjmlp 3y ago
    Hardly of value with kubernetes everywhere running on top of type 1 hypervisors. Microkernels have won, even if monolitich kernel advocates haven't yet got the message.
josefx 3y ago
> Vectorization, predictive branching, and asynchronous code are all front and center in the modern programmer's ecosystem. Not to forget all the hardware based security bypasses that let any random application read and even modify any memory location it wants to.
winternewt 3y ago
RAM is faster but CPU is even faster. The latency chasm between CPU and RAM has increased.
mike_hearn 3y ago
Being a microkernel doesn't automatically make you more robust. If you look at their docs, Hurd has only one feature that's different to Linux and that's a sort of souped up FUSE. But as they realized later, allowing arbitrary unprivileged programs to extend the filesystem like that doesn't mesh well with the UNIX security model. You can write a "translator" that redirects one part of the filesystem tree to another, so you get the same issues as with chroot or symlink attacks. Their proposed solution (never implemented?) is to stop programs paying attention to translators by default if they are running as a different user. There are other cases where translators can DoS apps or do other undesirable things. The basic problem is that the kernel boundary is a trust boundary. You assume that anything in the kernel is legit and won't try to attack you, which simplifies things a lot. In the microkernel world the original idea was that all the servers would be just ordinary programs you could swap in and out at will. But then the threat model becomes muddied and unclear. Is it OK to run a server that's untrusted? If so, to what extent? The Hurd seems under-designed as a consequence. To make that vision work you'd need to be willing to depart from UNIX way more, which really means being a research OS.
- Paul-Craft 3y ago
  > Being a microkernel doesn't automatically make you more robust. No, of course, it doesn't automatically do so. But it makes it a whole hell of a lot easier to write a reliable service, if you don't have to deal with all the crap that a monolithic kernel does. In a very real sense, lines of code are a liability: fewer LoC generally translates into fewer bugs in the software. I think you'd find Plan 9 interesting. It deals with many of the issues you're talking about in a rather head on way. In fact, it takes things even further than Hurd might, and allows processes to migrate to different processors, which may be contained on completely different machines.

RoseRose 3y ago

> In short, hardware is more capable, and so perhaps now we can afford to take more opportunities to trade a little bit of overhead for abstractions that are more modular and robust. We could afford that before, it's just that Linus didn't see the value and put his foot down. Which is definitely a choice.

taeric 3y ago

In a very real sense, the hardware has given a realization of microservice ideas, but at the hardware level. My WIFI card, the common and popular example, probably has more processing power than some of the early desktop computers back in the day. Certainly SSDs are getting much more complicated. They aren't general purpose, but I presume microkernel "services" would also not be general purpose?

lmm 3y ago
Often they are general-purpose. There's a blog from maybe 10 years ago of someone launching Linux on a hard drive (it refuses to fully boot because the hard drive doesn't have an MMU, but they get some familiar log output).
- taeric 3y ago
  Yeah, I vaguely remembered that, but couldn't find the details in a quick search. So, sadly assumed I may have imagined it. :D

praptak 3y ago

Do we have more hardware isolation? There was a pretty strong argument against microkernels - a driver running in userspace can still bork the whole machine if the hardware being controlled can write to memory at arbitrary addresses.

j16sdiz 3y ago
we have more hardware isolation. they are seldom implemented correctly on firmware/mainboard level.
bonzini 3y ago
Yes, there's IOMMUs. On the other hand, datacenters have become so large that a 1% performance improvement can amount to millions of dollars in hardware and energy savings, so the extra cost of a microkernel might not be very welcome outside consumer devices.
- effie 3y ago
  We did not yet have a big publicized hack of whole cloud infrastructure causing massive economic harm. When that happens (the buggy PC/Linux architecture running the world is ripe), more secure architectures will become commercially interesting despite the 1% performance penalty.
- pjmlp 3y ago
  Hardly of value with kubernetes everywhere running on top of type 1 hypervisors. Microkernels have won, even if monolitich kernel advocates haven't yet got the message.

josefx 3y ago

> Vectorization, predictive branching, and asynchronous code are all front and center in the modern programmer's ecosystem. Not to forget all the hardware based security bypasses that let any random application read and even modify any memory location it wants to.

winternewt 3y ago

RAM is faster but CPU is even faster. The latency chasm between CPU and RAM has increased.

mike_hearn 3y ago

Being a microkernel doesn't automatically make you more robust. If you look at their docs, Hurd has only one feature that's different to Linux and that's a sort of souped up FUSE. But as they realized later, allowing arbitrary unprivileged programs to extend the filesystem like that doesn't mesh well with the UNIX security model. You can write a "translator" that redirects one part of the filesystem tree to another, so you get the same issues as with chroot or symlink attacks. Their proposed solution (never implemented?) is to stop programs paying attention to translators by default if they are running as a different user. There are other cases where translators can DoS apps or do other undesirable things. The basic problem is that the kernel boundary is a trust boundary. You assume that anything in the kernel is legit and won't try to attack you, which simplifies things a lot. In the microkernel world the original idea was that all the servers would be just ordinary programs you could swap in and out at will. But then the threat model becomes muddied and unclear. Is it OK to run a server that's untrusted? If so, to what extent? The Hurd seems under-designed as a consequence. To make that vision work you'd need to be willing to depart from UNIX way more, which really means being a research OS.

Paul-Craft 3y ago
> Being a microkernel doesn't automatically make you more robust. No, of course, it doesn't automatically do so. But it makes it a whole hell of a lot easier to write a reliable service, if you don't have to deal with all the crap that a monolithic kernel does. In a very real sense, lines of code are a liability: fewer LoC generally translates into fewer bugs in the software. I think you'd find Plan 9 interesting. It deals with many of the issues you're talking about in a rather head on way. In fact, it takes things even further than Hurd might, and allows processes to migrate to different processors, which may be contained on completely different machines.