Also, the answer to your actual question is no. There’s definitely no way to block people from using any particular characters at the kernel level.

What you seem to be asking for is a way to absolutely forbid all software from writing certain characters to files, and/or from reading those characters. Aside from requiring that the kernel inspect all data in detail before letting other software have it, which would slow everything way down, it would prevent anyone from reading or writing binary data which happens to contain those sequences of bytes by coincidence. Binary data includes things like the programs which make the system work, so blocking those characters would be terminal

It ought to look like a bunch of □, which is the glyph generally used to indicate that the font has nothing to represent the character.

Specifically you’d expect U+25A1 □ WHITE SQUARE

Which is more than the law requires. What they’re supposed to report is an age bracket. You don’t need to store someone’s precise date of birth, and you certainly don’t need to make it available to other software, to report a broad age bracket

Optional as far as systemd is concerned, perhaps, but it’s designed to support a whole suite of software which will expect it to be used.

They’re also making dubious decisions about how it will be done, such as how they’ll handle the fact that date of birth is PII and something advertisers will be delighted to know. The laws they’re trying to support require very limited information, but they’re storing far more than that and they’ve actively decided not to protect it properly.

However optional it may be, they’re effectively defining the standard for what will be stored and how it will be accessed by all of the software which will use it

There are a million ways to back data up, many of them are as simple as “copy it to removable media”, and don’t require any clever operating system features at all.

What removable media you can use depends on the quantity of data, and how long you need the backup to last. Maybe DVDs, or USB drives. If the data is valuable enough, you can also pay for cloud storage and upload it

The reason I tend to object to these things is that bikeshedding isn’t free, it creates work and technical debt. That raises the bar for changes we ought to make, and I think it raises it quite a lot higher than objections which are frequently specific to the US and are largely imaginary (which is my honest interpretation of most of these changes).

That said, “genocide” is clearly unnecessarily provocative. It’s also not an industry-wide change, it’s just one function, so this particular change seems sensible to me

Be cautious about trusting the AI-detection tools, they’re not much better than the AI they’re trying to detect, because they’re just as prone to false positives and false negatives as the agents they claim to detect.

It’s also inherently an arms race, because if a tool exists which can easily and reliably detect AI generated content then they’d just be using that tool for their training instead of what they already use, and the AI would quickly learn to defeat it. They also wouldn’t be worrying about their training data being contaminated by the output of existing AI, Which is becoming a genuine problem right now

“shortest route” and “straight line” actually mean pretty much the same thing. The shortest route is the straight line. Sorry if I confused the matter by switching up the terminology.

Flying parallel to the lines of latitude would mean that your bearing doesn’t change much, sure, but flying in a straight line would require your heading to change continuously.

The aircraft in the screenshot was flying a very not-straight course

That’s misleading. The shortest route would be the “great circular” joining the two points, which lines of latitude definitely are not.

The only line of latitude which is a great circle is the equator.

No, it’s not. It’s noth of the equator, so the straight line route would look like a curve towards the north. This route is curved south, which means it’s actually because of air traffic control routing them along approved flight paths. That might be for traffic management reasons, or because of terrain on the route, or restricted airspace.

No, I’m arguing that the extra complexity is something to avoid because it creates new attack surfaces, new opportunities for bugs, and is very unlikely to accurately deal with all of the edge cases.

Especially when you consider that the behaviour we have was established way before there even was a unicode standard which could have been applied, and when the alternative you want isn’t unambiguously better than what it does now.

“What is language” is a far more insightful question than you clearly intended, because our collective best answer to that question right now is the unicode standard, and even that’s not perfect. Making the very core of the filesystem have to deal with that is a can of worms which a competent engineer wouldn’t open without very good reason, and at best I’m seeing a weak and subjective reason here.

The reason, I suspect, is fundamentally because there’s no relationship between the uppercase and lowercase characters unless someone goes out of their way to create it. That requires that the filesystem contain knowledge of the alphabet, which might work if all you wanted was to handle ASCII in American English, but isn’t good for a system which needs to support the whole world.

In fact, the UNIX filesystem isn’t ASCII. It’s also not unicode. UNIX uses arbitrary byte strings, with special significance given to a very small number of bytes (just ‘/’ and ‘\0’, I think). That means people are free to label files in whatever way they like, and their terminals or other applications are free to render them in whatever way seems appropriate, without the filesystem having to understand unicode.

Adding case insensitivity would therefore actually be significant and unnecessary complexity to add to the filesystem drivers, and we’d probably take a big step backwards in support for other languages

Some devices or software will ignore what the os or network are telling them and use their own DNS servers, mainly to bypass filtering. If that’s what’s happening then you’re mostly out of luck. The best you could do is set up firewall rules to block those other servers, assuming they all even use port 53, but that would probably just prevent those devices from working at all.

It’s not completely out of the question that you could intercept and redirect those requests, if they’re not encrypted