litchralee

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

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

That does appear to be the adhesive used to secure tall/heavy components so that they don’t break off during shipping or when lightly impacted.

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.

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.

the higher I can get the frequency, the less ripple I’ll have to deal with.

Why not just use a low-pass filter to remove the switching frequency? Most regulator outputs are already buffered with a large capacitor to stabilize the voltage, so adding the inductor to form an LC circuit is not exactly adding much.

However, there’s nothing really stopping me from doing variable frequency.

Why make this harder? A constant frequency simplifies the analog design, because you can do the bandwidth analysis once when verifying stability. A feedback loop that is statically and dynamically stable at one frequency might entirely fall apart at another frequency, because the frequency response of the regulator itself or the load may interact with the regulator frequency.

combine 3 pwm signals into one per channel

cpu begins grinding cycles to reset the buffers to adjust everything to a new duty center.

I’m struggling to see how this 20 MHz ATTiny would have so much trouble regulating a DC output that it needs to resort to rather strange techniques.

I mainly have experience on the TI MSP430 and ATMega328p, but both those microcontrollers have a robust PWM feature set that includes fixed waveforms that trigger an output whenever a value in memory is equal to the waveform. Such a value could also be the result of the ADC, meaning that zero CPU involvement is needed to keep regulation. That the ADC and PWM peripherals can be clocked independently from the CPU means this can all be done in the background, so the CPU can just go to sleep.

If the ATTiny3224 doesn’t have such capabilities, you would want to figure out another way to do things in the hardware peripherals – or even getting a different chip – than do regulation in software.

In the context of DC/DC converters, I don’t know if there’s a specific name for the regulation precision. But analogizing from op amp designs, I think a reasonable term would be “gain”. This is because the objective of the regulation mechanism is to apply a change which brings the output voltage back to some target.

If the output has moved away from the target by -10 mV, then the objective is to adjust the output by -10 mV. But this cannot happen in instantaneous time. The feedback loop delay necessarily means a small lag. But even after the lag, if there is insufficient gain, the output might only be able to move -2 mV per feedback cycle. So it would take 5 cycles to return to the target.

By adjusting the PWM frequency, you might be able to reduce the length of time for each feedback cycle, so doubling the frequency might mean you can now move -4 mV/cycle. But in exchange, there is less precision. So rather than -4 mV/cycle, it now might be -8 mV/cycle.

Doing this for two cycles means the output voltage is +6 mV. So the next cycle would try to correct with -8 mV, which brings the output to -2 mV. And so on.

A higher frequency with reduced precision has resulted in an output that will “wobble” more, but it will indeed converge faster toward the target, when dealing with larger deviations.

A circuit without load that is statically stable will maintain a target voltage indefinitely. Applying a static load to this circuit will cause a temporary deviation, a subsequent correction, and then it’ll maintain the target voltage indefinitely. But applying a dynamic load means this process is repeated over and over. That is to say, dynamic stability is a continual transient condition, and so the analysis is very much related to what happens in a step transition: how a regulator reacts when going from stable to perturbed.

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

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.

< gets off soap box>

I suppose it’s worth mentioning that the 3224 datasheet suggests that it’s perfectly capable of running at 3.7 volts directly, since it has a wide voltage range from 1.8v to 5.5v absolute. But I imagine you have other ICs that need the 5v supply.

I’m not entirely familiar with what you mean by a “convertor”, but I presume it’s some sort DC to AC function. Given the output loading, 3 amps through that Toshiba MOSFET seems reasonable enough, with the power dissipation being something like 0.3-0.5 W max, depending on switching speed.

A push-pull BJT configuration seems like it could be appropriate, if your application will be unbothered by limiting the Vgs to a max of 5.5v (the 3224’s max supply voltage). The MOSFET in question seems to be good for Rds(on) below 20 mOhm at that voltage, so it seems fine for at least a handful of amps.

If you are doing higher frequency switching than a few kHz, then you probably want to use a driver IC. And especially so if you have a higher voltage bus than the 5v needed by the ATTiny.

Is that something you’re looking for? As a practical matter, the effort to maintain multiple release branches and backports – compared to the norm of just maintaining a single main branch – is an outsized effort, available to only well-founded FOSS projects, usually by having an industry sponsor that makes it a priority.

