Every Operating System You Use Is a Compromise

A technical audit of Linux, Windows, macOS, QNX, and Qubes — and why none of them can be the platform for the next decade

A technical audit of Linux, Windows, macOS, QNX, and Qubes — and why none of them can be the platform for the next decade

I've spent 22 years writing systems software. The longer I work with operating systems, the more convinced I become that we are building the future on foundations designed for the past.

This is not a rant. It's an audit. I'll go through the major operating systems — Linux, Windows, macOS, QNX, and Qubes — and examine what each one cannot do. Not "does poorly." Cannot do. Architecturally.

The conclusion is uncomfortable.

Linux: 30 million lines at full privilege

Linux is a monolithic kernel. Every driver, every filesystem, every networking stack runs in Ring 0 — the highest privilege level the CPU offers. A bug in a WiFi driver can crash the entire system. A vulnerability in a USB driver gives the attacker full kernel access.

This is not a theoretical concern. CVE statistics show that kernel driver vulnerabilities are the single largest category of Linux security issues, year after year.

Real-time? Linux cannot guarantee response times. The PREEMPT_RT patch set has been in development for over 20 years. It was finally merged into mainline Linux 6.12, but PREEMPT_RT is not enabled by default — distributions ship PREEMPT_DYNAMIC, which has significantly worse latency. Ubuntu tried to make real-time a first-class feature and abandoned it because every third-party driver, every kernel module, every patch can break the RT guarantee. They moved it behind a paywall (Ubuntu Pro). The community rejected it.

The fundamental problem: Linux has approximately 40,000 spin lock sites in the kernel. Every one of them is a potential latency spike. You can audit 39,999 of them and the one you missed ruins your 10-microsecond deadline. QNX solves this with zero spin locks. Linux cannot — the architecture forbids it.

Storage? ext4 is a filesystem. PostgreSQL is a database. They are separate worlds. Moving data between them requires serialization, copying, format conversion. The filesystem knows nothing about your data model. The database knows nothing about your file layout. You maintain two storage systems, two backup strategies, two failure modes.

Want to encrypt your data? That's a third layer: dm-crypt or LUKS, sitting below ext4, with its own configuration, its own failure modes, and no per-file granularity — it's all-or-nothing at the volume level.

Want integrity checking? That's a fourth layer: dm-verity or IMA.

Four separate subsystems for what should be one: "store this data safely."

The process model? /proc is a pseudo-filesystem from 1992. Any process can read it. It exposes memory layouts, kernel symbols, command-line arguments, and environment variables. It requires hundreds of system calls to query — listing 200 processes means 800+ syscalls and parsing text output. Container escapes and privilege escalation attacks exploit /proc information routinely.

Linux is the best general-purpose kernel we have. It is also a 30-million-line monolith where security, real-time, and storage are afterthoughts bolted on top.

Windows: backward compatibility as a prison

Windows carries 40 years of backward compatibility. The NT kernel is competent engineering — but it serves a master that prevents it from evolving.

The driver model is a security disaster. Any signed driver runs in Ring 0 with full kernel access. The signing requirement was supposed to prevent malicious drivers — but stolen certificates are routinely used by ransomware groups to load kernel-mode rootkits. Once a signed malicious driver is loaded, it has the same privileges as the kernel itself.

NTFS was designed in 1993. It has no built-in encryption (BitLocker is a volume-level layer, not a filesystem feature). No integrity verification per file. No transactional guarantees for application data — only for metadata. The Master File Table (MFT) is a single point of failure that can corrupt the entire volume.

The registry is a hierarchical database from 1992 that stores system configuration, application settings, and security policies in a format that is simultaneously too structured for plain config files and too unstructured for a real database. It has no schema, no transactions, no encryption per key. It grows monotonically. Every Windows performance degradation over time traces back, at least partially, to registry bloat.

Real-time? Windows has no real-time guarantees whatsoever. The scheduler is optimized for interactive desktop use. Deferred Procedure Calls (DPCs) can delay any thread by milliseconds. There is no mechanism to guarantee a response time for any operation.

