the most secure OS in the world.....I hate it

Cubes OS aims for extreme security by treating compromise as inevitable and then hard-limiting what any hacked app can touch. Instead of running everything in one operating system space, it spins up isolated “cubes” (compartmentalized environments) for different tasks—work, browsing, anonymity-related browsing—so malware in one compartment can’t interfere with others. The system’s paranoia is explicit: it assumes software bugs will be exploited and that “nothing is secure unless you unplug the internet,” then counters that risk with confinement and control.

At the center of the approach is virtualization. Cubes OS is built around a type-1 hypervisor model using Zen-based virtualization derived from the Zen Project Hypervisor, and it runs each application inside its own isolated compartment. When a user launches an app cube (for example, a work Firefox or a separate “weird” Firefox), Cubes OS creates a new isolated environment for that app. Color-coded cube labels make it clear which compartment is active, while separate cubes prevent cross-contamination—dark-web browsing doesn’t mess with the “weird” environment, and neither can reach work-related apps.

Security also depends on how Cubes OS structures system components. App cubes are based on template cubes: a shared base OS plus a set of common apps. That template system lets users update core components in one place so every cube that relies on the template automatically benefits. If a cube gets infected, the response is simple: shut it down. The design prevents app cubes from modifying the underlying template, so the blast radius stays small.

Beyond app cubes, Cubes OS introduces service cubes and specialized control points for hardware and networking. USB devices and network access are isolated through dedicated cubes (for example, a firewall cube for inbound control, or a Tor network cube for onion routing). The system also includes a management cube for background administration and a “dom0” admin cube that acts like the root control plane. Dom0 is treated as the most trusted and most sensitive component: it has no internet connection and should only run the desktop environment and window manager. If dom0 is compromised, the system’s security model collapses.

The tradeoff is usability and resource cost. The setup is described as painful and slow, especially when running inside a VM. Hardware requirements include a 64-bit CPU with Intel VT-x (EPT) or AMD-V with RVI, plus IOMMU. Memory and storage demands are steep: at least 6 GB RAM (16 GB recommended) and 32 GB storage (128 GB recommended), with virtual machines requiring extra RAM and large disk allocations. The transcript also notes that Cubes OS officially discourages running inside a virtual machine, though it can be attempted via nested virtualization.

Installation proceeds via downloading the stable ISO, writing it to USB using Rufus in DD image mode, and then configuring BIOS settings such as enabling CPU virtualization and disabling Secure Boot for external installs. After installation, users select template cubes (Fedora, Debian 11, and Whonix by default in the walkthrough), then connect to networks as needed. Disposable cubes add another layer by wiping changes when stopped. Even with all that, the creator concludes that the security benefits come with performance and convenience costs, and suggests that for some users, running separate conventional VMs may be a simpler alternative—while still acknowledging Cubes OS’s strong confinement model.