Most modern operating systems follow a familiar shape.
They expose a POSIX interface.
They rely on hardware memory protection.
They assume programs will fail at runtime and build defenses around that assumption.
Singularity does not follow this model.
It is not POSIX.
It is not Unix-like.
It is not compatible with Linux or Unix software.
Singularity exists to explore a completely different way of building an operating system.
What This Operating System Is
Singularity is a research operating system developed at Microsoft Research.
It is:
• a full operating system, not a library or runtime
• non-POSIX by design
• not based on the Windows NT kernel
• not intended as a commercial product
• built to experiment with OS safety models
Singularity treats the operating system and the programming language as one combined system, not two separate layers.
Why Singularity Exists
Traditional operating systems are built on these assumptions:
• programs are unsafe
• memory corruption is inevitable
• isolation must be enforced by hardware
• the kernel must defend itself constantly
This leads to:
• complex kernels
• expensive context switches
• large trusted code bases
• runtime checks everywhere
Singularity exists because its designers wanted to test a different idea:
if software is proven safe at compile time, the OS does not need to defend itself as aggressively at runtime.
To test this idea properly, Singularity intentionally rejects POSIX, because POSIX assumes unsafe C-style programming and shared mutable memory.
Kernel
Singularity uses a small kernel, but the kernel is not the primary safety mechanism.
The kernel handles:
• scheduling
• low-level memory management
• basic system coordination
Unlike Unix or NT systems:
• isolation is not primarily enforced by page tables
• kernel/user boundaries are less emphasized
• safety is shifted away from the kernel
The kernel exists to support execution, not to police it.
Programming Model
The programming model is the core of Singularity.
Key characteristics:
• programs are written in type-safe managed languages
• no shared mutable memory between components
• communication happens through explicit channels
• ownership and lifetimes are enforced by the type system
Because of this:
• buffer overflows are eliminated
• use-after-free bugs are eliminated
• many race conditions are structurally impossible
This is why Singularity does not need POSIX.
The POSIX process + memory model simply does not fit this design.
POSIX Status
Singularity is explicitly non-POSIX.
It does not provide:
• POSIX system calls
• fork/exec process model
• Unix file descriptor semantics
• POSIX signals
• traditional Unix permissions
This is intentional.
POSIX assumes:
• unsafe languages
• shared memory
• defensive kernels
Singularity assumes:
• safe languages
• explicit communication
• design-time guarantees
Processor Architecture
Singularity was developed primarily for:
• x86
• x86-64
The OS assumes:
• stable hardware
• controlled environments
• predictable execution
Wide hardware portability was not a goal.
Correctness of the model was.
File System
Singularity does not follow a traditional Unix filesystem model.
Persistent storage is:
• managed as part of the system’s object model
• accessed through controlled interfaces
• subject to the same safety rules as memory and communication
There is no emphasis on:
• POSIX filesystem semantics
• Unix-style permissions
• compatibility with existing filesystems
The filesystem exists to support system safety, not compatibility.
Hardware Requirements
Singularity is designed to run in:
• virtual machines
• research labs
• controlled test systems
Typical expectations:
• modest CPU requirements
• modest memory requirements
• no dependency on GPUs
• no dependency on specialized hardware
It is not designed for consumer hardware diversity.
Who Should Use Singularity
Singularity makes sense for people who:
• study operating system architecture
• research programming language safety
• design secure runtimes
• question hardware-based isolation
• work on OS research or formal methods
It is useful as:
• a research reference
• a design experiment
• a conceptual OS model
Where Singularity Does Not Make Sense
Singularity is not suitable for:
• daily desktop use
• servers running existing software
• POSIX-dependent applications
• enterprise environments
• production systems
It intentionally sacrifices compatibility for clarity.
Singularity matters because it shows that many problems we accept as unavoidable in operating systems are actually design choices, not laws of nature.
It does not try to replace existing systems.
It exists to prove that a different OS model is possible one where safety is enforced before the program ever runs.
Top comments (0)