Ask HN: What's a reasonable microkernel-based OS for desktop usage?
55 comments
Minix 3.3 or 3.4 RC 6. It basically uses clang compiler and the NetBSD package base.
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.
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.
Oh wow. I didn't expect such positive responses. This gives me hope. I'll definitely look into Minix.
Thanks!
Thanks!
Can I recommend using a hypervisor like Xen?
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 :)
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 :)
Keep in mind Xen is bloated beyond belief, and all of this bloat is running in supervisor mode. It being an actual type 1 hypervisor makes it significantly better than approaches such as Linux KVM or freebsd bhyve, but the TCB is still too big.
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/
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/
Interesting. I my knowledge of hypervisors and virtualization is quite superficial. What makes Xen so bloated?
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.
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.
>What makes Xen so bloated?
Size, in kLOC, of the hypervisor itself, which runs entirely in supervisor mode and, as such, is part of the TCB.
Size, in kLOC, of the hypervisor itself, which runs entirely in supervisor mode and, as such, is part of the TCB.
Cool! You're a Hurder! Don't bump into Hurd devs all that often :P
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.
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.
I use QubesOS at home on a fairly powerful server box and I personally find it quite enjoyable for my usage. Most of the monitors here are hooked up to thin clients with GigE connections to the server. When the server powers on, it automatically starts up the DomUs and configures each one to receive USB events sent from the thin clients. For the display, the server pre-renders the graphics buffer on each domain OS and then sends the resulting frames back to the thin client to display on their respective monitors. After I did this, managing the computers around the house became a whole lot easier considering there was really only 1 major point of failure (the server).
Could you tell more about your setup? I'd like to do something like this for myself. Maybe some articles or search queries? Is this setup valid for multiple users simultaneously with separate desktops?
Interesting. I'd love to know more about workflows around a setup like this.
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.
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.
Might be worth looking into QubesOS[1]. It uses Xen to compartmentalize things. Never used it myself though.
[1]: https://en.wikipedia.org/wiki/Qubes_OS
[1]: https://en.wikipedia.org/wiki/Qubes_OS
I often go back and give Qubes_OS a try but then it lets me down with USB passthrough for a lot of devices I need - not least a USB tethered Internet connection (or USB Networking). It just is so complicated that I gave up and I'll look again when they get to version 4.
Not sure what the status is now, but many years ago I explored Xen CLient, which runs Xen as the base OS, but lets you run VMs with full hardware support (direct graphics card access etc) as your 'desktop' OS and switch between them.
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.
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.
Why micro-kernel in particular? Just curious.
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...
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...
I don't really have a good technical reason. Mainly just curiosity.
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!
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!
Ah OK I see. Yes as others have pointed out Minix. But for something you can really understand have a look at Xinu - small and very minimal, there's a great book on it too. You probably aren't going to run Xinu as your main desktop though! ;)
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...
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...
>the hardware support and tooling is unfortunately just too anemic to reasonable do this.
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.
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.
Running in a VM is a reasonable idea. Though part of my reason for wanting to run a microkernel is as a quest to run as minimal hardware + software as possibly without cramping usability (for appropriate meanings of "usability"). No good reason for this other than just to learn things along the way.
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)?
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)?
Which version of macOS and distro do you use? Are there good docs for setting it up?
I largely followed the guide on OSX-KVM repo on github. For the GPU to work, I used an AMD RX-560. After installing El Capitan with a virtual graphics card, I upgraded to High Sierra and passthrough the card.
It took a while, but worth the troubles.
It took a while, but worth the troubles.
> Am I being unknowingly unreasonable in wanting this?
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 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!
Thanks for the positive feedback! It's really encouraging.
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.
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.
Redox is looking pretty good now...
https://www.redox-os.org/
https://www.redox-os.org/
QNX springs to mind in that case, but I'm not sure if it's really viable as a day-to-day OS. There's a distro of it out there somewhere, I guess.
(Usually it's used in embedded systems)
(Usually it's used in embedded systems)
You are most likely thinking of QNX 6.5.0. That was the last version of QNX to include Photon, which was QNX's equivalent of X11. QNX no longer includes a desktop; its graphics stack is engineered solely for use by eg Qt apps (the equivalent of Qt using /dev/fb* on Linux).
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.
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.
This looks a little promising https://membarrier.wordpress.com/2017/04/12/qnx-7-desktop/
Discussion: https://news.ycombinator.com/item?id=14230112 (91 comments; April 2017)
FWIW, this is QNX's direction going forward. Photon is (sadly) old and unupgraded, and doesn't support the latest graphics architectures.
[deleted]
Isn't QNX the only actual microkernel that has any kind of significant active user base (though not for the desktop use case, of course)?
I've seen several deployments that used (and probably still use) QNX with Photon as more or less desktop system. Typically these are installations where software running on some backend servers running on QNX controls some kind of industrial process or otherwise weird hardware and the operations staff have QNX based workstations for UI to control that which they then at the same time use for some mundane desktop-ish tasks (email, unrelated web apps...).
[removed due to witch hunting]
While your enthusiasm makes me smile, Lubuntu is not a microkernel[1]
[1]: https://en.wikipedia.org/wiki/Microkernel
[1]: https://en.wikipedia.org/wiki/Microkernel
Wow, learned something new! I guess I never understood they existed :)
Good luck everyone!
Good luck everyone!
Linux is the antithesis to microkernels.
EDIT: It's not witchhunting if a factually incorrect answer is downvoted. (I'm a Linux user myself.)
EDIT: It's not witchhunting if a factually incorrect answer is downvoted. (I'm a Linux user myself.)
No no, in my opinion, an answer should be judged based on the quality of it's evidence, not necessarily if it's right or wrong, or if you agree with it.
For example, a comment that merely says "MINIX 3", should not necessarily be upvoted, due to its lack of evidence or explanation.
For example, a comment that merely says "MINIX 3", should not necessarily be upvoted, due to its lack of evidence or explanation.
> an answer should be judged [not] based on [...] if you agree with it
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.
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.
Redox OS is a interesting project although it's not ready for prime time usage since it lacks applications.
https://www.redox-os.org/
Windows ?
Well, according to Tanenbaum, Windows is a hybrid too: „Windows NT 3.1 was a half-hearted attempt at a microkernel system, but it wasn’t done right and the performance wasn't good enough on the hardware of the early 1990s, so it gave up on the idea for a while.“ http://www.cs.vu.nl/~ast/reliable-os/
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.
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.
Its a "hybrid" because its designed to behave and look like a micro-kernel, but instead of full subsystem/process isolation, all of the kernel subsystems exist in a single address space (although I guess this could be argued in the context of hyper-v not to be entirely true).
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...
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...
>I'm not sure an actual implementation buys you much over the NT approach.
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/
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/
I could point for each bullet point in your minux link how structuring your code like a microkernel (and a debug/instrumented build) solves the same problems, but I'm to tired to bother.
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.
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.
>but I'm to tired to bother.
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.
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.
Wait, so Windows is a microkernel OS? That's awesome.
And it is definitely a full desktop os.
L4 might be an option.
http://l4hq.org/projects/os/
Genode lets you choose from a range of microkernels on which you'd like the system to run.
The hurd unfortunately isn't pure microkernel multiserver architecture, but a mere hybrid, as they run a lot in supervisor mode for performance reasons, to do with limitations of the MACH microkernel they do use. It has about 0 developers on any given time, with the occasional work being done. There's been no real (fundamental) progress on it for over a decade. The issues in the hurd critique paper haven't been addressed, and the L4 port failed. Your time is best spent elsewhere.
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.
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.
I'd suggest HelenOS - see http://helenos.org they have hardware support for sound and USB filesystems etc that I think is lacking in Minix 3 but I don't think they have a web browser at this point. The main reason there isn't a microkernel OS is that nobody has invested the time into making one work, especially considering the popularity of Linux for free software advocates and Windows/MacOS for everyone else.
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!