I think I get the idea of Fedora Atomic (Silverblue, Kionite, etc.), but I do not get what uBlue is about.
Are those just another “ooh it’s distro X but with preinstalled Y” or are those some soft of overlays on top of Fedora? Can’t they just be some install scripts? Why not just base Fedora Silverblue? Maybe I don’t get the idea, because people seem hyped.
For one thing, image based distros are very convenient. If you tell someone “Just install Bazzite”, they will probably have a nice gaming experience without any tinkering, because everything is already set up for you ootb.
You have to understand the concept first. Fedora Atomic/ image based distros are built from top to bottom, not on the same level. If something changes from “above”, your install will change too, to an 1:1 copy basically.
Problem is, if stock Fedora isn’t allowed to ship/ doesn’t have some things pre-installed, it’s harder to iron out on the user level, e.g. by negatively affecting update times.uBlue is basically a “build script”, that takes the upstream image, modifies it, and redistributes that with the changes included.
In that way, the image from other users is the same as yours, with the same bugs.
This makes it more efficient and user friendly.It also allows devs to make their “own” distro with only their changes included, while offering a very solid base they don’t have to maintain themselves.
deleted by creator
Yes, basically. uBlue doesn’t maintain distros, really, it just repackages Fedora Atomic with some minor changes (including non-free drivers, for instance). That way if you need the software they repackaged into the image (like Nvidia drivers), you don’t have to use overlays, and instead can use uBlue images. In fact, you can actually rebase Fedora Atomic to uBlue and vice versa with a single command. All it does is change where the base images are fetched from, and it’s a potentially easy way to switch between images without having to perform a reinstall (do note that different packages in the base may modify config files that will persist between rebases, though). I haven’t personally tried it, so I don’t know if there’s a likelihood to run into issues, but it’s an interesting option nonetheless.
The more packages you install rpm-ostree, the likelier your system will break. You effectively turn back to a traditional distro that relies on a package manager, so all the things that can go wrong with a package manager are bound to go wrong. The whole point of fedora atomic is to offload the OS composition (so all the complicated packages stuff) higher up the chain. So that not everyone mixes up their own combination of packages installed, but instead you get a (semi-) fixed combination of packages that has been tested to work already before it lands on your computer.
The uBlue images are just different package combinations - but still you’re not the only one rocking the packages combination of bazzite for example, so it is rather unlikely you’ll run into a problem that only you and nobody else has.
This to me is also what sets fedora atomic apart from Suse MicroOS for example. With MicroOS you still have a package manager messing about with the system, and once it makes a mistake that gets buried in your system forever, except if you notice, roll back and fix it. As where with fedora atomic the mechanism how your system layout comes to your computer is similar to how git works (ostree) or images (like docker, which is what ublue ships). So if there’s a mistake in how your system is layed out, the next time you rebase/update you are guaranteed to end up with a the intended system layout.
It’s a good question.
Fedor does not provide an image for every DE/wm. Anyone can create a custom atomic fedora variant with the desired de.
Moreover, you can create your own image and deploy it to 100 machines and all of them will have the exact same os and packages. This may not be useful for you as an end user directly but the dev who is developing the image for you (e.g. fedora in the case of silverblue) knows that you have the exact same comouter as him and if it doesn’t work on your pc, it doesn’t work on his, because it is the same. Hence, better support for you.
There are cases when different hardware will have different results, even if the OS is 1:1.
Just wanted to make that part clear too.
deleted by creator
Graphical environments are just programs just like any other.
They are in Fedora, too. It’s just that installing one DE overtop another can cause config file clashes (ie installing Plasma alongside GNOME means GTK apps will have a minimize button when logged into GNOME)
Starting to write about this, it is actually really complex as rpm-ostree is really powerful. Read the man entry, it tells a lot.
Ostree can use ostree remotes (like git repos) or “ostree native containers” i.e. OCI containers (like Docker, Podman etc. which uBlue uses.
the rpm part meanwhile allows to add any RPM to the image, but it takes way longer. So doing this centrally is more efficient.
This has tons of benefits like adding packages that Fedora cannot legally add, or doing opinionated changes, or unstable stuff like drivers.
Instead of having every user apply them, this does them once and by that increases reproducibility.
Yes, all their images are purposefully normal fedora atomic images with stuff tacked on top. Some of that stuff comes in just scripts to make management a bit easier, some of it comes in the form of utilities like distrobox. They also come with zfs or proprietary Nvidia drivers or other things so you don’t have to manage them yourself, alongside tailscale and rpmfusion for nonfree stuff (like codecs). Some of them also have some light configurations, some of them have heavier configurations (especially in the case of bazzite).
You can totally do everything ublue does from a stock Fedora atomic image. Ublue just makes it a little more convenient. A sort of “oh, well I was going to do that anyway”.
Here’s the base dockerfile. As you can see, it confirms all of the above.
