In seeing how many people are working in uBlue to make and share their own custom images, is this infrastructure that you’re building with uBlue an easier way for someone to make their own “distro” and maintain it compared to the traditional way? My guess is that this is easier, but I wonder if it’s dramatically easier or if I’m comparing apples and oranges. For the people who like making a distro that makes some opinionated takes on something bigger, like what we see with Ubuntu and its derivatives, I wonder if this process is making that task easier.
Ok I’ll try to answer the best I can! Note that most of this is personal opinion and not reflective of the team blah blah, but I think we have enough people using it and we’ve been around long enough to make stronger statements. 
When we started the original team had something like 50+ years of experience building production systems and/or distributions. There’s nothing inherently special about our infrastructure other than doing it for a desktop instead of a Kubernetes cluster.
When Fedora chose to move ostree in this direction it let anyone who has ever made a Dockerfile a distribution developer. That’s an audience of millions and millions of developers. Many of them have thrown away way better code than ublue is today lol. The win isn’t a distro (this is why we keep saying we’re not making a distro), the win is a unified model of server and desktop – a Containerfile sent to podman in a for loop, that’s all we do, heh.
These techniques revolutionized Linux’s domination. Linux had already won server/cloud, this was round 2! The container changed everything, so we were confident going into it that applying these known-successful patterns would work because lots of us watched it happen in the server room with things like Kubernetes. (Here’s a great documentary on that story).
Significantly so. When we started our biggest issue was “that sounds nice, but would it work for an actual desktop?”. So we had to find out if it could be better than doing it the old way, especially since we know that the desktop’s current course isn’t sustainable.
This is also why we don’t call it a distro, we want the ChromeOS/Android-like model but we want a Fedora payload. And since it’s a Containerfile the sky’s the limit on customization. It’s a different consumption model, we can have our cake and eat it too. 
4 Likes
Awesome, I’m glad I was on the right track with my assumptions! This helps a ton for coming up with talking points.
Besides being a platform for a new kind of distro (custom images), I think this can also appeal to:
- People who want to make their opinionated distro with a lower barrier to entry
- People who like to tinker learning to do the tinkering on GitHub rather than on their own system directly
- People who like to share their config - instead of sharing a config file that they use they can just share the custom image itself in whatever form it is
That last point is specifically exciting for me. I’m imaging someone like Matt from the Linux Cast making his owned themed custom image and it being readily available to his subscribers through uBlue. I’m sure some folks would love to run the system of their favorite YouTuber with the protection of rebasing to something else if something goes wrong. It’s a great pitch!
Just new to desktop users, this is mostly all possible because it’s not a new kind of distro.
Yeah we’ve used the term “desktop devops” before to kind of describe it. It’s this but applied to the desktop: Guide To GitOps
Yeah, no need to dig in forums for scripts, we could just fix it in the image! Also one thing we’ve learned is people often tout the custom image thing as like a killer feature. It is, but the real win is sharing. Not as a set of individuals but as a group. Sure I could spend all day tweaking the perfect gaming computer, but why, a handful of people with git, some COPRs, and a well scoped mission can do a way better job.
NuggieOS.
1 Like