Universal Blue - Rebasing from Silverblue (with layers)

Really interested in the project, however; can’t help but feel like it’s spending an enormous amount of money and isn’t viable in the long term. What I mean is it is building tons of images and storing them constantly, and it makes me think they’re probably unsustainable as a project?

I only wonder since I’d love to use their images (especially just the base silverblue image they have with codecs/batteries included) but before depending on them for a lot of the core utilities I use, just would like to know if their project is viable long term or how to at least fallback if it ever happens that they do fall off from grace (financially, since I know a lot of their image creation and infrastructure is automated and require minimal maintenance).

1.) I have some custom layering (virtualization, libvirt virtmanager etc) that I would love to keep and is crucial to me, but seems like to rebase to ublue requires me to reset and remove those layers. What can I do to preserve those? If I do not preserve it, I worry that if I moved to ublue and then wanted to rebase back to silverblue, I would have to restart from scratch. How can I make something like this easy? If there is a way to make that easy id LOVE to move to ublue since it sort of fits my flow and seems fun with more sane defaults

(Looks like previously deleted topics on discourse don’t actually get deleted, sorry for making another thread)

1 Like

Welcome! I’ll address the sustainability first.

Up until we went GA this spring the previous few years have been ensuring sustainability. This isn’t as much of a financial issue as it is a maintainer issue. The project was designed from the ground up to be sustainable, we don’t run our own infrastructure on purpose.

Many parts of the project are “thin” on purpose. We’re always cognizant of what we can handle based on the incoming contributions, which is why at some point last year we stopped offering a bunch of images and concentrated on the “core products”, which are bazzite, bluefin, ucore, and aurora. Each of those needed to have enough people to keep it going, and generally speaking it’s keeping the builds green. Bazzite is an exception since it’s following linux gaming and that means it will always be doing aggressive feature development when compared to everything else we make.

Part of this means that we don’t really support the base images as end user OSes, we maintain them since we build everything on them, and if you know how to Linux you should be fine. If you’re rebasing from an initial install to one of them then then doing a reset and layering should be a one time operation. You can probably just copy and paste your layered packages and reapply when you rebase. Some people roll with the base images like that and generally speaking that should be fine. Local Layering means that we just can’t guarantee that upgrades will be bulletproof but if you know how to linux it’s no worse than a traditional linux distro.

In the interest of transparency, from a financial point of view we spend about 60 bucks USD monthly on github for nicer builders ($4 bucks per org member), and about 8 bucks on ISO hosting via cloudflare. Our current donations are almost exactly this amount so running the project doesn’t cost that much. Hope this helps!

12 Likes

If you ever need to spend less, a good idea to keep disk space consumption low would be to only keep the latest build of each version (i.e. gts, stable, latest, …), and replace them by the new one on the next build;
Pushing tags to Git would allow an individual to build a specific version if needed