Last year I had two new pieces of hardware and Mint was too old, so gave fedora a try. Have been happy with it. There’s a bit less integration with cinnamon but having much newer packages has come without instability so feels like a good tradeoff.
Have been experimenting with systemd-boot and UKI and not in a hurry to go back. I think the Python version is two major releases ahead. Kernel may be three.
I had to write my own script to assign a specific mirror, which was harder than it should have been but is done now.
I've been running Fedora since shortly after Ubuntu introduced Snaps, and couldn't be happier. I haven't experienced any bugs whatsoever, running it on two recentish AMD systems, one with integrated graphics and the other with an RTX3060.
I even installed it on my homeserver several months ago, which is an older Intel SFF PC, and it's been rock solid reliable, currently with an uptime of 21 days.
It's a thoughtful, well designed distribution with mostly sane defaults and nothing I could describe as obtrusive.
I installed Fedora 39 a few months ago. It was kinda working. I had some issues that I couldn't fix, but they weren't strong dealbreakers. I didn't install Fedora 40, because you know, if it ain't broken, don't fix it. But in November it started to complain during boot that Fedora 39 is not supported anymore, it's time to move on.
So a few weeks ago I updated to Fedora 41. (Updating from N-2 -> N is supposed to be fully supported)
I wasn't surprised that it broke my nvidia driver's dkms integration - I don't expect any distro to test their integration of the market leader GPU manufacturer. Whatever, it wasn't hard to fix.
So during the first night I kick off a long job. In the morning I turn on the screen to see what's going on: the system was suspended. When I wake it up, the screen is also locked. That was weird, as I have disabled all power mgment features, and I have also passwordless autologin on this machine. Then looking at some of the logs, it turned out that xdg-desktop-portal segfaulted in the middle of the night, which in turn killed all user sessions and processes and logged me out. And then it ignored my powermgmt settings, and sent the machine to sleep.
Well, that was cool, so I googled a bunch, unsuccessfully. Meanwhile I kicked off the job again, and it finished by the evening. I hoped that it was a one time thing. 2 days later it happened again, and another 3 days later one more time. And this service is not something that you can disable easily.
I stopped using Fedora about 3 weeks ago. Will try again maybe at a later point.
(There are always responses saying "it works for me" - I'm sure it does. I wrote my own experiences.)
Interesting experience, not one I can corroborate myself.
So a few weeks ago I updated to Fedora 41. (Updating from N-2 -> N is supposed to be fully supported)
Correct, and I do believe F39 -> F41 was tested, but every system will be a little bit different.
I wasn't surprised that it broke my nvidia driver's dkms integration - I don't expect any distro to test their integration of the market leader GPU manufacturer.
Fedora actually does test this. What driver installation method are you using? Unless you are using NVIDIA GRID for vGPU or need to use a very specific version of the generic Linux driver, use RPM Fusion's akmod-nvidia package[0]. Normal DKMS via NVIDIA's modularity CUDA repositories or the binary installer can be fraught with issues that users don't deserve. Rather than just installing the kmods directly, an akmod package will build an RPM for the modules and install that. You'll know well in advance if there's a problem before you reboot, nor have to twiddle your thumbs during the upgrade transactions. Just give the system an extra minute after running a kernel update before rebooting (watching "ps aux" for "dnf", "kmod", and "rpm" helps). Several system configurations regarding module parameters and initramfs boot options are included as well.
I finally did this today (I have a GTX 1070), but configuring my kernel parameters[1] to disable NVIDIA's fbdev allows me to once again have alternate console TTYs. Despite being an experimental option, it is enabled by default in newer drivers and it conflicts with another framebuffer. For the past few Fedora releases since it was flipped on I've had to use a second device to SSH to my system after the version upgrade to gracefully reboot once the driver module package rebuilt. The akmod rebuild trigger doesn't stall the offline upgrade reboot, so the driver isn't prepared in time for first boot. My standard practice is configuring my system to the multi-user target before issuing an offline version upgrade, then switching back after.
the system was suspended. When I wake it up, the screen is also locked. That was weird, as I have disabled all power mgment features, and I have also passwordless autologin on this machine. Then looking at some of the logs, it turned out that xdg-desktop-portal segfaulted in the middle of the night, which in turn killed all user sessions and processes and logged me out. And then it ignored my powermgmt settings, and sent the machine to sleep.
That is definitely a new one to me. In addition to your searching, did you happen to follow through with Fedora's problem reporting checklist[3]? It's not a mandatory step, but it can be incredibly helpful having these issues documented and brought to engineering's attention.
[0]: https://rpmfusion.org/Howto/NVIDIA (alternatively just enable the NVIDIA driver specific repository pre-provided by Fedora: dnf config-manager --enable rpmfusion-nonfree-nvidia-driver)
Have been experimenting with systemd-boot and UKI and not in a hurry to go back. I think the Python version is two major releases ahead. Kernel may be three.
I had to write my own script to assign a specific mirror, which was harder than it should have been but is done now.