OBS continued using the EOL runtime because of Qt regressions introduced in the updated KDE runtime. The OBS team decided the security risk of sticking to the EOL runtime was small, so they didn’t update.

But that still does mean that users were no longer receiving security updates. Ideally, OBS should have moved to the standard Freedesktop runtime and vendored in the older Qt dependency. That way, the they would still be receiving security updates for everything in the Freedesktop runtime. Then once the regressions were fixed, they could move to the updated KDE runtime and remove the vendored Qt dependency.

Overall, the risk OBS had was small. But it demonstrates a larger issue with Flathub, which is that they don’t take security as seriously as Fedora. There are hundreds of flatpaks in Flathub that haven’t been updated in years, using EOL runtimes and vendored dependencies that get no updates.

“strict guidelines” are resulting in flatpaks like OBS and Bottles, which are broken and the devs have tried to get them to stop shipping, then I’ll pass on Fedora flatpaks

That’s fine.

I criticize Fedora for sneakily (whether intentionally sneaky or not) setting their broken flatpak repo as the default

It’s not sneakily. Fedora Flatpaks do not have verified badges and in Gnome Software, they show “[Flatpak Icon] Fedora Linux” right under the install button.

Is this system perfect? No. For example, it stills shows “Mozilla Corporation”, but note that this issue also affects Flathub. That line is about the app creator, not publisher.

leading to a bunch of confusion by Fedora users that don’t know they’re actually using different, sometimes broken, packages from everyone else.

Most people get their packages from their distros repos. Arch, Linux Mint, Pop!_OS all default to distro repos. The latter two include Flathub, but still prefer debs by default. So most people are using unofficial packages by default that are different from what everyone else is using.

As for users feeling “tricked”? That’s a difficult thing to say. I would like to say that users should at least know something about the distro they are choosing (ie Ubuntu users should know about snap; Fedora/Debian users should know about their stances on FOSS, security, and patents; Arch users should know its a DIY distro). But I was once a new user and I remember using Ubuntu for months before learning that their packages aren’t official and about how their repo freezes work.

The situation could certainly be improved. Fedora could show a slide in Gnome’s Tour screen informing them about Fedora defaults to their own packages not supported by upstream and their stances on FOSS.

And that’s a perfectly fine position to have. I get most of my apps from Flathub.

I also think that Fedora Flatpaks should be allowed to exist. And most of them work without issues. They just don’t get as much testing as Flathub since the user base is smaller.

And Fedora Flatpaks are universal, they work on any distros.

Flatpak by design allows you to install Flatpaks from multiple stores. The fact that snap only allows one store is a common criticism of snap.

Fedora Flatpaks were created because Fedora has strict guidelines for packages. They must be FOSS, they must not included patented software, and they need to be secure.

Flathub allows proprietary and patented software, so not all Flathub packages could be preinstalled. And if a Flathub package was preinstalled, it could add proprietary or patented bits without Fedora having a say.

Flathub packages are also allowed to use EOL runtimes and include vendored dependencies that have security issues. Fedora does not want this. Fedora Flatpaks are built entirely from Fedora RPMs so they get security updates from Fedora repos.

Fedora has always been one of the flatpak friendly distros.

No, it’s not like snap. Fedora is not removing RPMs and replacing them with flatpaks. It just defaults to flatpaks. Fedora Flatpaks are built entirely from existing RPMs.

Fedora already has two “warnings” when it comes to their own packages.

First, Gnome Software shows a verified badge for all Flatpaks that are maintained by upstream. The Fedora Flatpak does not have this badge.

Second, when installing a Fedora Flatpak, the label “Fedora Flatpak” shows right under the install button

Sure, this isn’t perfect. Non-technical users may not understand what these mean. But it’s not like Fedora is intentionally trying to mislead users.

It’s not distro specific. Fedora Flatpaks are just built from Fedora RPMs, but they work on all distros.

If you care about FOSS spirit, security, and a higher packaging standard, then Fedora Flatpaks may be of interest.

If you want a package that just works, then Flathub may be of interest. But those packages may be using EOL runtimes and may include vendored dependencies that have security issues.

That wouldn’t work. Flathub and Fedora Flatpaks have different goals.

Fedora Flatpaks must meet legal requirement set by Fedora, so no proprietary or patented software.

Flathub also encourages upstream to maintain their packages. But upstream may not meet the security requirements set by Fedora. Fedora has much stricter packaging guidelines which don’t permit vendored dependencies.

I had a better desktop experience with the FOSS driver than the proprietary driver when testing a 2060 on Fedora 41.

Dark colors still emit blue light.

