Silverblue vs uBlue
Silverblue vs uBlue
I’m considering trying out an immutable distro after using Tumbleweed for the last 6 years.
The two major options for me seem to be Fedora Kinoite or uBlue Aurora-dx
My understanding is that universal-blue is a downstream of Fedora Atomic
So, the points in favor of Kinoite is sticking closer to upstream, however it seems like I would need to layer quite a few packages. My understanding is that this is discouraged in an rpm-ostree setup, particularly due to update time and possible mismatches with RPMFusion
uBlue Aurora-dx seems to include a lot of the additional support I’d need - ROCm, distrobox, virt-manager, libratbag, media codecs, etc. however I’m unclear how mature the project is and whether it will be updated in a timely manner long term
I’m curious what the community thinks between the two as a viable option
I’m unclear how mature the project is and whether it will be updated in a timely manner long term
ublue and bluefin co-maintainer here, we've been around for a while now (3rd birthday coming up!) and have been around in a more unofficial capacity for longer.
Bluefin is feature complete and is in maintenance mode, it's just going to get updated in perpetuity to 41, 42, etc. We invested in automation first so most of the maintenance is automatic and it doesn't take much for our team to do it. Right now most of our major ticket items are waiting for things to finish landing in upstream Fedora, most of which are targetted towards F41. A good portion of the team have been around in OSS for a long time and a bunch of us work in the industry and depend on Bluefin for our jobs, so much so that we have a great working relationship with Framework, so we're supporting those laptops as a community option for them.
Aurora is relatively new, coming in just as Plasma 6 landed in fedora. Most reports with issues we get for it are things like it being a new major release, wayland/nvidia issues, etc.
Hopefully that answers some of your questions, if you have more feel free to ask!
Hey! Thanks!
I’ve installed Aurora to my new drive based off the comments here so far, and it’s been pretty smooth bringing my configs over :)
Immutable is new to me, so I’m wondering how you manage host daemons and cli applications, such as mpd for music and password-store for password management
Is the best practice to keep one Fedora <current release> distrobox with them?
Also, are there any issues with upgrading a distrobox to a new major release over time?
So far my mindset has been make sure I don’t layer anything, but maybe some things like mpd do make sense to layer?
I also see
brewas another option. Perhaps that’s the preferred way for those types of tools? However, it seems like the system upgrade script updates distrobox and not brew?Sorry for the rambling question - just trying to understand best practices with an immutable distro 😅
Immutable is new to me,
It's best to ignore the whole "immutable" thing as most of the discussion around that is conflating a bunch of other concepts and it just leads to confusion. When it comes to things like host daemons, these systems are designed to deploy daemons the same way as cloud servers, so for mpd it'd be running the service as a container. A quick search of /r/selfhosted shows some options, but I'm on the road so don't have time to recommend a specific image, but generally speaking anything server related is done via containers.
I use the 1password firefox plugin for my password management. There still isn't a flatpak portal that allows flatpaked password managers to talk to flatpaked browsers, that can be a pain point to some people depending on your use case.
As far as how you manage your distroboxes, that's up to you. We differ from fedora here where they default to "just use toolbox" for everything, whereas we default to "just use brew" for everything. I keep an ubuntu and fedora distrobox in case I need to check something from those distros, and arch is a popular choice. If you're happy with your existing distro but want the reliability of atomic updates then this is a good option. For most new users I recommend not caring about distrobox, most of that stuff is for developers or people that know how to linux already and know exactly what they want.
Also, are there any issues with upgrading a distrobox to a new major release over time?
Containers are designed to be ephemeral, so that you can recreate them on the spot when something goes bad. So I never upgrade boxes, I recreate on the spot using my custom configs. That way I have the same experience on all my machines and when something breaks I don't lose any time setting things up again. Distrobox assemble is awesome for this: https://github.com/89luca89/distrobox/blob/main/docs/usage/distrobox-assemble.md
So far my mindset has been make sure I don’t layer anything, but maybe some things like mpd do make sense to layer?
I don't really layer anything, I use everything via containers or brew. Generally speaking some people might have a few things they have no choice to layer - a good example is a VPN provider that doesn't provide a wireguard config for network manager and instead you have to layer some 3rd party app. But it's also not the end of the world, updates will take longer but 99% of the time I'm asleep when that happens or it happens in the background and is transparent to me. The more you layer the more maintenance you'll have to do when you do upgrades, so if you end up adding a bunch of 3rd party repos it'll behave the same way as a traditional distro and likely need to be babysat.
The system will update all your boxes and your brew packages as well, so whichever one you use you'll never be out of date. Hope this helps!
One thing you can check out is quadlet, which is podman containers running as systemd services. You just basically put the .container files in the right directory and sytemd will pick them up and run them for you. I have syncthing and zerotier running like this.
I don't really think you need to layer anything unless you're doing virtualization, but I haven't really looked into that yet.
Short answer: use uBlue.
Longer answer:
Even though uBlue is technically "downstream", it also isn't. uBlue builds its' packages automatically, and you are never more than a few hours (1 day max for huge updates) away from upstream. It feels more like "sidestream" (if that word exists?).
One reason it exists is, as you already said, because layering takes quite some time.
At least I personally don't wanna use stock Fedora (Atomic) and would install some codecs, tweaks and such anyway, and uBlue does that already for me.
Update time doesn't matter anymore for me, because uBlue updates itself automatically in the background. Silverblue doesn't do that afaik.Depending on how "custom" your system should be, you can take a look at the uBlue builder, where you can create your own image based on already existing ones if you like.
The cool thing about Fedora Atomic is, that you don't have to stick to anything. If you don't like something anymore, you can rebase in less than two minutes without any hassle and jump from image to image, no matter if it's an official one (e.g. Silverblue) or some obscure uBlue image.
I’ve got Silverblue installed on my laptop, could I then rebase to uBlue and get the benefits of using uBlue over Silverblue?
Yep, you would just run a couple of commands in a terminal which would reset your layered apps and rebase to a ublue build of your choosing:
I can't say specifics about aurora-dx. Aurora got added to the official bluefin repo, I don't think it'll go away any time soon. https://github.com/NiHaiden/aurora if it becomes obsolete, just rebase to another atomic variant and layer your packages. It's hassle free and only one reboot (and one pin for backup) away.
You shouldn't layer any random package. You shiuld layer packages that you need and are useful for the system. Even if those are 100 packages. If you need them, you need them. Some packages can be installed via distrobox but you know that already, I guess.
How does bluefin fit in the dependency chain here - is this just the repository that builds official uBlue images?
Part of my confusion is trying to understand how these projects are related to each other
Edit - oh, I guess bluefin is the Gnome variant
If I understand it correctly, Bluefin was just the first downstream uBlue variant like Aurora that had the various goodies built into the images. Bluefin effectively being the Gnome version of Aurora. I think it was simpler to tie the Aurora builds into the existing Bluefin pipeline for generating images and packages.
I highly recommend Aurora (dx) if it sounds like it fits the bill for what you're looking for. After starting out with Kinoite and rebasing on Aurora-dx, the latter just feels like Kinoite with all of the desired additional packages already baked in, and some great additional shell scripts for convenience.
Rebasing sounded intimidating but it was literally just a simple shell command and a reboot. One additional command if you want to hang onto the previous image the way you had it. Rpm-ostree is pretty magical.
I'm using Aurora-DX and it has such great tooling for what I wanted from Silverblue for my day-to-day work. Never had any issues, and having easy VM's and Distroboxes has been great for different projects. As primarily python dev, it's awesome not having to faff with dependencies.
uBlue f**ed up their site a while ago, they had a huge list of images.
You can just use their
kinoite-mainimage, which is what I do. It has Distrobox, homebrew and a few more things.Use
kinoite-main:latestand you will even get automatic version upgrades without a problem.You can still rebase, you know? I tried Aurora and it was not for me, back on normal Kinoite.
But for sure it is a bit annoying to layer. But no issue. I layer 20 packages or so, 300 with dependencies, and all is fine.
I dont know about ROCM, their hardware enablement to my knowledge is just about NVIDIA, Asus and other proprietary stuff.
The developer image, dx, includes rocm-hip and rocm-opencl:
https://github.com/ublue-os/bluefin/blob/main/packages.json
The packages under “dx” are the main reason I’m considering it over stock Fedora
If you're already on tumbleweed you should check out MicroOS
@ozymandias117 We talked about Bluefin in one of our last episodes (German). For now we can recommend #microOS from @sysrich https://youtu.be/lKYLF1tA4Ik
When I check out the ISO for microOS, it lists microOS Kalpa as “alpha”
Is it ready to be used as a primary install?
So, the points in favor of Kinoite is sticking closer to upstream, however it seems like I would need to layer quite a few packages. My understanding is that this is discouraged in an rpm-ostree setup, particularly due to update time and possible mismatches with RPMFusion
It's not only discouraged but often times it's system breaking. I used Kinoite for a year before I just became too frustrated and gave up. The first thing I learned though was to stay away from package layering because it tended to break things more often than not. Basically if you can't find or build a flatpak and you don't want to use toolbox all the time, just stick with workstation. Immutable is great when deploying to multiple servers or locked-down corporate workstations, but it makes no sense for your personal setup especially if you're already familiar with Linux.
I am using Kinoite for quite a while now and not once did layering break anything. The only thing I notice is that the mesa drivers from rpmfusion occasionally go out of sync with the fedora repos and I have to wait a few days for an update. I think ublue would fix that but I am not bothered enough by that to make the switch. What where you trying to achieve that you managed to break Kinoite?
I am using Kinoite for quite a while now and not once did layering break anything.
That's great for you. Not everyone may use their distro in the same way as you.
https://discussion.fedoraproject.org/t/is-silverblue-rpm-ostree-intended-to-be-used-with-layered-packages/26162/2 https://discussion.fedoraproject.org/t/fedora-silverblue-36-will-not-succesfully-deploy-after-layering-packages/77502/3 https://gitlab.gnome.org/GNOME/gnome-software/-/issues/991 https://github.com/coreos/rpm-ostree/issues/4280
Not to mention the whole Firefox debacle of including an outdated borked version based with the system install instead of just moving to Flatpak install of most recent stable release. There's a very valid reason why package layering is discouraged by atomic maintainers and why toolbox is there by default as part of OS. And don't even get me started on DKMS and driver installation.