Zen and the art of motorcycle maintenance (on making modifications)

It's hard to improve other people's lives if your own needs major work

This isn't a post about mental health, but, before we get to the technical part of this post, I need everyone to do a TCP SYN to the IANA neighbor on your left, and the IANA neighbor on your right. Yes, that means 192.167.253.x or 11.0.0.y. You see, everyone here has someone else in their lives that might need a little help one of these days, and one day the opportunity may come for you to help that other person when they need it most, even if they don't show it.

But this isn't about that. This intro paragraph is about when you need help from others. In that case, I want everyone to know that it's OK to not be able to deal with everything by yourself. Stop your firewall-cmd, and flush your iptables. And let your IANA neighbor know that you need some help. I know it's hard. But those around you can help. Reach out.

An old fixer upper

You can't start a midlife crisis project if your mind isn't into it. You might be dealing with all sorts of serious issues bothering your every day and this will consume all your energy. So the first thing you shall do before you start your project is to sort out your affairs. Make your bed. Do the laundry. Run the dishwasher, and then write some Ur Project Recipes.

Having done the important things, you can now meander off in your pet project. There's quite a few ways to start work on your fixer upper project. You can do a fresh paint job. You can replace worn out tyres. Polish the spokes. Grease the chain. Or take out the engine block and electrical harness.

A Linux Distribution is no different. You should be able to perform simple maintenance and make invasive changes to it all the same. And the cost of doing these changes should be minimal for minimal modifications, and larger as the impact of them grows. The upfront cost of doing the smallest possible modification should be really small.

Tiered modding of the distro content

The system I'm building is that the smallest unit of change takes almost no effort to start. For this reason I've built the pkg cli in such a way that one can build a local package with it without installing any additional software aside from a few build tools. The cost of doing this is minimal - just a few pkg installs and you can start. All the next tiers will need a deployment of dispatch on your system.

The largest modification you can do is to rebuild the entire distro content all by yourself. Either using recipes contributed from the main repositories or ones you've made from scratch all by yourself. Doing this results in an incompatible ABI between the current official repositories and the ones you are making. You are now your own OS.

In between those sits a tier where you can publish your own repositories but do not need to rebuild any package that isn't part of your own hosted registry (repository). You're still compatible with the official repository content - even if your packages have a different architecture baseline.

All together these 3 tiers offer exactly the resolution most people will ever need to build their own projects on The Ur Project repos, or their own completely independent Linux OS product.

There will be in-depth posts about each of these workflows. This post is already getting a bit longer, so, I'm going to post about each of them in detail one at a time, so you can see how it works in reality, with examples and screenshots.

Tier 1 - local package builds

Locally built packages are ideal to prove a concept and leverage the build system to integrate software into any local deployment. The resulting output files are directly installable, and can be combined into a pkgtar bundle that will make it easy to install several packages on local systems through sneakernet, aka that old USB stick, or from that local NAS.

Tier 2(a) - hosting a derivative repository

From the second tier you'll have to deploy dispatcher. Fortunately, I've spent time to make this really simple. One has just to install the package through pkg and call sudo dispatch init to do the setup. More on deploying the build system.

The default dispatcher setup will initialize the peering setup of the official Sandcastle-Base and Sandcastle-Common repositories, and give you a local dev registry that publishes into a Dev repository. This means you're all set to start building recipes into packages and publish your repository.

A derivative repository is one that derives (inherits) but doesn't modify what it inherits. Basically it's just a convention where your repository just "adds" new packages to the repo, but doesn't replace any. This is the lowest risk form of publishing your own packages - they're unlikely to break anything because they don't modify anything.

This is the perfect setup for adding new content and staging it so it can be tested. If you choose to host your repository over the internet through apache/nginx, everyone will be able to add your repository to their own system and use it just like the official repositories.

Tier 2(b) - hosting an overlay repository

The overlay repository is technically the same setup as the previous tier, but with the important distinction that the overlay repository replaces content in Sandcastle-Base or Sandcastle-Common with modified versions of it. This could be to enable features, or disable features, or to fix bugs. Another reason could be to do staged development of unstable branches.

This setup has a very important drawback: It fundamentally changes compatibility and can easily break. One of the key things is that in this setup, the overlay repository must monitor the overlayed repository for changes to detect ABI breaks and rebuild ASAP in case this happens. This is done through abi-watcher and it will trigger rebuilds (that must be reviewed) to resolve them, but a human is needed here to guide this process.

Tier 3(a) - hosting an OS with a different ABI

The next tier level is one that takes just the recipes, and compiles them all with different architecture or minimum ABI flags. This could be an Aarch64 build, or an x86_64-v4 port for you know who. In this case the build system should probably do a git mirror and track changes in the official registries and rebuild them verbatim for the new ABI.

In this mode the builder will likely handle most things without issue - this could be a very easy deployment since it mostly just rebuilds. But you might run into architecture or ABI specific issues that need resolving, so an overlay or local patches may still be needed. However, this is the perfect way to port The Ur Project to a new architecture format and pioneer the work to handle multiple hardware architectures.

Tier 3(b) - hosting an independent OS

This is the most daunting but possibly one of the most satisfying ways to spin a whole new distro up from scratch.

You would start by mirroring the latest Buildroot-X repositories or federating them into your own system, so that you have at least the bootstrap completed. After that, you'd want to start building your own low level bootstrap cycle to replace Sandcastle-Base with your own low level OS. Possibly this is where one replaces glibc with musl and you might drop systemd.

The outcome would be an OS that bears no relation to the official Ur Project repos and wouldn't be compatible with it (for the most part). But it would allow someone to build quite a few interesting things, like, a super minimal alpine-style container image (even though the Ur Project container images are already 100MB or less), or a systemd-less offspring, and certainly this would facilitate custom low-end hardware distros for automotive and embedded.

This is all in testing at the moment

The build system code facilitates all these things naturally - the above tiers are natural variations that can be achieved by manipulating the relationships between repositories and registries, and using the floor linkage between repos.

I'll dive into each of these with actual examples of how this looks in reality and show with screenshots or even a video what it takes to get started, setup and rolling.

--sofar (aka Auke)