Linux

Ok so...

I have bazzite on a steam deck.

It works extremely well!

But... say I want to set up... Unity, or Godot, or Bevy, or something that doesn't have a flatpak or appimage.

If I am understanding this right...

The actual base OS is basically a custom version of an immutable/atomic Fedora 41 variant, and I should not fuck with that.

The system update terminal?

I should only run ~~ublue~~ ujust commands in it, not yum, not dnf, not rpm-ostree.

When I want to install something not flatpak or app imagified, things like all the requirements for compiling code ...

For that, I should be using the 'fedora' container... as the current fedora container is actually what allows for that level of tinkering with... or if something only actually lists its sources and dependencies in debian based os's, just set it up in a debian distrobox container... right?

Wrong?

Generally the industry shifted in a direction where it heavily relies on containers for running cloud applications. This solves many problems with traditional server systems where you'd be sticking to certain distro, so certain dependencies are in fixed versions, which brings some limitations. Container is an environment to run process in an isolated way so that it had its own root filesystem, its own view on what resources are available, sort of like it was separate machine, but it’s still running on the same machine natively using the same kernel as the host. You can then have multiple of such containers, all serving its narrow purpose and they all come with the complete fs and whatever distro release they are tested with. Nowadays cloud computing is all about containers and they come from images that are built in OCI format using Dockerfile syntax. After building an image, it is typically pushed into registry where it can be pulled from over network to be utilized across different nodes, which makes it pretty easy to scale and propagate changes in cloud environments.

Now what that means to Bazzite/Universal Blue is that it uses similar tech to deploy the system, though the target here is your local machine. Of course some of the characteristics aren’t relevant in this scenario, but it solves some of the same problem - build predictable and reproducible environment that can be thoroughly tested before publishing. The general idea is similar to how devops build cloud apps: there is CI pipeline that runs the build using giant Dockerfile (or Containerfile, same thing) inside of which they include everything that the system needs (running traditional package manager and act as it was normal Linux distro during the build), which then results as image that’s being pushed to registry. Bazzite users then install updates by pulling new version of the image and 'rebasing' to it. It is called rebasing here, because rpm-ostree lets users add additional layers with more packages on top of that.

EDIT: here’s the Containerfile I've been talking about: https://github.com/ublue-os/bazzite/blob/main/Containerfile Might give you some idea on how this works.

Everyone else seems to have addressed the cloud part, which I was a little skeptical about too. I understood it is a development aspect, not an end user aspect, so I decided to use it. I've been using it as my daily driver for about 6 months and have had no problems.

The atomic part was the biggest hurdle for me, since I wasn't familiar with rpm-ostree, but I'm getting the hang of it. It's had the added benefit of keeping me from breaking things through stupid mistakes since I can just roll back my changes.

The buzz word is not aimed at the regular gaming nerd. It is aimed at gaming nerds who are also developers. Universal blue, the project behind Bazzite, Bluefin, and Aurora, aims to market to developers to use their systems first, on the basis of the tech backend. So then they make the cool FOSS things that the nerd public can use. Cloud native just means that something is engineered and made to make use of the container based devops pipeline.

For example, an atomic immutable OS that is meant to be developed and distributed via the container infrastructure (this is what Universal Blue is). So, instead of working on making an OS the regular way, collecting packages and manually connecting and tidying up absolutely every puzzle piece so it fits together, then pushing it through the installer packaging wizard, etc. This OSs are made by taking an already existing distribution, in this case Fedora atomic distros (but this is by no means mandatory), then customizing some things. Like installing libraries, applications, firmware, kernels and drivers. Then putting it all into a container image, like you would do with a docker or a podman server image. This way, on the user side, they don't need to install the OS, instead they already have the minimal atomic system handling framework and just copy and boot into that OS image. This automates a lot of the efforts required for bundling and distributing an OS, and it makes new spins on existing distros really fast and efficient to make. It also means that users don't need to be tech savvy about stuff like directory hierarchies or package management, and updates, installs, upgrades can all be automated to the point of the user barely even noticing them.

On a similar note, these distros, as development workstations, are usually pre-configured to make use of a container based dev pipeline. Everything is flatpacks and development is handled all via docker, pods, etc. Keeping the system clean from the usual development clutter that sediments over time on a traditional development cycle. As a happy coincidence, this makes the dreaded “works on my machine” issue less prevalent, making support of software a tad easier.