There was an article on Open for Everyone today about Nobara, a Fedora-based distribution optimized for gaming. So I have no beef with Tomas Crider or any other creator/maintainer of a distribution targeting a specific use case. In fact they are usually trying to solve or work around real problems and make things easier for people. That said I have for years felt that the need for these things is a failing in itself and it has been a goal for me in the context of Fedora Workstation to figure out what we can do to remove the need for ‘usecase distros’. So I thought it would be of interest if I talk a bit about how I been viewing these things and the concrete efforts we taken to reduce the need for usecase oriented distributions. It is worth noting that the usecase distributions have of course proven useful for this too, in the sense that they to some degree also function as a very detailed ‘bug report’ for why the general case OS is not enough.
Before I start, you might say, but isn’t Fedora Workstation as usecase OS too? You often talk about having a developer focus? Yes, developers are something we care deeply about, but for instance that doesn’t mean we pre-install 50 IDEs in Fedora Workstation. Fedora Workstation should be a great general purpose OS out of the box and then we should have tools like GNOME Software and Toolbx available to let you quickly and easily tweak it into your ideal development system. But at the same time by being a general purpose OS at heart, it should be equally easy to install Steam and Lutris to start gaming or install Carla and Ardour to start doing audio production. Or install OBS Studio to do video streaming.
Looking back over the years one of the first conclusions I drew from looking at all the usecase distributions out there was that they often where mostly the standard distro, but with a carefully procured list of pre-installed software, for instance the old Fedora game spin was exactly that, a copy of Fedora with a lot of games pre-installed. So why was this valuable to people? For those of us who have been around for a while we remember that the average linux ‘app store’ was a very basic GUI which listed available software by name (usually quite cryptic names) and at best with a small icon. There was almost no other metadata available and search functionality was limited at best. So finding software was not simple, at it was usually more of a ‘search the internet and if you find something interesting see if its packaged for your distro’. So the usecase distros who focused on having procured pre-installed software, be that games, or pro-audio software or graphics tools ot whatever was their focus was basically responding to the fact that finding software was non-trivial and a lot of people maybe missed out on software that could be useful to them since it they simply never learned about its existence.
So when we kicked of the creation of GNOME Software one of the big focuses early on was to create a system for providing good metadata and displaying that metadata in a useful manner. So as an end user the most obvious change was of course the more rich UI of GNOME Software, but maybe just as important was the creation of AppStream, which was a specification for how applications to ship with metadata to allow GNOME Software and others to display much more in-depth information about the application and provide screenshots and so on.
So I do believe that between working on a better ‘App Store’ story for linux between the work on GNOME Software as the actual UI, but also by working with many stakeholders in the Linux ecosystem to define metadata standards like AppStream we made software a lot more discoverable on Linux and thus reduced the need for pre-loading significantly. This work also provided an important baseline for things like Flathub to thrive, as it then had a clear way to provide metadata about the applications it hosts.
We do continue to polish that user experience on an ongoing basis, but I do feel we reduced the need to pre-load a ton of software very significantly already with this.
Of course another aspect of this is application availability, which is why we worked to ensure things like Steam is available in GNOME Software on Fedora Workstation, and which we have now expanded on by starting to include more and more software listings from Flathub. These things makes it easy for our users to find the software they want, but at the same time we are still staying true to our mission of only shipping free software by default in Fedora.
The second major reason for usecase distributions have been that the generic version of the OS didn’t really have the right settings or setup to handle an important usecase. I think pro-audio is the best example of this where usecase distros like Fedora Jam or Ubuntu Studio popped up. The pre-install a lot of relevant software was definitely part of their DNA too, but there was also other issues involved, like the need for a special audio setup with JACK and often also kernel real-time patches applied. When we decided to include Pro-audio support in PipeWire resolving these issues was a big part of it. I strongly believe that we should be able to provide a simple and good out-of-the box experience for musicians and audio engineers on Linux without needing the OS to be specifically configured for the task. The strong and positive response we gotten from the Pro-audio community for PipeWire I believe points to that we are moving in the right direction there. Not claiming things are 100% yet, but we feel very confident that we will get there with PipeWire and make the Pro-Audio folks full fledged members of the Fedora WS community. Interestingly we also spent quite a bit of time trying to ensure the pro-audio tools in Fedora has proper AppStream metadata so that they would appear in GNOME Software as part of this. One area there where we are still looking at is the real time kernel stuff, our current take is that we do believe the remaining unmerged patches are not strictly needed anymore, as most of the important stuff has already been merged, but we are monitoring it as we keep developing and benchmarking PipeWire for the Pro-Audio usecase.
Another reason that I often saw that drove the creation of a usecase distribution is special hardware support, and not necessarily that special hardware, the NVidia driver for instance has triggered a lot of these attempts. The NVidia driver is challenging on a lot of levels and has been something we have been constantly working on. There was technical issues for instance, like the NVidia driver and Mesa fighting over who owned the OpenGL.so implementation, which we fixed by the introduction glvnd a few years ago. But for a distro like Fedora that also cares deeply about free and open source software it also provided us with a lot of philosophical challenges. We had to answer the question of how could we on one side make sure our users had easy access to the driver without abandoning our principle around Fedora only shipping free software of out the box? I think we found a good compromise today where the NVidia driver is available in Fedora Workstation for easy install through GNOME Software, but at the same time default to Nouveau of the box. That said this is a part of the story where we are still hard at work to improve things further and while I am not at liberty to mention any details I think I can at least mention that we are meeting with our engineering counterparts at NVidia on almost a weekly basis to discuss how to improve things, not just for graphics, but around compute and other shared areas of interest. The most recent public result of that collaboration was of course the XWayland support in recent NVidia drivers, but I promise you that this is something we keep focusing on and I expect that we will be able to share more cool news and important progress over the course of the year, both for users of the NVidia binary driver and for users of Nouveau.
What are we still looking at in terms of addressing issues like this? Well one thing we are talking about is if there is value/need for a facility to install specific software based on hardware or software. For instance if we detect a high end gaming mouse connected to your system should we install Piper/ratbag or at least make GNOME Software suggest it? And if we detect that you installed Lutris and Steam are there other tools we should recommend you install, like the gamemode GNOME Shell extenion? It is a somewhat hard question to answer, which is why we are still pondering it, on one side it seems like a nice addition, but such connections would mean that we need to have a big database we constantly maintain which isn’t trivial and also having something running on your system to lets say check for those high end mice do add a little overhead that might be a waste for many users.
Another area that we are looking at is the issue of codecs. We did a big effort a couple of years ago and got AC3, mp3, AAC and mpeg2 video cleared for inclusion, and also got the OpenH264 implementation from Cisco made available. That solved a lot of issues, but today with so many more getting into media creation I believe we need to take another stab at it and for instance try to get reliable hardware accelerated encoding and decoding on video. I am not ready to announce anything, but we got a few ideas and leads we are looking at for how to move the needle there in a significant way.
So to summarize, I am not criticizing anyone for putting together what I call usecase distros, but at the same time I really want to get to a point where they are rarely needed, because we should be able to cater to most needs within the context of a general purpose Linux operating system. That said I do appreciate the effort of these distro makers both in terms of trying to help users have a better experience on linux and in indirectly helping us showcase both potential solutions or highlight the major pain points that still needs addressing in a general purpose Linux desktop operating system.
Regarding low latency audio, I spent a day last week testing the new 5.16 Fedora kernel, which is the first with CONFIG_PREEMPT_DYNAMIC enabled, using the preempt=full kernel boot parameter. I am happy to say that it helps a lot. I am able to use JACK applications with Pipewire with 128 frames/buffer @ 44.1 kHz without glitches. What surprised me most about preempt=full is that the CPU load from lower priority tasks makes a difference in how many glitches I hear. I could go down to 32 frames/buffer @ 44.1 kHz and I didn’t get more glitches when I was compiling Rust in the background.
Pipewire is awesome. It could use a GUI to configure it, particularly the buffer size and sample rate. Currently this requires editing text configuration files and using environment variables, which isn’t too bad, but the UX could be improved.
“What surprised me most about preempt=full is that the CPU load from lower priority tasks makes a difference in how many glitches I hear.”
Sorry, I meant that the CPU load from low priority tasks does *not* make a difference with preempt=full.
You can change buffer size and sample rate at runtime, see here: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-PipeWire#runtime-settings
The problem to me isn’t technical, the problem is the attitude of distribution developers.
The attitude of many developers of big projects is to be dismissive and condescending towards their users; “you don’t like it? there’s the door”. This inevitably leads to a balkanization of open source projects.
As long as this attitude prevails, forks will continue to happen, and new projects starting from scratch will keep spawning.
I used Fedora for many years, until I tried to provide feedback, and it was completely dismissed. I was treated as “just a filthy user”. That’s all I needed to correctly judge the future of the project and now I’m a happy Arch Linux user.
The solution is very simple, but it requires accepting the problem, which most developers won’t.
Funny you say that when GNOME is the biggest example of a project that says “if you don’t like it there’s the door”. LOL
I tend to agree with you on many points but it would be all fine and great if GNOME software was actually usable.
Well it is, like 60% of the time and even then app search is erratic. Like you may find an app by typing the first 3 letters of it or the context for which you are looking for it and you might find it. If you happened to know its full name and type it, GNOME software will just pretend it doesn’t exist.
In my case I am fine using DNF, I have use Linux for 25y. I am just sorry for the poor souls depending on that ‘app store’s.
GNOME Software will never be usable. It’s a POS by design just like the rest of GNOME since terrible version 3 came out.
That is a bug in the app metadata, probably because the name of the binary is different from the app name, and in that case because also the app name is not in the ‘keywords’ field of its .desktop file.
Please file a bug for that, the patch to fix it is easy. If you name the app I can file it and provide a fix.
I agree. Usecase distros muddie the waters of an already confusing choice of Linux distributions. I think the fact that they exist indicates a need that’s not being catered for. Some users want to share the way they configure their Linux. Currently the only path they see, either technically and in terms of getting the word out, is a usecase distribution.
I think it would be a lot better if there was some easy way to develop a “recipe” that answers a common “problem”, and then distribute that answer to everyone who shares your interest.
For example, say I have a great recipe for how to set up a great gaming rig. I know all the right settings, I know all the things you need to install, all the presets that need to be configured in each application.
One simple way is documentation. That can be hard to find and lots of people don’t bother reading it, and anyway until we all adopt Esperanto there’s the language barrier.
Instead of rolling my own distro, I create *something* — let’s call it a Mod (as in “Modification”), for lack of a better term — and post it to LinuxMods dot org. Other users looking to optimize their distro for gaming can download my Mod, install it, and emerge with a setup exactly like mine, down to the wallpaper, Qt or GTK theme, video settings, and so on.
Ansible Playbooks are the obvious contender for such a system. Maybe that’s ultimately the answer. Maybe we ought to start promoting Ansible as the new usecase distro maker. Don’t roll your own distro, develop a playbook.
That is somewhat similar to what distros like NixOS and GNU Guix do – you have a recipe describing a system that you build. But unlike Ansible, each build produces an independent directory tree from scratch, preventing the build up of cruft. Unfortunately, their learning curve is still too steep to be practical for most Linux users. But hopefully, someone will manage to create more user friendly distro inspired by NixOS eventually.
I don’t think they are needed. Period. Most are just a bit of UI theming and a few hacky install scripts. I wish people would contribute to building something as a community that is durable, not one more fork.
Kali says, hold my beer
Hi there,
why not creating in Gnome Software a section called use-case linux distribution. In this section you would have a list of sub-sections: gaming distros, scientific distros, creative distros, etc … In each sub-section you would have a list of major existing distros on the market. Given that, users could simply click on a specific use-case linux distro, e.g. Lakka for transforming your computer into a gaming console http://www.lakka.tv/. By doing so, this would install all the metadata specific with this distro. That may also stimulate distro maintainers to work on flatpaking their preferred software, but also working on use-case OStrees updates. You could achieve that by working with some of the main distros dev to define a minimal set of metadata that they would upstream to you in order to enrich gnome software. Basically gnome software could become the place to discover/update not only software, but also distros (including use-case OStrees updates). A software and a distro to govern them all! I’m pretty sure that many maintainers would love this idea as it would remove them some of the burden of improving the discoverability of their distro.
This.
An advantage is you could still crowdsource the different flavors. And a reputation system could help the good implementatiins bubble to the top…
I think that is what are are slowly moving towards in a sense, although not labelled as ‘change you distro’, but more like evolving the categories to be clearer and better aimed at what people are looking for within specific usecase elements. Of course one could consider taking it further and allow people to somehow classify themselves as for instance ‘gamers’ and then have GNOME Software adapt its recommendations etc. based on that., but again we would have to evaluate if the cost of maintaining the infrastructure to be able to do that is paid back in a genuinely improved user experience.
«they often where mostly the standard distro, but with a carefully procured list of pre-installed software»
Debian Blends and meta-packages are a good approach on this: keep the main tree and no extra repos, and do your specific inside a Debian package.
You don’t mention the Fedora spins and other non-Fedora distributions focusing on a specific desktop, eg. the Fedora KDE Plasma Desktop.
What is your opinion on their usecase?
As a Fedora KDE Plasma Desktop user i could consider most software or even the whole infrastructure of the Gnome-based Fedora Workstation “unnecessary bloatware” ( yes, i no, it isn’t ;).
Are you satisfied with the interoperability of the Gnome/KDE/Plasma/etc. applications vs. the different DEs on Fedora?
You missed the entire point of the article. A version of a distro with a different desktop is not the same as a version of a distro being marketed as “for gaming” “for developers” “for [whatever]”.
I don’t think it’s at all fair to say J “missed the entire point of the article”. In fact, based on your responses to J and others on this forum, I would encourage you to work on your skills in subtlety. :-)
I think J asks a very valid question. For example, there are many “flavors” of Ubuntu available (e.g. Kubuntu, Xubuntu, etc), but it’s really not fair to treat them as separate distributions. They all have the same kernel, packaging system, and even the same package repository.
Although I can see how this might be different from the “usecase distributions” the author is referring to, it’s conceptually not. A use-case distro is really just a derivation of a separate, general-purpose distro. And like a general-purpose distro, it only contains small package differences that seem to artificially fill the Linux ecosystems with “choices”—even if it means those choices are entirely unnecessary.
I do believe those are in a different category as it is about presenting a different user experience through a different DE, there are challenges in terms of 3rd party software and standards created by our wealth of options, but that is a separate question. At the end of the day my main issue with usecase distros is that it feels silly that you are supposed to re-install your whole operating system because you want to do something.
I think the issue with user case distros could be easily fixed by community editions. What if EndeavourOS and Garuda Linux could be published as community editions (so still unofficial) of Arch instead of forks, for instance?
The real problem is many distros doesn’t allow editions beside “official” and that leads to more fragmentation and confusion.
I think of usecase distros as being a patch on top of the vanilla distros. That being said, the app store could be the place to have these patches. The store would not contain just the apps, but the the whole patch. The patch itself would contain instructions to install all necessary apps, upgrades, distros configuration and maybe kernel tweaks. So, if instead of creating a Ubuntu Studio distro, they could have created Studio Patch and I could just go in GNOME Store and install the Studio Patch on my Ubuntu vanilla.
I’m just not sure about naming it “patch”
Distro Patch
Distro DLC
Distro Extension
Distro Extra
Distro Tweaks
Distro Mod
Any other name?
Does that mean that Fedora will finally officially maintain non free software packages even if it doesn’t ship with Fedora by default? Because if it doesn’t, I don’t think those usecase distros will end.
This was Debian idea around “The Universal O/S” and the idea that it should be designed to allow people make it whatever they want. And that might even include people making usecase variants (aka debian “blends”) that are just Debian underneath (which there are quite a few of, esp if you count all the rasppi usecase things based on Debian).