First, microkernels being the future: This is a sentence that was said time and time again, but while microkernels definitely have some advantages in separating components which could yield better security, in practice it also introduces other security concerns, not present with monolithic kernels, mostly with the communication between the kernel services.
Second, about the no secure Linux distros thing: As many others have mentioned, there are security-conscious Linux distros, mostly the “immutable” distros. You can use Fedore Silverblue (or even better, SecureBlue) as a daily driver, with Flatpak for your apps. That way, your main OS is read-only, thus harder to infect and all system updates are signed and verified. Using Flatpak helps enforce permissions on apps in a manner similar to Android permission (you can deny an app the right to see your files, for example).
Third, I don’t really understand what you mean by “Linux’s security holes”. Of course it’s not bug free, but no kernel of this magnitude is. Also, GrapheneOS uses Linux as well, albeit with a hardening patchset, but you can also get that with desktop Linux distros. If you think Linux (being a monolithic kernel) is automatically less secure than microkernel and hybrid kernel based systems, take a look at Windows and macOS, which both use non-monolithic kernels, but most security experts will tell you that you’re better off using Linux.
Fourth, about all the niche, mostly hobby OSes you listed: A big part of security is about having more eyes on the source code. Even if you write a kernel in a “safe” programming language, there will be bugs. Something as advanced as a kernel that’s ready for daily desktop use and provides advanced isolation between processes is going to be so complex that you won’t be able to see what bugs arised from the different parts interacting with each other. Safe programming languages make it easier to write safe code, but don’t stop you from messing up the logic that defines what apps have which permissions. Your best bet is to stick to software that has had time to mature and had more people and companies look through it. Linux is regularly audited by all tech giants, because all clouds use Linux to some extent. If it’s secure enough to isolate the workloads in Google Cloud, and Amazon’s AWS, it’s going to be secure enough for your desktop, provided you use it well (make use of it’s security features and don’t shoot yourself in the foot by disabling mitigations and the like). This is partly why I think the idea that OpenBSD is more secure than Linux is somewhat outdated. Yes, they advertise it as such, but it has seen much-much less auditing than Linux did in the cloud era.
Of course, there’s nothing wrong with playing around with alternatives operating systems, just don’t think you’ll be more secure just because something is written in Rust, or is a microkernel. Those can help, but there’s much more to security than the guardrails a programming language or software architecture can provide, especially with something as complex as a modern kernel.
Whew, there’s a lot to unpack here.
First, microkernels being the future: This is a sentence that was said time and time again, but while microkernels definitely have some advantages in separating components which could yield better security, in practice it also introduces other security concerns, not present with monolithic kernels, mostly with the communication between the kernel services.
Second, about the no secure Linux distros thing: As many others have mentioned, there are security-conscious Linux distros, mostly the “immutable” distros. You can use Fedore Silverblue (or even better, SecureBlue) as a daily driver, with Flatpak for your apps. That way, your main OS is read-only, thus harder to infect and all system updates are signed and verified. Using Flatpak helps enforce permissions on apps in a manner similar to Android permission (you can deny an app the right to see your files, for example).
Third, I don’t really understand what you mean by “Linux’s security holes”. Of course it’s not bug free, but no kernel of this magnitude is. Also, GrapheneOS uses Linux as well, albeit with a hardening patchset, but you can also get that with desktop Linux distros. If you think Linux (being a monolithic kernel) is automatically less secure than microkernel and hybrid kernel based systems, take a look at Windows and macOS, which both use non-monolithic kernels, but most security experts will tell you that you’re better off using Linux.
Fourth, about all the niche, mostly hobby OSes you listed: A big part of security is about having more eyes on the source code. Even if you write a kernel in a “safe” programming language, there will be bugs. Something as advanced as a kernel that’s ready for daily desktop use and provides advanced isolation between processes is going to be so complex that you won’t be able to see what bugs arised from the different parts interacting with each other. Safe programming languages make it easier to write safe code, but don’t stop you from messing up the logic that defines what apps have which permissions. Your best bet is to stick to software that has had time to mature and had more people and companies look through it. Linux is regularly audited by all tech giants, because all clouds use Linux to some extent. If it’s secure enough to isolate the workloads in Google Cloud, and Amazon’s AWS, it’s going to be secure enough for your desktop, provided you use it well (make use of it’s security features and don’t shoot yourself in the foot by disabling mitigations and the like). This is partly why I think the idea that OpenBSD is more secure than Linux is somewhat outdated. Yes, they advertise it as such, but it has seen much-much less auditing than Linux did in the cloud era.
Of course, there’s nothing wrong with playing around with alternatives operating systems, just don’t think you’ll be more secure just because something is written in Rust, or is a microkernel. Those can help, but there’s much more to security than the guardrails a programming language or software architecture can provide, especially with something as complex as a modern kernel.