Thanks, I haven't seen that one before, but I'd really prefer an open source application.

BitWarden already has lots of clients.

Does it? I'd be very much interested to know. I've been looking for other clients before, because I didn't like the sluggishness of the Electron client, but couldn't find any usable clients at all. There are some projects on Github, none of which seemed to be in a usable state. Perhaps I have been missing something.

This is being blown a bit out of proportion though. All they are saying is the official SDK may have some non-free components going forward. So what? It’s a private company, they can do what they want. Or the community can just fork it and move forward with a free one if they want, but it’s just not going to be in the official BitWarden clients. Hardly news or a big deal.

Nobody said that they can't do that (although people rightfully questioned that their changes are indeed comatible with the GPLv3). I very much disagree that this isn't a big deal, though.

When you use a typical 74 Wh ("20000 mAh") power bank, you can expect more than 12 hours of runtime, if your average power draw stays at or below 5 W. Of course you aren't going to do much transcoding with a Pi in any case, but multiple concurrent streams shouldn't be much of an issue.

Seen raspberry pi mentioned some times, I don’t have one, so maybe I’m wrong, but I don’t think there would be an easy way to power it up on a train for example.

You could fairly easily power it from a USB power bank. At least up until the Raspberry Pi 4. The Pi 5 with its weird 5 V / 5 A power requirement is a different beast. They should have gone with something standard like 9 V / 3 A PD. It might still work ok if you don't power lots of peripherals with it.

How do you store a driver’s license in Bitwarden? Last time I checked they didn’t support file storage. Do you just put it in the cloud storage?

They do support file storage. I've been using that for years for storing small files related to certain accounts an such.

At least 900VA capacity

Just being pedantic here, but VA is a power rating, not a capacity rating. A UPS has both a power rating that tells you how much power it can deliver at any given moment and a capacity that tells you for how long it can do so.

Great shot! One of my favorite birds.

I would advice against using SSDs for storage of media and such. Not only because of their higher price, but also because flash memory cells tend to fade over time, causing read speeds to decrease considerably over time. This is particularily the case for mostly read-only workloads. For each read operation the flash memory cell being read loses a bit of its charge. Eventually the margin for the controller to be able to read the data will be so small, that it takes the controller lots of read operations to figure out the correct data. In the worst case this can lead to the SSD controller being unable to read some data alltogether.

No, tmpfs is always located in virtual memory. Have a look at the kernel documentation for more information about tmpfs.

It is. It might end up on disk in swap, if you run low on memory (and have some sort of disk-based swap enabled), but usually it is located in RAM.

Try diasbling the second DHCP server altogether. You only need one, since you have a flat network.

Are you sure there is exactly one DHCP server running?

I'm exclusively running unprivileged LXC containers and haven't had any issues regarding the firewall, neither with iptables nor nftables.

No, it is not like Docker. You can treat an LXC container pretty much like a VM in most instances, including firewall rules. To answer the question, you can use fail2ban just like you had done in your VM, meaning you can run it inside the LXC container, where fail2ban can change the firewall rules of that container as it sees fit.

You could give bubblewrap a try instead. It is quite similar to systemd-nspawn.

I understood that. My point was rather that in this particular case (a CPU bug that could be fixed via microcode, but AMD chose not to do so for certain CPUs), RISC-V wouldn't have been of any advantage, because there would be nothing to fix in the first place. Sure, one could introduce microcode for RISC-V and people have argued in favor of doing so for this exact reason, but the architecture was intentionally designed to not require microcode.

As much as I like RISC-V, it is kind of ironic to suggest RISC-V ist the solution to this. At least as it stands, because of RISC-V's simplicity, most if not all current RISC-V CPUs don't even run microcode, so there is nothing to update/fix in case of a CPU bug. There's even a very current example of this problem with that chinese RISC-V cpu that has this "GhostWrite" bug that allows every unpriviliged process to gain root access.

That's good, I never liked the clunky .home.arpa domain.

Thanks for your notes on that part. Sometimes, when I didn't have a special temperature sensor part at hand, I have used a normal silicon diode as a temperature sensor. That works okay, but calibrating it is a little annoying, as it isn't exactly linear. For more serious projects, I usually use the DS18B20. I like that part because it is easy to use, no need for any calibration, since the D/A conversion happens internally in the component and you talk to it digitally.

What does it offer that nginx doesnt?

Automatic HTTPS, you don't have to use certbot or something similar to get/renew certificates. Also, its configuration is really simple and straight forward.