well if the bots do implement checks for this software, that also wastes their compute, but at a disproportionately large level just to make sure a few images (compared to actual billions of other images) aren’t obfuscated.

That would increase complexity, but I kind of like the ability to gauge what the image was probably supposed to be. It seems like AI can’t identify objects as easily even when the changes aren’t really that drastic.

Currently I am experimenting with using a ‘phrase’ to encrypt the image in chunks as well, which has shown some really promising results!

Anubis can do an okay job… (at least so the whole site isn’t being actively DDos’ed) at the cost of compromising user experience a lot by sending harder challenges more often. It kinda sucks that the average user might not have that fast of a CPU, while motivated scrapers might spend tonnes on compute just out of spite.

(i am a bit biased on this though)

you can use it to (sometimes) transplant your personal config and documents onto another OS, but it comes with the tradeoff of losing space in root that might be used for massive libraries (compute libraries suck in this regard).

And sometimes your /home will depend on things that your rootfs doesn’t have, which has caused problems for me before. But if you planned for these things beforehand, and your installed software doesn’t do something really dumb, it can work out pretty well, although my personal experience with this is limited to effectively embedded Linux where this is usually a non-issue.

Even ext4 still has safety measures (BLOAT!11!!1) because of journaling.

This is why i compile my kernels on ext2 with without swap for maximum utilization /j

I wonder if using a hash-based system could work slightly better (on platforms where you can’t edit image links) in these cases where a platform decides to stop serving to some users or go defunct. So that way, you can at least have a slight chance of ‘fixing’ an image after the fact.

It wouldn’t work with most image share sites, but at least you could rehost it on a mirror yourself.

if we are being kinda serious, we would probably just go with either the systemd user metadata solution, or… (on a scale of insane to less insane):

• store it in a passwd comment (which means the finger command will now remotely leak age, but is backwards-compatible)

• have an SELinux (or similar) setup so that new users have more restricted permissions by default. While I would absolutely do this myself whenever I have kids, this is just really unnecessary for most everyday users. At the very least this obfuscates the reason why a user might have less permissions.

• make a generic, encrypted-by-owner file in /etc/, but this still has privacy issues if we need every account to state their age.

Obviously the best solution is just educating parents about managing parental controls, but we can’t have nice things ig.

for once this is just me reverting back to caveman brain where i just do > char + 64 and char + 96 tests so I can avoid stdlib on C… (which is really dumb)