That's a pity. Wouldn't it be nice if we somehow could separate the cruft from the craft?
What if some computational deity sifted through our collective codebase and distilled the essence, the minimal, purest kernel? Such minimangel's task would be daunting and probably useless, since the moment we'd throw some new use cases and requirements, NIH and patents, POCs and MVPs and we're back to the simmering mess in no time.
The other closest thing is probably an exokernel, which is essentially a rump kernel with all the of the stuff that's optionally in userspace removed from the kernel. MIT did a lot of experimentation there.
The article is not talking about the kernel, it is talking about the whole installed system. It is saying people are making minimal distros with custom kernels for single functions.
For the longest time I viewed kernel programming as an exalted realm of "optimized bare-metal software written by visionaries and wizards" (like operating system core developers of the Dave Cutler variety). Having had the misfortune of dabbling in reverse-engineering Windows drivers and debugging in-tree Linux kernel drivers, I now believe they're often messy hackjobs written by low-paid average-skilled embedded developers, no less fallible than the average enterprise Java programmer (https://blog.ffwll.ch/2022/08/locking-hierarchy.html expresses a similar sentiment). And I feel the maintainers are sometimes spread far too thin (Dmitry Torokhov manages a good chunk of Linux's entire input system, no wonder he lets mistakes slip by in the touchpad driver, I'm just disappointed I reported a bug to the mailing lists and never got a reply after like a month).
EDIT: The wizards are out there, for example https://pvk.ca/Blog/2019/01/09/preemption-is-gc-for-memory-r..., but they're not evenly distributed, and perhaps the insane cutting-edge code they write (and the less insane code I write) isn't necessarily dependable, since by definition they lie on the edge of human understanding.
A jitted, partially evaluation capable kernel. The thesis is very readable, proof: I could enjoy almost all of it and I'm a monkey. It might give some insights about kernel design that may not be told in mainstream ones.
I think you underestimate the amount of functionality in something like the Linux kernel and how much work it would take to recreate even a small percentage of it.
The kernel is also shockingly simple. Sure there are some tricky bits, but writing kernel code is very straight-forward. In fact every time I've written kernel code it has always been a "it can't really be this simple" type moment -- but some of that code is still running production machines today so... it must have been.
NOTE: this is not me bragging, it's me suggesting the mystique is a bit undeserved.
There is GNU/HURD that was supposed to be the kernel. However, its development hit roadblock when microkernel design ended up extremely difficult to debug. Sometimes you can't predict real complexity from the architectural drawing board and prevailing hype in academia, pointing to microkernels as the future at that time. Linus just wanted to implement his own, simple UNIX kernel, based off proven principles, without doing original kernel research.
I feel obligated to point out that there is a notable lack of eyeless developers in Linux kernel developer community, even after many, many years of development.
That's a pity. Wouldn't it be nice if we somehow could separate the cruft from the craft?
What if some computational deity sifted through our collective codebase and distilled the essence, the minimal, purest kernel? Such minimangel's task would be daunting and probably useless, since the moment we'd throw some new use cases and requirements, NIH and patents, POCs and MVPs and we're back to the simmering mess in no time.
reply