Another thing not mentioned yet is maintenance overhead. These distros operate around the clock, all over the world, with talent from the likes of RH and co. There are far fewer people (who run your mirrors) who know how to maintain a torrent tracker (or similar), and on top of that, I haven’t really seen any good BitTorrent caching methods. Support would need to be added to your package manager of choice.
It also comes down to most client having asymmetric bandwidth, and that most users do not have every package installed and therefore can only distribute a very small amount of the total distro. Those users probably don’t want to be constantly uploading, either. I also can’t imagine torrents are too fun to work with when it comes to distributing constantly changing package manager metadata, too.
Oh it’s definitely over-complicated, and contrary to what others say here, Silverblue can definitely have some very difficult to troubleshoot problems (especially when using things outside the direct Fedora ecosystem), which are greatly worsened by rpm-ostree taking 15 years to do anything despite sharing code with the supposedly lighting-quick dnf5. For servers, rpm-ostree is great (it’s in all of RH k8s offerings, see RHCOS), but on desktops, there’s definitely a good reason why RH has to apparent offering and Fedora calls theirs “emerging”. Still miles better than having an unbootable system after updating.
Yeah, third-party Linux VPN clients are pretty screwed on silverblue, and probably always will be. Especially since when installed in a container, they require being ran in a rootful container with selinux labeling disabled to enable direct access to /dev/net/tun, and as you’ve quickly found out, most of those weird bash based installers haven’t adapted. It’s best to use generic VPN configs through your DE atm.
It’s immutable (aka. atomic), which means the system files cannot be changed, even by root.
This is a definite “well um actually” moment, but technically immutability can be switched off at any time with chattr, and “true” immutability will not be achieved until full image signing is commonplace. You can see the ideas laid out here: https://github.com/ostreedev/ostree/issues/2867
But how does this solve the problem of the config files of the various DEs (GTK rc files or other theme stuff) messing with each other in the home directory?
but they don’t have the means to maintain that many distros “properly”
That’s why they’re not separate distros from Fedora (as in, they don’t even host their own RPM repos nor maintain their own set of Fedora packages like Manjaro vs Arch) and purposefully so. It’s just stock Fedora with a few configs, third party repos/packages, and some scripts preinstalled. The entire thing runs on GH actions.
Afaik yes, the token is keyed to a specific source in the case of verifying through a website, but from what I can tell, that doesn’t stop someone else from creating a separate malicious website (or git repo) that looks similar but contains malware, and publishing that as a verified app with a similar name as the real app to flathub (so there would be multiple versions of an app, with only 1 being the “real” one on flathub).
If a new user installs malware from flathub while trying out mint for the first time, they’ll probably blame mint instead of flathub. Nobody will say “damn, I should have listened to that warning” while their “discrod” app rm -rf’s their entire PC away, they’ll instead claim Linux is crap and go somewhere else. Doing this helps keep mint safe, and definitely encourages unverified FOSS apps to hurry up and get verified.
This is a great start, but tbh, I’m not fully sold on “verified” flathub apps. Verification requires a token to be placed into a source repo or a website, but there appears to be nothing on actually verifying that the source/site are the original creators. So, for example, if someone packaged a malicious version of librefox and established it under io.github.librewolf-community instead of the canonical io.gitlab.librewolf-community, I’m concerned it’ll still show as verified (though quickly removed). The process can be read about here.
The cheapest you’ll find that is still pretty good for HDDs is serverpartdeals. They have recertified Seagate Exos X22 20TB drives with 2 year warranties for $215. They also offer new drives with the full 5 years, ofc. Exos can be a little loud, as with other enterprise drives. You’ll still need a way to read from it in case you don’t have a spare drive bay, too.
ostree is based on OCI images, the basis for containers and the like. “Rebasing” just refers to swapping out the OCI image containing your root with another.
Not everything should be flatpak’d. In your case, xpipe (and in the future, waypipe) should always be installed in a docker container containing your normal “mutable” OS. It’s why Fedora is evaluating Ptyxis: when you open a terminal, instead of defaulting to your immutable root, it can be set up to go to a container which has your home mounted but a traditional, mounted root.
I think a true arch linux experience can be done with immutable distros by modeling themselves after something like a nixos config or an rpm-ostree treefile. Like, during bootstrapping, you’d feed in a config file which would install everything into a future RO root. Would definitely be a lot of work, though, since pacman does (and probably will never) have the capability to manage multiple read-only roots.
You don’t have to install everything as a flatpak if you don’t want to. You can totally install most things in a rootless distrobox container, then use distrobox export (if you’re using distrobox instead of toolbx) to get a nice desktop entry. It’s how I run VSCode and Quartus Prime, for example.
Generally speaking, though, pacman is really basic, and the majority of the atomic/immutable magic happens in the package manager. That’s why only existing, complex package managers such as rpm-ostree (which shares a code base with DNF) have full support for it.
Another thing not mentioned yet is maintenance overhead. These distros operate around the clock, all over the world, with talent from the likes of RH and co. There are far fewer people (who run your mirrors) who know how to maintain a torrent tracker (or similar), and on top of that, I haven’t really seen any good BitTorrent caching methods. Support would need to be added to your package manager of choice.
It also comes down to most client having asymmetric bandwidth, and that most users do not have every package installed and therefore can only distribute a very small amount of the total distro. Those users probably don’t want to be constantly uploading, either. I also can’t imagine torrents are too fun to work with when it comes to distributing constantly changing package manager metadata, too.