Modular by construction
Components are separable, and the ones you do not want are absent rather than installed and switched off. A system you can subtract from is a system you can reason about.
Products / Operating system
An operating system you do not have to fight.
A Linux-based system built for developers and organizations who want a lean, transparent and highly customizable environment instead of a general-purpose OS with decades of accumulated defaults. It is in design and early development, and there is nothing to download yet.
01: The bet
Ubuntu made Linux easy for everyone. We are doing the opposite.
GUI Linux is already solved. Ubuntu, Fedora, Mint, Zorin and Pop!_OS made it accessible, they did it well, and there is nothing left to win by doing it again. 0dyssey is not chasing that half of the problem, and conceding it is what makes the rest of this page a claim rather than a boast.
The half nobody has taken is the setup. A lean tiling environment with the tooling already curated still has to be assembled by hand, out of configuration files and accumulated Linux experience, by every person who wants one. That cost is the target. Remove the setup tax, not the power.
The terminal stays. It is a feature, not the enemy, and a system built to keep you out of it is solving a different problem for a different person. What sits on top of the base is built by hand rather than inherited as someone else's defaults with a theme over them.
02: The argument
Why build one at all.
Modern operating systems are built for the mass market, and that is not an insult, it is a design constraint. Serving everyone means shipping defaults that suit nobody exactly, carrying decades of compatibility, and hiding the machine behind layers that are difficult to inspect and harder to change.
The result is familiar to anyone who works close to the metal: you spend your time adapting to the system rather than the other way round, and when something behaves oddly the honest answer is often that nobody currently working on it knows why that code is there.
We want the opposite properties. A system where what runs at boot is a decision somebody made and can explain, where the pieces you do not want are absent rather than disabled, and where changing behavior means changing a component rather than defeating one.
That is not a general-purpose operating system, and it is not trying to be. It is a system for people who would rather own the layer underneath than negotiate with it.
03: Design commitments
Decisions already made.
These are the constraints the build is being held to. They are stated in the present tense because the decisions are real, even though the software is early.
Transparent by default
What happens between power-on and a usable shell is inspectable and documented. No behavior that only exists as folklore in a forum thread from six years ago.
Secure by construction
Security is treated as a build-time property: a smaller surface, explicit privileges, sane defaults. Not a hardening guide published after the fact for the user to apply.
Performance as a constraint
Weight is a design failure, not a tax to accept. What ships is what is needed, which is the only reliable way to stay fast rather than becoming fast in a benchmark.
Customizable without a fight
Changing how the system behaves means changing a component through a supported path, not defeating a default that assumed you would never want to.
Built for people who work close to the machine
Developers, systems people, and organizations running their own infrastructure. The environment is tuned for that work rather than made friendly enough for everyone at its expense.
04: The stack
What actually gets built, from the machine up.
An operating system is an integration problem before it is a coding problem. This is the order the integration has to happen in.
This is the plan of work, not a changelog. None of these layers is finished, and the ones nearer the bottom of the list have not been started.
Base system
The kernel configuration, the boot path, and the smallest set of userland that constitutes a machine you can log into and trust.
Init and services
What starts, in what order, and under whose authority. The part of a distribution that determines whether the system is legible or magic.
Package and update model
How software arrives, how it is verified, and how a machine gets from one known state to the next without becoming a unique snowflake.
Security model
Privilege boundaries, defaults, and what is exposed by a stock install. Decided alongside the base rather than added over it.
Developer environment
Toolchains, containers and the daily working surface, treated as a first-class part of the system rather than something the user assembles afterwards.
Integration and release engineering
Reproducible builds, images, and the machinery that turns a directory of decisions into something another person can install.
05: The composition
Proven layers, composed.
Every layer under the top one is existing software, chosen on its merits and used as it is. The only new thing is the layer at the top, and that is the honest scope of the work.
Not a fork, a careful composition of proven layers on a Void Linux base. Each one does its job and hands off cleanly to the next. Naming a component is a decision taken, not a claim that the parts are already assembled.
- L4
0dyssey
the user experience layerThe one layer to be written here rather than adopted: curated defaults, a control surface for the settings that matter, and the documentation that turns the four layers below into a system somebody else can pick up. It does not run yet, and this is the only rung on the list that does not already exist.
- L3
i3
window managementTiling, keyboard driven, configured in one readable file. It stays a window manager instead of growing into a desktop environment.
- L2
xbps
packages and updatesHow software arrives, and how a machine moves from one known state to the next, with the same tooling for a single package and for a whole system.
- L1
runit
init and supervisionWhat starts, in what order, and what restarts it when it dies. Small enough to read end to end, which is why it is here instead of a larger init.
- L0
Linux kernel
hardware and schedulingDrivers, memory and process scheduling under one authority. Chosen for the boring reasons: broad hardware support, and behaviour that is already documented in depth.
each layer hands off cleanly
06: The data sheet
The data sheet.
Every line is a decision already taken, written down plainly so it can be argued with rather than guessed at.
This sheet records decisions, not measurements. Nothing on it has been benchmarked, because there is no build stable enough to benchmark, and a figure published now would be a figure invented now. The row that would normally carry the numbers says exactly that instead.
- Telemetry
None, by decision
No reporting path is being built into it. There is nothing to switch off later, because nothing goes in in the first place.
- Source
Open core
Every layer it is composed from is already open, and the layer specific to this project is meant to be published the same way. How the machine works is not intended to be a trade secret.
- Legibility
A requirement, not a preference
What starts at boot, what a package installs, and what a default assumes should all be readable by the person running the machine. Behaviour nobody can account for counts as a defect, not a quirk.
- Base
- Void Linux
- Kernel
- Linux
- Init
- runit
- Packages
- xbps
- Window manager
- i3, tiling
- UX layer
- Bespoke, not adopted
- Intended user
- Developers and systems people
- Telemetry
- None
- Measured figures
- Not measured yet
- Downloadable build
- None yet
- Status
- In development
07: What it is not
The things we are deliberately not building.
A scope stated only as ambitions is not a scope. These are the readings we want to rule out now rather than disappoint later.
- Not a general-purpose desktop trying to replace what most people already run happily.
- Not a themed respin of an existing distribution with our name on the wallpaper.
- Not a product with a launch date being kept quiet. There is no date to keep quiet.
- Not a community project asking for contributors it has no capacity to mentor yet.
- Not something you should plan production infrastructure around today, and we will say clearly when that changes.
08: What exists today
Design, decisions, and early code.
This band changes the moment there is something real to hand you.
No build to download
There is no ISO, no installer, no package mirror, no release channel and no early-access list. What exists is the architecture, the decisions above, and early development against them. The work is being written up as it happens, and that writing is the honest way to follow it until there is a build.
Follow the build logs09: Build log
One entry per stretch of work, held to a fixed shape.
The standard the log is written against, settled before there is anything in it. Numbering will start at 001, every entry will carry the day its work happened, and nothing will be backdated.
The numbering is the guarantee. It begins at 001 with nothing behind it, so this log cannot quietly acquire a history it did not have.
No entries published
The log has not started. There is no entry 001 yet, nothing has been backdated, and no sample entry is standing in for one. 0dyssey is in development, and the first entry will be written when there is a piece of work finished enough to describe accurately, not when this page needs something in it.
Read what is publishedThe shape of an entry
Fixed in advance, so the format is settled before the first entry can quietly define it. Every entry will answer these four things, in this order.
What the bar was
The narrow thing this stretch of work had to achieve, stated before any of it is claimed. A bar written after the fact is a bar that was always met.
What is built
Only what runs today, in the past tense, with nothing asserted that a reader could not check from the work itself. No screenshots of mockups, no roadmap theatre.
What is half-built
The parts that are genuinely unfinished, named rather than left to be assumed done. If two things are half-built, both get named.
What is next
The next concrete piece of work and why it comes before the others. No date attached to it, because there is no date to attach.
10: Sequence
How this gets to a build you can run.
Phases, not dates. The marker sits on the phase the work is actually in today.
No entry below carries a quarter, because none of them has one. When a real date exists it will be printed here and nowhere else first.
- Done
Architecture and the decisions above
The design commitments, the module model, and the scope, including the refusals. Enough to build against and enough to argue with.
- Now
Base system and boot path
The bottom of the stack: kernel configuration, boot, and the minimum userland that makes a machine you can log into. This is where the work actually is.
- Next
Init, services, packaging and updates
The layers that decide whether the system is legible: what starts and why, how software arrives, and how a machine moves between known states.
- Later
An image another person can install
Reproducible builds and release engineering, which is the point where this page stops being a plan and starts being a download.
11: The long game
The long game.Horizon, not current capability.
None of the three exists, none of them has a date, and none of them is a later phase of the roadmap above. This is the direction the design is being held to, printed here so that the roadmap cannot be mistaken for the whole of the ambition, or the ambition for the state of the software.
A developer's operating system, not a general one
A system small enough that speed is a property of its size rather than a tuning exercise, with the toolchain and the daily working surface treated as part of it rather than as something the user assembles afterwards. Tooling chosen for how developers actually work, and growing with the system instead of accumulating in it.
AI native at the system level
Woven in at the system level rather than bolted on as an app: a machine that automates what it can, acts on your behalf, and talks to you, prompting, explaining and asking, instead of making you drive every command by hand. This is the one rung where the operating system and the rest of the engineering are the same problem. It is also research-hard, so it is stated as the north star and nothing more.
The moonshot: from the ground up
Building the system from the ground up, eventually the kernel. Named separately on purpose: it is a decades-long endeavour rather than the next item after the ones above, and filing it as a roadmap entry would be a lie about its size.
12: Questions
The questions this page raises.
These are answered here and on the FAQ from one source, so the two can never say different things. Where the honest answer is that nothing exists yet, that is the answer given.
Every answer below is written against the state of the work today. None of it describes software you can run.
Is 0dyssey open source, and what is the licence?
The layers it composes are existing free software and keep their own licences regardless of anything decided here. The licence for the parts written for this project has not been decided, so there is nothing to announce and nothing to imply. It gets stated here once it is chosen. A licence quoted today would be a position taken for a website rather than a decision made about the software.
Who is it for?
Developers, systems people, and organizations running their own infrastructure: the people who work close to the machine and would rather own the layer underneath than negotiate with it. The more useful half of that answer is who it is not for. This is not an attempt to make Linux friendly for people who do not want a terminal. That problem is solved, and other distributions solved it: a graphical Linux desktop is genuinely good now, and building a worse version of one would help nobody. The audience here already chose the terminal and wants the environment around it to stop costing days of assembly.
Do I need Linux experience?
The design intent is that the command line is always there and is never the only way in. Comfort with a terminal should make the system faster to work in, not be the price of getting into it. Treat that as a commitment to hold the project to rather than a feature to plan around: the surface that would make it true is designed and not built, and there is nothing today you could sit in front of and test the claim against.
Is this a reskin of an existing distribution?
No. Void Linux is the base, with the Linux kernel underneath it, runit as init, xbps for packages and i3 as the tiling window manager. Those are proven layers and rewriting them badly would be a waste of everyone's time. It is not a fork, it is a careful composition: each layer does its job and hands off cleanly to the next. What is being built for this project is everything above them, the tooling, the defaults and the working surface, and that is the part worth judging. Someone else's defaults with a theme on top would not be worth shipping.
What hardware will it need?
There is no answer to that yet, and any figure printed here would be invented rather than measured. Running well on modest and older machines is a design goal, and it follows from the same decisions as the rest of the design: what is absent cannot cost you anything. But a requirement is a measurement, nothing is stable enough to measure, and a number published now is a number a future build would be held to for no reason. The requirements get published when they have been measured, and not before.
When can I try it?
You cannot. There is no build: no ISO, no installer, no package mirror, no release channel, no version number and no early-access list to join. There is also no date, which means there is no date being kept quiet. The work is written up as it happens, and following that writing is the honest way to track real progress instead of a marketing countdown.
What happens to my existing setup?
Nothing, because there is nothing to install. When there is an image, the intent is that it behaves like any other Linux installation: ordinary partitioning, an ordinary boot loader, ordinary dual boot, and documentation for the common configurations rather than a special path only we understand. None of that is a promise to plan around until an image exists and has been tested on real machines. Nobody should be repartitioning a working machine for software with no build.
14: Keep reading
The reasoning, at length.
The decisions above are stated here and argued elsewhere. These are the pieces that show the working.
- ArticleChoosing an init system, and why 0dyssey runs runitWhy the L1 rung is runit: the property we judged candidates on, and what the choice cost.
- ArticlePackage models, and the debt you defer by freezingWhy the L2 rung is xbps, and what a rolling base charges you in exchange.
- ArticleThe case for tiling window managementWhy the L3 rung is i3, and why it stays a window manager instead of growing into a desktop.
- BuildA privilege-separated display managerThe same problem class, shown through an in-house build: integration with nothing underneath left to blame.
15: Follow along
Watch an operating system get built in the open.
The decisions, the dead ends and the rewrites get written up while they are still fresh. If you want to know when there is something to run, that is where it will be said first.