Discovered issues with Fedora Silverblue

Key issues include:

  1. Fedora Flatpaks always take precedence over Flathub, causing problems with missing codecs for apps like Kdenlive and Totem.

  2. Default Steam Udev rules are not installed, leading to joystick compatibility issues due to missing steam-devices.

  3. The initial GNOME welcome screen does not allow language selection post-installation, complicating sales for OEMs in multilingual markets, especially in Europe.

I’m unsure how to contact developers, but perhaps someone here can advise on potential fixes. Thanks!

1 Like

Also, the lack of a pre-installed office suite is a major barrier to widespread adoption and should not be ignored

You can disable the Fedora flatpak repositories if you prefer:

$ flatpak remote-modify fedora --disable
$ flatpak remote-modify fedora-testing --disable
1 Like

Added silverblue

Hi Oliver, thanks, I posted this in order to help mass adoption towards novice users

1 Like

I would also add

  • missing thumnailer support
  • thus a semi-broken firefox (I dont know, I add rpmfusion)
  • the need to layer packages to fix this
  • the need to layer packages to make NVIDIA work

all of these are legal issues, which may be possible to change with systemd sysextensions.

What are not legal issues but still cause a pain for users are:

  • no intelligent automatic updates like uBlue. clunky GUI integrations instead
  • Fedora Flatpaks, prioritized, an additional runtime
  • toolbx instead of distrobox, lacking a ton of capabilities
  • missing basic CLI tools like nvtop, btop, wireguard-tools, lm_sensors, lynis, nmap, parallel, python3-pip

those are decisions, and I am not sure how democratically they were made.

atomic desktops need to be handled differently. So including a few more packages should be an okay solution.

2 Likes

I wonder what the average use-case is for Silverblue, but it’s a bit surprising it doesn’t come with LibreOffice? Workstation (F40-41) does which makes it seem like a decision on Silverblue.

LibreOffice is not part of the base system, which is only the OS, it is a user program and therefore installed through flatpacks, just like any other program you want to use.

1 Like

the use case for Silverblue does presume regular high speed internet connection for the daily updates, so I’m not sure leaving out opinionated big software stacks like that is any major barrier.

In OpenSUSE’s atomic desktop, a post install script adds enough Flatpaks to get you going – that might be something that Fedora Atomic could consider.

There are the same things, integrated into Anaconda afaik.

But they install the apps from Fedoras Flatpak repos, which are fine, but not officially packaged and a duplicate.

1 Like

Honestly I can’t remember, but I must have changed my Flatpak repo soon after install.

I believe it’s a good idea to have an alternative repository in case anything happens to Flathub. However, I understand that it becomes problematic when the Fedora package is missing essential features like codecs.

This issue can be easily resolved by adjusting the priorities. For instance, when a user enables Third-Party Repositories via a button. This would involve running the command:

gsettings set org.gnome.software packaging-format-preference "['flatpak:flathub', 'flatpak:fedora-testing', 'flatpak:fedora', 'rpm']".

I’m not convinced that Flathub should be the default.

We certainly can’t ship things that… we can’t ship. I get that in some cases missing functionality is frustrating, but we don’t remove things out of some kind of puritanical high-mindedness. In practice, that may be less important to individual users, but if you’re using Fedora Linux in, say, your business, you may need to care.

Fedora Flatpaks are built with our security polices and security-focused compiler flags. They’re built in our buildsystem by packagers who have earned the project’s trust. Flathub offers verification that certain applications come from or are authorized by the (primary) developer of that app, but that’s not at all the same thing.

Fedora also makes sure that everything we ship is free and open source software, and that anyone actually can build it. That way, if you’re building something on Fedora Linux, you know that you have the basic software freedoms available to you with no catch.

Fedora carefully and responsibly updates our packages when there are serious (and less serious!) security issues. There is no such coordination across Flatpaks, and no easy way of telling, across the board, where some unmitigated problem is present.

For most users, for most apps that we package as Flatpaks, the Fedora version is a safer choice.

You might disagree — and Fedora as a project might change our stance on some of these things as the situation changes. For example, if Flatpak sandboxing was universally more restrictive (like apps on Android or Apple devices), some of these concerns would be less important.

But, as it is, that’s our policy, and I think this illustrates why we don’t want people making “minor” changes and distributing them under the Fedora brand. Our choices reflect our policies, and those policies are promises[1] to our users about our software. If you want to make different policy choices, that’s cool — but you need a different name.


  1. um, best-effort promises ↩︎

5 Likes

Hi Matthew, I completely agree with you and stand firmly in support of open source. However, I think we might have different approaches. From a pragmatic perspective, I believe the best way to attract more users to Fedora and Linux is to allow them to learn on their own why open source is advantageous.

If we target individuals who aren’t tech-savvy, they may become frustrated when they attempt to open an .mp4 file (something that makes up about 80% of video files) and encounter issues. For instance, if they install Kdenlive and run into errors while editing such files, they might perceive the system as broken and go towards proprietary alternatives.

I believe a more effective approach would be to include a warning or prompt explaining why certain features are disabled by default and the reasoning behind it. Alternatively, we could make Fedora Flatpaks compatible with codecs (if installed) in some way. If we conducted a poll about how many Fedora users operate without Flatpaks and codec support, the results would likely be disappointing.

While I’m personally against this proprietary format, I think the key to winning over more users is to provide options and clear information for the average person. Otherwise, Fedora risks becoming a niche for programmers and enthusiasts, putting us at a disadvantage against other distributions.

I plan to support the creation of a remix as a gateway to a fully open-source Fedora. My goal is to offer something that’s user-friendly for newcomers, allowing them to learn about it over time, informing them also, which could ultimately lead to greater pressure on companies to adopt open source solutions.

1 Like

Commenting mostly about the inclusion of extra packages

Personally, I want my base system to be as small as possible, especially when it’s an immutable system, being smaller reduces the need for reboots due to package updates. It already bothers me that includes Firefox instead of having it as a flatpack, and I wouldn’t like it to include big pieces of software I wouldn’t use, like LibreOffice.

I believe the best way to close the gap for non tech savvy users is to have a pre or post installation UI that suggest packages (or better yet, groups of packages), and links to official documentation explaining (with a summary first, then detailed) why some decisions about software are made, and (if legally possible) point people in the direction necessary to find more information if they want to work around those limitations.

Sometimes when topics like this surface is because the information is available, but not easily discoverable or easy to understand.

Having said that, I never thought ostree distros target would be non tech savvy people, It was my understanding that Fedora Workstation existed for that, and users could later start distro hoping once familiar, as it’s often the case.

Regardds

Why is Firefox part of the base system? Which other package needs it, and if a browser is needed can’t it be another one, one which the user of the distro installs as flatpack? I never use Firefox so I also like to see it go.

I understand the idea of having a browser for the first contact of the user with the system. But maybe have Firefox as the flatpak version from Fedora’s flatpak repo, like some other apps. It would be easier for the user to change browsers, or switch to Flathub’s version of Firefox.

You can add the udev rules after the fact.

You can install Libreoffice with rpm-ostree or Flatpak