notabot

The TCP connection time out on linux defaults to a bit over two minutes, although individual client programs can use different values, and I’m assuming Windows is similar. Honestly, I was thinking about the time to boot a server, but if you’re just suspending you’d almost certainly be ok, albiet with a slight power draw even when the machine is not in use. Hibernating might also be ok as long as your hardware gets through its POST quickly.

WoL works, but your server will take some time to come back online, but the router probably wont be able to buffer the traffic for that long, and a tcp connection would likely timeout before then anyway. You usually want to send the WoL magic packet, wait for the server to come back online, and only then start sending traffic.

An airgapped machine is certainly going to be most robust from external attack, but even then you should probably encrypt your files to ensure privacy should you ever discard, or otherwise lose control of, the storage media.

An encrypted partition may be sufficient, but your journal entries will still be “plain text” when it is mounted, and so you will be able to read them without extra effort. If you want to make it so that once an entry is written it is encrypted and can only be read with deliberate effort, you could use GPG encryption.

First generate a key pair with a really strong passphrase, and store it on a USB drive. Then import just the public key onto your journaling machine and store the USB drive somewhere safe. With just the public key on your machine you can encrypt files, but you can’t decrypt them. Ideally you’ll set up your journalling tool to only write via GPG, but if not, you can just encrypt each entry after you write it.

As to what journalling tool to use, I like VIM, although I know not everyone gets on with it. You can have it start up with a template ready to go, not write temporary files, and save via GPG so the plaintext never hits persistent storage.

Ah, that frission of excitement when you come to restore! Will it work? Does it contain that very important file? Is it up to date? How much will future you hate past you if it isn’t there?

Have you tested your backups recently? Having them complete is one thing, having the data you need for recovery is another. Have you backed up your vm configurations and build scripts?

Go test your latest backup!

Sure, that would be a little different, but unless you could make a convincing argument, backed up with a solid set of unit tests, at the least, as to why and how you were able to remove that much code whilst only adding a comparatively small amount, I’d still be inclined to reject it and ask for it to be broken down into smaller units.

Now, that explaination might be something along the lines of it being dead code that is not called from anywhere, or even that it was a patched version of an upstream library, and the patch is now included in that upstream, in which case, fair enough, good work, and thanks very much. As a rewrite or refactor though, it’s too big to sensibly review and needs breaking down into separate features.

I’m assuming this is some sort of canary message to indicate that the code base has been compromised, the author can’t talk about it, and everyone should immediately stop using the service. Surely no-one would be unwise enough to commit this otherwise?

Even ignoring the huge red LLM flag, a 25kLOC delta in a single PR should be cause for instant rejection as there’s no way to fully understand or test it, let alone in 2-3 weeks.