No idea about the Lemmy hosting bit, but I highly doubt that .com you got will renew at $1 going forward. Judging by this list it'll most likely be $9+ after the first year.
At $1/year, the registrar you used is taking a loss because they pay more than that to the registry for it. They might be fine with that for the first year to get you in the door, but they'd presumably prefer to be profitable in the long term.
Clearly he's actually the BBEG lich in disguise. Time for a phylactery hunt! ;)
Have you also enabled Bot Fight Mode? (There's a setting to "Block AI bots" that seems useful in your situation)
In Europe I get a voting pass sent in the mail for every election. To vote I have to show both this pass and a valid ID.
In the Netherlands it doesn't even have to be a valid ID. If it hasn't been expired for more than 5 years it's fine for voting purposes.
Try exiting it and then make sure no tmux process is still running, by for example running ps -aux | grep tmux.
For future reference: the command to kill the tmux daemon (and as a side-effect, all other running tmux processes connected to it) is tmux kill-server (or in tmux, typing :kill-server, assuming default keybindings).
The -b in crond -b means to run it as a daemon (in the background), though it appears that is also the default (source). This means the script will continue, but since that's the last line it exits. With the entrypoint stopped, the container also stops.
The fix should be to replace that line with exec crond -f so the crond process runs in the foreground and becomes the main process running in the container, replacing the entrypoint script. crond -f without exec should also work, but that needlessly keeps an extra process (the shell running the entrypoint script) alive.
You don't actually have to set all the modification dates to now, you can pick any other timestamp you want. So to preserve the order of the files, you could just have the script sort the list of files by date, then update the modification date of the oldest file to some fixed time ago, the second-oldest to a bit later, and so on.
You could even exclude recently-edited files because the real modification dates are probably more relevant for those. For example, if you only process files older than 3 months, and update those starting from "6 months old"^1^, that just leaves remembering to run that script at least once a year or so. Just pick a date and put a recurring reminder in your calendar.
^1^: I picked 6 months there to leave some slack, in case you procrastinate your next run or it's otherwise delayed because you're out sick or on vacation or something.
These signs were detected higher in the atmosphere, where the temperature and pressure are more reasonable. And since it took until now to detect the presence of the ammonia, it's probably not a large component of the atmosphere.
So not boiling hot and probably not that much ammonia. That still leaves the thick clouds of sulfuric acid though, those are still very much a thing any probe or mission to Venus would have to be able to deal with.
If you don't mind using a gibberish .xyz domain, why not an 1.111B class? ([6-9 digits].xyz for $0.99/year)
Any chance you've defined the new networks as "internal"? (using docker network create --internal on the CLI or internal: true in your docker-compose.yaml).
Because the symptoms you're describing (no connectivity to stuff outside the new network, including the wider Internet) sound exactly like you did, but didn't realize what that option does...
I've never used Rust or Zig, but for Go: (disclaimer: this is all from memory, so there may be inaccuracies or out-of-date information here)
Go does not allow circular references between modules. That restriction allows the compiler, when compiling a module, to not only put the compiled machine code in the resulting object file for that module but also the information that in C would be required to be in a header file (i.e. type definitions, function signatures, and even complete functions if they're considered candidates for inlining, etc.). When compiling a module that imports others, the compiler reads that stuff back out of those files. Essentially a compiled Go library has it's auto-generated "header file" baked-in.
In older versions this was actually human-readable: an early part of the object file would essentially look like trimmed-down Go when opened in a text editor. IIRC they've switched to a binary serialization format for this some years back, but AFAIK it still essentially works the same.
I guess when comparing to C or C++, you could compare this to automatically generating pre-compiled headers for every module, except the headers themselves are also auto-generated (as you alluded to in your post).
If by "shared library" you mean a dynamically linked one: IIRC Go does allow shared libraries to be used, but by default all Go code is linked statically (though libraries written in other languages may be dynamically linked by default, if you import a module that requires it).