To be fair, $600 for 64GB of RAM is a steal in this economy (you could probably sell the RAM alone for $800). So if you want that much RAM and are ok with the rest of the system - go for it. I mostly wanted to point out why I personally would not like such a machine (why I’m “sleeping” on it).

Mine was the equivalent of $660 at the time with 32GB of RAM (excl. HDDs). In this RAMpocalypse it would probably cost around $1k.

I am interested in trying out an Arm/RISC-V PC for a Linux server. However, what stops me from buying almost all of them is that they require you to use a dubious, poorly-maintained manufacturer fork of some Linux distro.I don’t want my hardware to become e-waste when the manufacturer looses interest in 10 months, so running an upstream distro (like Fedora/Debian/NixOS) is a hard requirement for me. It seems that they half-solved that issue for this machine, so that’s actually good progress.

For this particular machine, Jeff Geerling also reported that the idle power draw is 17W. That’s higher than my faster, fully-upgradable mATX AM5 x86 NAS…

Induction stoves can typically deliver more power into the the item you’re trying to cook.

Technology Connections tested a small, mobile 1.8kW induction plate against a 5kW gas burner: https://youtu.be/_yMMTVVJI4c Guess which is faster.

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:

1. Run fsck on the partition from a live USB if you haven’t already
2. Enable more verbose logs from the kernel and the initramfs systemd. The LLM suggests removing quiet splash and adding rd.debug systemd.log_level=debug systemd.log_target=console ignore_loglevel (best check the actual parameters yourself).
3. If possible for you: Copy the install to another drive, change the UUIDs, and try again with that.

Debian also supports “unattended-upgrades”: https://wiki.debian.org/PeriodicUpdates

I actually have it set up the same way on both: Automatically install updates (and restart some services), but don’t reboot. I don’t think it was different/easier on Ubuntu.

Overall, the two distros are very similar for a server application. If you’re already running Debian on your PC, I would also go with that for a server.

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.

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