I had often reboots followed by more update installation and then a shutdown, so I assumed this was working as intended (i.e. finish installing the updates, which might require a reboot, and then power off).

Is this light enough to run on a SBC (think of something with the power of a Raspberry Pi 3 or a bit more) with decent performance (for just 3-4 users)?

I was running it on an Odroid N2 for 2-3 years, and upgraded to a RK3588 Orange Pi something a couple of years ago. It's not fast but it's useable. At one point I succeded in making the collaborative editing working, but it stopped after updates. Maybe it needs more love than what I'm able to spare, but the feeling after years is that you have to accept some level of unreliability.

Fun facts, and/or actual knowledge you might even use one day. This said, I've definitely never had a use for knowing about CORONA spy satellites dropping film cartridges on the Earth (see https://en.wikipedia.org/wiki/CORONA_(satellite)) or about bell-mouth spillways...

Totally true. Also consider that although software can theoretically or technically be patched, sometimes patches just don't exist... the amount of unmaintained but yet useful software is just huge.

Why do they initialize a disk image with /dev/urandom instead of /dev/zero? Given it's not an encrypted disk container, I don't see any valid reason to do so, but perhaps I'm not seeing something?

Probably avoid zero write optimizations. This force actual allocation of disk space for the data, instead of pretending to do so.

So to make future performance more predictable?

Did anyone else read "Go subtitles" instead of the actual title?

Personally the one or the other makes no difference: I wont use it.

At least I can probably make a throwaway discord account, at worst with a phone number verification. With facebook they demand selfie video of your head, maybe your driver's license probably also your phone number. And maybe they just ban the account after all that anyway.

I started reading RFCs as a teenager when I stumbled upon an RFC collection on a CD-ROM distributed with a computer magazine. It didn't last long until I started implementing my own SMTP client.

And then I discovered this, and for a moment I was a bit afraid: TELNET SUBLIMINAL-MESSAGE Option [https://www.rfc-editor.org/rfc/rfc1097.html]. I didn't immediately understand it was a 1st April's joke, and was thinking something like "how many other weird things nobody ever heard about are actually implemented into Internet software?". Also because, of course, I was regularly using Telnet at that time. Then I realized the date and the fact that the option number (which is supposed to be a byte) was defined as... 257. Later I discovered that of course 256 was already assigned to the Telnet Randomly-Lose option, the very first such RFC, a comment of which seems very contemporary despite having been written in 1978: "Several hosts appear to provide random lossage, such as system crashes, lost data, incorrectly functioning programs, etc., as part of their services.".

The whole collection is here: https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_C.... And as other people mentioned, some are really funny.

It should, in the same way you can embed compression-resistant watermarks. But the bit density would be ridiculously low, depending on the amount of noise you can accept.

This is using Twilio, but given there's an Asterisk server behind, you can actually use any VoIP provider that allows outgoing calls over SIP right? Depending on the country you live in and/or where you want to call, you might get simpler & cheaper options (although for emergency service if you want to have it, which I think is important unless there's an alternative way to call emergencies around, it's more complicated).

yes absolutely. I was somewhat familiar with twilio already so I went the easy route. I'm pretty sure you can even hack it up with google voice if you are motivated enough