It would be interesting to know what share of servers have that enabled.

I have it enabled on Debian and Ubuntu and I’m quite happy with it. But I had pretty bad experiences with reboot-less updates on other (desktop) distros.

Agreed.

You almost need an AI agent in a sandbox to download and run all the POCs to weed out the fake ones until one of them becomes well known.

Sounds like a good malware vector to target security researchers…

Yeah, assuming everyone installed the patch is quite optimistic. But censys probably also undercounts the number of fixed systems, as some Linux distros (e.g., Ubuntu) don’t change the version when shipping security fixes. I’m running the sury.org package which would report as 7.4.33 but has been patched. Still it looks like there’s tons of unpatched services.

Yes, hopefully most people had time to install the updates. And maybe the false exploit reports helped slow down malicious people too.

So it seems like it was rather easy for an IT security professional to create an exploit within 24h of the disclosure. Not sure if every script kiddy can do it, but this means that there are certainly malicious people/organizations who can.

Ultimately, it seems to me that the only real choice is to patch our (public) systems ASAP these days.

I think for me spin-down was working initially. But then I added some Docker containers and those could only be run on the HDDs, blocking spin down. With Debian I just put the containers on the smaller SSD, allowing the HDDs to spin down.

I like being able to drop in whatever disk I need to for expansion or replacement.

I didn’t move that far away (to Debian + ZFS), so that limitation still remains. Although the addition of Raid-Z expansion should alleviate things quite a bit.

My NAS/home server takes about 180 kWH/year, or 20W on average (costs me about 5 Euro/month). This feels like a lot to me and makes up a good chunk of my total energy usage.

What I did to optimize it is mostly select a “low-power” x86 platform, and limit the number of disks. I also decided not to use TrueNAS because it couldn’t let the disks from going to sleep.

The machine hosts 10 TB of usable storage (+RAID 1), syncthing, immich, file server, Influx DB, Grafana, and a few other services.

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…

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.

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.

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.

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:

• ZFS: Each house gets a “NAS” that provides a ZFS filesystem to store the data. This gives you the ability to share the drives across your use cases (you, rest of the family), snapshots, RAIDZ support, and usage quotas. For the OS, you could use what you prefer (TrueNAS, Debian, Ubuntu, …).
• Syncthing to synchronize the files across the servers/houses. This allows you to read and write data from anywhere and syncthing will mirror the writes to the other places. I use it to synchronize data across 5 devices and it works quite well.

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

1. Trying to create a new owncloud instance and put your data somewhere other than in /var, or
2. Try to move the data location of an existing owncloud instance?

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).