In the space of mini PCs/NUCs, this does seem comparable. But bear in mind that the entire space of “home server” is a lot bigger than NUCs. After all, not everyone just wants to host an NVMe drive or two; they might want to fit some cheaper SATA SSDs or even spinning rust, as part of a cascade of stroage, with caching on SSDs and other nice things.

Likewise, the dual LAN ports with 802.3bz support is nice, but the reality is that most networks are only 1 Gbps with some devices supporting 2.5 Gbps. Quite frankly, for server use that actually needs one or both port’s bandwidth, the link would likely be better served with SFP+ slots, because of better compatibility with cheap enterprise switches available online, and because SFP+ transceivers run less hot than their twisted pair counterparts at 10 Gbps. Heck, you could even use a 40 Gbps QSFP+ NIC, which only requires a x8 or X4 PCIe slot (depending on PCIe generation of the NIC). On that note, a single PCIe slot is nice, but it does preclude the use of a double-wide GPU for transcoding use.

I would sum all this up as lacking expandability. Yes, it can be expanded somewhat. But for folks that want the capacity of an ATX-based build, this ain’t it. And for folks with abundant solar power, electricity consumption for older gen chips isn’t as much of a dealbreaker. It certainly checks off a lot of people’s boxes, yours included, but that doesn’t mean that people are “sleeping on” this, because at the end of the day, if it doesn’t serve their purposes, it’s not the right box for them. In terms of price, never underestimate the cost of $0.00 that is an old, unused laptop; they make remarkably decent servers for light loads.

Also, as of this writing, only the 32 GB RAM variant is available on the USA website.

Corporations even before AI have sued each other, precisely on the premise that “your code looks like ours. We think you stole it” and then have a petty fight in court because their lawyers couldn’t hash out a settlement.

Now with so-called AI washing, it’s only going to get worse, because LLM generated code doesn’t have to be 100% identical to be considered a derivative copy of the original. It all goes back to the central question: did this copy come from this original work?

The corporate IP lawyers will be making bank off of the ambiguity.

I’ve had similar trouble understanding this aspect in the past, so I’ll share how it now makes sense to me, within the frameworks of existing IP law. IANAL.

Copyright law protects a specific, tangible work from duplication, meaning that if someone directly derives an unauthorized copy from an original work (eg scanning a book), then that’s copyright infringement. However, copyright law does not simply look at whether a copy is identical to the original. There must be an analysis of the provenance of the copy: did the copy come from the original?

Two people can separately stand at the Grand Canyon visitor center and use their own cameras to take identical film photos from the same vantage point, such that the developed film is identical in every way. And yet, neither has violated each other’s copyright, because neither photo came from the other. Person A can sell their copy to a magazine, while Person B distributes copies for free with their holiday cards. This is all A-OK.

The trouble is when somebody suspects infringement, because they see a copy that looks unusual similar to an original. If they decide to raise a copyright lawsuit, then the defense would like a way to affirmatively show that “no, our copy didn’t come from your original”. How do they do this?

In software, the approach would be to methods like the clean room approach. This is explicitly a method for legal reverse engineering, precisely to avoid copyright concerns. It works because while copyright protects a tangible work, it does not protect the ideas recorded by that work. So if somebody was given only the idea, and tasked with writing the software that re-implements that idea but without ever seeing the original, then the resulting work cannot possibly have been based on the original work. Rarher, it’s just a take on the same idea, which is allowed to be similar, in the same way as the photo of the Grand Canyon. There is no straight line that connects the supposed copy to the original work, apart from the idea itself, which copyright does not cover.

With LLMs, there is zero assurance that any clean room approach was followed. By training directly on original, copyrighted works, there is a cloud of uncertainty about whether the LLM is regurgitating parts of the original (which would be infringement) or if it actually reduced the user’s prompt into an idea, and then independently generated code which implemented that idea.

Copyright infringement poisons everything that is derived thereafter, so even the spectre of a doubt causes problems, because if GNU or whoever else builds atop questionable copyrighted software, that foundation collapse suddenly if someone brings a lawsuit to enforce their copyright. And those are pricey to defend, even if it’s without merit.

The clean room method, when followed faithfully, is a way to discourage potential litigants from even filing a lawsuit, because it’s clearly obvious that they would fail to prove a connection to the original work. Patents are a different story (where ideas are protected).

LLMs basically have the same problem as when an engineer quits and goes to work for a competitor. Will they have (accidentally or not) taken trade secrets with them and implemented those in the competitor’s product? A well-advised company would go through great lengths to make sure that engineer isn’t working directly on a competing product, to avoid a costly lawsuit. LLMs do no such mitigation.

From memory, I believe it does. But that means the bisection would give the result that the merge commit is responsible for the bug. Which isn’t wrong, but most workflows do not just blindly revert a whole merge, but would have to follow-up to surgically find and fix the bug in the merged-in branch.

So that would be yet another invocation of Git bisect. The hazard is believing that bisect is an fully automated bug finder, when it would just stop at the first merge commit if the bug came in from elsewhere.

