Ask HN: What's a reasonable microkernel-based OS for desktop usage?
Title question.
When I say desktop usage, I mainly mean a full fledged browser. For everything else I mostly have a fully cli workflow.
This comes out of me tinkering with more "exotic" OSes like GNU/Hurd and Plan 9. I've had fun with the Hurd and would like to learn more by running my day to day on it; however, the hardware support and tooling is unfortunately just too anemic to reasonable do this.
Is this kind of thing even possible at the moment? Are there reasons to not want a desktop running some microkernel OS? Am I being unknowingly unreasonable in wanting this?
Thanks!
55 comments
[ 585 ms ] story [ 873 ms ] thread(Usually it's used in embedded systems)
For what it's worth, QNX <7 is similar to Windows XP - not the latest version, but very much in active use, and definitely not abandonware.
My interest in QNX is solely academic/hobbyist; I actually keep QNX 4.25 and 6.5.0 open in QEMU in the background and VNC to them occasionally for fun. (4.25 uses 1.3% and 6.5.0 uses ~5% CPU if I don't pause qemu.)
Finding older versions of QNX is a small challenge; getting them working is also Fun™. For reference, my email is in my profile.
For reference, older versions of QNX may not work well on newer hardware, unfortunately.
EDIT: It's not witchhunting if a factually incorrect answer is downvoted. (I'm a Linux user myself.)
For example, a comment that merely says "MINIX 3", should not necessarily be upvoted, due to its lack of evidence or explanation.
True, that.
> an answer should be judged based on the quality of it's evidence, not necessarily if it's right or wrong
I fail to see the difference between these two.
> a comment that merely says "MINIX 3"
...is answering the question. It doesn't do so eloquently, so it usually doesn't deserve an upvote, but neither a downvote.
[1]: https://en.wikipedia.org/wiki/Microkernel
Good luck everyone!
While it is technically not an "OS", I find that it offers some of the same security advantages a server-based microkernel OSes do. Although DomUs aren't technically privileged userspace processes, it does mitigate the risk of something like a faulty, kludgy mess of a driver taking down an entire system, and while I admit it's not as fancy as something like Mach IPC, it does allow for secure communication between different domains.
And on a personal note, as a former GNU/Hurd dev it does make me happy when I find people in the wild with interest in its design :)
Is it possible to use Xen as traditional desktop OS with Keyboard/Mouse/Monitor running X and a Window Manager? Would you run it in a Dom0 or DomU? How would you switch between them, etc.
[1]: https://en.wikipedia.org/wiki/Qubes_OS
It was originally marketed as a mechanism for running a Corporate OS and a Personal OS simultaneously, with both of them running at within about 5% of native performance.
A better approach is to run the VMM (which handles VM exceptions) as a normal user process under a microkernel. seL4 implements such an approach, with the added benefits of capabilities; the VMM doesn't get any more privileges than it actually needs, thus a successful attack against the VMM from within the VM could not actually provide anything beyond what supervisor mode execution within the VM would.
A lot more on this to be found here: https://ts.data61.csiro.au/projects/TS/virtualisation/ More papers (not restricted to virtualization): https://ts.data61.csiro.au/projects/TS/publications.pml
And, while at it, I also recommend reading Gernot Heiser's blog, which has plenty on this. https://microkerneldude.wordpress.com/
The seL4 kernel has piqued my interest a lot. Though, shamefully, I have to admit the interest isn't backed by many technical reasons. I'm on a vague, pesonal quest to run as minimal a system (both hardware and software) as possible while also keeping things as secure as possible. seL4 hits both those buttons, philosophically.
Thanks for the links. This gives some good places to turn my interest into actual knowledge.
Size, in kLOC, of the hypervisor itself, which runs entirely in supervisor mode and, as such, is part of the TCB.
I'm kind of sad the L4 port didn't take. The desire to hack on something like that definitely mulls around in the back of my mind.
As for the hypervisor idea, another comment mentions QubesOS which I've looked at in the past. This kind of thing does appeal to my "Make Everything Minimal" desire as well as (admittedly vague) concerns about security and isolation.
The newest Windows version the article mentions is Vista. I am not aware though of such fundamental changes to the Windows kernel as would be needed to make it a true micro kernel.
This means that instead of incurring a full context/privilege switch just to pass messages between components, the messages go through (say the IO manager with an IRP) the subsystem controllers with simple function calls and effectively shared data structures (although its designed not to look that way).
Because its compartmentalized like this, it would actually surprise me if somewhere in MS research/etc they don't have a full context switching version of the kernel running. Such a project would if nothing else help to catch "bugs" and validate the subsystem and drivers aren't misbehaving. Of course driver verifier achieves most of this goal by itself with simpler checks.
OTOH, while the idea of a micro-kernel helps to solve a lot of development/design issues I'm not sure an actual implementation buys you much over the NT approach. That is, while its easy to say "just restart the storage subsystem" implementing something that is capable of getting the state right in a microkernel environment sufficiently that a bug which takes down a critical subsystem isn't repeatably fatal (or just drops important filesystem updates/whatever) likely creates even more complexity in which latent bugs can hide. Particularly in the face of buggy hardware where the driver is trying to avoid/work around a hardware misbehavior, doing something like restarting a disk controller won't necessarily unwedge a stuck command queue in the hardware.
So, that said, I think if you keep the crappware (most "security" software for starters, maybe certain GPU drivers too) off a windows system its really rare to have windows crash. In the past 15 years I can't actually remember the last crash I saw on a machine running only WHKL qualified drivers, and i've never seen a crash on a server core machine.. etc...
As an introduction to that, I'd suggest reading https://en.wikipedia.org/wiki/MINIX_3#Reliability_policies
as most of that is tied to the pure microkernel multiserver approach, with strictly only the microkernel running in supervisor mode.
If you want to go into more depth, then I'm going to suggest
https://ts.data61.csiro.au/projects/TS/publications.pml
https://microkerneldude.wordpress.com/
And, of course, if what worries you is performance, then look into: http://blog.darknedgy.net/technology/2016/01/01/0/
Lets just say, that in two decades of writing drivers and OS internals, i've shifted my opinions away from being a strong micro-kernel advocate toward a hybrid approach similar to what NT does.
Also, per you last link, i'm still one of the people who think virtualization and non zero copy syscalls adds too much overhead. Burning up 100% of a core to copy packets between userspace, the kernel, and then DMA'ing them to the device is pointlessly slow. Adding in a copies between kernel subsystems is worse and can't be avoided as easily as something like the NT registered I/O model. There are whole projects (dpdk for example) for which that single context switch/copy is to much too.
By all means, do. As far as I can see, these do not work without the enforced isolation of running as userspace processes.
>Burning up 100% of a core to copy packets between userspace, the kernel, and then DMA'ing them to the device is pointlessly slow.
That's not how it usually works.
Not sure about tooling, but I think hardware, one of the two problems you mentioned can be solved by virtualizing. You can run the micro kernel-based OS in a VM and hardware support usually will get better because it is standard. If you don't like the feeling of running the OS inside a window in the host OS, you can assign the whole machine to a graphics card and a set of keyboard and mouse with pass through (io-mmu/VT-d) on Linux KVM. That way, you only have to worry about a compatible graphics card, and everything else is emulated and standard.
I haven't tried any micro kernel-based OS myself but I had a very good luck running both Windows and macOS virtualized on my Ivy Bridge desktop system I built 7 years ago running Fedora as the host OS. It's freaking amazing and I suffer almost no performance degradation.
It took a while, but worth the troubles.
At this point the Hurd doesn't even have USB or sound, IIRC, so even with virtualization we're a bit upstream without a paddle.
Random question. My experience with virtualization is quite limited. How streamlined is the data sharing stuff between instances (files, clipboard, etc)?
Using a microkernel as a desktop leaves you in a generally no worse off position than using something like Linux or Windows. Unless you are intending to do specific high performance work, then you probably won't see much or any difference.
I am currently using a Toshiba NB500 netbook running Centos 6.9 as my machine due to having to support a number of other Centos 6.9 systems. But I am intending to shift to Minix 3.4 in the latter part of 2017 or early 2018 for doing certain kinds of development work that I am interested in.
If you have the resources and time, give a variety of systems a go and see what gives you a better bang for your buck for your circumstances.
Thanks!
i don't think so. or if you are, then i am too. or it depends on how much you want this and why.
i lurked on the Hurd IRC about 5 or 6 years ago, and i get the sense that developing these systems is a lot about the journey of development. it seemed as though most people who were running the Hurd used hardware virtualization.
the browser can certainly be viewed as block to minimality. have you tried elinks? could a V7-like JS runtime replace JITing it?
i don't have answers to these questions. i do think framing the original question around minimal webbrowsers (where "minimal" means it can be run on Minix or similar) is insightful and appropriate to the forum. thanks for posting this question!
I've opened elinks here and there in the past, but have never really given it a fair chance. You've motivated me. At the moment I run almost completely in a browser called UZBL and have javascript and cookies disable. The web, or at least the part I intersect with, is surprisingly useful like this.
Assuming we could move to elinks, then the question becomes one of supporting minimal tooling for the various mimetypes, like video. The main annoyance I would expect is from bank websites, which tend to have really narrow browser requirements.
Take your pick from microkernel.info.
If you want it to be open source and you want to be able to work with it to some extent, however, there's compromises involved (the main one being that hardware support is terrible), but the latest Minix 3.4 release candidate is about the only such system that will do that for you, and the closest there is to replacing monolithic unix as a general purpose OS. It specifically tries to be a replacement for netbsd, sharing most of its userspace.
Early stages, but you could take a look at this OS written from scratch by someone with an amazing track record in OS development:
https://github.com/vygr/ChrysaLisp
Some pretty cool stuff there to get your teeth into...
Over the course of the years of me tinkering, I seem to keep trimming my tools to slimmer and slimmer things that I feel I can grok fully. This has me at the point where I think of an OS as "just" a thin layer on top of the kernel syscall API.
So curiosity now has me asking about implementation details of the syscalls and all that jazz. I have the linux source tree on my machine and do poke around, but the sheer size is somewhat daunting.
So my reason for asking about a micro-kernel in particular comes from a combination of liking "minimality", wanting to see different approaches to kernel design, and wanting to grok the "full stack".
Anyway. Thanks for the pointer to ChrysaLisp. Looks interesting!
Others worth mentioning are SkyOS. I don't think Robert has worked on it for years, but I believe the source code is still available and there used to be quite a lot of very readable documentation outlining the architecture.
ChrysaLisp is certainly one to watch. He's the guy behind the now defunct Tao OS. The Tao tech was way too far ahead of its time. Maybe now is the time...
https://www.redox-os.org/