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…
It’s just so phenomenally little it doesn’t make any sense, a full routine wouldn’t even full charge a smartphone battery (not even close). Put solar on the studio roof instead.
I think you’re wrong on that one. E.g. when cycling, 100W for 15 minutes is achievable for most people, which corresponds to 25 Wh of energy. To charge a modern phone you need about 15 Wh. So if your overall system efficiency is at least 60%, which seems realistic, you’d be able to charge a phone with that.
I guess it’s just not financially viable. Because those 25 Wh would still correspond to less than 1 cent in value (at 0.3€/kWh).
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:
- 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.
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:
I’ve created a small helper script to help me with this:
#!/bin/bash
USED_VER=$(uname -r)
echo "Kernel version in use: $USED_VER"
echo "Other installed versions:"
dpkg --list 'linux-image*' | grep ^ii | grep -v $USED_VER
echo "Remove unneeded packages above using the following command:"
echo "sudo apt remove linux-image-VERSION"
It prints a list of the installed kernels (excl. the running one) and prints the command to uninstall the packages (it doesn’t remove anything by itself).
That sounds pretty bad and probably means other things are broken too. The easiest option would probably be a reinstall at this point, but if you want to learn something you can also try to salvage your install.
To recover, it’s probably easiest to manually configure your Ethernet connection as described by InnerScientist and then re-install the network-manager package.
First, you can check the status of the network-manager package using dpgk. It should look like this (ii at the start, but it sounds like it’s not installed in your case):
$ dpkg -l | grep -i network-manager
ii network-manager 1.52.1-1 amd64 network management framework (daemon and userspace tools)
ii network-manager-l10n 1.52.1-1 all network management framework (translation files)
You can also check /var/log/apt/history.log to see what went wrong and if there are other things you need to fix.
I performed the upgrade in two steps apt upgrade --without-new-pkgs and apt full-upgrade (based on the release notes). I can see the following on the line Upgrade: for the command apt full-upgrade:
network-manager:amd64 (1.42.4-1+deb12u1, 1.52.1-1)
On the Remove: line you can see the packages that were removed. Unfortunately, the names of many libraries were changed in this release (e.g., libreadline8:amd64 to libreadline8t64:amd64), so there’s a lot of noise in there. Maybe you can look at that line and ignore everything that starts with lib to see if any other important packages were removed.
One thing that comes to mind is that the 50series is only supperted by the open version of the proprietary Nvidia drivers. The closed version doesn’t support your new GPU, but would work with your old GPU. Do you know which version you installed?
I’m running Ubuntu on a server. I’ve enabled the free Ubuntu Pro subscription to get ESM patches for the universe repository. Not sure if it really matters, but better safe than sorry.
The easiest distros to run Resolve would probably be Rocky Linux 8, Alma Linux 8 (both are based on RHEL 8). Instead of the EOL Rocky/Alma 8.6, you should use release 8.10 (8.6 would update to 8.10 anyway). However, while still currently “supported”, these are still shipping (mostly) 6-year-old (!) packages. Also, only a small number of packages is actively supported by Red Hat. IMO, this implies that these distros offer a lower level of security. The most critical parts (browser, kernel) are still well-supported, so the difference is probably not too large for most regular users. However, you may also struggle to run some other software (although Flatpaks are available). It’s unfortunate that Resolve only supports an ancient version of Rocky (Rocky 10 is now out)…
Read (only) access should be fine. What makes it complicated is if there can be writes from multiple locations. Basically, the simple version would be to just periodically copy the data from the primary to all secondary locations.
I can see why you’d want to go with an off-the-shelf NAS. But, I would carefully check if it supports your use case, as it’s quite advanced.
If the data only needs to be read & written from a single server (and the others are just backups), you can also use simpler replication instead of synchthing. E.g. syncoid or TrueNAS replication. It sounds like you should be able to do that with separate datasets per household in your usecase.
I would probably go with a simple approach like this:
There are probably more advanced (enterprise?) ways to handle the file synchronization. But, I think this hould be good enough for normal, personal use. The main disadvantage is that you’re only synchronizing the current data (excluding the ZFS snapshots). On the other hand, this also allows you to mix file systems if necessary.
I’m not quite sure what you’re trying to do here. Are you
If you’re trying to do the second one, there’s a useful guide on it here: https://omiid.me/notebook/25/move-docker-volume-to-bind-mount. The first one should be even simpler, you can just replace the volumes in the compose file by bind mounts (basically, just this step of the tutorial: https://omiid.me/notebook/25/move-docker-volume-to-bind-mount#modifying-docker-compose).
The Windows filesystem: https://en.wikipedia.org/wiki/NTFS. Basically, don’t try to share the game drive with Windows.
If you have an AMD GPU (except for the very latest GPUs), you should be good out of the box. The AMD driver comes pre-installed with mesa.
Other than that… don’t use NTFS to store your games.
Edit: Maybe I misunderstood your question. I understood it as: What are some recommended changes to do after installing a Linux distro. Did you meant to ask about differences between distros?
The Linux Experiment recently looked into touchscreen support of different desktop enviromenents. His findings mostly align with your comment. However, this seems to be one of the rare cases where the distro matters for Gnome. Upstream Gnome (e.g., as shipped by Fedora) works fine with touch screens, but support on Ubuntu Gnome appears to be quite broken.
The Linux Experiment videos:
I would go a bit further than that. To me, not keeping archival backups for at least a few months seems grossly negligent. To a degree where they should be legally liable for the damages. They probably have some waivers for that in their terms… but they may not hold depending on the jurisdiction.