TLDR: If some magic wizard would make me Fedora's supreme ruler, I'd morph the release model into one similar to that of Firefox or the Linux kernel. I'd also dramatically increase relations to RPM Fusion, so that we together can finally make things easy and robust that Fedora itself can't or doesn't want to provide. And of course: immutable operating systems FTW!
A thought experiment
Nearly 20 years ago I became interested in contributing to what just a few months later morphed into the Fedora Project. These became my first steps as an Open Source contributor. Despite this I managed to become a teeny tiny bit known in the Fedora world and might even have influenced a little. My focus after some years shifted to the Linux kernel, but Fedora is still dear to my heart. Its upcoming anniversary hence made me wonder multiple times:
Would a modern version of my younger self start contributing to Fedora?
My brain always comes to a conclusion along these lines:
That's highly unlikely, because today's Fedora Linux is kinda uncool and somewhat oldish!
Funnily enough at the same time something in my head yells: "Some of what makes Fedora Linux uncool and oldish is what helps making it so great! And you for sure don't want it to become yet another rolling release distro similar to 'cool' distros like Arch Linux and Tumbleweed!". Which lead me to a thought experiment of megalomania this blog post is about:
If I could dictate how Fedora Linux operates, what would I change to make it cool again while ensuring its stays great?
What Thorsten as Fedora's ultimate leader would aim for
Well, here are the two things that would be at the top of my todo list:
1. Switch to a more modern release model that better suites these times and serves mainly two goals:
a) Have a quick release pace with two distro streams. The first stream would target users that want fresh software relatively quickly, but don't want a rolling release distro. The second stream would target users which prefer software that (1) whenever possible went through a proper field test in Fedora's first stream and (2) withholds major changes whenever possible to one "jump" release per year.
b) Make Fedora's devel streams help upstream software developers a lot more forging their future versions into shape: with more cooperation in this place we'll help each other tremendously and thus make FLOSS itself better.
2. Broadly increase the cooperation with external projects to make things (a) simple and (b) robust that many users want to do, but Fedora can not (for legal reasons) or does not want to (like software that is not FLOSS) provide.
So how to actually do this? Well, that requires separate sections to explain.
A modern release model
Every few weeks a new release with new features and once a year one version becomes the base for a new LTS series that quickly supersedes the previous one – that's a modern development scheme that among others was made popular by Firefox.
I would make Fedora Linux follow that model on a distro level: it better suits the times, is more attractive, and has benefits for stabilizing the distro and the software it contains.
I already hear some of your yelling "this will lead to unreliable releases", "it requires too much resources", "this will never work", and many similar things. But people yelled such things when the Linux kernel and Firefox switched to this model, too. Now look at them: the quick pace with small steps turned out to be great for both users and developers. That's why I would make Fedora follow a similar scheme.
How? Well, like this:
* Morph the current Fedora Linux into a "Fedora Deft Linux" (alternatively "Fedora Agile" – or maybe just continue calling it "Fedora Linux"). It would be similar to the Fedora Linux releases we have now, just with a much quicker release pace of *four* weeks. Each release immediately would immediately replace the previous one and rolled out like any other update -- just like Firefox 111 becomes EOL and is replaced by Firefox 112 when the latter is launched.
* Create a "Fedora Steady" (or "Fedora Linux Longterm") that follows the same release pace (just like Firefox ESR follows the same pace as Firefox). It normally would only bring new software versions that already have proven themselves at least one cycle in "Fedora Deft". Base software like anaconda, compilers and toolchains would only be updated once a year in a coordinated "jump release", where they are mass-synced/merged from a Fedora Deft release where they have proven themselves. The approach is similar to Firefox ESR and Linux longterm kernels. This stream would be the de facto successor for the "Fedora Linux <current version -1>" release (e.g. Fedora Linux 36 now and soon F37 once F38 is out).
Yes, this will require package maintainers to meddle sometimes, as we deal with thousands of upstreams that work at different paces and release schedules – and for some upstreams switching to a new release is the best or only sane way to address security issues. But the quick release pace would make this easier. And we deal with these sorts of problems in today's Fedora every day already, hence that meddling would not be much different in a "two Fedora streams" scheme.
The new approach allows one crucial thing we don't do currently: properly field-test a new version (say when the Linux kernel jumps from the 6.1.y. to 6.2.y series) in one stream first (e.g. Deft) before users that fear unstable software get it as an update (e.g.Steady). That being said, there is one additional thing it'd do to reduce the friction between goal and reality:
* When upstream maintain regular and longterm branches (e.g. Firefox vs Firefox ESR; Linux stable kernel vs longterm kernel; KDE regular vs KDE LTS; …), give users the option to choose which of they they want to use. Hence ship both of them in Deft and Steady; Deft by default would use the normal branch, Steady the longterm branch.
Both Deft and Steady of course would need updates-testing channels, just like the two current Fedora releases have one. Normally only security updates should come through here to the users, everything else should wait till the next release – no big deal, it's at max just 4 weeks away. But if upstream mixes security fixes and new features in new releases, they are fine as regular update first in Deft and a few days or a week later in Steady as well, as long as packagers ensured they got some testing in Fedora's devel streams beforehand – ideally while those releases were still in beta. Which brings me to another aspect:
New Fedora Deft releases of course would need to be prepared somewhere. This would be done in two addition development streams:
* "Fedora Devel" would be the successor for Rawhide and regularly ship the latest versions -- and for somewhat reliable upstreams also pre-releases of software that is expected before the overnext Deft release. That for example would include Firefox Beta (which Fedora currently does not ship in Rawhide) or pre-releases of the next mainline kernel. But only when that software is meant to be stable enough for users that don't mind pre-releases or snapshots in beta quality – hence don't ship Firefox Nightly or Linux kernel merge window snapshots (which Rawhide currently ships) here .
* A "Fedora Pioneer" stream at the start of a new Fedora Deft devel cycle would simply incorporate any changes from Fedora Devel, unless there are strong reasons to avoid some update. Then stabilize the upcoming stream over the following weeks until the next Fedora Deft is released. It's thus like a beta, but I would avoid that term, as it's too scary.
This scheme would help upstream getting their software into shape for their next release, which benefits both Fedora and the whole world of FLOSS. To avoid big problems, normalize epochs: if a new upstream version turns out to be problematic, just revert to the older version and delay the switch to the newer upstream version by one Deft cycle, which is only four weeks away – no big deal.
A new beta version of a software packaged in Fedora thus would go to Fedora devel; if it's considered good enough it at the start of the next cycle could move to Fedora Pioneer, where first the beta and later the final is tested and polished over the course of four weeks. From there the version would move to Fedora Deft, where it would be for four more weeks; this version or a later version would go to Fedora Steady, either right at that point or in Steady's yearly "jump release".
New versions of upstream software thus would reach Deft users within about four to eight weeks; everybody that wants it quicker would have to use Fedora Pioneer.
Make things simple and robust that Fedora does not provide
Most users want their operating system to "just work": they don't care much if something requires patent encumbered software or proprietary drivers. And they don't care if it's Fedora or somebody else's fault, if something they want to do is hard to realize or breaks frequently on updates. They will simply switch to another Linux distribution that works better for them – and of course will never forget their bad experience with Fedora.
That's why installing and using patent encumbered software or proprietary drivers needs to be easy and robust in Fedora for the latter to be successful.
Those things currently are not easy and robust. The root of the problem is Fedora's stance on patent encumbered software and its tight focus on FLOSS. I'd definitely *not* change this, as it's right to draw these two lines. I'd do something else:
I'd made Fedora cooperate more with external projects that provide solutions for the things that Fedora can't or doesn't want to support. Flatpak, Flathub, and Fedora's support for them already became quite good and is even getting better with Fedora 38. Hence it's mainly the interaction between the Fedora Project and RPM Fusion that I'd improve to make Fedora Linux better and more attractive.
This is what I'd do:
- Make enabling RPM Fusion free or non-free something that users can do in just one step – ideally one that doesn't require a command line at all, but a "curl https://example.com/rpmfusion-free-install.sh | sudo bash" is fine, if anything else is impossible for legal reasons.
- When above "one step install" is performed, automatically switch over all installed packages to their non-encumbered versions from RPM Fusion (e.g. uninstall Fedora's ffmpeg-free and install ffmpeg – either directly or in an overlay on ostree-based Fedora variants). Additionally install additional software that would be in Fedora's default install if that was possible (possible candidates would be video players like Celluloid for Fedora Workstation or Vlc for the Fedora KDE Plasma Desktop Edition). Ideally it's something in dnf and rpm-ostree that would handle this, due to the related aspect raised in the next point.
- If some software is available in both Fedora and RPM Fusion, make dnf/rpmos-tree install the packages from the latter by default when the user installs them – e.g. when the user runs "dnf install audacity" a week after installing Fedora and enabling RPM Fusion, he should by default get audacity-freeworld from there and *not* the audacity package from Fedora. In similar scope, install typically used add-ons from RPM Fusion by default on package installation – e.g. when user runs "dnf install qmmp" dnf should automatically install qmmp-plugins-freeworld from RPM Fusion to complement Fedora's qmmp package.
- Better ensure that updates on the Fedora side don't break something for users that have related packages from RPM Fusion installed. For example ensure that a mesa update does not cause trouble for users that have mesa-va-driver-freeworld installed (something that recently happened every a few times with to good solution in sight).
- I'd make using Nvidia's graphics drivers more robust. Things got better in recent years, but there is still quite a bit of room for improvement. Shipping the latest longterm kernel as an option in Fedora (see the section about Fedora Deft and Steady above) would help here and allow users to avoid occasional breakage due to new Linux mainline releases only Nvidia can fix. But there is more that can be done – for example automatic fallback to nouveau if Nvidia's driver doesn't work (while telling users about it once the system booted so they can take action). Also: "akmods are fragile; it's a really ugly hack only meant for corner cases – e.g. users of rawhide or people that don't use Fedora's kernel" (these are the words of the original akmod author). Avoid the risks by shipping pre-compiled kernel-modules, which is very hard or impossible to do currently (side note: maybe Nvidia's new open source kernel driver will obsolete that problem, so maybe it's not worth spending too much time on – not sure).
- Related: when the user chose to use RPM Fusion non-free on a system with a nvidia gpu, make the install magic described in the first two points above also install Nvidia's driver -- but only semi-automatically, after telling the user about the risks of such drivers and showing them the drivers EULA. And it should likely suggest switching to the latest longterm kernel, too.
Obviously some of the work to realize this needs to be done on the Fedora side, some in RPM Fusion. But the Fedora Project needs to drive all these changes (or at least guide them) whenever legally possible, as if we like it or not: Fedora needs RPM Fusion (or something like it) to be appealing for many users. That's why doing this is even in the interest of Fedora's main sponsor, as it will ensure Fedora is relevant in the market and attracts a strong user base – which is needed for Fedora to fulfill the goal the main sponsor created Fedora for in the first place.
Closing words and more thoughts
Disclaimer: I know that this is not a good sales pitch; if I had wanted to make it one, I'd have asked others for feedback on the idea and this text before publishing this post. Maybe I should have done it. But I'm not that well known in the Fedora world any more, hence I guess this post won't have much of an impact anyway – and writing things down already took way more time than I wanted it to. At least it finally cleared my head, as the idea to write a blog post like this was circulating in my brain for a year or two already; the upcoming Fedora anniversary finally motivated me to sit down and type it in...
Believe it or not, there are quite a few other things on my mind that I wanted to write about, too. But doing that properly would have required even more time; and they are not as important to me as the two topics I wrote about above. But for completeness, here in very short form is what "Thorsten, the imagined Fedora despot" also would do:
- ensure continued or even intensified investment in the immutable concept (e.g. Silverblue, Toolbox, et al.)
- ensure continued or even intensified investment in supporting Flatpak and Flathub
- talk to other distros to make packaging easier for all of us: a lot of man-power is wasted because packagers on various distros do the same thing over and over again without much peer coordination
- ensure continued investment in making package building possible straight from git repositories
- increase coordination with other distros and upstreams to better handle and coordinate bug tracking – ideally by convincing upstreams to have downstream bug reports, so that users of say Debian, Fedora, or openSUSE will easily find reports a problem an Arch Linux user filed that happens on all distros
- tone down the "package ownership" thing a bit and make package a bit more a wikipedia style
- discourage patching upstream software in Fedora even more, to ensure packagers submit their changes upstream, unless there are very strong reason to carry a patch in Fedora
Ohh boy. This became quite a blog post. Sorry. Never meant to be that long, but I guess I nevertheless even forgot a thing or two. Remember: This was written by someone that is not much active in the Fedora world these days – and all just a "What would I do as supreme ruler" thought experiment of megalomania. But even as a supreme ruler I'd not immediately set out and realize my ideas – I'd first discuss and fine-tune them together with stakeholders and the community.
EOF
P.S.: feel free to add comments about this idea to my fediverse posting about this text.
Keine Kommentare:
Kommentar veröffentlichen