The WSL paradox tells the whole story. Microsoft's best answer to developer needs was to run an entire Linux kernel inside Windows. Not to fix Windows — to embed a different OS inside it. That's not integration. That's capitulation.

macOS: a walled garden with a Unix foundation

macOS is a Mach microkernel (XNU) with a BSD personality layer. It's technically more secure than Linux by default — System Integrity Protection (SIP), signed system volume, hardware-enforced memory protections on Apple Silicon.

But it has its own problems.

APFS is better than ext4 and NTFS — it has native encryption, snapshots, and copy-on-write. But it is still a filesystem, separate from any database. If your application needs structured data, you run SQLite or Core Data on top of APFS. Two storage systems. Two failure modes. The filesystem cannot query your data model.

No real-time. macOS is not and has never been an RTOS. Audio professionals know this intimately — Core Audio works well because Apple engineers spent enormous effort on buffer management, not because the OS guarantees timing. Run a heavy Spotlight indexing job during an audio session and watch your buffer underruns spike.

The platform is closed. You cannot run macOS on non-Apple hardware (legally). You cannot modify the kernel. You cannot replace the compositor. Apple decides what macOS is, and you live with that decision. This is fine for consumers. It is unacceptable for robotics, industrial control, automotive, medical devices, or any domain where you need to control the entire stack.

Driver ecosystem? Apple controls it completely. If Apple doesn't ship a driver for your hardware, you write a kernel extension — but Apple has been deprecating kernel extensions (kexts) in favor of DriverKit, which runs in userspace with limited capabilities. This is actually good for security but means third-party hardware support is increasingly restricted.

macOS is the most polished desktop OS. It is also a locked box optimized for exactly one use case: Apple devices running Apple-approved software.

QNX: the RTOS that can't run your software

QNX is a true microkernel RTOS. It provides hard real-time guarantees — sub-10-microsecond response times. It's used in nuclear power plants, medical devices, and car infotainment systems (BlackBerry QNX is in 235+ million vehicles).

It also demonstrates exactly why being a good RTOS is not enough.

The driver problem. QNX has a tiny driver ecosystem. No WiFi drivers for most consumer hardware. No Bluetooth stack for most devices. No GPU acceleration for modern graphics cards. If you need to connect your QNX system to a network, you need specific supported hardware. If you need a display, you need specific supported hardware.

No AI, no modern development. QNX's development toolchain is decades behind. No PyTorch. No TensorFlow. No modern package manager. No container runtime. Building a machine learning pipeline on QNX requires cross-compiling everything from a Linux host — and many libraries simply don't compile.

Cost. QNX licensing starts at tens of thousands of dollars for commercial use. For safety-critical certification (IEC 62443, ISO 26262), costs run into the hundreds of thousands. This is reasonable for a car manufacturer but prohibitive for startups, small device makers, or the broader developer community.

The fundamental trade-off: QNX proves that a microkernel RTOS works. It also proves that a great kernel without a software ecosystem is a niche product. QNX has been around since 1980 and has never broken out of embedded systems — not because the kernel is bad, but because nobody can build a modern application on it.

Qubes OS: security through VMs, at a cost

Qubes takes a radical approach: every application runs in its own virtual machine. Your browser is in one VM. Your email client is in another. Your development environment is in a third. The hypervisor (Xen) isolates them.

It's the most secure desktop OS available. It's also nearly unusable.

Performance. Every VM has its own kernel, its own memory space, its own overhead. Running 10 qubes (domains) means 10 copies of a Linux kernel in memory. Context switches between qubes go through the hypervisor. Copy-paste between qubes requires explicit, manual permission grants.

No shared state. This is the core problem. Applications that need to share data — a mail client that opens attachments in a document editor, a browser that saves to a file manager — must do so through the hypervisor's restricted IPC. In practice, users copy files between qubes manually. There is no shared filesystem, no shared clipboard (by design), no shared memory.

The UX tax. Every security boundary is a friction point. "Which qube should this link open in?" "Which qube has the file I need?" "I need to copy this text from the work qube to the personal qube — right-click, Copy to Qube, select target, confirm." Qubes makes every operation a security decision. Most users can't sustain this.

