It's a project. Not a product.

What I'm building isn't something that's shiny. The output, for now, is merely a validation of what builds it. So, I'm not going to be focused on making a super shiny Linux Distro that will knock your socks off. Yet. I might be one day. But, I might never. And I'll explain why.

Making a really good Linux Distro isn't just "pick the right versions" or "pick the right -fomg-optimize CFLAGS". It's doing so, every day, for every build. But it's also much more than that. It's picking the right licenses to include, and which ones to reject. For every source tarball that the distro consumes. You can't call yourself a "fully OSS distro" and include linux-firmware. So you may need to declare some nuance on what licenses and what IP you will allow in your distro, and what you will not.

But you can't even fulfill that promise unless you actually check every single ingested software component and make sure that it adheres to your licensing standards. So how do you know?

In the same light, you have to do the same for vulnerabilities if you want to say anything about risk. If you do not do CVE scans of your own software, the only promise you can make is that the risk is unknown. That's worse than being able to point out the exact vulnerabilities that you expose your users to. By a long shot.

The difference between a hobby distro and a serious one is that a serious one can make statements about risk, because it's doing the work to properly express the risk to the consumers of it.

So first and foremost: I'm making a "builder" sort of thing that builds a Linux Distro. The focus is entirely to make that thing first class.

I'm also just flat out making a non-choice: The builder, and the things it can make, must be suitable for all consumers. Not just a subsection - no, all of it.

The last choice is probably a much bigger take: I want the build system to be easy to work with for developers that want to alter a tiny part, or almost every part of the distro. And allow sharing and exchanging of it.

First Class

To me a first class build system is one that isn't obstructionist in how people may want to use it. But it also means we have to make some hard choices up front. I can't build a first class build system on the ecosystems that are built up around a few popular programming languages, because they are fundamentally not ready for First Class Usage. So there isn't going to be any npm or python stuff. Hard stop. I can't make a serious build system and at the same time hook into an ecosystem that is being attacked, and overrun, by bad actors. Sorry.

Everything is written in Rust. Both backend and the update client. Code between them is shared. The build system is self-hosting. Bootstrapping is an integral part of the process.

Calling all customers

The build system is consumer agnostic. No assumptions are made as to how the output is used. Composition is a layer on top of the build system. Compositions such as OCI containers should be as easy to create from the build system output as normal (FHS) disk installs, bootable (live) images, cloud images, and possibly weirder things like swupd did. All those things are composition layer.

Would you like an immutable rootfs? You got it. You don't? You got it, too.

The package install tool can install, remove, upgrade packages. It also can make packages. It can verify them. It can rebuild them (and prove reproducible builds). It can build all compositions. Either new FHS roots, OCI containers, images for VMs or live USB hardware.

Community

The build system I envision throws nothing in the way of developers trying to improve things. Want to build a quick package locally, and install it on a system or two? You should be able to, without doing any weird steps. Want to run a shadow repo with 2-3 packages that have some small modifications? You should be able to set up a build system and publish your own repo. Want to maintain a custom repository that everyone in the community can subscribe to, so you can provide a few dozen custom packages? Or you're totally nuts and want to make a special "rebuild" of the entire base OS but recompile everything with the "-fomg-optimize-harder"? I'm not going to stop you - do it!

Repositories are using TUF (The Update Framework) to provide validated content. Repos can be added and removed easily. You can make your own deployed build system shadow official ones, and even rebuild repositories with different compilation features or compiler flags. Sharing repositories is simple and straightforward.

The take away

My vision is of a future where it's less about "rpm-vs-deb" but more about "Mark-with-Brian". There are so many capable and talented developers that could do magnificent things for people who use Linux, but they're scattered and a lot of their work will never intersect because fundamentally, most Linux distros will never collaborate directly. It's really up to the users to start dictating that they don't want a half-good distro. Darned be the other good half, because you'll just have to find it yourself.

I'm hard stopping and saying that the best thing I can see is that people make their own cool distros and share all that stuff. Make weird wacko stuff distros. Make super secure ones. Make super fast ones. Make super small ones. Make super hardware-platform ones (for whatever platform you think is super). We need to stop saying that if you want to work on Aarch64 that you should pick a distro that purely targets that. No! You shouldn't have to pick. Let's pick the same language that we can use to relay knowledge (recipes, repos) and make a system where we can easily exchange this knowledge between Aarch64 and x86_64. So a ground rule should be that sharing knowledge in a reusable way should be priority number one. The shared thing can't also be littered with non-portable manipulations either. This has consequences for what packages will look like. What goes into it is the sharable thing. How you build it isn't. If you modify your build to do ia32 builds on top of x86_64, that's a local build change. Not something you share as part of your "package sharing". A new libcap-ng version? That's shareable.

But it has to be serious. I can't see myself build a distro that doesn't do a serious job of security, licensing, verifiable and reproducible builds. If I'm not going to be serious about this, I'm not pushing the envelope. And serious means something specific: It should be serious enough to use with strong security requirements. CVE scanning just makes sense. Not after the fact - at ingest time. Same for licenses. Builds should be reproducible. Always. Not just when someone really tries in a pristine home lab. Always. Everywhere. Malware scan? Yes. Proper GPL compliant repositories? 100% yes. by default.

If it's not clear what my intent is, then I apologize. I'm somewhat terrible at writing coherent pieces that try to convey the thing I'm trying to say. It is what it is - I'll rehash bits in more detail later as it becomes available and I feel that it's a good time to delve a little deeper in to what I've built that makes these promises possible.

--sofar (aka Auke)