They also looked at Gnome and raw DRM. As mentioned in the talk, there’s no significant difference between Gnome and KDE. Without VRR, they each loose one frame compared to the raw DRM. With VRR all three are on par.
The Gnome results are available in the repo: https://gitlab.freedesktop.org/klysik_nv/xdc_2026_latency/-/blob/main/Charts/heatmap_path_comparison.png?ref_type=heads
I don’t think people with new hardware are typically more technically competent… I think it depends more on the use case and how much money people are willing to spend. I think there are a lot of gamers that are quite new to Linux. But, e.g., right now Debian stable doesn’t support the Nvidia 50 series at all (released in January 2025).
To be honest, it sounds like you’ve tried the prime candidates. You probably know better than us which one fits you best. Ultimately, I also think that it doesn’t make that much of a difference for an advanced user. You can probably get almost any distro to do what you want.
I guess they’re very similar overall. The main advantage I see for Mint/Ubuntu over LMDE/Debian is hardware and driver support. On Ubuntu you get much more recent versions for the kernel, Mesa, Nvidia drivers, … from the HWE stack.
Mostly, I’ve only had minor issues: Old packages on Linux Mint, missing packages on Debian and Arch, system instability after updating without a reboot on many distros (NixOS, Fedora, Alma, …). But I’ve had two major issues that caused me to abandon a distro:
On Fedora KDE, I felt that my system was overall not as stable as other distros. Then they decided to ship (as a rolling update to a “stable” version) an experimental KDE patch that broke the lock screen for a week. The breakage itself was not so bad, but shipping a patch before upstream merged it to their nightly builds irked me quite a bit.
On NixOS, I was not able to get development stuff to work (I’m probably just too dumb for Nix/NixOS). First, I tried to set up a dev workflow that has quite a few external constraints (glibc version, Python version, running on other distros, …). I failed on multiple fronts and gave up on this. Then I tried to build my own KDE/Kirigami app on NixOS and also struggled a lot with it. I struggled for quite a while but gave up on it in the end. I moved to CachyOS afterwards and it worked flawlessly 🤷
This sounds like a rather weird issue. I agree with your take that grub is not the problem. It seems that there is some issue with the kernel, or the initramfs systemd… Downgrading the kernel didn’t resolve it, so maybe it is a corrupted disk after all? Some suggestions:
fsck on the partition from a live USB if you haven’t alreadyquiet splash and adding rd.debug systemd.log_level=debug systemd.log_target=console ignore_loglevel (best check the actual parameters yourself).the CPU is never taxed, albeit undervolted with minus 30 on all cores in PBO
In case of an unstable system, the first thing I would do is disable all overclocks (including PBO, EXPO, undervolt, …)
Do you think benchmark results like these are meaningful when comparing Linux distributions?
They don’t really provide any explanation for why it should be faster than CachyOS. So I’d take their claims with a bucket or two of salt.
Yes, the tax is paid by the consumers. But, those consumers will probably not be willing to pay more just because the company was too slow in updating their cash registers. So the problem quickly solves itself.
I don’t see the problem. Drop the tax and if the companies can’t handle it, they continue to pay it. And once it costs them money they will fix it in 1 week instead of a year.
Ich versuche noch einmal Vikunja (TODO Liste) aufzusetzen.
And to be more clear: OnlyOffice also did not grant permission to use said logo. They used this to try to deny people the ability to create forks, which goes against the core principles of the AGPL and open source.
Yes. If I remember correctly, it was the Proton VPN installation guide for Ubuntu (https://protonvpn.com/support/official-linux-vpn-ubuntu) telling people to install gnome-shell-extension-appindicator. That package in turn pulls in the entire Gnome shell…
It’s a thing where the Gnome desktop is installed as a dependency and shows up on the next boot: https://www.reddit.com/r/gotgnomed
Debian strongly recommends against adding repos from other distributions or other versions of Debian: https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian Doing that can easily break your system. They also recommend against adding repos for specific software packages (e.g. for LibreWolf), but this is generally less problematic.
Personally, on Debian, I try to get packages in this order:
Personally, I’m quite happy with Plasma Wayland on multiple machines and distros. However, Plasma has already been forked to create Sonic DE: https://github.com/Sonic-DE/sonic-win No idea if this will gain any traction once Plasma drops X11. For now, the activity seems to focus on the readme file…
Spreading false information about Gnome claiming it is insecure sounds like a valid concern for the Gnome team.
Could you point me to that, I couldn’t find anything related to Gnome security in the linked article.
A bit unfair IMO by the downvoters to not explain their downvotes?
There were disagreements between Gnome and System76 and they decided to go separate ways. The whole “contributing to upstream” situation is also kind-of muddy at best. Maybe that’s grounds to write a disappointed blog post 4 years ago, but saying that they are “not to be trusted” today goes too far IMHO.
Also, looking at how Gnome and System76 behave upstream (e.g. in Wayland) today, it seems to me that Gnome is the bigger problem…
I don’t know if there are any differences between the two packages. But, the CachyOS version is part of their official repositories and doesn’t depend on the AUR. I don’t know if that would have any implications regarding how often you need to rebuild the module.
Sure, I’d consider that the main option (and it had already been proposed by multiple people here). But, it also seems like that would come with quite a bit of additional hassle, as discussed below. I’ve personally had some quite annoying issues with incompatible DKMS modules… So, instead of using the unsupported AUR option, it might also be worth considering switching to a very similar distro that actually still supports this hardware configuration.
The kernel has supported it for a few years now and it’s a supported architecture for Debian.
For me, the main thing holding me back from getting a RISC-V SBC/computer is the lack of high performance processors. But they seem to be making progress there too.