“Do the right thing by default, but make it introspectable and fixable.”
— Rudy
This document is written to present a critique of current operating system design, particularly in Unix-like systems, and to propose a coherent, alternative vision in the form of a new OS family: RadianOS. While others are welcome to critique, expand upon, or debate these ideas, the conceptual framework laid out here represents original thought and is protected accordingly.
The motivation behind this manifesto arises from longstanding frustrations with Linux, BSD, and Unix-based systems as a whole. These platforms, while powerful and historically important, are rooted in design assumptions made decades ago—assumptions that no longer align with how modern systems are used, built, or secured.
Linux is powerful, adaptable, and widely used—but it carries an immense legacy burden:
- Entrenched in historical design: Filesystem layout, init systems, and permission models are all inherited from the Unix of the 1970s.
- Code complexity and fragmentation: Competing philosophies, overuse of abstraction, and excessive tooling make the ecosystem inconsistent.
- Weak isolation: Root access is still central, and most security mechanisms are reactive patches rather than foundational guarantees.
- Package chaos: DEB, RPM, Flatpak, AppImage, and more—there is no universal, safe, or predictable way to manage software.
- Incoherent configuration: Each distribution structures system configuration differently, with no consistent state model.
BSD attempted to improve on Unix’s limitations, especially in code quality and system clarity. However, its relevance has diminished for two reasons:
- Its user base and hardware support lag behind Linux, largely due to historical lawsuits that limited its early momentum.
- It remains focused primarily on servers, routers, and embedded contexts, not general-purpose or developer-friendly computing.
Linux and BSD are just descendants of a broader legacy. The real problems begin in Unix itself:
- The filesystem hierarchy is rigid and arbitrary, not suited to namespaced or isolated apps.
- The process model was built before distributed computing, multi-core async runtimes, or container isolation.
- The root model assumes trust and centralization, which no longer fits how we use computers.
- The "everything is a file" abstraction once simplified things, but now causes API complexity and leaky abstractions.
- Hardware-software interface layers are fragmented and redundant across drivers, firmware, and system calls.
These are not just bugs. They are results of outdated premises. The software we use today still runs on a philosophy designed half a century ago. This cannot be patched indefinitely.
RadianOS is not a Linux distribution. It does not seek POSIX compliance for its own sake. It does not aim to support every existing application, or follow tradition where tradition no longer serves.
Instead, it starts from modern assumptions:
- Machines are networked and multi-core.
- Security must be proactive, not reactive.
- Apps are independent units, not system-spanning dependencies.
- Configurations should be declared, not scattered.
- Tools should explain themselves.
What follows is a breakdown of the major problems identified in Unix-style systems and how RadianOS proposes to address each.
The Unix filesystem layout is not just old but unfit for modern software. Binaries, configs, runtime data, logs, and user state are scattered arbitrarily across /etc, /usr, /var, /opt, and beyond.
- Namespaced, app-centric structure: Each app lives in its directory, such as /apps/editor or /apps/browser, including its binaries, libraries, data, and UI assets.
- Declarative system structure: Configuration lives in /config, system definition in /system, and user-specific data in /users. These paths are clean, inspectable, and predictable.
- Immutable base system: Core files are read-only and versioned. System changes are layered as overlays, not applied directly. This improves security, reversibility, and clarity.
This layout matches how applications are built and distributed today, not how they were written in 1975.
Unix’s fork() system call, though ingenious in its time, has become a liability. It complicates memory management, breaks async runtimes, and is increasingly incompatible with high-level language models.
- Eliminating fork() entirely.
- Async-first process spawning: Processes are lightweight, event-driven, and designed for isolation and message-passing.
- Explicit concurrency: The OS supports structured, observable process hierarchies and safe parallelism.
This aligns with how concurrent systems are written—in Rust, Go, Erlang, or JavaScript, not with how they were imagined in 1969.
Unix's security model centralizes trust in a single user, root, who can do everything. Most OS security is built on restricting or emulating what root can or cannot do.
- No root user. Not even hidden or privileged system processes run with universal access.
- Capability-based security: Every process gets a limited set of permissions (capabilities) on creation. Access is explicit, inspectable, and revocable.
- Escalation is always opt-in: Like OAuth for system resources, requests for higher permissions must be declared, justified, and reviewed.
Security should be a property of the system, not of trusting one privileged user.
The init system today has become a complexity monster—systemd, while powerful, is bloated, unpredictable, and hard to introspect.
- Event-driven, modular init: The init system is reactive, clean, and can be controlled via clear signals and events. No monolithic processes are running in the background.
- Explicit service configurations: Services are configured declaratively and linked with events in the system, allowing for fully reproducible state transitions.
- No daemon mess: The idea of constant background daemons is eliminated. Instead, services are activated on demand, and the system state is synchronized with their needs.
Gone are the days of unnecessary complexity. RadianOS would provide a simple, predictable, and clean system configuration.
While container technologies like Docker are commonly used in development and deployment, they are not fundamentally integrated into the OS.
- Built-in containerization at the OS level, not just at the application level. ** By default, all processes run in isolated sandboxes, with simple mechanisms to allow inter-container communication if necessary.
- Minimalist container images: Each image represents a simple, complete application, with no excess baggage.
Containers are not just for "cloud-native" applications—they are the foundation of how applications run, deploy, and update.
The challenge of designing a new OS is vast. We do not expect RadianOS to be adopted overnight. But our goal is to demonstrate that the future of computing can be cleaner, safer, and more consistent. RadianOS will not simply be a new OS—it will be an entire ecosystem, one that moves away from the chaotic, security-risk-laden legacy of Unix-like systems.