My Linux laptop is set to check for updates daily, which I then apply manually when I notice the tray icon. I sometimes procrastinate when it comes to reboots though.

My Android phone is on auto-update, which seems to mean whenever it’s being charging for a few hours (so typically when charging overnight). Because the battery is still pretty good and I don’t need to charge daily, that comes down to once every 2-3 nights or so.

My personal Linux servers (which run my self-hosted apps) are configured to automatically apply all updates (and reboot if necessary afterwards) at the time of day I’m most likely to be awake and available to manually fix stuff if anything goes wrong. The Docker-containers that run on them mostly get auto-updated to the latest version every 6 hours by Watchtower. A few containers have more cautious policies though, ranging from pinning a major version (but auto-upgrading to new minor versions within that) to pinning a specific version and at most sending a notification if there’s an update. The latter is limited to stuff that has broken before and/or where newer releases are known to be buggy or incompatible.

When it comes to major updates (i.e. new distro releases) of my Linux machines, I typically wait about a month before upgrading because I’ve been bitten by release-day bugs before.

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 <prefix> :kill-server, assuming default keybindings).

C and C++?

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"¹, 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.

¹: 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…

It also means that ALL traffic incoming on a specific port of that VPS can only go to exactly ONE private wireguard peer. You could avoid both of these issues by having the reverse proxy on the VPS (which is why cloudflare works the way it does), but I prefer my https endpoint to be on my own trusted hardware.

For TLS-based protocols like HTTPS you can run a reverse proxy on the VPS that only looks at the SNI (server name indication) which does not require the private key to be present on the VPS. That way you can run all your HTTPS endpoints on the same port without issue even if the backend server depends on the host name.

This StackOverflow thread shows how to set that up for a few different reverse proxies.

They’ve checked in my code in their own repository, using an automated tool that keeps track of its origin so they can still check for updates. (The build tool knows to check this directory before trying to pull in dependencies from elsewhere)

One benefit to them is that their build won’t break if I decide to delete that specific repository (see also: the left-pad incident) or do silly things with version tags (deleting versions, or re-tagging a different commit with the same version number, that sort of thing).

But more relevantly for this thread, it also means that if I release a new version and they upgrade to it, the PR on their repository won’t just be incrementing a version number in go.mod and adding an unreadable hash to go.sum: the diff will show all the changes I’ve made since the version they previously used.

I may have slightly misremembered the license text (subsection 4c):

You must cause any modified files to carry prominent notices stating that You changed the files;

So I guess technically you only need to indicate that you have changed the files, not what you’ve changed in them. I suppose that’s less burdensome because it only needs to be done once per file at most.

I don’t think so, no.

Leaving aside the fact that I don’t want to do that:

They’ve quite sensibly vendored my library, so I’d have to hope they pull in updates without checking the code changes: since it’s such a tiny library (excluding tests but including fairly extensive comments, it’s less than 100 lines of quite readable code) I don’t think it’d be easy to get it past their code review system if I tried to sneak in enough code to take down entire companies.

Also, my GitHub account is tied to my real-world identity, so I’d probably be in a lot of trouble if I somehow succeeded.

For MIT, why do you care? That’s perfectly fine and explicitly allowed by the license. Same for Apache, but with a few extra requirements (like keeping a list of changes in the source code and preserving licensing information etc.).

As for how I know big corporations are using my code: the fact that a prominent project (publicly used by several tech giants) took a dependency on one of my tiny (permissively licensed) library packages is probably a clue.

[EDIT: removed now that the original is fixed]

And MATLAB appears to produce 51, wtf idk

The numeric value of the ‘1’ character (the ASCII code / Unicode code point representing the digit) is 49. Add 2 to it and you get 51.

C (and several related languages) will do the same if you evaluate '1' + 2.

Fun fact: apparently on x86 just MOV all by itself is Turing-complete, without even using it to produce self-modifying code (paper, C compiler).

It’s the right-most one, partially hiding behind the T in HEIMAT.

If there happens to be some mental TLS handshake RCE that comes up, chances are they are all using the same underlying TLS library so all will be susceptible…

Among common reverse proxies, I know of at least two underlying TLS stacks being used:

• Nginx uses OpenSSL.
  • This is probably the one you thought everyone was using, as it’s essentially considered to be the “default” TLS stack.
• Caddy uses crypto/tls from the Go standard library (which has its own implementation, it’s not just a wrapper around OpenSSL).
  • This is in all likelihood also the case for Traefik (and any other Go-based reverse proxies), though I did not check.