Oberon OS: A system built by people who hated unnecessary things

Every few years someone says:

“Modern operating systems are too bloated.”

Most of the time, that sentence ends with a Linux distro recommendation.

But Oberon didn’t complain.
It simply chose not to become bloated in the first place.

And it did that decades ago.

A system built by people who hated unnecessary things

Oberon was developed at ETH Zurich, led by Niklaus Wirth the same person who created Pascal and Modula-2.

This matters because Oberon wasn’t “let’s build an OS”.
It was:

“Let’s see what happens if we design everything together, correctly.”

Kernel.
Compiler.
Language.
UI.
Applications.

All one idea.

No POSIX checkbox.
No legacy compatibility guilt.
No “someone might need this later”.

**The Oberon language is the operating system

Oberon is written almost entirely in the Oberon language.**

Not “mostly”.
Not “with some C”.

Almost everything.

Why? Because Wirth believed that if the language is simple, safe, and expressive, the entire system benefits. No impedance mismatch between layers. No glue code nightmares.

The result:
A full OS that is shockingly small.

Small enough that you can actually understand it.

The UI idea that still feels weird (and smart)

Oberon didn’t really believe in traditional GUIs.

Instead, it believed in text.

Commands weren’t hidden behind menus they lived directly inside documents. You’d click a command written as text, and it would execute.

Documentation wasn’t separate from interaction.
The UI wasn’t separate from content.

This sounds alien today but it quietly solves a lot of problems modern systems keep reinventing.

No config screens.
No “where is this option”.
The system explains itself as you use it.

Performance by subtraction

Oberon wasn’t fast because of clever optimizations.

It was fast because:
• there was less code
• fewer abstractions
• fewer layers pretending to be helpful

Memory management was tight.
Scheduling was predictable.
The system did exactly what it said it would do.

Nothing more.

Nothing hidden.

Why Oberon never became mainstream

Short answer: it didn’t want to.

Longer answer:
• No POSIX compatibility
• No easy way to port existing Unix software
• Academic focus instead of ecosystem growth
• Required users to learn Oberon’s way

Oberon wasn’t designed to win adoption wars.
It was designed to prove a point.

And it succeeded at that.

Why Oberon still matters (especially now)

In a world of:
• multi-GB OS installs
• undocumented behavior
• layers on top of layers on top of layers

Oberon asks an uncomfortable question:

What if most of this isn’t actually necessary?

It reminds us that:
• simplicity scales
• correctness compounds
• small systems are easier to trust

You don’t need to run Oberon daily to learn from it.
You just need to study how unapologetically focused it was.

Final thought

Oberon didn’t fail.

It finished its experiment.

And left behind a blueprint most of us are still too afraid to follow.