The other hazard that I didn’t mention is a presumption that every commit – merge or not – is individually buildable and testable. For good workflows, this is the case. For some… more casual workflows where broken code is pushed and then fixes thereafter, bisect will not be able to hone down to a singular commit.

There are business, technical, and UI/UX reasons for having a client. The business case is that it clearly demarcates the service they’re selling, because it must be installed and isn’t built-in (eg Firefox VPN). The act of having the user do something means that for a brief moment, they have to concentrate on the product. Consumers have this tendency to value things higher if they were involved in its success, such as when building flat-pack furniture.

The technical side is that while a VPN is indeed just a tube that transports packets securely to the VPN servers, the fact is that there are so many ways for this to go wrong. For example, leaking DNS requests is a way to throw the confidentiality guarantee* of a VPN out the window. As can Happy Eyeballs, where the same HTTP request is sent by both Legacy IP and by IPv6; if both aren’t sent through the tunnel, confidentiality is lost.

To deal with this, the client can implement mitigations, such as setting a different DNS nameserver, as well as the (IMO exceedingly inappropriate) measure of disability IPv6 outright. These are not functions which the built-in VPN client in the OS would necessarily do, although some OS network managers genuinely will do a good job. But even more important than applying mitigations is to check for leaks! The client app can run periodic tests to make sure DNS or IP packets are always going down the tunnel, such as by checking destinations that only exist through the tunnel. Failure to pass this test should throw up huge warnings that the user’s confidentiality may be imperiled. This is table stakes for a retail VPN service in 2026.

Finally, UI/UX for a VPN requires that the whole thing be easy: users want to browse the web, download … uh… Linux ISOs, and go about their life with a VPN that Just Works ™. Most people do not want to copy a Wireguard config into the OS using a terminal. A VPN service should have broad appeal, since the fear mongering advertising suggests it’s a product that everyone online should use.

At bottom, we can say that “retail VPNs” really do need a client app. But for technically minded folks, a Wireguard config would be enough, because the endpoints would also be configured to route solely down the tunnel. Or even use an isolated netif, in the case of Linux namespaces, which is IMO quite clever.

Another word of caution: bisection will have a rough time navigating around merge commits, because those introduce nonlinear “forks in the road” that also tend to be introducing large, possibly-breaking, non-trivial changes. But if your workflow is already avoiding merge commits except when necessary, then the drawbacks are minimized.

Yet another reason to prefer linear history in Git whenever possible, because bisect will work more predictably.

That said, if you’re needing to use automatic bisection very often, this may point to a lack of a CI pipeline to validate commits automatically. After all, if a broken change is flagged before you notice, then you wouldn’t need to bisect because the system has identified the faulty commit.

Would cert-manager for Kubernetes be approximately what you’re looking for? In that particular case, it’s a service that runs in a K8s cluster, that can auto-request CSRs and send them to Lets Encrypt using one of the challenge types. It takes care of managing the returned certificates, such as renewing them before expiration and registering the private keys within the K8s key store.

I presume that you’re not already using K8s, so maybe that project will help you find the keywords to describe the sort of certificate manager that you want.

If you’re already using Debian on desktop, then Debian on a VPS makes sense from a maintenance perspective: you only have to track one set of security updates. When there’s suddenly a critical update for some vulnerability, you can update both at once because it’s the same upstream repos. Whereas with Ubuntu on your VPS, you’d have to be mindful to make sure to check back when the same vulnerability is patched there.

Do not underestimate the effort to upkeeping a server, and do try to unify your procedures so you’re spending less time doing the necessary things, and more time building up your self hosting stack.

I vaguely recall seeing (what I hope was) a joke where the C preprocessor allowed the use of Old English in lieu of the typical keywords. I can’t seem to find it right now.

Unirust has you covered: https://github.com/charyan/unirust

(to be clear, that’s a joke and please don’t code with that, even if it would further Rust adoption)

I’m surprised they don’t lock some things behind account logins. Is it that hard to decide what would be acceptable to no longer serve without an account?

From this most recent event, such a policy would probably need to be proposed and voted on, if the voting members of Codeberg want it that way.

The way I read their post, it’s doing double duty: the first is the announcement of the ToS changes. The second is laying out their overall position, because – by their own words – LLMs are controversial and with this announcement, they are pushed into a discussion where not everyone is on the same page. Should the LLM problem continue to get worse for Codeberg, their post is fair warning that future measures might be proposed and voted on. No one should believe that the two ToS changes alone have fully mitigated the LLM problem for Codeberg.

And I think that goes exactly to their point about communities: Codeberg fosters human communities, unlike LLMs that embody nothing, and GitHub that is commercial with a free tier. If something is going to change, it will be by community discussion and decision. In that sense, their radical transparency is exceptional.

I’ll offer a comparison not yet mentioned in the context of hosting software, but which should sound familiar in the social media context: moderation is hard at scale.

By every metric of scale, Codeberg is a competitor to the behemoth that is GitHub. And that means they have to contend with tough choices, such as who and what to host on their servers, no different than BlueSky, Facebook, and the individual instances of the Fediverse. And to be clear, Codeberg has always been limited to FOSS projects anyway, so nobody can genuinely argue that limits weren’t in the cards.

