Just try it. Here’s an example that I know it will work flawlessly for, because I used it for this: at $formerjob, all laptops come with a piece of malware called “connections”, which obnoxiously pops up at some point during the day (stealing window/mouse focus) and asks you some asinine survey question about morale on your team and/or the company values. There are a few good ways to solve this: apparmor/selinux (but this runs the risk of your config file conflicting with the rules shipped by IT), a simple bash script that runs pkill every 5 seconds (too slow and it still steals focus, too fast and your laptop fans start spinning), etc. A better way is to use a bpf hook on execve.
Ask an LLM to write a simple ebpf program which kills any program with a specific name/path. Even crappy local models can handle this with ease.
If you’re talking about more complicated map-based programs, you’re probably right that it will struggle a bit, but it will still figure it out. The eBPF api is not very different than any other C api at the end of the day. It will do fine without the standard library, if you ask it to.
Your TLD registry operator still technically remains fully in control of your records. I am actually surprised more of them have not abused their power so far.
Most TLD operators are non-profit foundations set up by nerds in the early days of the internet, well before the lawyers, politicians, and MBAs could get their hands on it.
If you want to see what happens otherwise, just look at the gTLD landscape. Still, genuine power abuse is relatively rare, because to a large extent they are selling trust. If you start randomly taking down domains, nobody will ever risk registering a domain with you again.
The most important TLDs are decidedly not non-profit foundations run by the nerds who set them up in the 1980s, and governments routinely manipulate the DNS for policy reasons.
"Unicode" aka "wide characters" is the dumbest engineering debacle of the century.
> ascii and codepage encodings are legacy, let's standardize on another forwards-incompatible standard that will be obsolete in five years
> oh, and we also need to upgrade all our infrastructure for this obsolete-by-design standard because we're now keeping it forever
> "Unicode" here means the OG Unicode that was supposed to fit all of past, current and future languages in exactly 16 bits.
Well... it explicitly wasn't supposed to fit all past characters when they decided on 16 bits.
And they weren't sure on size for a while, and only kept it for a couple years, so I would make the fact that you're complaining about the 16 bits more explicit.
But also it did turn out to be forward compatible. That's part of why we're stuck with it!
Indeed really not true. For example: I am quite mixed, declared my own race on an unclaimed spot of non-scientific identity-formation, and despite what some would say and discounting any possible future irradiation, my genitic diversity is absolutely zero ;-)
eBPF is a weird, formally validated secure subset of C. No "normal" C program will ever pass the eBPF validation checks.
reply