The Linux Edge (1999)
blog.corememory.io
blog.corememory.io
I suppose we may see something like that eventually, but this article is now 20 years old. Isn't that about the same amount of time between Unix and Linus beginning to work on Linux? I know there's various new OSes in the works, but nothing has caught on yet. But, it's not like Linux caught on immediately either, ("just a hobby, won't be big and professional like gnu"). Maybe in another 5 or so years all the systems hackers, professionals and amateurs alike will all be flocking around NewOS, which is so much better and fun to hack on than crufty old Linux.
This also means that people doing new things know they'll have the most impact if they do it on Linux and so that's were they do it (plust it being everywhere means they're likely to be familiar with it.)
Personally I think if something new were to come along it would have to have something that makes it interesting socially and I'm not sure there's a lot of room for improvement on that front. It's not impossible it's just a little difficult to imagine.
In fact from my personal experience Linux and hardware especially on laptops is very hit or miss.
I'm guessing this is because many hardware companies don't upstream do to patents and other legalities.
If a project comes along that can solve those issues I can see Linux having a GCC LLVM moment.
If instead drivers were contributed back upstream this wouldn't be a problem.
Personally it's been a while since I've had a laptop with serious driver problems on Linux. Some discrete cards from Nvidia cause problems and there's some weirdness with secure boot but other than those I really haven't seen what you're talking about.
I don't think you quite understand what I'm saying? Mainline here refers entirely to the kernel. There is no "mainline linux userspace." (unless you count a handful of Linux specific userspace tools for stuff like ext4 filesystem creation.)
"By constructing a general kernel model drawn from elements common across typical architecture, the Linux kernel gets many of the portability benefits that otherwise require an abstraction layer, without paying the performance penalty paid by microkernels.
By allowing for kernel modules, hardware-specific code can often be confined to a module, keeping the core kernel highly portable. Device drivers are a good example of effective use of kernel modules to keep hardware specifics in the modules. This is a good middle ground between putting all the hardware specifics in the core kernel, which makes for a fast but unportable kernel, and putting all the hardware specifics in user space, which results in a system that is either slow, unstable, or both."
So the combination of a kernel model with interfaces reflecting good system design choices, and extensibility through a well defined kernel module interface, allows Linux to migrate to new hardware designs and leverage new components, while continuing to leverage all of the Linux compatible code written over the years. That is a very difficult combination of advantages for a new system to overcome.
Google Fuschia (BSD) is planned to succeed billions of Linux-Android installations.
Linux Foundation now favors BSD over GPL.
IMO, if it weren't for the GPL we would see very few of the contributions made to Linux get handed back to the community. That it more or less runs everywhere is part of what makes it interesting (and was a major point of TFA.)
The Innovator's Dilemma model of technology disruption suggests that the "next Linux" will be worse in most ways but better for some narrow use case. Perhaps bare-metal containers or unikernels on servers and something like Google's Fuchsia or some RTOS for mobile phones and IoT devices?
The examples you gave boil down to 3 narrow use cases:
- The retention project / intellectually stimulating activity of writing your own operating system.
- Licensing.
- Some really specific hardware, where in some sense you're building an operating system in name only. Might as well just call it an application.
I think what OP means by "interesting socially" is that the new Linux isn't going to succeed on any technical or economic merits.
My guess would be the next Linux innovates in some way concerning national or ethnic identity, environmental conscientiousness, or radical politics.
For example, an operating system written in a non-Latin alphabet programming language. Or an operating system that is only delivered for solar-powered hardware. Or whatever is going to be the radical anarchism or communism of the software world (if you think GPL / free software is that, it ain't).
The market has clearly demonstrated that it doesn't care about phones being real time. They used to be considered critical systems from what I understand and many did actually run realtime OSes. Now we've got android and iOS (android is about as far from an RTOS as you can get, it's almost impossible to write an app that's not guaranteed to just killed by the OS at some point.)
The whole mess of VM hosts, hypervisors, containers, and container images is basically a messy half-baked microkernel architecture. A kernel running under another kernel with thin I/O abstractions (virtio, etc.) is sort of like a partition within a microkernel. VM hypervisor hardware pass-through is like allowing a microkernel service to drive one system component.
The fact that the market created all this shows that one monolithic kernel is insufficient from a security, permission management, and configuration management perspective at least if one assumes the limitations of Unix-like permissions and isolation.
I'm not necessarily saying Linus was wrong. Linus was right in the 1990s and from a "get it working and ship it" point of view.
If you value speed above all else, modularity is detrimental. If you value security or robustness, modularity helps you design components in such a way that one component's failure doesn't bring down the whole system, or compromise data being worked on by other components.
You mean, like a unikernel? I don't think anyone has tried to write a modern desktop stack that runs within a unikernel, as the Amiga OS did (parts of the desktop widget interface were even hardwired in ROM) but it can't be that hard if you can get useful language-based guarantees.
That's not the way amiga software was though heh.
I've also seen proof-carrying code proposed as an alternative; binaries must carry proof that they do not exceed certain capabilities and the proof is verified before they are run.
Then Liedtke's L4 happened, spawning the 2nd generation based on the principle of minimality. This changed the situation.
We're currently in the 3rd generation (with capabilities), its main representative being seL4, and the current landscape bears no resemblance to that of 1991.
With google's financial muscle behind fuchsia, operating systems will only get more interesting thereon.
A pretty accurate description of fads and fashions in academia.
"I don’t necessarily think these researchers were knowingly dishonest. Perhaps they were simply stupid. Or deluded."
By the way, I read this quote as a sincere attempt to understand what was going on in the mind of some people. I am afraid the actual explanation may be a bit more prosaic. A monolithic kernel might -o horror of horrors- be quite mundane. And where is the tenure in that?
I'm a confirmed Linux user [switched from macOS], but to me it's clear that git dwarfs Linux in terms of sheer _significance_.
Sure, Linux is what runs most big systems and that is really cool, but if Linux hadn't come around, there was already BSD [which is also good and a lotta my buddies were advocating in the mid-late 90s]. But git is quite unique and has / had no easy substitute. I don't [personally] know a single technology person who doesn't use or interact with git daily. And the benefits of reliable, free/open, and distributed version control are just monumental for the average working code stiff.
There was Monotone, which was git's main inspiration. If it weren't slow as molasses, we might be using it today instead of git.
While I like Linux, that may be overstating the case
At the same time, the OS research field really was like this at that time. At MIT, for example, it felt a bit like “which flavor of exokernel would you like to study?”
...
"But from a design point of view this is also the right thing to do: keep the kernel relatively small, and keep the number of interfaces and other constraints on future development to a minimum."
This is exceptionally poor writing. The second sentence is what he meant to say, which is completely different from the first sentence. An operating system is mostly just a bunch of interfaces for user space programs to use, so they don't have to talk to hardware directly. An OS without interfaces is pretty much an oxymoron.
Limiting the number and types of interfaces, of course, is a very sensible idea. But I was very confused for the several paragraphs between those two sentences about what Linus meant.
The first very basic rule is to avoid interfaces. If someone wants to add something that involves a new system interface you need to be exceptionally careful. Once you give an interface to users they will start coding to it and once somebody starts coding to it you are stuck with it. Do you want to support the exact same interface for the rest of your system’s life?
Sure, I figured out what he meant a few paragraphs later, but his writing made it much more difficult than it needed to be.