I’m not going to deny that he can act aggressively, but his point is still valid. The anti-Rust sentiments of some maintainers has slowed down the upstreaming of Rust into the kernel. It doesn’t make sense to waste people’s time by letting R4L limp along in its current state.

R4L either needs to be given the go-ahead to get things upstreamed, to the dismay of some Linux maintainers who don’t like Rust, or R4L should be killed and removed from the kernel so we can stop wasting people’s time.

Personally, I think killing R4L would be a major mistake. Android’s Linux fork with Rust support has been a major success for Google and significantly cut down on vulnerabilities. And the drivers for Apple’s M chips has been surprisingly robust given how new they are and for being reverse engineered.

Not AI.

My bad on the Apple part.

The Nvidia driver didn’t support some protocol that AMD/Intel did that was used by desktops for the night light.

Yes, they could have made the night light work. But why would they when Nvidia said the feature was coming soon? Well it turned out that soon was taking a very long time and eventually KDE actually did create a special night light implementation just for Nvidia. The problem was that it was a hack that had extra overhead. And in the end the hack didn’t get shipped because Nvidia finally starting supporting the protocol.

Unfortunately not. There’s been a number of things on Nvdia’s side that slowed down Wayland adoption.

They didn’t always support Xwayland hardware acceleration.

Nvidia pushed for a technology called EGLStreams while everyone else agreed on GBM. So the desktop stack had to support both. Nvidia eventually relented and started supporting GBM.

Nvidia didn’t support VRR or night light for a while.

Nvidia didn’t support necessary stuff for Gamescope to function properly.

And overall Nvidia on Wayland was just buggy. I remember that many games failed to launch or had weird performance issues. But those issues just went away when I got an AMD card.

But things are in a much better state today. Though I did recently test a 20 series card on Fedora 41 and it was a terrible experience on the proprietary drivers. But when speaking with orhers, they didn’t share my issues.

One opinion that Wayland has is that the client is responsible for decorating its window. It draws its own title bar, shadow around the window, and the cursor.

Though not everybody was happy with this. A few protocols were created that lets clients tell the compositor to draw decorations around the window and the cursor.

But still, every app needs to support those client side decorations and cursors because not all compositors support those protocols. Gnome notably doesn’t, they like client side decorations.

Before Wayland, there was X Window System, created in 1984. X Window System was designed in a time where you had one good computer connected to multiple displays used by different people. X went through many versions but version 11 (X11) stayed around for a long time.

But the architecture just isn’t good. It wasn’t designed for modern needs. MacOS used to use X, but replaced it to fit modern needs. Windows didn’t use X, but they too updated Windows to fit modern needs. But Linux and other OSs stuck with X for a lot longer, hacking it to make it work. Honestly, it’s amazing how well it does work.

But isn’t not great. It wasn’t designed with security in mind, it doesn’t do multi-monitor well. Behind the scenes, it considers everything to be one giant display; issues arise when it comes to mixed-dpi displays and when monitor refresh rates don’t match. It’s also just a bloated, old code base that people don’t want to work on. Fixing X would not only be difficult, but would break compatibility.

So people got working on a modern replacement for X aiming to avoid its issues. Wayland is leaner, more opinionated, and designed for how modern hardware operates. Wayland itself is just a protocol (like X11), and there’s many different implementations of that protocol: Mutter, Kwin, wlroots, smithay, Mir, Weston, etc. Meanwhile X11 pretty much only had one relevant implementation, Xorg. Wayland’s diversity has its pros and cons. Pros include (1) you can create your implementation in any programming language you want rather than being stuck to just one, (2) an implementation can fill just the needs on the person making it rather than trying to generalize it for everyone. But cons include the fact that this fragmentation leads to scenarios where one implementation supports something that others don’t and implementation-specific bugs.

Wayland’s opinionated design is also draws criticisms. It gives a lot of control to the compositors rather than windows, which is how Xorg, MacOS, and Windows work. Nvidia’s wayland adoption was also slow and terrible. It took many years to get it into the only decent shape it’s in now.

Mint never preinstalled the snap. They package their own version of Firefox. I believe they have an agreement with Mozilla.

Weird, it’s been working for me for a while. I just need to manually set “media.ffmpeg.vaapi.enabled” to true in about:config.

Nate Graham is hesitant increase the frequency. When the feature was announced, he repeatedly emphasized it a was a single year popup. He doesn’t want to go back on his word.

It’s a year’s worth of improvements.

Though if you’re using Proton Experimental, you’ve already been receiving these improvements since it uses the staging (or git?) branch.

I believe Proton stable releases use the stable version of wine with fixes backported.