Because if it's open source you can't make money from it or have multiple tiers.

I use Bazzite for development bc it works like a Mac with sane defaults and a just works approach:

- IDEs are no problem. Editors will "just work" for anything you type into the app store - Bazzite handles the special cases for you and installs them through brew taps or Flatpaks.

- For development it's basically just like a Mac where you also can't install system-level packages: Node, Python etc work through brew / nvm / uv same as on Mac. Development that involves containers will be unchanged from a Mac. For compilers specifically, same as on Mac: Install it through brew, or if you need a Debian or Fedora base you do `distrobox create` and you can apt-install in a transparent podman container.

Yes of course, but you need to do it via the package manager. You can't "sudo make install". If you build your own software and want to install it system wide, you need to flatpack/brew it or run it in a docker container.

(obviously you can modify the filesystem if you really really really want to).

Bazzite is gaming oriented version of Fedora CoreOs. There are many different versions. I am running bluefin.

I've tried a lot of desktop linux distros, and to be honest, immutable linux feels like the future. Anything you do can simply be rolled back. Break something? Just roll it back.

And if you run something like Bazzite, but want to try out Bluefin-Dx which is developer oriented, then you can rebase your existing installation. If you don't like it, just revert back to Bazzite with a single command.

However, it's desktop oriented. Don't run CoreOs on a server.

The immutable fs thing isn't just Bazzite; it's a fork of Fedora Silverblue[1] (it sounds like AI wrote this, but it didn't! I fear I am becoming the AI...)

Immutable filesystem-based operating systems became fairly widely used as the "base" system for Kubernetes nodes. Because on a container-focused system, you never need to touch the rootfs.

This started as a project called CoreOS[2], which was eventually acquired by Red Hat for its OpenShift (Red Hat Kubernetes) platform.

On servers, immutable rootfs makes a lot of sense. Silverblue (et. al.) was an attempt to see if that concept translated to Desktop systems well. Reviews are mixed. Some people swear it's the best thing since bread. Other people claim it's worse than having dental work done.

I'm personally somewhere in the middle. I think the concept is good, but if you want to do anything to change the core system, like installing custom video drivers, it quickly becomes a pain. I like to equate it to the "n00b"-OS. People who "just want the damn computer to work", immutable is great, because neither they nor an application can do anything to really break the system. On the other hand, it really limits (without complex work-arounds that other systems don't need) what "power users" can do.

In "the perfect immutable OS world", you would never directly install any application; instead, you run everything in a container (i.e., Flatpak). So you have layers of protection: an immutable root and a container-based permission system; the worst* thing an application could do is blow up your home directory. But if you manage permissions correctly, the most damaging thing would be an application blowing up only itself.

[1] https://fedoraproject.org/atomic-desktops/silverblue/

[2] https://www.redhat.com/en/technologies/cloud-computing/opens...

Bazzite mostly suggests installing stuff via Flatpak or Homebrew. (No, really, brew on Linux lol). You can also layer in things with rpm-ostree but it's clunky. I think the immutable OS makes sense for a consumer but not for a developer.

So I'm using Nobara instead. It's a different Fedora-for-gaming but has most of the same improvements. It is a traditional system, not immutable. CachyOS is also very popular and that gets you an Arch-for-gaming. Just yesterday I learned of PikaOS, a Debian-for-gaming.

The main thing all these gaming-customized systems are doing is getting graphics drivers and proprietary codecs installed for you easily.

The immutable linux is pretty great if you find one that fits you type of dev work. The prebuilt images are powered by a config (so you could build your own) but it's great that you can just follow someones good "config". Switching/updates are suddenly easy.

For example i just need docker for webdev and there is bazzite-dx basically bazzite with docker and few things added. Works pretty great, sometimes when something goes bad i rollback the image and wait for future version.

You can modify the fs using rpm-ostree. It will overlay your changes on top of the immutable image. The recommended way is to create toolbox/distrobox which uses containers to isolate stuff.

Yes, rpm-ostree solves that

https://docs.bazzite.gg/Installing_and_Managing_Software/rpm...

https://coreos.github.io/rpm-ostree/

In addition to the other comment mentioning rpm-ostree, brew is installed on bazzite by default and works about as well as it does on macOS.

You can also use fedora toolboxes to create containers mounted on your home folder, though it is clunky.

It competes with steamos. There are other gaming distros that work like normal distros.

Oh sure, but if I just need to troubleshoot why Minecraft-launcher (a first party app) won't launch ... it didn't give any output; it didn't even exist apparently, but only because MS were hiding it, had to crack out Process Explorer just to get something to troubleshoot on ... then it turns out the "turnkey" app from their first-party app store, loading the first-party app, on the same company's OS just failed with no indications to the user at all, not even a "this app crashed". Solution was to cut out as much of MS as possible ... it's just infuriating when it doesn't work, which seems to be all-the-time.

More power to Bazzite and Valve, the sooner games app run in other OS the better.

Sure, but isn't that the point? Needing to be a celebrity to fix something?

Afaik reflex is a bit different - it times the input to frame latency in your game, and tries to start the gameloop as late as possible in the frame so that your input gets sampled at the latest possible time and the frame still makes it to the vsync period, this isn't really a compositor tech.