If you have ever wondered whether a Linux distribution is something you build or something you download, the answer is usually “both, on different days”. Ikey Doherty’s Barney lands on the build side of that question in a fairly deliberate way. The project is a Rust tool for assembling Linux distributions from source, with the build process itself as the public artifact. The funding context is loud and worth knowing about. The technical premise deserves to be evaluated on its own merits regardless of which side of the Omarchy debate you sit on.
Most announcements about new distributions start with screenshots and end with download links. Barney starts earlier than that. The repository describes the project as a tool to build a Linux distro, with the explicit position that shipping a distro is not the goal. Doherty is using a YouTube series to teach the process rather than release what the source calls a “wallpaper respin”, which is the industry shorthand for taking an existing base and reskinning the desktop without changing much underneath.
The practical question for most readers is whether a Rust build system aimed at one developer’s teaching project is worth your attention this year, or whether it is better to wait and see what survives the first six months. This article is for people who are willing to spend an hour reading the source before drawing that conclusion.
What the toolchain actually changes
The single most important design choice in Barney is that everything is built from source rather than from prebuilt images. That choice has consequences that show up the moment a dependency changes.
A Linux distribution is more than a list of apps. It is a layered stack of dependencies, each with its own version, compile flags, and assumptions about the layer below. When something at the bottom of that stack moves, the packages above it have to be revisited, and the packages depending on those have to be revisited again. That chain is what most people call “the base image”, and the base image usually breaks in ways nobody can easily diagnose.
Barney caches build outputs according to what produced them. If a dependency changes, the cache marks every package that depends on it as stale. Unchanged work gets reused. Stale work gets rebuilt. That sounds like build-system plumbing, but the practical effect is that the tool can tell you why a rebuild is happening rather than asking you to trust it. For a maintainer, that is the difference between debugging a real problem and guessing at a vague suspicion.
The cache only earns its keep when it records the reasons for the work. That is the line Barney is trying to hold.
How the layout and container choices help
Doherty’s design borrows the idea of stateless layouts from his time on Intel’s Clear Linux team, then carried that idea through Solus and AerynOS, which used to be called Serpent OS. In practical terms, the system does not freeze any one arrangement of files or directories as the canonical state that has to be copied forward through every build. The arrangement is regenerated from source and rules instead of being carried by hand, which means a build can rebuild the layout from scratch without inheriting drift from the previous attempt.
Containerized builds support that choice. Each build runs in a controlled environment, so the host machine’s installed packages and current settings do not silently leak into the output. Barney also stores results by content, so identical files that happen to appear in multiple packages can be deduplicated. None of these choices are new on their own. The combination is the point. The inputs, the file arrangement, and the resulting binaries stay connected to one another instead of letting each layer pile up its own history independently.
The ambition extends to rebuilding the toolchain itself from scratch, with the implementation written in Rust under the MPL-2.0 license. That is a high bar, because rebuilding foundational tools is where small mistakes in inputs become expensive to diagnose later. The container and content-addressed design give the project a way to surface those failures before they get buried in a finished install.
Trade-offs you should weigh before you follow along
The points below are the ones the README does not yet tell you, and they matter more than the announcement of the project itself.
- The project is at the early-stage tutorial phase. There is a YouTube series. There is no shipped distribution. Treat the artifacts as scaffolding rather than a product.
- The first audience is people who already understand distro plumbing. If you are not comfortable reading a build log, this is not yet a tool that will hand-hold you.
- Reproducibility is a stated design goal, not a verified outcome. The proof is whether another person can rebuild the artifacts bit for bit from a clean environment. That experiment has not been published yet.
- The maintainer pool is effectively one person. That is fine for a teaching project. It is a single point of failure for anything mission-critical.
- The funding dispute that motivated the project is separate from the technical merits. You can find the source-first approach interesting even if the Omarchy argument leaves you cold, and you can find the argument persuasive while still being skeptical of the Rust toolchain.
None of these reasons should dismiss the project. They are the price of working in public at an early stage.
Why the funding story is hard to separate from the work
The reason Barney exists in the public eye is the contrast with Omarchy, and skipping over the context would be a disservice to the reader. The source reports the Omacom Foundation took more than $13 million in pledges between its August launch and the date of Doherty’s reply, with eight executives (including Michael Dell at $1 million) and an additional $1.95 million worth of AI compute credits from Meta, Anthropic, OpenAI, and Fireworks. The source also reports that Doherty, who is an Irish Traveller, reacted strongly to a DHH post drawing an analogy between Denmark’s wolf population and Romani people camping in Copenhagen parks. Doherty called the comparison horrific and said the combination of money and the views had drawn him back into this kind of work. His own laptop buying plans shifted after Michael Dell was listed as one of the launch backers.
That is the context, stated as the source states it. The technical question is separate, but the two are joined by Doherty’s own framing. Barney starts from a single developer’s history and objections. That gives the project a clear motive. It also means the project will end up judged not only on its code but on whether it can grow past that origin story. A motive is not a roadmap. A smaller promise is not a finished answer.
What to actually watch as the project matures
If you care about Linux distributions at the system-build level, the parts of Barney worth paying attention to are concrete and verifiable rather than emotional.
- Whether a clean clone of the rules produces the same artifacts on a second machine, with no undocumented host dependencies.
- Whether the cache explanations are honest about why work was invalidated when a dependency changes, or whether the tool just re-runs everything.
- Whether the documentation explains failures without requiring access to Doherty’s personal machine or unreleased tooling.
- Whether the YouTube series teaches the process, or ends up being a build log with narration.
- Whether a community of contributors can form around the build rules without depending on the founder’s attention for every change.
A Rust codebase and a clever cache do not make a distro maintainable on their own. They make the maintenance work easier to test. The source does not say Barney will replace Omarchy, become a widely used build system, or remain a focused teaching project. It does say that someone with years of distro experience thinks the build process is worth showing in public rather than behind a launch video. That is reason enough to spend an hour reading the source. That hour is better spent than reading another announcement with a polished screenshot.