Even that won’t be truly effective. It’s all marketing, at this point.

The problem of hallucination really is fundamental to the technology. If there’s a way to prevent it, it won’t be as simple as training it differently

If that’s their solution, then they have absolutely no understanding of the systems they’re using.

ChatGPT isn’t prone to hallucination because it’s ChatGPT, it’s prone because it’s an LLM. That’s a fundamental problem common to all LLMs

It was pointed out to me a while back that the paradox of tolerance is only a paradox if you consider tolerance to be a philosophical position.

In fact, we don’t treat it like that. We treat it as a social contract, in which context it is no paradox at all to say that if you aren’t tolerant then other people aren’t obliged to tolerate you in turn

Because printers (of the kinds you’re likely to find on the consumer market) don’t make dust in any significant quantity.

They make fumes, which are an entirely different kind of hazard and need different precautions

That’s not been my experience. Every time I take a link to share from the app it includes tracking which I need to remove

Stories about events we can identify in the archeological record, probably. Forest fires, major battles, geological events, things like that which can be used to line the stories up with specific real-world events

Presumably they stopped doing it in those states, or it’s being appealed or something.

Also possible they’re just ignoring a court order, I suppose, but that seems unlikely

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

Fair enough, I didn’t consider compute resources

The actual length of the password isn’t the problem. If they were “doing stuff right” then it would make no difference to them whether the password was 20 characters or 200, because once it was hashed both would be stored in the same amount of space.

The fact that they’ve specified a limit is strong evidence that they’renot doing it right