AnotherOS

About the project

Why it exists, how it is built, and how far to trust it.

AnotherOS is a personal project. It exists because writing an operating system end to end — kernel, libc, toolchain, desktop, package manager, installer — is the only way to actually understand how one fits together.

What it is for

The homelab. A spare laptop, a machine on a shelf, hardware that would otherwise be recycled. It is not trying to replace anything on anyone's daily driver, and it is not a product.

Principles

  • Own the differentiator, reuse the commodity. The kernel, the desktop and the package manager are written here. Compilers, codecs and toolkits are ported.
  • No stubs. A component lands when it is implemented and tested. Scaffolds that merely compile are not merged, and in the application toolkit this is mechanical: if a symbol is not documented, it is not in the library. A missing feature that reads as a present one is worse than an absent one, because it fails at the moment it matters and reports success everywhere else.
  • Measure, don't assert. Performance claims come with the numbers on both sides. "Faster" without a figure is not a claim.
  • Each claim gets its own instrument. When a system asserts two things — that the values are right and that they arrive on time — one measurement will silently cover only the easier of them. The sound stack is the worked example: a server consuming its clients eight times faster than real time kept every checksum green and every latency figure improving, while the audio was nonsense.
  • A clean boundary around the compositor. The compositor core links no third-party toolkit; it talks to such components over IPC. That keeps the part that defines the system independent of what is ported into it.

Honesty about maturity

It boots on several real machines, dual-boots beside macOS on a Mac, compiles its own software, and runs a browser and native Windows programs. It also panics, it has gaps, and the photographs of those panics are on this site alongside the screenshots that went well.

The documentation is written the same way: where something is implemented but proven only under emulation, or works on one machine and not another, the page says so rather than rounding up. A claim that was made and later found wrong stays withdrawn.

Treat it as something to explore, not something to depend on.