Pre-launch · base image and runtime in build
Less system, more model
Kyber Linux is a hardened, minimal Linux built for AI workloads. A small attack surface, a small power budget, and a model runtime that is part of the base system rather than a container bolted onto a general-purpose distribution.
- Minimal by default
- Hardened out of the box
- Runs on modest hardware
A general-purpose distribution is a poor base for one workload
Three costs you inherit by starting from a distribution built for everything.
You ship a thousand packages to run one thing
A device doing inference does not need a print server, a display stack or three scripting languages. Every one of them is a thing to patch, a thing to audit and a thing that can break.
Hardening is a project you do afterwards
Defaults are chosen for convenience, because a general distribution has to work for everyone. Locking one down is weeks of work that has to be repeated on every image.
Power is a real budget
On a device in someone's pocket, a robot on battery or a small box on a shelf, watts spent on background services are watts not spent on the model.
Start from nothing, add only the workload
The image contains what the job needs and nothing else. That is the whole design.
- 01
Start from nothing
The base is assembled from a declared set of components rather than trimmed down from a general distribution. What is not in the image cannot be exploited, cannot break and does not need patching.
- 02
Harden by default
Read-only root, verified boot, kernel lockdown, least privilege for services. Not a checklist someone works through after installation — the state the system boots into.
- 03
Run models as first-class work
The model runtime is part of the base system, so memory, accelerators and thermal headroom are scheduled by something that knows what an inference job is.
Six decisions that define the system
Small, verifiable and boring, in the way infrastructure should be.
A small image
Fewer components mean a smaller attack surface, faster boots, less to patch and less to explain to an auditor. Subtraction is the main design activity.
Immutable and verified
A read-only root filesystem with a verified boot chain. The system that starts is the system that was built, and drift between the two stops being possible.
A model runtime in the base
Inference is a first-class workload rather than a container fighting a scheduler designed for web services and desktops.
A power budget you can measure
Idle draw is a design constraint, not an accident. On battery-powered and fanless hardware, the system's own consumption is a number that has to be justified.
Atomic updates and rollback
Updates are whole images that apply at once and roll back if the machine does not come up. No half-updated system on a device nobody can visit.
Open source, reproducibly built
The image definition is public and the build is meant to be reproducible, so anyone can check that what runs matches what was published.
AI-native means the scheduler knows what a model is
General-purpose systems allocate memory and CPU for processes that start, work briefly and exit. An inference workload holds gigabytes of weights resident, wants an accelerator, and cares about thermal headroom over the next ten minutes. Those are different problems.
- Weights are resident, not transient — memory management should expect that rather than fight it.
- Accelerators are scheduled, with contention resolved by policy instead of by whoever asked first.
- Thermal and power are inputs to scheduling, because on small hardware they decide what is possible next.
- Model identity is system state — which model, which version, loaded where, visible to the operator.
The layer under the whole system
Kyber Linux is what everything else in the Kyber family stands on. One base means the deck in a pocket, the robot on the floor and the server in the rack share a boot chain, an update mechanism and a security posture.
- KyberDeck — carried hardware, where the power budget is tightest.
- KyberBot — machines, where an interrupted update is a physical problem.
- KYBERIOS and KyberAgent — the systems and agents that run on top of it.
- One image definition, three device classes, one thing to audit rather than three.
Nothing to download yet — so here is the honest state of the work
Kyber Linux is pre-launch. An operating system that is not yet published should say so plainly.
- Now
Base image and model runtime
The minimal image, the boot chain and the runtime, built and rebuilt against the hardware the rest of the family runs on.
- Next
Reference images per device class
One for carried hardware, one for machines, one for small servers — the same base with three honest configurations.
- Later
Public repositories and reproducible builds
Image definitions, build pipeline and signatures published together, so the claim that it is minimal and verified is something you can check.
Frequently asked questions
What is Kyber Linux in one sentence?
Kyber Linux is a hardened, minimal Linux distribution built for AI workloads, with an immutable root, a verified boot chain, atomic updates and a model runtime in the base system.
Why another distribution?
Because the alternative is trimming a general-purpose one down and hardening it by hand on every image, repeatedly. When the workload is narrow and the hardware is constrained, starting from an assembled minimal base is less work and much easier to verify.
Is it really smaller and lower-power?
Smaller, yes, by construction — a system with fewer components has fewer components. Power depends entirely on the workload and the hardware, and anyone quoting a single number without both is selling something. What we can commit to is that idle draw is treated as a design constraint and published per reference image.
What does hardened mean here?
Read-only root, verified boot, kernel lockdown, minimal package set, services running with least privilege and mandatory access control. Standard techniques, applied by default rather than left as an exercise.
What hardware does it run on?
The reference targets are the ones the rest of the Kyber family needs: carried devices, robot controllers and small servers. Anything else is a matter of drivers, and the image definition is public so a new target is a fork rather than a request.
How does it relate to KYBERIOS, KyberAgent, KyberBot and KyberDeck?
It is underneath all of them. KYBERIOS is the operating system for the business, KyberAgent is the agent, KyberBot runs machines, KyberDeck is the carried hardware — and Kyber Linux is the base they all boot.
Be there when the repositories open
The waitlist form goes live soon. Until then, the blog is where the design decisions get argued.
No form yet, no data collected — just come back.