Same as any FF or chromium fork. The further away from the original you are, the longer security and performance updates will take to trickle down.
biribiri11
joined 8 months ago
Go for FreeBSD: this might require a learning curve, because this is an OS I’ve never used. Are commands that different from debian?
Both of them are, at the very least, unix-like, so the core command set is mostly the same, albeit with sometimes large functional differences.
Simply install debian 12.5 again, the easiest choice.
You are familiar with Debian. This is probably the choice I’d go with.
Kernels are also updated more often than with debian as far as I know.
That’s why Debian has backports.
To be fair, all the FF engineers probably dgaf about a platform where they don’t even have the freedom to use their own browser engine.
Yeah, I was just linking the other one because its usage of temporarily disabling immutability is more apparent. That one also disables immutability temporarily to install nix.
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
It does let you do cool things though, like install nix: https://github.com/dnkmmr69420/nix-installer-scripts/blob/main/installer-scripts/silverblue-nix-installer.sh
It’s a good thing for the owners of the codebase, but often, a bad thing for the community (even if the community contributes to said codebase).
For example, FOSS maintainers sometimes will (want to) relicense to protect their income stream:
https://github.com/CaffeineMC/sodium-fabric/issues/2400
https://github.com/LizardByte/Sunshine/pull/150
While corporations might literally have maintainers sign away their rights so they can take the work from their own community:
https://lwn.net/Articles/937369/ (canonical requires a CLA, though this + the subsequent re-license might have happened anyway)
https://lwn.net/Articles/935592/ (RPM spec files are MIT licensed at the Fedora level. There are likely chnages to RPM files contributed by the community that are now source-restricted in RHEL)
https://networkbuilders.intel.com/docs/networkbuilders/accelerate-snort-performance-with-hyperscan-and-intel-xeon-processors-on-public-clouds-1680176363.pdf (See section 2.2. Previously, this work was BSD)
Mixed bag, really.