The distinction is that less alike Meta, and more alike with the Fediverse, Codeberg takes no hostages: people with obvious AI repos (or even marginal repos, given the possible ambiguity) are free to take their code and leave. Yes, they have to rebuild their CI pipelines, but that’s always required for any platform, including self hosting.

The fact is that Codeberg is a centralized entity that needs to (try to) make consistent policy. In this case, they have a concern about copyright and nothing anyone says can magically dematerialize that risk. If their new policy is not agreeable, then decentralized self hosting is probably the only way forward. But that was always an option with ForgeJo and federation.

And indeed, folks moving from GitHub or elsewhere are not exactly without fair warning that they might have to migrate again; we’ve not reached a utopia yet.

By what criteria do you say that? You might be right, but without any qualification for how one might be better than another, it’s as useful as saying “purple is better than yellow”.

But ultimately, you’re looking for a moderation paradigm and don’t owe me or anyone else a criteria or explanation for what you ultimately choose. It merely means that the question as posed is unanswerable, no different than “why is green the best color?”.

“best” is relative, and while moderation can achieve a great deal of success on a smaller scale, it’s proven to be extremely tricky at large scale. Mike Masnick of TechDirt (and on the BlueSky board of directors) has documented this rather well, using some very notable case studies.

For example, moderation is both necessary and complex (Twitter post buyout): https://www.techdirt.com/2022/11/02/hey-elon-let-me-help-you-speed-run-the-content-moderation-learning-curve/

Decentralized moderation like Mastodon is good (by blocking Gab from the get-go) but requires active coordination from federated operators: https://www.techdirt.com/2019/07/16/gab-mastodon-challenges-content-moderation-more-distributed-social-network/

At a slightly larger scale, volunteer moderators can be overburdened and lead to adverse infrastructure shutdowns (Parler getting bumped for violating AWS policies): https://www.techdirt.com/2021/01/13/parlers-laughably-bad-antitrust-lawsuit-against-amazon/

My point with these examples is that a moderation system solely based on volunteer effort can be: 1) overwhelmed, 2) manipulated, or 3) antithetical to the purposes of the community and/or platform. There is no magic moderation system that will be 100% effective for your environment at all times.

TIL git history.

That said, I’m trying to figure out what the target workflow is, specifically for the “autorebases all your branches to match” functionality. Assuming we are not talking about rewriting published history – and nobody should ever really be doing that anyway, when multiple commiters are using the same branch – I presume this is a situation where the dev has multiple, unpushed features that are WIP, each in their own local branch and building on each other. The trouble I’m having is the number of commits per feature.

If the number of commits per feature is 1, then that means each branch just has one commit that its dependent branch doesn’t have. What is the point of the branch then? Just have a single WIP branch and keep building a linear commit history. If you need to give someone one of the features, then give them the commit which inplemtns that feature and nothing afterwards.

If the number of commits per feature is >1, then this is certainly more difficult to work with, and the appeal of git history starts to shine when dealing with WIP commirs. But why is the dev in this situation, where they’re building multiple dependent features but they’re none are fully complete yet? Because if they were complete, then I presume the dev should squash the commits so the number of commits per completes feature is 1.

My current thought is that having >1 commits to implement a single feature is a transient condition, and good practice is to get to 1 commit per feature. Is there something I’m missing?

I saw this counterpoint on Mastodon and I think it sums up things rather well: https://hachyderm.io/@chris_e_simpson/116925250364867462

Child labour is such an excellent comparison to use against the “if it is effective why not use it” argument.

What is the absolute simplest way to accomplish this?

< gets on soap box>

The absolute simplest way is to use IPv6: on your Debian machine, assign multiple IPv6 addresses, one for each service you want to expose to your LAN. There’s no penalty with having a dozen v6 addresses.

Although you have those addresses, your machine generally uses just a single one for its own outbound and inbound traffic. For each service, you would edit their config so that they bind to a specific IPv6 address. Finally, you would configure an AAAA entry in DNS so that your chosen subdomain will point to the IPv6 address in question.

As an example, suppose you had three different web servers running Nginx, currently on port 80, 8081, and 42069. What you would change is the server config for each server instance, adidng the IPv6 address as part of the “listen” directive. Since each instance is now bound to a different IP address, nginx can now listen to the conventional port 80 and n’ary will the three collide. In other software, the configuration option you’re looking for is the “bind address”. By binding each app to its own IP, it will only respond if you send a request to that IP (or DNS name, which translates to an IP); this conveniently makes debugging really easy.

For a home network, you might have a single /64 IPv6 subnet. But that still means you literally have billions upon billions of addresses to use before you ever run out. And as you’ve recognized, using DNS names to identify services is a lot easier and intuitive than using port numbers. It also neatly avoids the need to memorize IPv6 addresses, because that’s never been necessary: we have DNS.

If your ISP won’t give you IPv6, you can still use locally-assigned private ranges, known as ULA, and this works because your services are contained to your LAN. Best practice is to randomly generate a subnet then use it.

< gets off soap box>