I have a raspberry Pi 2 running NetBSD at home providing a lot of useful services.

It uses just 1.5W.

Any more recent alternative would consume much more power.

That’s sort of why this is on my mind.

I’ve just replaced an old Cubieboard (RPi1 alternative - about 2W) running Pi-hole and an old temperamental gigabit router (~10W) with a 2014 Mac mini (plus second Gigabit adapter) - which uses about 11W (a really efficient computer for its age!)

It’s less than the old combo drew - but I wonder if I could be accomplishing the same with an (or even a couple of) SBCs - and if that would ‘pay for itself’ (environmentally well as financially) after a couple of years.

> and if that would ‘pay for itself’ (environmentally well as financially) after a couple of years.

At 11W, the financial costs of running are quite low. I think it's about 90 kWh per year. Depends on your rates, but I've seen $0.60 quoted in comments lately as a high rate for PG&E customers in California, which is about $55. You might well be able to invest in something that can run your load for fewer watts, but I don't know if it's worth the effort.

You're likely to get a lot more savings by looking at things that use more energy.

Why is it NetBSD and which services do you have? I’d love to read about that, and I think I might utilise mine that way too.

NetBSD because I love simplicity and because it draws less power than running Raspbian.

It is running Gitea, Prometheus and a bunch of small tools I wrote (weather monitoring, home automation, family data sharing and tools for my Kids)

But how is it draw less power comparing to Raspbian? I’m not arguing, just curious how you measured that, and why NetBSD that much more efficient. I have a RPi2 with Raspbian, and another one with DietPi, I expect them to sip power similarly, considering they’re mostly idle anyway. Would love to read some blog on this though, if you happen to have one.

I too would like to see a side-by-side comparison but if we assume that the claim is true, one reason might be that NetBSD runs very few daemons after a default install. I run NetBSD on a handful of Raspberry Pi Zero machines, and it is really quite a surprise that they run as well as they do for a $5 computer. Your typical Raspbian install has a lot more going on after the default install.

Do you use the built-in WiFi on any of the Raspberry Pis?

By coincidence I installed NetBSD last weekend on a Raspberry Pi. Never used it before, but it seemed very nice. I had some issues with sshd (most likely just me doing something stupid) and never got as far as experimenting with WiFi, but supposedly there is some support (unlike FreeBSD and OpenBSD that do not support WiFi on any Raspberry Pis?).

Not with any of the BSDs, although I have tried. Instead I either use a USB to GigE adapter or a Waveshare carrier board (for the Zeros). The built in NICs for the ones that have them usually work fine.

If you really need wireless you can buy a USB WiFi dongle, and since there is a lot of support a compatible one is restively easy to find.

> Your typical Raspbian install has a lot more going on after the default install.

I believe that this is true for just about all widely popular distributions. It's probably possible to set up Arch to have power draw similar to NetBSD, but you're going to have to know what you're doing and it's probably going to require more administration/attention to keep running smoothly than NetBSD does.

I had Arch installed on my RPi2s, but I didn’t like the need to update the RPi that frequently, wearing off the SD card. And later on, it became unsupported by Arch ARM. Now I use DietPi, and it’s my favourite Linux distribution (for an SBC server) so far. It has very small number of processes running too). So that’s why I’m curious whether it would be much different with NetBSD.

I just measured it by myself with a domestic power usage tool.

That is fascinating, one of the reasons I hadn't done that is a concern about power management features. I'd read openbsd at least had them running flat out most of the time.

you just need to open one channel to another node (better if well connected) and all your payments will be routed through that node.

If you have multiple channels you have more routing alternatives and can choose the best one for every single payment.

So, for a normal case where multiple people want to trade with multiple other people/merchants we would need a centralized node with connections to every single one of the clients and every single one of the merchants (so a "bank"). Both clients and merchants need to open a channel on L1 (so it's goddamn slow or expensive) to that node and freeze in the channel the full amount of tokens they would wish to spend with every single peer or merchant in the future (so basically a "deposit" of all or at least a lot of the funds in a "bank"). And every merchant would need to do that too for the full amount of anticipated transactions. And then this system will work on L2 somehow, if the system will correctly calculate paths and and sums in all the channels there are. To exit the system, channels must be closed on L1 (slowass or expensive) and if there are not enough funds in the channels, create new channels with more funds, again on L1.

Even in the most absurdly centralized scenario, the system is practically unusable as soon as there are more than a handful users. Or people just stop pretending and use custodian tokens, aka bullshit IOUs.

If you're worried about the durability of your contents, you can publish them on multiple relays, even self-hosted ones.

Also, events are just JSON content: you can easily dump them on your local storage and republish on another relay whenever you want.

I don't know about the good GPU support and is not a rolling release, but Devuan is a systemd-free Debian derivative you might be interested with