GCC says there are a bunch of undefined symbols, first one being "R" right in the beginning:

  typedef  unsigned  char u;
  u w,X,T,D[1<<16],t[]=R,U=255;

Same with "TWI" (Two-Wire Interface) , a name that Atmel (now Microchip) uses for I2C bus. There are 3 wires there (SDA, SCL, ground). Or 4, if you count power.

Maybe I shouldn't. But then I have to deep-dive into yet another flagrant cheap hallucination. You see, when a molecule oxidize, it becomes a different molecule.

It is impossible for a benzoquinone to oxidize, yet remain a benzoquinone. There are just two of them [1], and the two are isomers [2]. Transforming one into another would be isomerisation, not oxidation.

Not to mention — "oxidize on contact with air" is such a pile of nonsense. Just look at those things: benzene ring with a couple of oxygens sticking from it. [1] That stuff is pretty darn stable in presence of atmospheric oxygen.

[1] https://en.wikipedia.org/wiki/Benzoquinone

[2] https://en.wikipedia.org/wiki/Isomer

...and then dozen of words further on:

"blue benzoquinone has the capacity to act against the bacteria that cause tuberculosis, while the red one is effective against Staphylococcus aureus."

How quaint! Blue colorless molecule is different from the red colorless molecule!

I don't think this is a valid argument. Free-tier VPS do exist also.

On the other hand, if you don't trust unattended-upgrades [0], and prefer to spend time poking package manager manually (while at the same time considering that time an expense) - sure, that's a strong argument in favour of using lambda.

[0] https://ubuntu.com/server/docs/how-to/software/automatic-upd...

That story is mentioned in the TFA.

Fish lack urea cycle, so they produce and excrete significant amounts of ammonia as part of normal metabolism.

https://www.kernel.org/doc/html/latest/admin-guide/sysrq.htm...

It's technically not an unmount, but still a pretty strong guarantee OS will not corrupt the image being written.

When done, reboot has to be done from the same sysrq handler, of course.

They are plenty reactive in a sense of interacting with enzymes and other cellular machinery.

But not that much, unfortunately. Those same "cYbeRseCUrITy" orgs also ingest SSL transparency logs, resolve A and AAAA for all the names in the cert, then turn around and start scanning those addresses.

In my experience, it only takes a few hours from getting an SSL certificate to junk traffic to start rolling in, even for IPv6-only servers.

Small percentage of that could be attributed directly, based on "BitSightBot", "CMS-Checker", "Netcraft Web Server Survey", "Cortex-Xpans" and similar keywords in user-agent and referer headers. And purely based on timing, there's a lot more of that stuff where scanners try and blend in.

Nowadays, wireguard would probably be a better choice.

(both of above of course assume one is to do a sensible thing and add "perma-bans" a bit lower in firewall rules, below "established" and "port-knock")

Yep, #1 source of junk traffic, in my experience. I set those prefixes go right into nullroute on every server I set up:

https://raw.githubusercontent.com/UninvitedActivity/Uninvite...

#2 are IP ranges of Azure, DO, OVH, vultr, etc... A bit harder to block those outright.

Built-in approval thing sounds like a good idea, but in practice it's unusable. Typical session for me was like:

  About to run "sed -n '1,100p' example.cpp", approve?
  About to run "sed -n '100,200p' example.cpp", approve?
  About to run "sed -n '200,300p' example.cpp", approve?

Nearly every shell script starts with "#!/bin/sh", so you can't drop /bin. Similarly, nearly every python script starts with "#!/usr/bin/env python", so you can't drop /usr/bin.

Hence symlink.

Eh, kinda. That's where "essential" .ko modules are packed into - those that system would fail to boot without.

Alternative is to compile them into kernel as built-ins, but from distro maintainers' perspective, that means including way too many modules, most of which will remain unused.

If you're compiling your own kernel, that's a different story, often you can do without initrd just fine.

Claude spits that very regularly at the end of the answer, when it's clearly out of it's depth, and wants to steer discussion away from that blind-spot.

When deployed on a popular server, one bit of "IP intelligence" this detector itself can gather is keep database of lowest-seen RTT per given source IP, maybe with some filtering - to cut out "faster-than-light" datapoints, gracefully update when actual network topology changes, etc.

That would establish a baseline, and from there, additional end-to-end RTT should become much more visible.