It really should be shut down for Arch’s sake.

I think it should really be split into two parts:

1. The more widely used packages should be moved to an official repository with review procedures. Perhaps the (quality) requirements can be lower, but these must be reviewed by trusted people.
2. The remaining packages should be moved to user namespaces, like the other user-package repos do. That will at least prevent (most) takeover attacks.

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.

No, Debian is typically quite a bit older than even the Ubuntu LTS. E.g. they currently still don’t ship a Nvidia driver that supports the 50 series GPUs.

It looks like the fixes were merged in 6.18, 6.19, and 7.0. But all older (but supported) LTS kernels didn’t have the fix, like 6.12, which is used in Debian 13. And it also seems that Ubuntu, RHEL, and SUSE had not picked up the patches in their kernel versions.

That may be true for personal computers, but the impact of this vulnerability is mainly on servers. And those typically run distros like Debian, Ubuntu, RHEL that didn’t have a patch at that time.

It seems that most LTS distros didn’t get a heads up and there are no patches available. Uh oh.

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

I think the problem is that the license grant (that has been in place for a decade) is not that clear.

You are licensed to use compiled versions of the Mattermost platform produced by Mattermost, Inc. under an MIT LICENSE

• See MIT-COMPILED-LICENSE.md included in compiled versions for details

You may be licensed to use source code to create compiled versions not produced by Mattermost, Inc. in one of two ways:

1. Under the Free Software Foundation’s GNU AGPL v3.0, subject to the exceptions outlined in this policy; or […]

I read it as releasing the binaries under MIT and granting people an AGPL license for the (non-enterprise) code. Some read it as not granting you the full AGPL rights.

To me, the fact that they advertise Mattermost as “open-source” and the statement on the “reciprocal license” above indicates that Mattermost also reads this as an AGPL license grant. However, they don’t seem to be interested in fully clarifying the license situation. But, I think they would have a very hard time to argue in court that this license doesn’t allow AGPL forks. And I haven’t seen any evidence of them acting against any of the existing forks.

Eh, that post title is quite sensationalistic.

1. Nothing regarding the license has changed in the last 2 years.
2. It seems like they consider the non-enterprise code to be licensed under the AGPL:

Thank you for the community discussion around this topic. I do recognize that our licensing strategy doesn’t offer the clarity the community would like to see, but at this time we are not entertaining any changes as such.

UPDATE Feb 2, 2026: To be specific, our license is using standard open source licenses, a reciprocal AGPL license and a permissive Apache v2 license for other areas. Both are widely used open source licenses and have multiple interpretations of how they apply, as showcased in this thread.

When we say we don’t “offer the clarity the community would like to see”, that refers specifically to the many statements in this thread where different contributors are confused by other people’s comments and statements.

For LICENCE.txt itself, anyone can read the history file and see we haven’t materially changed it since the start of the project.

If you’re modifying the core source code under the reciprocal license you share those changes back to the open source community. If you’d like to modify the open source code base without sharing back to the community, you can request a commercial license for the code under commercial terms.

Maybe we can hold the pitchforks a while longer, unless they actually make a negative change.

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:

1. From the official Debian packages
2. From Flatpak
3. Pre-built binaries (I put them in my home, not in /usr/bin)
4. Build from source (I also put those in my home)

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.

One option that you could also consider is switching to CachyOS. It seems that they’re handling support for these legacy GPUs in a much nicer way: https://discuss.cachyos.org/t/announcement-maintenance-notice-nvidia-driver-restructuring-580xx-590xx/20010

I have 3080 and I’ve seen significant performance issues too (e.g. in Cyberpunk 2077, KCD2). I think it depends a lot on the games you play. Apparently DX12 (via vkd3d) doesn’t perform well on Nvidia cards.

My next GPU will probably not be an Nvidia card.

Barrier - Keyboard and mouse sharing via network - I use this extensively and the break in compatibility is destructive for me.

Barrier has been unmaintained for a while now. The two active forks are deskflow (upstream) and input-leap. Deskflow has limited supported for Wayland. It seems that they’re working on resolving the remaining issues: https://github.com/deskflow/deskflow/discussions/7499