Complexity in Operating Systems
x86.lol
x86.lol
L4 is even smaller, but too small. You have to run another OS on top of L4 to get anything done. QNX can run ordinary application programs. At one point there was a version of Firefox for QNX, and all of the GNU command line tools worked.
Linux in embedded applications tends to come with a vast array of stuff you don't need, too much of which will respond to the network.
Question: Why did none of the operating systems written on L4 work on a practical level to get useful work done?
QNX is the one I have heard of most often when someone wants to tout a microkernel based OS success. In fact I've never heard another OS being suggested in that context.
Given the repeated claims about the benefits of microkernels, complexity management, better security, self-healing faults, lower bug density etc etc. Why isn't QNX the hottest OS that everyone wants to run for just about everything? Certainly everything that needs to be secure on a hostile network. Some might not want the performance trade off of essentially making your cache smaller so things run slower but plenty wouldn't mind that trade off at all. Yet it hasn't taken off or even gotten a toehold that I can see. Nobody has ever tried to sell me QNX for anything. Remember pwn2own and the various variants - never saw QNX even entered there...
Why is that? I feel like there is something being left out of the standard discussion of these things that is crucial. RMS said Hurd didn't work out because it was really hard to debug. Is that it? Is there some other reason why microkernels are just too hard to deal with? Are the benefits a bit illusory? Is it something else?
These are genunine questions. Usually when I ask them I'm met with a wall of unsubstantiated claims and anger bordering on abuse. But still no microkernel based OS I can run to do useful work. I wish I understood why I don't have a microkernel based OS to even play with better.
1. Microsoft had the OS business locked up.
2. QNX cost more than Windows.
3. Their marketing was not very good.
Then QNX, the company, was sold off to an audio company. That was a disaster. Then it was sold again to Blackberry. Along the way, they went from closed source to open source to closed source to open source to closed source. This antagonized the QNX user community. QNX relied on ports of GCC, Eclipse, etc. for development, and all those communities stopped supporting QNX.
Right now, you can still buy QNX. But not on line. You have to talk to a sales rep. If you have to ask how much it costs, you can't afford it. It's widely used inside things like car dashboards. The classic line is "you use Linux to run your web server, and QNX to run your nuclear power plant."
They've been terrified of people pirating it. I used to tell their people that their problem was not piracy, it was being ignored.
They should have a business model like Epic has for Unreal Engine - anyone can download and use it for free, and when you get over $100K in revenue, they get 5%. Although that's easier to enforce in gaming, because few titles hit $100K in revenue and those are easy to find.
(Some years ago QNX had a sales win with a major auto manufacturer. They'd been considering an embedded version of Windows. Microsoft insisted that the Windows splash screen appear when the dashboard powered up. This was not well received by the auto company, and they went with QNX.)
As far a cache, depending on what's going on, you may find lower cache usage. In school, I had an assignment to run a simulated filesystem benchmark and identify the sizes of various caches on my system from the benchmark results. I was quad-booting Linux, L4Linux, QNX, and Win2k on my desktop at the time, so I ran the benchmark on Linux, L4Linux, and QNX. QNX actually showed better cache utilization than Linux (bigger filesystem working sets before noticeable percentages of cache misses at the various levels). If your kernel is extremely small, it has good cache locality, likewise for a small fs driver. So, if you're really hammering just one application and one or two drivers, you might get better cache utilization from a microkernel.
Until you get pretty deep into the weeds, none of KVM's code can actually do anything architecturally specific, since all of the glue code is architecturally agnostic. KVM supports a ton of architectures, intel-x86/amd-x86/armv/s390/risc-v/...
On top of that, KVM tries to avoid having extra ioctls (essentially KVM syscalls). A lot of the ioctls are so flexible that they don't really tell you anything about what a CPU should* look like. The ioctls let you create a VM that is in essentially any valid state a CPU could reach (since VMs need to be migratable).
Take a look at the sample code in the rust kvm-ioctls crate [1] and you'll see what defines a VM.
1) Open the KVM fd for access to the ioctls.
2) Make the VM fd.
3) Make guest RAM, and shove the asm from up above into it.
4) Make a vCPU.
5) Initialize the registers for the vCPU.
6) Run the VM, and handle the exits (KVM sometimes can't handle what the VM is doing and returns to usermode to have them deal with it. Think device emulation).
This avoids initializing a lot of state for the VM, but it's enough to run it. Notable details are things like CPUID (supported cpu features for the VM), the Interrupt Descriptor Table, and the control registers. If this VM took an exception/interrupt right now, it would immediately triple fault. This sample VM is running in "real mode" (16-bit unpaged mode).
[1] https://github.com/rust-vmm/kvm-ioctls/blob/master/src/lib.r...
I hope we come to see even more purpose-focused operating systems in the (near) future.
What did you do to make Haiku OS boot?
It’s similar to the issues you have with non-x86 architectures. If I have an ARM laptop and I want to run a proprietary application on it that was compiled only for x86... well, I largely can’t. (Microsoft and Apple have both had to develop translation systems for this independently, and it slows things down and eats battery life. At least MS’s implementation, we don’t know much about Apple’s yet.) Contrast that to free software applications, where distros like Debian have thousands of them available in the repositories for all supported architectures, and you can build them yourself if they’re not in the repos.
If you want alternative OSes to be an option, buy hardware that runs with free software.