I posit that the grand majority of selfhosted FOSS software, by project count, does not have back ported branches. And so production environments will want to set up an offline validation setup to evaluate update, prior to making the switch. Not convenient, sure, but not exactly insurmountable either.

Downside: breaking changes are fairly common AFAIK.

By my extremely cursory reading, this stopped being a problem after the v2.0.0 release, when they adopted semantic versioning. According, breaking changes would only occur when the major version number is rolled. And version v3.0.0 was just released 5 days ago, whereas v2.0.0 was released in October 2025.

It may be down to taste, but I view 9 months as being acceptable, given the breadth of features offered and the folks willing to put effort into the project.

IMO, abandonware means software that is a dead-end upon its very release, with no hopes or plans for anyone to every build upon it. Abandonware is generally not extensible, follows no good design philosophy that would let someone else build it up, and embodies essentially nothing.

Even a 100-line throwaway Python script has more utility to someone when it is published on PasteBin or whatever. But something like a binary executable released with no source code, with no support, and with no intent by the developer to ever make anything more of it, that’s abandonware.

some ominous comments stating that it is practically unmaintained (which is not true)

Objectively, I can see that the last commit to the default branch was in March 2026, and that the 10th newest commit was back in September 2025. Of these 10, 3 are new features and 6 are fixes and 1 is documentation. I also see in the issue tracker that no project developer replied to the two newest reports, which were reported 2 weeks and 2 months ago.

As a subjective opinion, the explanation that Conduit is essentially rock-solid and this doesn’t need much upkeep or commits, that is just not credible. The Git history shows fixes and new features, but at a rate that averages just one commit per month. And some of those commits are literally one-line changes.

But let’s suppose that the maintainers are uninterested in small UI or quality-of-life features, and only make changes when it crosses their threshold for what is “important” enough. That’s a choice, sure, but let’s see if that holds water. Here is the project’s response to an issue opened in January, with the response being in February that confirms a UI bug and schedules it for the next release.

That was three months ago. No updates. No mentioned branches or PRs or merges. All while this bug remains in place. And that’s understandable for FOSS project developers, for whom the project is not their day job.

But in any circumstances, the totality of the evidence does not inspire confidence, let alone a determination that Conduit is “rock solid”. And that’s even before looking at the code.

TL;DR: the premise of the question is wrong. Conduit is not maintained.

the original switch (as it looks good) which it turns out, does not really appreciate having to switch 230V instead of the 12V (or 24V?) it was designed for. I believe I can patch up the switch to work as designed, however I do want a better solution to switching the lamp on and off.

Please, please do not ever subject electric components to more than their rated voltage. Unless the switch has an overt label that says it is rated for: 1) 230 volts, and 2) AC, this is a recipe for tragedy.

I will briefly explain why, and then get to the suggestions. In a nutshell, components designed for 12 volts use closer spacing between conductors, premised on air’s natural insulating ability. Likewise, the insulation and plastic housings are designed to withstand that low voltage without becoming a hazard. But higher voltage means the spacing must be wider, the insulation thicker, and above 60 volts is when more strict regulation come into effect, because that’s the international threshold for where there is a serious risk of fatal electric shock.

As for DC vs AC switches, they are built differently to suppress arcs that form when opening the contacts. When a manufacturer gives the voltage rating for both DC and AC, it is often the case that one is substantially lower than the other, depending on which type of arcs they intended the switch to safely suppress. This is a worst-case rating, though, and a modern LED light bulb is unlikely to cause arcs (except when it’s dying).

To my knowledge, there are no common pre-built relays that provide their own low-voltage DC supply. Some relays do provide low-voltage AC (eg 24 VAC to control 240 VAC), but that doesn’t help you since that’s still putting AC into a DC switch.

However, a fairly safe approach would be to use a 230 VAC relay with the most common, safe power supply in the world: a USB phone charger. Provided that your relay can switch on 5 VDC, it should be easy enough to find a small USB charger that can be hidden inside the lamp, wired safely to 230 VAC, and that feeds 5 VDC to your existing tractor switch, which connects to the relay.

Given that your original problem was related to WAN upload performance, why did your investigation lead you to Ethernet flow-control? An ISP connection generally deals in packets at Layer 3 (“network”, eg IP) of the OSI model, whereas Ethernet is a Layer 2 (“data-link”) layer technology.

