Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)S
Posts
1
Comments
45
Joined
3 yr. ago

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

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

  • 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

    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.

  • And if any gaming will be involved I’d probably steer clear of either of them, since the available graphics driver will likely be outdated rather quickly.

    Ubuntu LTS (and therefore Linux Mint) gets updated graphics drivers between releases, so the situation is not too bad. I'd say it's good enough for most people. You only really have an issue if you want to buy a brand-new AMD/Intel GPU.

    For comparison, Debian 13 (and LMDE) currently ships the Nvida 550 driver, while Ubuntu 24.04 ships the 580 driver.

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

  • Yeah, I looked into ARM or RISC-V options for a NAS, but ended up going with x86. Upstream Linux support is just a hard requirement for me. As the author points out, the support that you get from the SBC manufacturers is lacking at best.

  • Rust implies only 1 thing, and that’s no memory leaks, assuming you don’t use “unsafe” code. It’s still very much vulnerable to logic bugs and has the same performance as c (GNOME) and c++ (KDE).

    Rust actually doesn't guarantee that there are no memory leaks. I think the more important memory safety improvements are regarding use after free, out-of-bounds accesses, null pointer issues, and double free problems.

  • Linux @programming.dev

    Pop!_OS 24.04 Beta Along With COSMIC Desktop Beta In Late September

    www.phoronix.com /news/Pop-OS-24.04-COSMIC-Beta-Sep