I think the best way forward would be a single board computer that can do an open source equivalent to chromecasting. Plug that in and leave your TV unconnected to the network.
You can't do chromecast directly, because Google holds encryption keys for it. Unfortunately, this means casting apps need to be modified to support it.
There's a few projects like this:
Short of it is that John Deere is preventing farmers from repairing their own tractors. How much it threatens the food supply, I'm not sure, but there is an obvious connection.
That's more of a Japanese company thing than something specific to Nintendo.
Not that it makes it OK, but this is a country that looked at how workers are treated in America and decided the problem was not going hard enough.
OK. How do you reconcile that with "Hashing passwords isn't even the best practice at this point"? Key derivation functions are certainly the recommended approach these days. If they are hashes, then your earlier post is wrong, and if they aren't hashes, then your next post was wrong.
Lots of older databases had fixed length fields, and you had to pad it if it was smaller. VARCHAR is a relatively new thing. So it's not just saving space, but that old databases tended to force the issue.
Nobody has an excuse today. Even Cobol has variable length strings.
It matters for bcrypt/scrypt. They have a 72 byte limit. Not characters, bytes.
That said, I also think it doesn't matter much. Reasonable length passphrases that could be covered by the old Latin-1 charset can easily fit in that. If you're talking about KJC languages, then each character is actually a whole word, and you're packing a lot of entropy into one character. 72 bytes is already beyond what's needed for security; it's diminishing returns at that point.
Sarah Palin had her Yahoo mail account hacked because of those "security" questions. In 2008. We should be well past the time where they are a thing.
Some kind of upper bound is usually sensible. You can open a potential DoS vector by accepting anything. The 72 byte bcrypt/scrypt limit is generally sensible, but going for 255 would be fine. There's very little security to be gained at those lengths.
Some implementers reuse the same salt for all passwords. It's not the worst thing ever, but it does make it substantially easier to crack than if everything has its own salt.
Sorta. Not really.
Key derivation algorithms are still hashes in most practical ways. Though they're derived directly from block ciphers in most cases, so you could also say they're encrypted. Even though people say to hash passwords, not encrypt them.
I find the whole terminology here to be unenlightening. It obscures more than it understands.
Rules here are 64 as a reasonable maximum. A lot of programmers don't realize that bcrypt and scrypt max at 72 bytes (which may or may not be the same as 72 characters). You can get around it by prehashing, but meh. This is long enough even for a reasonable passphrase scheme.
They want AGI, which would match or exceed human intelligence. Current methods seem to be hitting a wall. It takes exponentially more inputs and more power to see the same level of improvement seen in past years. They've already eaten all the content they can, and they're starting to talk about using entire nuclear reactors just to power it all. Even the more modest promises, like pictures of people with the correct number of fingers, seem out of reach.
Investors are starting to notice that these promises aren't going to happen. Nvidia's stock price is probably going to be the bellwether.