<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/css" href="/feed.css"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>The Ur Project</title>
  <subtitle>Notes on building a new Linux distribution, and the thing that builds it.</subtitle>
  <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/"/>
  <link rel="self" type="application/atom+xml" href="https://ur.foo-projects.org/feed.xml"/>
  <id>https://ur.foo-projects.org/</id>
  <updated>2026-09-19T00:00:00Z</updated>
  <author><name>sofar (aka Auke)</name></author>
  <entry>
    <title>Architecture - Compositions - part 9</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/architecture-compositions-part-9/"/>
    <id>https://ur.foo-projects.org/posts/architecture-compositions-part-9/</id>
    <published>2026-09-19T00:00:00Z</published>
    <updated>2026-09-19T00:00:00Z</updated>
    <summary type="text">The dispatcher builds images automatically, as soon as an image could be updated. What a composition is, a simple composition.toml for pkg compose, the composition list and test results in dispatch, and why immutable system images have to wait.</summary>
  </entry>
  <entry>
    <title>Project Status Update - week 3</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/project-status-update-week-3/"/>
    <id>https://ur.foo-projects.org/posts/project-status-update-week-3/</id>
    <published>2026-09-18T00:00:00Z</published>
    <updated>2026-09-18T00:00:00Z</updated>
    <summary type="text">End of week 3, measured against the same four release criteria. A Live USB that boots and installs - on two machines so far, and it took manual work to get there - with WiFi and the touchpad working. A local package build demoed. Automated testing of the build system next. And the item that decides whether anyone else can use any of this: documentation.</summary>
  </entry>
  <entry>
    <title>A demo - a local package build</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/a-demo-a-local-package-build/"/>
    <id>https://ur.foo-projects.org/posts/a-demo-a-local-package-build/</id>
    <published>2026-09-17T00:00:00Z</published>
    <updated>2026-09-17T00:00:00Z</updated>
    <summary type="text">A video, and not much else. Forty-nine seconds of a package built locally with nothing but the pkg tool - the source fetch, the recipe, a signing key, the build itself, then a bundle installed on the machine and run. The same code the build server uses, with no build system deployed anywhere.</summary>
  </entry>
  <entry>
    <title>Architecture - Repositories - part 8</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/architecture-repositories-part-8/"/>
    <id>https://ur.foo-projects.org/posts/architecture-repositories-part-8/</id>
    <published>2026-09-16T00:00:00Z</published>
    <updated>2026-09-16T00:00:00Z</updated>
    <summary type="text">A repository is a handful of content-addressed stores and a metadata tree. Why the checksum is the address, how that makes duplicate content free and unchanged subpackages a no-download update, and what the other four stores - licenses, provenance, recipes and sources - are there to prove.</summary>
  </entry>
  <entry>
    <title>Architecture - Packages - part 7</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/architecture-packages-part-7/"/>
    <id>https://ur.foo-projects.org/posts/architecture-packages-part-7/</id>
    <published>2026-09-15T00:00:00Z</published>
    <updated>2026-09-15T00:00:00Z</updated>
    <summary type="text">What comes out of the build is split in two: a signed TOML manifest that describes every file, and a plain zstd tarball stored under its own checksum. Why that makes a rebuild that changed nothing a free update, why there are no timestamps, and how bundles carry it all across an air gap.</summary>
  </entry>
  <entry>
    <title>Architecture - Intent, subpackages, and sets - part 6</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/architecture-intent-subpackages-and-sets-part-6/"/>
    <id>https://ur.foo-projects.org/posts/architecture-intent-subpackages-and-sets-part-6/</id>
    <published>2026-09-14T00:00:00Z</published>
    <updated>2026-09-14T00:00:00Z</updated>
    <summary type="text">Every package is split into subpackages, and pkg installs the core ones by default. How pkg.toml can pull in man and doc pages automatically, why pkg list shows what you chose to install instead of everything that came along with it, and how sets nest and follow their changes during an upgrade.</summary>
  </entry>
  <entry>
    <title>Architecture - The registry - part 5</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/architecture-the-registry-part-5/"/>
    <id>https://ur.foo-projects.org/posts/architecture-the-registry-part-5/</id>
    <published>2026-09-13T00:00:00Z</published>
    <updated>2026-09-13T00:00:00Z</updated>
    <summary type="text">The shortest one in the series, because a registry really is just a box of cards. A directory of recipes, a registry.toml that indexes the ones which count, and a sets directory holding the package groups that pkg tracks by intent when you install them.</summary>
  </entry>
  <entry>
    <title>Zen and the art of motorcycle maintenance (on making modifications)</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/zen-and-the-art-of-motorcycle-maintenance-on-making-modifications/"/>
    <id>https://ur.foo-projects.org/posts/zen-and-the-art-of-motorcycle-maintenance-on-making-modifications/</id>
    <published>2026-09-12T00:00:00Z</published>
    <updated>2026-09-12T00:00:00Z</updated>
    <summary type="text">A fixer upper should cost about what the job is worth, and so should changing a distribution. The tiers of modding The Ur Project, from a local package build that needs nothing but pkg and a few build tools, through derivative and overlay repositories, to a rebuild for a different ABI and a completely independent OS.</summary>
  </entry>
  <entry>
    <title>Project Status Update - week 2</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/project-status-update-week-2/"/>
    <id>https://ur.foo-projects.org/posts/project-status-update-week-2/</id>
    <published>2026-09-11T00:00:00Z</published>
    <updated>2026-09-11T00:00:00Z</updated>
    <summary type="text">Two weeks public, and a walk back through the four release criteria to say what moved and what did not. Automatic image builds, a debranded browser, updates working from the Live USB, an admin TUI for the tasks that should stay out of the web UI, and the repo server that still has to be bought and stood up.</summary>
  </entry>
  <entry>
    <title>Architecture - The recipe format - part 4</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/architecture-the-recipe-format-part-4/"/>
    <id>https://ur.foo-projects.org/posts/architecture-the-recipe-format-part-4/</id>
    <published>2026-09-10T00:00:00Z</published>
    <updated>2026-09-10T00:00:00Z</updated>
    <summary type="text">The recipe is the unit of input for the build system: one TOML file, declarative, with no scripting and no macro language. Why TOML beat YAML and JSON, what the recipe, source, patch and dependency sections actually look like, and the browser-based editor and linter that take the tedium out of writing them.</summary>
  </entry>
  <entry>
    <title>On telemetry</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/on-telemetry/"/>
    <id>https://ur.foo-projects.org/posts/on-telemetry/</id>
    <published>2026-09-09T00:00:00Z</published>
    <updated>2026-09-09T00:00:00Z</updated>
    <summary type="text">A survey at the end of the call, and why the answer here is no. Clear Linux shipped a genuinely privacy-preserving telemetry client and users hated it anyway. The Ur Project collects nothing: no appetite for it, no lawyers to bring in, and a good test pipeline catches more than crash reports ever will.</summary>
  </entry>
  <entry>
    <title>Architecture - Content review - part 3</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/architecture-content-review-part-3/"/>
    <id>https://ur.foo-projects.org/posts/architecture-content-review-part-3/</id>
    <published>2026-09-08T00:00:00Z</published>
    <updated>2026-09-08T00:00:00Z</updated>
    <summary type="text">A pile of blocks only stands up if every block is checked before it is stacked. The gates content has to pass to get into the Ur Project: license scanning, malware scanning, the compile, reproducible builds, package tests, vulnerabilities, and the review page that puts all of it in front of a human who has to decide.</summary>
  </entry>
  <entry>
    <title>Architecture - dispatcher - part 2</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/architecture-dispatcher-part-2/"/>
    <id>https://ur.foo-projects.org/posts/architecture-dispatcher-part-2/</id>
    <published>2026-09-07T00:00:00Z</published>
    <updated>2026-09-07T00:00:00Z</updated>
    <summary type="text">Koji made large package changes serial and painful. Dispatcher instead spins up throwaway repositories that resolve dependencies like real ones, so a hundred interdependent recipes can be staged, built and accepted as one group. These are closures.</summary>
  </entry>
  <entry>
    <title>Architecture talk - dispatcher</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/architecture-talk-dispatcher/"/>
    <id>https://ur.foo-projects.org/posts/architecture-talk-dispatcher/</id>
    <published>2026-09-06T00:00:00Z</published>
    <updated>2026-09-06T00:00:00Z</updated>
    <summary type="text">What dispatcher is and what it does: a job scheduler that watches registries of recipes and turns them into repositories of packages. The graph view that made the topology workable, and the long bootstrap from a Fedora seed to three bit-identical buildroots in a row.</summary>
  </entry>
  <entry>
    <title>Once more, with feeling</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/once-more-with-feeling/"/>
    <id>https://ur.foo-projects.org/posts/once-more-with-feeling/</id>
    <published>2026-09-05T00:00:00Z</published>
    <updated>2026-09-05T00:00:00Z</updated>
    <summary type="text">A week of being sick, starting a new job, and watching Phoronix and Reddit pick up the project. What readers saw that isn't there: this is an opinionated build system, not an opinionated distro, and a project where companies sit down at the table with the rest of us instead of across from us.</summary>
  </entry>
  <entry>
    <title>The N-V-R and what it isn't</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/the-n-v-r-and-what-it-isnt/"/>
    <id>https://ur.foo-projects.org/posts/the-n-v-r-and-what-it-isnt/</id>
    <published>2026-09-04T00:00:00Z</published>
    <updated>2026-09-04T00:00:00Z</updated>
    <summary type="text">Why there is no epoch here. How name-version-release keeps every package in a content-addressed store unique, and how publishing one list of "current" pins turns upgrades, removals and downgrades into the same operation.</summary>
  </entry>
  <entry>
    <title>Project Status Update</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/project-status-update/"/>
    <id>https://ur.foo-projects.org/posts/project-status-update/</id>
    <published>2026-09-03T00:00:00Z</published>
    <updated>2026-09-03T00:00:00Z</updated>
    <summary type="text">A hard status update instead of a conceptual one. Where the code will live, what still stands between "it works" and "it's ready for consumption", what the unknowns are on hardware, and what moving the build system onto its own product broke along the way.</summary>
  </entry>
  <entry>
    <title>Fe2O3.nH2O</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/fe2o3-nh2o/"/>
    <id>https://ur.foo-projects.org/posts/fe2o3-nh2o/</id>
    <published>2026-09-02T00:00:00Z</published>
    <updated>2026-09-02T00:00:00Z</updated>
    <summary type="text">Why this project is written in Rust. Some notes on what C asks of you, what Rust's tooling gives back in test quality and type safety, and where scripting languages do and don't fit at the lower levels of an OS.</summary>
  </entry>
  <entry>
    <title>What's in a name?</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/whats-in-a-name/"/>
    <id>https://ur.foo-projects.org/posts/whats-in-a-name/</id>
    <published>2026-09-01T00:00:00Z</published>
    <updated>2026-09-01T00:00:00Z</updated>
    <summary type="text">Picking a license is the easy part. Naming the thing is the hard part. Why the project is named after a very old, very weathered stack of rocks in Iraq, and what that says about playing the long game.</summary>
  </entry>
  <entry>
    <title>Where it's going</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/where-its-going/"/>
    <id>https://ur.foo-projects.org/posts/where-its-going/</id>
    <published>2026-08-31T00:00:00Z</published>
    <updated>2026-08-31T00:00:00Z</updated>
    <summary type="text">A little bit on vocabulary - explaining recipes, registries, packages and repositories. What a Content Addressed Storage model buys us (airgapped updates, and deduped content). And why sharing content is our first class citizen.</summary>
  </entry>
  <entry>
    <title>The shape of a liquid</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/the-shape-of-a-liquid/"/>
    <id>https://ur.foo-projects.org/posts/the-shape-of-a-liquid/</id>
    <published>2026-08-30T00:00:00Z</published>
    <updated>2026-08-30T00:00:00Z</updated>
    <summary type="text">What the project actually is - one Rust codebase that both builds the distro and consumes it, a tree of repositories rooted in a self-rebuilding build root, and a consumer side that is more than a package manager.</summary>
  </entry>
  <entry>
    <title>How I'm doing this</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/how-im-doing-this/"/>
    <id>https://ur.foo-projects.org/posts/how-im-doing-this/</id>
    <published>2026-08-29T00:00:00Z</published>
    <updated>2026-08-29T00:00:00Z</updated>
    <summary type="text">Nineteen years of packaging by hand, what finally got automated away, and where LLMs do and do not belong - not in the build system, not in your distro content, but in the boring parts around them.</summary>
  </entry>
  <entry>
    <title>It's a project. Not a product.</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/its-a-project-not-a-product/"/>
    <id>https://ur.foo-projects.org/posts/its-a-project-not-a-product/</id>
    <published>2026-08-28T00:00:00Z</published>
    <updated>2026-08-28T00:00:00Z</updated>
    <summary type="text">The output isn't the point yet - the builder is. Why a serious distro has to make statements about licensing, CVEs and reproducibility, and why the build system comes first.</summary>
  </entry>
  <entry>
    <title>If you found this</title>
    <link rel="alternate" type="text/html" href="https://ur.foo-projects.org/posts/if-you-found-this/"/>
    <id>https://ur.foo-projects.org/posts/if-you-found-this/</id>
    <published>2026-08-27T00:00:00Z</published>
    <updated>2026-08-27T00:00:00Z</updated>
    <summary type="text">Nineteen years of building Linux distributions, over 25 years of time, four distros alone at Intel, and why I'm starting yet another one - and what I think we got wrong the last time.</summary>
  </entry>
</feed>
