Yes, all their images are purposefully normal fedora atomic images with stuff tacked on top. Some of that stuff comes in just scripts to make management a bit easier, some of it comes in the form of utilities like distrobox. They also come with zfs or proprietary Nvidia drivers or other things so you don’t have to manage them yourself, alongside tailscale and rpmfusion for nonfree stuff (like codecs). Some of them also have some light configurations, some of them have heavier configurations (especially in the case of bazzite).
You can totally do everything ublue does from a stock Fedora atomic image. Ublue just makes it a little more convenient. A sort of “oh, well I was going to do that anyway”.
For the opponents, what is the proposed alternative?
I’d imagine this is the crux of the problem. Banks need some way to determine if someone will pay back their loans, and what better way than to tabulate their history of doing just that? Should banks be willing to take risks in a system with stuff like the 7 year rule?
The US’s Department of Defense is one of Red Hat’s biggest customers. Other than that, the US government theoretically uses Linux quite extensively, going as far as making significant contributions such as SELinux. It was mentioned already, but academia uses Linux a lot, too. I saw lots of machines at SLAC running CentOS 7.
The entire thing. It needs to be completely rewritten in rust, complete with unit tests and Miri in CI, and converted to a high performance microkernel. Everything evolves into a crab /s
Calamares has poor integration with the rest of the ecosystem including their existing tooling. For example, it has no kickstart support, and no support for their immutable installs (afaik, anyway). It was less effort to put their existing cockpit tooling into anaconda and make a whole new web ui than it would be to add support for all their stuff into calamares.
It wouldn’t be too difficult(tm) to fork their kernel and make custom configs of it. Here’s the git repo that holds their rpms and their respective kernel configs, it’s just that nobody has cared enough to create/propose “slimmed down” specialized kernel images: https://src.fedoraproject.org/rpms/kernel/tree/rawhide
You can just clone the repo and point COPR to it, then automatically build custom kernels.
In general, though, Fedora would not want to leave any users behind. Instead, the proposal for hwcaps is currently being drafted: https://pagure.io/fesco/issue/3151
With hwcaps, default installs will be x86_64 v1, but will be upgraded to “optimized” packages if available upon updating. This makes packaging a bit awkward, though. Packagers already need to maintain packages for multiple versions of the distro. In fact, they need to support F38, F39, F40, and rawhide atm. Needing to maintain an extra 3 builds for each package on top of x86, x64, aarch64, ppc64le, and s390x is a bit of a burden, so success might be limited.
I’d really like it if Fedora didn’t discourage packaging static libs, but still discouraged building packages with static libs. It’d be nice to have them for development purposes.
I also wish they made “third party” software a bit easier to access in their installer and distro as a whole. The option to enable Nvidia drivers is buried, and even though flathub is now unrestricted when toggled in the installer, it’s not the first priority when prompted for software to install in gnome software.
A longer support cycle with less releases would also be nice, but would defeat the purpose of the distro. I guess it’d make more sense if CentOS Stream released more frequently and with more packages available in EPEL, similar to Ubuntu.
It’s something we might see with the next EL release cycle. rpm-ostree has treefiles complete with the option for (experimental) lockfiles. There’s already config files for CentOS Stream to build CentOS Stream CoreOS, and those can be adapted for Alma. I think, atm, it’s more of an issue of general interest than technical limitations.
It’d be dangerous if an installed app claimed to be something like sudo or bash. Even if a mechanism was created for flatpak apps to claim a single shell command, there is no centralized authority on all flatpak apps to vet them. If there was for flathub, and each uploaded package was checked, that still leaves every other non-flathub flatpak repo which must implement the same vetting. Because there’s no way to guarantee to do it safely, and because flatpak devs are unwilling to compromise, this is just what we get.
+1 to running whatever is packaged by your distro. For me, Fedora is rarely out of date. If worse comes to worse, you can always volunteer to become a packager and improve the ecosystem for everyone while fixing your own problems.
By the way, all Fedora packages are scanned with ClamAV as part of bodhi tests. Here’s the test matrix where xz 5.6.0 passed the scan, and would have allowed the exploit in for the F40 beta if it wasn’t obsoleted by another build where the vulnerability’s mechanism was disabled because it triggered valgrind failures in other software.
Sure, there’s more sophisticated AV software out there, but at the end of the day, the F40 beta was temporarily saved because of luck, the beta freeze period, and valgrind. The ecosystem as a whole was saved because “Jia Tan” wasn’t aware that making Postgres run slightly slower immediately raises alarm bells.
Fedora has a (disabled) present repo for Nvidia drivers from rpm fusion OOTB. Just open the hamburger in gnome software, go to software repositories and enable “RPM Fusion for Fedora
<version>
- Nonfree - NVIDIA Driver”, and install akmod-nvidia as usual. For atomic desktops, you’ll want to use something like ublue, though, because rpm-ostree doesn’t support akmods afaik
To add onto this, if you really wanted to rebase and don’t want config file clashes, you can use ostree config-diff after rebasing to show what config files changed. You can also simply remove all the files in /etc, and on the next boot, ostree will re-populate it with the contents of /usr/etc in a three way merge. Just be sure to copy, at bare minimum, /etc/shadow, /etc/passwd, and /etc/fstab otherwise it’ll be very awkward when you try to boot again and your boot process fails because it doesn’t automatically mount your disks and you can’t login because you have no users. It’s kinda cool tho, that, at least for this very specific issue, those 3 files might not be needed if/when systemd-homed’s JSON User Records and Discoverable Partitions see wider adoption.
(Note: this is dumb and error prone, and you should absolutely do what the other commenter said)
Hopefully DNF5 gets in for F41, especially since it was supposed to get in as the default for the current release, F39. If anyone’s curious, here’s the vote for deferring:
https://pagure.io/fesco/issue/3039
And they did, with bsdiff, an algorithm invented awhile ago. I wish system package managers carried this/weren’t actively dropping their implementations :(
The KDE packaging team is no longer packaging Xorg, but the GNOME team is. The “re-upstreaming” is a completely different effort with no guarantees on bugs. In addition, the package providing Xorg support in KDE is to be marked obsoleted and will be removed when upgrading. Here’s the actual ruling:
KDE packages which reintroduce support for X11 are allowed in the main Fedora repositories, however they may not be included by default on any release-blocking deliverable (ISO, image, etc.). The KDE SIG should provide a notice before major changes, but is not responsible for ensuring that these packages adapt.
GNOME Xorg still has full support from the team that has always worked on GNOME, unlike Plasma’s Xorg on Fedora 40.
Yes, all their images are purposefully normal fedora atomic images with stuff tacked on top. Some of that stuff comes in just scripts to make management a bit easier, some of it comes in the form of utilities like distrobox. They also come with zfs or proprietary Nvidia drivers or other things so you don’t have to manage them yourself, alongside tailscale and rpmfusion for nonfree stuff (like codecs). Some of them also have some light configurations, some of them have heavier configurations (especially in the case of bazzite).
You can totally do everything ublue does from a stock Fedora atomic image. Ublue just makes it a little more convenient. A sort of “oh, well I was going to do that anyway”.
Here’s the base dockerfile. As you can see, it confirms all of the above.