KubeCon US 2024 Project Report
(I have set this post as a wiki, I am tired and need help linking to stuff, thanks!)
Now that bootc is going into the CNCF that means we’re now a cloud native community. Welcome everyone, I’ve been here since 2015 or so, if you’re new to this way of Linuxing then don’t worry. I’m going to go into detail why this is a monumental change for Universal Blue.
If you’ve been as excited as I am about getting this thing done and as invisible as possible … we just gained a few million new developer friends. This is crucial as the Linux desktop has been underserved, and that’s a bunch of great people who know how to computer.
This is one of the reasons we say that why Universal Blue is not a distribution, we’re here to solve that exact problem, remove it from our lives. We want to concentrate on the workload, and make the OS invisible. 
What is this report?
One of the benefits of being in cloud native is that center of gravity pulses hard around the KubeCon+KCCNs around the world. This year we’ve had Paris, Salt Lake City, and Hong Kong. And the first one in India is coming up! That means that our project now has a cadence that matches the rest of cloud native. We align with the industry naturally.
It also means that we’ll try to make updates around that time. Since this was a monumental one for us I thought I’d write a lengthy report. Please come ready with questions, no one’s going to yell at you, the idea is to get a goodm, written down status of where we stand in our quest.
Events
When I worked on Ubuntu at Canonical the pinnacle event was the Ubuntu Developer Summit. It’s where I met people whom I would become friends with for over 20 years now, many of whom do really awesome stuff in this industry. Community thrives when we’re together. Here’s the latest Ubuntu Summit vids.
By being in cloud native we can use those events as our first developer summits. We automatically have a worldwide network of places where other cloud native developers meet.
There were alot of Frameworks at KubeCon, and helm did a release on a Bluefin laptop! There’s definitely a growing set of people who love theirs, and they all run all sorts of Linuxes, it’s a diverse community. Just getting those enthusiasts together will help accelerate adoption.
The Curse of Enterprise
I know many of you have concerns about how your layered apps will live in the bootc world, so let me tldr it. But before that let me state this:
We’re not going to put you in a position where you are doomed. We will always support local layering. But we will default an image intended to run without local packages as the intended experience.
You may need to manually set a config in a file. But you do it once and move on with it, you just don’t mind the occasional bit of maintenance.
And also, I have no choice, many of you know I hate local layering with the fury of 1,000 suns. But in the real world, there’s tons of things in production that will need to be supported. That bodes well for Red Hat’s investment in the tech. That’s the classic open source model (there are others), but this is a good example that we should point out.
Enterprises pay companies for this kind of stuff. If there’s anything I learned from my time at VMware, enterprise software is so awful that the bootc team will be chasing after every edge case at some point haha.
What you’ll actually see
But I want Bluefin to be the one with the least amount of compromises, so we’ll strive for that pure image mode, I ain’t got time for this. Also we’re talking about the layer we’re at, X11 is gone, that’s got nothing to do with us, sorry folks. But I can see people are confused so …
As far as user experience goes, rpm-ostree is being split into two commands, bootc, and dnf. That’s it. 
As a user you will see this (note that you need to use sudo with bootc currently but let’s show what it will look like):
bootc
bootc manages the image stuff, that’s it:
rpm-ostree status→bootc statusrpm-ostree update→bootc updaterpm-ostree rebase horrible-url→bootc switch ghcr.io/ublue-os/bluefin:stablerpm-ostree rollback→bootc rollback
If you use ujust update or ujust rebase-helper you’ll just see nicer progress bars.
dnf
dnf will do your local package stuff:
rpm-ostree install vpn.rpm→dnf install vpn.rpm- and then whatever dnf thing for third party repos, etc, it’s a dnf plugin. So whatever you have now
But also this doesn’t exist yet! So you’ll continue to use rpm-ostree for this. This will probably be sorted next release of Fedora but who knows.
Setting Expectations
I get the feeling that many of you think that dnf locally will give you the traditional linux experience but with the reliability of a bootc image.
You’re probably not going to get that. Manually maintaining individual packages always adds entropy we can’t account for. If you turn on local layering, then you’re saddled with the Curse of the Enterprise. I realize many of you will wear this as a badge of honor. But hey, I ain’t going back to that life haha. (Also it’s no big deal)
dnf5 will make a huge difference for how we build our images, we’ll be able to just cut out most of this stuff. We can replace all that rpm-ostree gunk with clean dnf installs existing Fedora users will be immediately able to recognize. Death to technical debt!
I hope that clears things up. Please ask questions.
What’s up with zstd:chunked?
Our last main boss is download efficiency. This is a high priority upstream, probably around this spring, so one more cycle.
sysext
And then we have the systexts. The Final Shape is here. @tulilirockz @gerblesh and zeglius have been working on sysexts, and if one of them could reply with some of the cool videos you’ve been showing off in the discord that would be awesome.
And since we’re a cloud native project, we share a common friend in Flatcar Linux (my preferred server distro, btw). They are heavily investing in sysexts for their distro, and we intend to utilize it as another powerful tool to get what we want.
I was able to introduce the podman team to the Flatcar team, and there’s tons of places where we can get big wins, like with composefs, and Fedora’s Timothee Ravier also has been doing a ton of work in that area. Seems like everyone wants this because it helps get rid of that local layer gunk. This is why we hate the term “immutable distro”, that makes no sense, people have been doing read only /usr since the UNIX days. It’s not about that, it’s about aligning ourselves with the model that can help make the linux desktop better, by a significant margin!
So wtf is cloud native?
We’ve gotten dunked on for the term “cloud native” because many of you had never heard of that term. But as I said in my video, this community moves quickly, and we’re now a part of it. Of course parts of the disk are immutable, it’s basic reliability. I expect my car to come with a seatbelt, but we’d upset people if we called traditional distros “Unreliable” or “Legacy”. In cloud native we call that a “pet”. You want one, you take care of it, I have a real beagle named Oscar which is better in every possible way:
We’ve taken the Linux desktop into an entirely new model, that’s why we don’t call it a distro. Distros just kind of fade into the background. People call this “distroless”. But I think most of you are realizing that making the linux desktop the same as the rest of linux is really nice!
This is the simplest definition of cloud native: One common way to linux, based around container technology. Server on any cloud provider, bare metal, a desktop, an HTPC, a handheld, and your gaming rig. It’s all the same thing, Linux.
I can’t even begin write that community aspects, so we’ll have to figure that out together. That’s the true win, the cloud native community itself is huge for us. I cannot WAIT to introduce you to them.
If I missed anything please ask a question, it will be useful to come back to this at KubeCon+KCCN London and see where we were at this point in the project’s life.
You can help by donating to the open source projects you love! Here’s our starter list.
