I am not native English speaker so sorry for misunderstandment

I didn’t say it’s overall better

I said even though on base level OpenBSD is much more clean and secure than Linux it lacks or lags behind Linux in adding mitigations for security vulnerabilities

And there are far less eyes on OpenBSD so many vulnerabilities don’t get discovered in first place

Any software can be malicious even essential ones just look at recent Xz vulnerability (And it was discovered by sheer chance), OS should have systems in place like proper sandboxing, permissions (Not half baked one like flatpak) …

Linux servers exploit is different than Linux desktop exploit and 1000% different than exploiting Android

It’s general misconception that Android is just Linux but it’s not, it’s like saying Linux is just GCC compiler

It’s not, GrapheneOS is hardened Android check their site for more information

And android is not just linux + SELinux there is much more to it

Server security is not completely same as desktop one, Linux kernel is spaghetti code with very large attack surface, only reason it’s not exploited more is Linux Desktop is not as lucrative target as Windows, Proper sandboxing doesn’t exist and is half assed, Qubes is the only one properly doing sandboxing on Linux

OpenBSD and Qubes seems best solution so far but neither are ideal

Qubes doesn’t address Linux’s security problems it just sandbox/virtualize them and it requires beefy hardware

Fedora Silver Blue doesn’t do anything special really it’s your normal linux distro just immutable and relies on flatpaks (On another note Flatpaks sandbox are easy to break and most programs don’t use it properly)

Their basic premise seems solid, but is it actively developed? it seems to go through long periods of inactivity

Some vulnerabilities are not specific to linux like Heartbleed, Spectre, Meltdown

And even though OpenBSD fix most famous/severe ones, others are not tested or their fix may lag behind

Qubes OS is wrapper around underlying operating systems, so it doesn’t really fix for example Linux’s security holes it just kinda sandbox/virtualize them

Fedora Silverblue seems to be Fedora but immutable so many of linux’s problems still apply

More info on Atmosphere (Open Source Horizon AKA SwitchOS) as I find it fascinating that an OS created for a gaming device got such tight security:

https://www.reddit.com/r/emulation/comments/hygtnx/mesosphere_opensource_nintendo_switch_kernel_now/

Quotes from Creator of Atmosphere:

It is a completely unique microkernel with a cooperative (non-preemptive) scheduler. The kernel is secure – so far as I can tell (as a reverse engineer and hacker), it has zero security bugs. They throw out years of backwards compatibility (they’re not POSIX/UNIX), and they really, really benefit from it from a security and modularity PoV. Horizon’s the only meaningful RTOS with a microkernel that I’m aware of (other than Fuschia). Everything’s in userland – filesystems, gpu (and other device drivers). The OS is capability-based and conceptually all about lots of different processes/drivers (“system modules”) that host microservices. The fact that Nintendo designed such a rock-solid, modular, custom operating system for their consoles fascinates me.

IPC is the hottest hot-path in a microkernel, correspondingly Nintendo marked every function involved in IPC as attribute((always_inline)), this was kind of a huge pain to reverse engineer as a result. In addition, Nintendo implemented “SvcReplyAndReceive” as a single system call that allows a microservice server process to reply to and receive a new message in one invocation. That said, there’s actually less overhead than you think. Past of why FUSE is slower than a kernel driver for FS is because FUSE has to talk to the kernel to do filesystem stuff, so when you read a file you have your process -> FUSE -> kernel -> hardware. In comparison, on Horizon the kernel is completely uninvolved in filesystem management (it doesn’t even have the sdmmc hardware mapped). Thus processes will do process -> FS system module process -> hardware.

In Horizon, everything is very distinctly not a file. There’s no global filesystem paths the way that unix/linux have special /dev/whatever. Pipes don’t exist in Horizon – all IPC is done via the horizon ipc (“HIPC”) protocol. UNIX/POSIX have stuff like fork() and child processes…but creating a process is an incredibly privileged operation in a capability-based operating system. Fork() is impossible to implement in Horizon, all threads are created via SvcCreateThread() instead. Child processes aren’t a thing that exist.