What evidence supports your statement, given that it contradicts the overall results of tests conducted in the past year by both DJ Ware and Michael Larabel from Phoronix?
Extremely slow package manager (the most important one)
Fair. Though, IIRC, it's in the same order of magnitude as apt and zypper. But yeah; apk, pacman and xbps are definitely faster by a wide margin. Hopefully, dnf5 will be able to close the gap significantly.
confusing installer
I often hear this. But I'm not sure if I understand. Is it because Anaconda does not walk you (explicitly) through all parts of the installation (at least by default)? And, instead, chooses to give the user an overview (at some point) in which the user is expected to go over each one of them by themselves.
fast deprecation of important technologies and testing of new technologies on its users (making major upgrades risky)
Fair. I think this is the most legitimate concern. Thankfully, over the last two years, I have yet to bang my head against a brick wall for reasons related to this. But I understand why others are more reluctant based on Fedora's (less recent) track record.
Fedora's tendency to default to (potentially) premature software, can definitely be a legit reason to prefer other distros instead.
I'm a "(sweet) summer child" in that I've only been using Fedora for over two years now. Therefore, I haven't experienced the commonly cited 'shifts' that have caused many issues to other users. Regardless, I do (somewhat) understand.
Regarding wget2, I didn't even know that was a thing. Thank you for mentioning it! I have yet to understand why or how Fedora unanimously agreed to push that change.
To this day I notice that there is some skepticism with Btrfs, and I think it is because fedora also pushed it early.
This, however, I can't agree with. And perhaps you're conflating matters. Btrfs was not ready when it was first supported. However, Fedora was not an early adopter. They only defaulted to it in 2020. By contrast, AFAIK openSUSE was the first to default it in 2014. Heck, the next year it was defaulted by SLE as well. By the time Fedora did the same, the severe issues and instabilities were already ironed out. So, I'd attribute the scepticism towards Btrfs as the community's PTSD after many community members lost valuable data early in Btrfs' lifetime.
Yup. That's basically it. AppArmor isn't a slouch either, but SELinux works well and is well-tested on Fedora. It's a pity. I do think that SELinux > AppArmor, so if security is a serious concern of yours, then it's worth considering Bazzite over Nobara. If, however, security is a top priority of yours, you might even consider secureblue. It's not great for gaming though 😅. At some point, hardening clashes with performance gains...
Can I bother you to share any resources on the differences between the atomicity between fedora and open suse?
It's genuinely hard to point towards an exhaustive source on the matter. Perhaps related to the fact that there are continuous advancements and developments going on that make it hard for something to not feel outdated very quickly. But, basically, Fedora Atomic heavily relies on OSTree/libostree for accomplishing its 'immutability'/atomicity. While, on the other hand, openSUSE MicroOS utilizes Btrfs snapshots (primarily) instead. Some implications are:
Fedora Atomic is able to track changes. openSUSE MicroOS currently does not. Though, this feature is planned.
Fedora Atomic is (pretty) reproducible; even if after dozens of transactions one returns back to an earlier state without tracing back. This is possible through the use of layers instead of directly changing the base system. This is something Btrfs snapshots can't do currently. Therefore, there's nothing that indicates that openSUSE MicroOS is able to do the same. Though it can be reproducible in its own way.
Git-like features of OSTree/libostree allows branching (and other git-like features) when managing deployments. Concept of branching is alien for Btrfs Snapshots.
Fedora Atomic basically offers built-in factory reset. For openSUSE MictroOS, this is planned.
Like git, Fedora Atomic can rebase. In practice, this allows it to change drastically through a single reboot without actually reinstalling. This is used to rebase to a new major version (from Fedora 39 to Fedora 40), but even more impressive is to change from Silverblue (GNOME) to Kinoite (KDE Plasma) to Sway to Budgie etc. And all of this, without (most of) the cruft associated with these changes. Heck, you could even rebase to uBlue images or any others you fancy. This concept of rebasing is not found on openSUSE MicroOS.
In theory, Btrfs snapshots should be more flexible in regards to applying changes we may find on traditional distros. But, unfortunately, because Fedora Atomic is further along its development, we don't actually notice this. (The upcoming update related to bootable containers for Fedora Atomic doesn't make it any easier for openSUSE MicrOS to be more flexible anyways.)
The upcoming update related to bootable containers also allows Fedora Atomic to be (relatively) declarative and hence; less state. This concept is also currently absent on openSUSE MicroOS.
Ongoing developments may alter the above list significantly. It's even entirely possible that all features mentioned above will be found on both distros in the upcoming years. However, vision and scope are perhaps decisive when it comes to making any predictions regarding the future. We haven't gone over those yet... Going over those is out of scope for what this comment intends :P .
xD, it's done by typing three times "-" or "*" next to each other with nothing else on the line itself and the lines before and after. So to illustrate it with quotation marks:
"(Empty)"
"---" (or "***")
"(Empty)"
Note that in the above example, i had to leave another empty line in between the lines. So it's not exactly correct. Unfortunately, without a break line, I can't even illustrate it. So, this is done from necessity. Though, it means that technically, the stars below were one "/" removed from becoming a line.
The existence of both is justified for their unique merits. However, I'd argue that the 'immutable'/atomic model makes more sense for a system that's dedicated towards gaming.
For a general daily driver, it all comes down to your specific needs. If Bazzite satisfies those, I'd argue it's the safer pick. However, if (for some reason) Bazzite falls short[1], then go for Nobara instead.
There's a lot more to it than this, but I kept it short for the sake of brevity.
Honestly, there's only very little that Bazzite actually can't do. Though its unique workflow might require some adjusting. Regardless, if you go for Bazzite, ensure to take a proper look at its documentation.
What evidence supports your statement, given that it contradicts the overall results of tests conducted in the past year by both DJ Ware and Michael Larabel from Phoronix?