No real-time. Xen is not an RTOS. The hypervisor itself has no latency guarantees. You cannot use Qubes for anything that requires deterministic timing.

Qubes proves that VM-based isolation works for security. It also proves that security at the VM boundary destroys usability and performance. The question is whether there's an isolation mechanism that provides the security of VMs without the overhead — something at the hardware memory management level, not the VM level.

The gaps nobody fills

Here's the matrix. I've looked at this from every angle, and no combination of existing systems covers it:

Nobody has all of them. Not even close. The closest combination would be "QNX for real-time + Linux for drivers + Qubes for isolation + a custom database for storage" — which is four separate systems duct-taped together.

And that's before you add AI. None of these operating systems were designed with the assumption that an AI would be administering the system, auditing security, building software on it, or analyzing every file operation in real time.

Why this hasn't been solved

Three reasons.

1. The driver problem is a moat. Linux has millions of drivers written over 30 years. Any new OS that wants mainstream adoption needs those drivers. Writing them from scratch is a multi-billion-dollar effort. This is why every alternative OS either dies at the driver problem or gives up and runs Linux inside itself (WSL, Qubes, Chrome OS).

The only viable path is to run Linux drivers unmodified — in a VM — while running native applications outside the VM with full performance and security guarantees. This requires hardware virtualization (VT-x / AMD-V), which every modern CPU supports but no mainstream OS exploits at the kernel architecture level.

2. The filesystem/database split is sacred. Every OS assumes that files and structured data are different things stored in different systems. This assumption is embedded in POSIX, in Win32, in every API, in every application. Unifying them means breaking the API boundary — which means a new programming model, which means no existing software works unmodified.

Unless your programming language knows about the unified storage. Then the language handles the abstraction, and the developer never sees the boundary. But that means building a language specifically for the OS — which nobody does because it's "too much work."

3. Real-time and general-purpose are seen as mutually exclusive. QNX is real-time but has no software. Linux has all the software but no real-time. The industry treats this as an either/or choice. You pick one and accept the consequences.

But hardware virtualization changes this equation. If the real-time kernel runs in VMX Root and Linux runs in a VM, you get both — hard real-time for native applications and full driver/software compatibility via the Linux VM. The cost is one additional context switch (~1 μs) for operations that touch Linux drivers. For everything else — pure native performance with real-time guarantees.

What would it take?

A hypothetical OS that fills all the gaps would need:

• A microkernel small enough to audit (thousands of lines, not millions), running in VMX Root mode
• Zero spin locks — the only way to guarantee sub-10μs response
• Linux in a VM for driver compatibility — unmodified, fully functional, but contained
• A unified storage engine that is simultaneously a filesystem, a transactional database, an encrypted store, and an integrity-verified archive — per page, not per volume
• Hardware-enforced IPC — shared memory with MMU-enforced access control, giving the speed of shared memory with the security of VM isolation
• A language designed for the OS — one that compiles to native code, knows the storage schema at compile time, and handles the abstraction between filesystem and database operations
• AI at every layer — not as an afterthought, but as a first-class participant in security, administration, and development

The code for such a kernel would be surprisingly small. A microkernel scheduler with 256 priority levels and zero spin locks is roughly 500 lines. A memory manager with per-page permissions is another 400. The VM manager for hosting Linux is perhaps 800. The storage engine — if it already exists as a production-tested database — needs only a filesystem API layer on top.

The real cost is not the kernel. It's the language, the database, the protocol, the GUI framework, and the decade of production testing that makes the storage engine trustworthy. Those don't come from a "let's build an OS" project. They come from building something else first — and realizing that the OS is the missing bottom layer.

We keep patching 30-year-old operating systems because building a new one is considered impossible. It's not impossible. It's just that the prerequisites — the language, the database, the runtime — take so long to build that by the time they exist, nobody remembers why they started.

But the prerequisites are the real product. The OS is just the last layer.

Follow me for more on systems engineering, databases, and why AI needs better infrastructure than what we have today.