If there is a bottleneck at your WAN modem, then that will cause congestion at layer 3, but Ethernet flow-control can only deal with congestion that exists at layer 2. What has likely happened is that you have configured your gateway so that congestion at layer 3 is mirrored onto your layer 2 LAN. And if flow-control is enabled, then that would result in back-pressure propagating back to your VMs. Your VMs will then slow down their layer 2 rate, which conveniently forces the layer 3 traffic to also slow down.

This is an incredibly round-about and inefficient way to do traffic shaping. You should not configure a network so that L3 and L2 issues bleed into each other. A major consequence of using flow-control in this way is that it reduces the capacity of your LAN, even for traffic that isn’t going out to the WAN.

The customary approach for keeping L2 and L3 separate is to perform traffic shaping solely at the threshold where your LAN meets the bottleneck. This would be OpenWRT, since after OpenWRT would be the WAN (50 Mbps upload). OpenWRT would be configured with some sort of QoS feature so that certain L3 packets are selectively dropped.

You cannot do effective L3 traffic shaping without dropping packets. In fact, all competent L3 protocols expect dropped packets in order to slow down their data rate: SCTP and TCP have their own exponential congestion control mechanism, UDP simply accepts that some packets won’t make it through, and QUIC has its own mechanism as well. Simply put, all L3 protocols only understand one signal that tells them to slow down, and it is to drop a few packets. They will adjust accordingly, finding the stable equilibrium where traffic flows at the very cusp of congestion.

The Main reason for this problem seems to be the down-stepping of 10Gbit traffic to 1Gbit devices

This is a red-herring, for the reasons I’ve outlined above. With 1+ Gbps connections on your LAN, your L2 network is an order of magnitude faster than your WAN upload. It cannot be the case that a fast LAN makes a slow WAN slower. This is not RF impedance where step-transitions cause reflections; we are dealing in packet-switched networks, where queuing theory controls.

TL;DR: please try OpenWRT QoS instead

This is not a good idea: having to search means an implicit reliance on a search engine. Even with a trustworthy web search – and those are becoming fewer and fewer – why add this complication? The URL doesn’t even have to be large; it just has to be readable.

Even worse is when there’s an adversary: what would stop someone from buying getcontinuwuity.org but have it be pro-Big Tech propaganda, with tracking cookies galore, and then pay Google or Bing to put it at the top of the web search results?

Whereas in 2026, a URL is not confusing at all to include. People know what http:// or https:// mean. Even big brands might not own their own product name’s domain. This exact problem came up just six days ago: neowin.net/…/paintnet-can-finally-be-downloaded-f…

The whole point of marketing is to reduce the barriers for people to find something useful or valuable. Adding an accessibility barrier is antithetical to that objective.

This is the homeserver written in Rust, right?

A suggestion: wherever a QR code is included, the human-readable content should be included next to it. Not everyone has a QR code reader handy, or their reader has the bad habit of immediately opening links or apps. In this case, I see that it just goes to continuwuity.org and is benign, but others may be apprehensive at naked QR codes.

(there’s obviously an exception for QR codes that are intended to convey machine info, like TOTP codes)

I agree with this comment, and would suggest going with the first solution (NAT loopback, aka NAT hairpin) rather than split-horizon DNS. I say this even though I have a strong dislike of NAT (and would prefer to see networks using flat IPv6 addresses, but that’s a different topic).

Specifically, problems arise when using DNS split-horizon where the same hostname might resolve to two different results, depending on which DNS nameserver is used. This is distinct from some corporate-esque DNS nameservers that refuse to answer for external requests but provide an answer to internal queries. Whereas by having no “single source of truth” (SSOT) for what a hostname should resolve to, this will inevitably make future debugging harder. And that’s on top of debugging NAT issues.

Plus, DNS isn’t a security feature unto itself: successful resolution of internal hostnames shouldn’t increase security exposure, since a competent firewall would block access. Some might suggest that DNS queries can reveal internal addresses to an attacker, but that’s the same faulty argument that suggests ICMP pings should be blocked; it shouldn’t.

To be clear, ad-blocking DNS servers don’t suffer from the ails of split-horizon described above, because they’re intentionally declining to give a DNS response for ad-hosting hostnames, rather than giving a different response. But even if they did, one could argue the point of ad-blocking is to block adware, so we don’t really care if SSOT is diminished for those hostnames.