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

Upstream, the Fedora KDE Plasma edition is also doing well. Nice to see that within the first release after promotion to a full edition.

I generally agree, but keep in mind that CPU TDP is not a good metric to predict the total power consumption of a home server. Most of the time, the CPU is in a very low power state and the power consumption is dominated by things like the mainboard, drives, PSU, … Wolfgang has a good video on the topic: https://youtu.be/Ppo6C_JhDHM?t=239

That said, the conclusion that the 5600U system draws more power than a N150 one is probably still correct in most cases.

The Ryzen 5000 series should be a good choice for such an application, they’re still quite powerful CPUs. You should just make sure that you get the notebook/APU variant of the CPUs (e.g. 5600G or 5600U) and not the desktop variant (e.g. 5600 or 5600X). The desktop variant has significantly higher idle power consumption (see e.g. https://www.reddit.com/r/HomeServer/comments/1l707yc/nas_idle_power_usage/, they report 50+W in idle, while my 8500G system idles at 17W). The one you linked should be fine.

It’s either +44% (from $70) or -31% (from $101). Percentages are weird…

Yes, and it should probably be cheaper in Poland. But it’s really 17% more expensive in this case, not 44% (or 30% as the article calculates).

The Polish price includes 23% VAT, no?

15 years is too long, it doesn’t match the state of the industry or technological progress.

How is this too long? I would consider it a reasonable amount of time to receive security updates on a computer.

I have a notebook that I bought in 2012. It can run Ubuntu LTS 24.04, which is supported until 2034, without issue. There is no indication that the next release will stop supporting this hardware. I don’t see why Microsoft couldn’t provide this.

Interesting, I didn’t know that but it seems like Wayland is indeed CSD by default. However, all relevant compositors except for Mutter support xdg-decoration (https://wayland.app/protocols/xdg-decoration-unstable-v1). So in practice it’s still only a Gnome issue.

No, that’s Gnome, not Wayland. KDE still prefers SSD on Wayland.

I feel it has gotten much better in recent years. The first time I tried KDE 5 it looked weird to me. But now I acutally quite like KDE 6. Or maybe I’ve just learned to tolerate it…