I honestly wouldn't mind seeing Linux get re-written as a microkernel, converting everything else into kernel modules that can be installed, configured and dynamically loaded as required. That would reduce a lot of the existing bloat in Linux, though can be achieved just as easily configuring every available flag before compile time.
There's no need to try to turn Linux into something it isn't. There are lots of OSs, it's possible to use ones that aren't called "Linux".
> achieved just as easily configuring every available flag before compile time.
It takes longer now to go through `make oldconfig` than it used to take to compile the kernel. At some point, it starts to make more sense to split up concerns. It's pretty amazing that the same kernel does all right on a phone and on a supercomputer, but maybe it's stretched a little thin: we still have drivers for sound cards that haven't been sold since the 90s, when sound cards were an extra peripheral that you crammed into an ISA port and had to pick an IRQ for and there was a 15-pin D-sub connector for MIDI devices but most people just used them for the GRAVIS GAME PAD WHICH THE ULTIMATE DEVICE FOR PEOPLE THAT WANT ALMOST ENOUGH BUTTONS TO EMULATE THE SNES. see_the_joystick_unscrewed_it_was_a_mess.gif these_controllers_sucked.jpg
I have a giant "kernel firmware" package on my LiveSlak image. It is 500MB, a little more than a quarter the size of the entire image. I am certain that I will not ever use more than 50MB of those, but because it is one big blob, I don't know. List the sound/wifi/ethernet/graphics chips in all the laptops in the house.
So it's nice that your ISA sound card works without you having to locate a driver for it, right, unironically: that is very cool. On the other hand, I typed `git pull` in the kernel directory yesterday or the day before, and it took about 30 minutes.
> they are in the category of good things that are too hard for average programmers
Average programmers like Chuck Moore, Ken Thompson, Linus Torvalds, Arthur Whitney. I mean, I worked with Thomas Bushnell and he's brilliant and he does not seem to have completed his work of shipping a kernel for GNU/HURD. The smartest programmer that ever lived, St. Terry, did not do a microkernel, and he delivered a working .iso file. I guess all of those guys are average. Where are the programmers that are smart enough to build these microkernel systems?
This is the trap: "This system is conceptually nice when examined from a certain angle, and if you don't agree, it's because you're not smart/talented/knowledgeable enough." You say something is total shit and someone comes along and says it's just that you are a caveman and unable to appreciate it, and sometimes you are a caveman but sometimes it's total shit and you're not a caveman, the other guy is a defensive eunuch, masturbating without producing anything. Brian Kernighan, when asked about Standard ML, said he didn't mean to disparage his colleagues' work, but that ML seems to have been used almost exclusively for building ML compilers, and this is the feeling I get from a lot of these systems. 02_night_night_produced_by_nosajthing_featuring_kevin_hart_1.mp3
I agree with you on microkernels; my objection was that this use of "modern" is the worst hand-wave that coders do nowadays. Almost invariably, it doesn't mean "systems in current use" but "systems that I both like and I am familiar with". A microcontroller is "modern hardware" and nothing that anyone asserts about "modern hardware" applies to it. Half the time, the hardware in a server doesn't fit what people mean when they say "modern hardware".
"Modern" means nothing in current use: it's worse than meaningless, in fact, because it is subjectivity disguised as objective pragmatism. It's spouted by the CADTs that movefastbreakthings in order to dismiss things they don't want to consider.
Very smart people work on monolithic kernels. Have you read the book "The Structure of Scientific Revolutions"? Incredibly smart people are still trapped in thinking paradigms. Torvalds is smart and very capable but self-interested and kind of arrogant.
It's hard to make a good microkernel. People can belt out working, high performing monolithic kernels in a lot less time. The relative ease of other architectures sucks the air out of the room for innovation and advancing the state of the art. I liked the idea of microkernels but didn't think it was worth it until I saw Genode running on top of SEL4. Linux is working really good these days so people still don't see the need.
I don't think monolithic kernels completely kill innovation, there is orthogonal innovation happening that monolithic kernels can take advantage of. (real) capability architecture, or using languages that prioritize safety while not being slower. A lot of growth can happen in Linux without throwing everything away for a microkernel, so I'm not down them. But I think microkernels are the next paradigm.
I think more people brainlessly shit on microkernels because of stuff Torvalds said than people brainlessly repeat that microkernels are superior and we should throw away all our working shit, but I could be wrong.
> Have you read the book "The Structure of Scientific Revolutions"?
No, but I imagine I should take this as a recommendation. I wouldn't necessarily treat software as the same, though: you can replace all of your software much more quickly than you can anything that requires physical hardware or retraining, and software doesn't depend on academia to move.
> Incredibly smart people are still trapped in thinking paradigms.
I'm not convinced that this is what's going on. There was no shortage of people interested in microkernels. There's been industry interest: Apple took Mach, but they hacked half the micro out of it. The hypothetical trap that has kept people stuck on monolithic kernels isn't real: anyone knows how message-passing works, they don't suddenly stop understanding this concept when you try to make the ethernet driver run in userspace.
What's actually changed is the nature of the machines themselves. For any real computing when microkernels were designed, computers:users were still N:1. Real computing moved and it was 1:1 when real microkernels arrived. We've now got 1:N. Heterogenous computing was a challenge back then and the network wasn't the computer: heterogenous computing is now the norm and the network is the computer to the extent that most people cannot work using a machine that has no browser because access to remote resources matters more than what is going on in the kernel in your system.
The trap is thinking of computers as monoliths. The network isn't just the computer, there is no more computer without a network. Joe Armstrong was brilliant, so Erlang had the right model. Plan 9 had the right model. Tony Hoare was right but Andy Tanenbaum was inconsequential. Why has HTTP eaten the world? Simple, universally accessible protocol for message-passing and resource-sharing across a network. A microkernel, by contrast, is separated but still tightly coupled.
So, like with everything that reeks of wonkery, I'll believe it when I see it. NetBSD's rump kernel looks like a more promising architecture. Microkernels look to me a lot like VLIW, with its "well, nobody's caught up yet, it'll be faster than everything as soon as the compiler writers stop fucking it up it will really be way faster, in principle it should emulate x86 code faster than x86 CPUs run x86 code". Microkernels look like the "Automated proofs will make software reliable" fad that thankfully died. I will believe it when I see it.
> Torvalds is smart and very capable but self-interested and kind of arrogant.
I won't argue with this, but his "Why do you glorify doing something new and stupid, when doing good things well is what people *really* should be admiring" rant. I don't think he's trapped, I think he's taking a realistic approach.
> People can belt out working, high performing monolithic kernels in a lot less time.
It seems like it's much easier to produce a demo-quality microkernel and then publish your thesis and proceed to spend your career on Linux.
If we have learned exactly one thing since the 1980s, it should be "worse is better".
If it's easier to get a high-performance kernel with one architecture than it is with another, on what grounds is the other preferable? You can pick a kernel up and put it down and any given network will have a half-dozen different kernels on it. So if it's easy to churn out a kernel to do this and a kernel to do that and machines are 1:N and half the time these systems are single-taskers slotted into a broader system, what the hell does a microkernel buy you? The structure of the system you use has moved up one level: your system no longer lives on one computer, and a cleaner kernel--even if we pretend a microkernel is cleaner--doesn't buy you much.
Like the capability-based security systems. These mattered when you had a mixed-use system: you don't have that. You have desktop machines that have to do everything, then tiny VMs (whatever was cheapest on Low-End Talk when the deployer was buying) that have to do everything, and then everything past that is task-per-machine.
> The relative ease of other architectures sucks the air out of the room for innovation
The network is the computer. Which matters more to you in practical terms: how the kernel works on a given machine, or how the EVM works?
Good code is I/O-bound. For a deployment environment
> Linux is working really good these days so people still don't see the need.
Because the network is the computer and it's all hypervisors managing VMs anyway, the cost of changing OS has never been lower. It's near-zero friction. I port some dumb webshit I run locally to Plan 9, right, and it turns out extremely boring. I hate Debian and I am still using Debian all over the place because it doesn't matter.
> But I think microkernels are the next paradigm.
20 years from now, if we still have electricity and are not all running CollapseOS, I feel fairly confident that it'll be monoliths, unikernels, unikernels under hypervisors, and maybe we get hybrid/exo/etc.
> I think more people brainlessly shit on microkernels because of stuff Torvalds said than people brainlessly repeat that microkernels are superior
Sure, accurate, but I think people brainlessly shitting are not worth addressing.
I do think that "It's just that the hackers that created things that defined the current paradigm were just not very good and thus didn't favor my pet technology" is a bad approach: there are some thought-stopping cliches for code, and they are almost all completely wrong, perniciously wrong.
There is also a special place in hell for people that manage to convince coders to chase their tails down a rabbit hole full of twisty passages, all of which look like yaks, because they like an idea that has never worked and they paper over their defensiveness by affecting condescending smugness. "Real microkernels haven't been tried yet! You're just not smart enough." Tony Hoare is presumed absolutely correct until conclusively proven otherwise; as noted above, he's right about CSP, and here he's right about "so simple there are obviously no deficiencies" being superior to "so complex that there are no obvious deficiencies". Pistol Mcfly - Google Me - 05 Otis.mp3
Everything makes that claim, and likely will make that claim while security is an unsolved issue (i.e., forever).
A computer that is unplugged has the best security, but is not useful. A computer with zero security never gets in your way. There is a point you have to pick in the trade-off, between "useful enough to accomplish what you want to accomplish" and "secure enough to prevent security problems from interfering with the things you want to accomplish".
Note that the trade-off is not linear: it's possible to have a system that is marginally more secure but only half as useful.
@p@dcc@Maholmire@pwm@dushman@nerdeiro@BrodieOnLinux@mima@SrEstegosaurio@Hyolobrika microkernel only has to conceptually be separated into components and communicate with message passing but it's possible to do this without enforcing the boundaries. I believe QNX is like this, you can bypass message passing but don't do that! Your software won't crash because you followed the rules. Until you fail to validate untrusted input. But in practice you want to enforce the boundaries. That has security benefits but mainly it's about reliability. component crashes. it's a mini-server with defined input and output, no shared memory. you just restart it.
this is an implementation detail but it appears that vendors are incompetent. tons of implementation and configuration flaws in commercial offerings, like really basic stuff.
> microkernel only has to conceptually be separated into components and communicate with message passing but it's possible to do this without enforcing the boundaries.
Well, sure, but if we mean "not enforced, just message-passing style instead of shared memory", then half the kernels classified as monoliths might count as microkernels. That was one of Armstrong's interesting observations: sometimes message-passing can be much faster than sharing memory if passing a message lets you avoid locking, and his system has all of these immutable data structures so you don't even have to copy or copy-on-write, you just pass a pointer.
> it's a mini-server with defined input and output, no shared memory. you just restart it.
This is how Erlang is intended to work as well. I think this is how good systems tend to work.
@p@dcc@Maholmire@pwm@dushman@nerdeiro@BrodieOnLinux@mima@SrEstegosaurio@Hyolobrika at some point everywhere started saying "hybrid kernel" and I think this is the reason why. you're only a microkernel as you approach 100% of the kernel doing it (100% is obviously impossible.) Linux is pragmatic and I agree that microkernel concept is dogmatic.
It looks like this paper went for the obvious approach, but when I said I expect a lot of unikernels, I meant like a Forth system is a unikernel. I mean compute-dust. GreenArrays 144-core chips look like the start of a near-inevitability. (Feel free to believe it when you see it.)
In more practical terms that apply today, unikernels where the application code is written in a bytecode VM have a different security model than "just write it in C and link that code in". You can do compile-time guarantees that prevent you even requiring an MMU. So you tack a blob on. You can do this kind of thing with BEAM or Inferno right now (compile some Limbo code, include only as much as needed to run that code in the builtin filesystem, boot that kernel), and I imagine people have built similar systems around more conventional kernels.