The Ur Project

Documenting the craft of stacking things so they remain stacked. For a very long time.

Architecture - Designer - part 13

A distribution is only as good as its packages, never better.

Open the gates

Any Linux Distribution stands or falls with the content that it offers. If it doesn't offer enough content for users, they'll find one that does have the content that they want. If the content is stale or outdated, users will go to a distribution that is newer, because they know they can get it elsewhere. So any distribution will want to open the flood gates of content and pass through every single thing they can to users. Right?

Close the gates

Not so fast. Unfettered ingestion of content is a terrible idea. First, there are so many development quality software around that it's not worth trying to package that all up. Users don't want software that breaks their system, brings it down, eats all the resources or just fills up hard drive space and doesn't do anything useful. And then there's the security aspect of beta software. The reputation of a good distro that wants to be secure can't be lax here.

Open the gates, a little bit

But you can't just keep raising the bar for software. At some point you won't have any useful software left. So the air intake of the good Linux distributions is semi open. It rapidly consumes updates from reliable software products, first of all. And it experiments with new features and content that users want, but the people who run the distro decide based on data whether it's a good idea or not to do so (yet), or whether it's better to hold off for a bit until the cool new bling feature is more stable.

This poses a significant problem for operators. They have to do all this work, and more and more things pile on their desk that they have to make decisions over. This is the true cost of running a Linux distro: Time. Everything costs time. Time to look for new content that users want. Time to determine whether it's even worth looking into it. Time to download and take a quick peek at the software. Time to compile and test it a bit, and see whether it's even ready to be built yet. Time to maybe do a quick security review of the architecture and assess risk. Time to see if the build system will take it. Time to run the unit tests, if there are any. It's all time.

Some of that is genuinely fun work. Don't get me wrong. But a lot of it is just tedious stuff. Like, having to pry the build scripts of a random project and figure out that when the README.md said it just needed libA and libB, it lied and needed a deprecated API from libB linked against an unmentioned libC, plus all these undocumented runtime dependencies, and non-standard installation locations.

My time is valuable

So where do I spend my time? Obviously the work needs to be done, but I don't want to do some of the tedious things anymore. In Clear Linux we built autospec for this reason. It takes some of the tedious work and turns it into a mechanical solution that does 90% of the work sorting out dependencies and how to build the project. It was really really good. It solved so much of our time problem, and allowed us to scale out.

But, it was slow and often blind to certain variations. It often needed manual tweaking and adjustment. So when I started out scaffolding The Ur Project, I tried to build something a little bit more solid than autospec. And quickly it became obsolete due to the fact that making recipes that are declarative for the most part is something that LLMs can just do. So I experimented with various approaches to allowing LLMs to do basic packaging work, and, it works really well. So good that I'm not writing recipes anymore. It's not worth my time. It's all boilerplate stuff mostly.

The tough bits

Now, this opens up a big can of worms and probably will upset a bunch of folks. Which I understand. It's just that at this point I'm going to say that if you want me to manually package recipes by hand, you're going to have to bring me a lot of suitcases with green pieces of paper. My time is much better spent reviewing what was created, and testing it thoroughly. And of course, using my extensive experience doing this by hand for many, many years to know what looks right and is probably OK, and what is a terrible way of doing it and should be shot down hard.

The second part is that you can't trust LLMs. These sneaky buggers will just sudo into your system and manually rewrite whatever they can get their hands on if you tell them to "fix a problem". So whatever LLM is doing recipe work, it must be properly isolated, and that is why designer is built like it is.

Designer is an API

Designer is an isolation layer. It moves the "probation" code into a separate silo where experiments can build, be manipulated, scanned, tested and LLMs can perform these functions without LLMs having the ability to decide anything. All the agents can do is submit, change, iterate, retract.

The designer offers enough data through the API so that LLMs can deeply inspect build logs, dependency chains, and do all this work. The LLM agent can run as a separate user ID and use their own token access. They can combine many changes into a closure and build changes that are dependent and thus test the viability of large and complex ABI changes before they even are reviewed.

Human review is always the gate

The designer web interface is part of dispatch-web, and shows all the designer content so you can look as things iterate, build, and move through the content intake process. Most importantly, the designer page will show you which proposals have reached maturity and can be promoted. This commits the change(s) into the registry, after which dispatcher will build the actual real published binaries.

This puts human review front and center. By the time the human looks at proposals, the content is already scanned for:

And the reviewer gets shown the output of these scans, plus a full diff like view showing the changes with this version.

A review diff for a libuv update

What's next here

I'm currently wrapping up some better integration with coding agents and designer will come with opencode instructions for those wanting to try this out on launch. The recipe skill work instructs coding agents to the right API endpoints and shows how to setup tokens to get started. Most of this should all just work out of the box, whether you use your own model or not.

--sofar (aka Auke)