Intel shut down Clear Linux in July 2025, ending a decade of work on what was widely measured as the fastest general purpose Linux distribution available. On August 31, 2026, Auke Kok, who spent more than seventeen years at Intel across Moblin, MeeGo, Tizen and Clear Linux before leaving in 2023, published the first notes on a successor project. It is called The Ur Project, it is written in Rust on both the producing and consuming side, and its stated goal is not to be a distribution. It is to be the thing that builds one, so that a company or a community can produce its own.
The short answer
Auke Kok, a former Intel engineer who worked on Moblin, MeeGo, Tizen and Clear Linux before leaving in 2023, has published the first design notes for The Ur Project. It is not a distribution. It is a stack for building distributions, written in Rust on both the producer and consumer sides, targeting reproducible builds, provenance tracking, The Update Framework, composition layers, optional atomic updates and containerisation, and packaging for more than a thousand upstream projects. Kok names community contribution difficulty as Clear Linux's central flaw. There is no software to download yet, only architecture and the start of infrastructure.
When Intel killed Clear Linux in July 2025, the reaction in the Linux world was less about the distribution than about what it represented. Clear Linux was the reference point in benchmark articles, the one that showed how much performance an ordinary distribution leaves on the table through conservative compiler flags and generic builds. It ended with an immediate cutoff, archived repositories and an instruction to migrate quickly.
A little over a year later, one of its architects has posted what he wants to build next.
The diagnosis is about contribution, not code
Auke Kok spent more than seventeen years at Intel, working on Moblin, then MeeGo, then Tizen, then Clear Linux, before leaving the company in 2023. That is an unusual amount of accumulated experience with the specific problem of standing up a Linux distribution from scratch, several times, inside a corporation.
His stated diagnosis of Clear Linux's central flaw is worth reading carefully, because it is not the answer most people would give. He does not point to a technical limitation. He says it was far too hard for the community to contribute to, and that there was no straightforward workflow for getting development work integrated.
That is a real and underrated failure mode. A distribution can be technically excellent and still have exactly one supplier, and when that supplier reallocates a budget, the excellence evaporates in a single forum post. Clear Linux never developed the outside contributor base that lets a project survive its sponsor, and the reason was that contributing was difficult by construction.
What Ur is proposing instead
The project describes its goal as building a mature Linux distribution building software stack that allows users and companies to build their own secure distro. That sentence is doing a lot of work, so it is worth unpacking.
The deliverable is not an ISO. It is the machinery: the build system, the packaging definitions, the update mechanism, the composition tooling. The distribution you end up running is one you assemble, whether that is an embedded image with a fixed function or a desktop system with GNOME or Xfce on top. Optional atomic updates and containerisation are part of the target rather than the premise, which suggests the intent is to cover a wider range of deployment styles than an immutable desktop.
Both halves are to be written in Rust, producer and consumer. That is a maintenance argument as much as a safety one. A build system and its runtime counterpart sharing one language and one dependency graph is considerably less work for a small team than the usual pile of shell, Python and C that accumulates around package management.
The supply chain items are the serious part
Three entries in the design list belong together and say more about the project's ambitions than the language choice does.
Reproducible builds means that building the same source with the same inputs produces byte identical output, so a third party can verify that a published binary corresponds to the source it claims. This is the foundation everything else in the list rests on.
Provenance tracking means keeping a verifiable record of where each artefact came from and what produced it. For a stack whose entire purpose is letting other people build their own distribution, this is not optional. If a hundred organisations each assemble a system from these parts, the question of what exactly went into any given image has to have an answer that does not depend on trusting whoever assembled it.
The Update Framework is an established specification for update system integrity, built around signed metadata, role separation and key rotation, so that trust in an update never rests on a single key or a single server staying correct forever. Choosing an existing specification rather than inventing one is the correct instinct, and it is a concrete commitment rather than a vague gesture.
Together these are a coherent position: the trust story has to be built in from the start, because it cannot be retrofitted onto a build system that has already produced a thousand packages.
The parts to be sceptical about
There are two, and it is fairer to the project to name them plainly than to be polite.
The first is scale. Packaging more than a thousand upstream projects, including full desktop environments, is a genuinely large amount of ongoing work, and the announcement is from a project with no deliverables yet. Clear Linux carried that load with Intel's resources behind it. The gap between an architecture document and a maintained package set is where most new distributions stop.
The second is the AI dependency. The project says it will rely on AI and large language models in part, and does not say where. Read charitably, that is aimed at exactly the work that makes small distribution teams give up: generating and refreshing build recipes at volume, triaging build failures after a toolchain change, keeping metadata current across a thousand upstreams. That is a reasonable hypothesis about what has changed since the last time someone tried this alone. It is also unproven, and it sits uncomfortably next to the reproducibility and provenance goals, which are precisely about being able to verify what happened rather than trusting a process.
Both concerns are about execution rather than design. The design itself is more thought through than most new distribution announcements, which tend to lead with a desktop theme.
Worth watching, not worth installing
There is nothing to install. What there is, is a public set of notes from someone who has built this category of thing repeatedly, arguing that the way to keep a distribution alive is to make it easy for outsiders to contribute, and starting from the supply chain rather than from the package manager.
If you want the current state of a project that is further along in a similar direction, our coverage of AerynOS and its versioned repositories looks at a distribution rethinking the same layer with working software behind it.
Sources and further reading
- Former Intel Engineer Who Was One Of The Clear Linux Architects Is Starting A New Distro, Phoronix, August 31, 2026
- The Ur Project, notes by Auke Kok
- Clear Linux OS terminated as Intel trims the fat, The Register, July 21, 2025
- Intel announces end of Clear Linux OS project, archives GitHub repos, BleepingComputer
Frequently asked questions
Is this Clear Linux coming back?
No, and the framing is deliberately different. Clear Linux was a distribution that Intel produced and users consumed. The Ur Project describes itself as a software stack for building distributions, so that users and companies can produce their own secure distro. That is a different product with a different audience. Kok's own diagnosis of what went wrong is that Clear Linux was far too hard for the community to contribute to and lacked a straightforward workflow for getting development work integrated, which is a governance and tooling problem rather than a technical one.
What is actually built so far?
Very little, and the project says so. As of the announcement there are no deliverables. What exists is a set of published notes laying out the design and the beginnings of the infrastructure needed to bring it up. Treat this as an architecture document from someone with unusual credentials rather than as software you can install. The value in reading it now is in the design decisions, not in a download.
What does the design actually specify?
The published list covers reproducible builds, provenance tracking, integration of The Update Framework for signing and update security, composition layers for assembling a system out of parts, and packaging for more than a thousand open source projects including GNOME and Xfce. Both the producer side, meaning the build system, and the consumer side, meaning what runs on the resulting machine, are to be written in Rust. Optional atomic updates and containerisation are part of the target, and the same stack is meant to serve embedded and desktop systems.
What does relying on AI mean here?
The announcement states the project will rely on AI and large language models in part, without detailing where. For a distribution build system the plausible uses are the tedious, high volume work: generating and updating build recipes for a thousand upstream projects, triaging build failures after a toolchain bump, and keeping packaging metadata current. Those are the tasks that make a small distribution team give up, and they are the reason Clear Linux needed Intel sized resources to keep moving. Whether that substitution works is one of the open questions worth watching.
Why did Intel end Clear Linux?
Intel announced the end in July 2025 on the Clear Linux Project forums, with immediate effect: no further patches, no updates, no maintenance, and the GitHub repositories moved to read only archives. Users were told to migrate quickly. It came during a broad round of cost cutting at the company. The distribution had a real technical reputation, built on aggressive compiler flags, function multi versioning and a stateless configuration model, and none of that was enough to survive a budget decision made elsewhere.