Which btw also include the Fedora Flathub repository.
We no longer touch the repos as Fedora is now in agreement with using Flathub.
You start to sound like a GrapheneOS dev. It makes no sense to prevent users from reinstalling removed packages.
It’s for user security. I have no interest in debating this decision, my reasons are outlined.
Distrobox updates automatically on Bluefin and Bazzite.
In this case we disagree with Fedora, Atomic Fedora should not have Firefox in image. It does not matter to us what they do, we explicitly remove it.
If you like the way Fedora builds their Firefox RPM, that’s all the more reason for you to use a fedora distrobox.
I shutdown my laptop every day and update every day. That is fine for me.
Irrelevant. Not everybody does. Some people pin an old image due to a bug and sit on a far older image. If you had it your way, they’d be using a week or month old build of Firefox – that’s unacceptable.
Removing Firefox prevents people from reinstalling it
Good. I can promise you if that gets fixed and I have a way to continue to prevent it, I will.
Flatpak Firefox does not have the ability to create user namespaces for tab process isolation. This is due to all Flatpaks using the same badness-enumerating seccomp filter, there is no additional hardening possible and they still block userns creation.
This is an issue for Mozilla. They are happy enough with the state of the Flatpak to not only verify it, but list it on their website. Unless you’ve got a CVE for the Flatpak version of Firefox I don’t see any point in even engaging with this argument.
We remove Firefox because having it on the image is a security hazard. You want your browser to update more often than your operating system.
We prefer the flatpak, but if for some reason you need the RPM I would suggest installing it with distrobox.
We build twice a week, that’s not frequent enough for a web browser.
Ultimately it’s saving you from yourself, if this bug gets fixed and there’s a way I can unfix it, I will do so.
If you need RPM Firefox, my recommendation is that you install it with Distrobox. This also solves the security issue that we remove upstream Firefox over - update frequency.
You don’t want Firefox to only update when your operating system image does. As far as I’m concerned the bug preventing Firefox from being re-added is a feature.
I opted for Lutris because Bottles has issues that make it unrecommendable and unsupportable by us.
Because it’s only shipped as a flatpak (They bullied the Fedora packager until they quit) it doesn’t support the frame limiter built into gamescope on the deck images (Requires a patch in Mesa).
As a contributor to the Northstar mod for Titanfall 2, we originally wanted to recommend it as the default Linux install path due to it’s friendly UI, but found because it avoids using winetricks it’s missing required dependencies. Despite us trying to work with them and contributing code, to this day it still doesn’t work, and recent discussions about this problem were extremely abrasive from their side, much like the above linked issue.
Ultimately Lutris provides a more consistent experience for gamers that are already used to Steam - with the same tools working for both. That’s my reasoning anyway.
As far as wine, we only install wine-core and not the entire stack, that’s purely for Lutris dependency reasons and isn’t intended to be used by the end user. Wine-ZGUI for instance is a Flatpak, and Lutris will install its own copy of wine - most likely Wine-GE or a derivative.
Those we leave alone, they’re really only meant as a base for other images anyway.
Not being able to relayer it is a good thing in this case, you don’t want the browser to have any limits on when it can update.
If you need something other than the flatpak, I would recommend installing it in a Fedora distrobox and exporting it.
We (ublue) remove Firefox and install the flatpak because you want your browser to update when it needs to update, and not only when your OS image updates.
It’s layered into the image like any other rpm. Standard steam package you’d install in Workstation.
We stopped doing this a few versions ago, main reason was inconsistency between the deck and desktop branches, since deck needs to be properly layered due to it essentially being a desktop environment.
Additionally, we’re not able to offer HDR or steam input with Wayland through distrobox. That being said, bazzite-arch remains a distrobox image with real utility for other use cases and we continue to maintain it.
They all try to share patches and ideas too, if there’s competition - it’s friendly.
We’re aware of it, it’s just complicated and directly related to kernel differences between Valve’s heavily modified 6.1 and Fedora’s 6.6/soon to be 6.7
This release lays the groundwork since it’s the first one with a fully custom kernel. In addition updates will be coming faster for the foreseeable future. A lot was held back due to us working on maintaining secure boot support when switching kernels.
Speaking on Bazzite, KDE is our default to match SteamOS, but we put more effort into the GNOME release if anything due to us trying to maintain feature parity with Valve’s KDE, including being able to right click and add to steam, use the desktop nested, enable VRR, add custom themes based on the ones Valve shipped, and add the steam deck wallpapers ported to GNOME.
That being said, GE’s points about GNOME are very real, and they have a lot of catching to do in regards to gaming. KDE has DRM Leasing, VRR and HDR right now.
It’s for anybody, incredible tool.
We solve this problem by treating distroboxes as cattle and not as pets. Blow them away at any time.