kuberoot

IIRC people were testing cybertrucks for some auto-closing functionality, and if they encountered resistance, they would back off... Then try harder, slicing through hotdogs

One point on perception - doesn't the sun appear somewhat yellow because the blue light has a stronger tendency to scatter, meaning that the roughly white light of the sun is less blue, with all the blue color of the sky being taken away from the color of the sun?

Ambiguous, yes; very ambiguous, though, sounds like you're preemptively dodging any blame for misreading :P

Right, but that requires somebody to find and document exploitable firmware revisions, create and distribute hardware/software to exploit them, develop the aftermarket software/hardware, and all that potentially separately for each car model. And then that just becomes a war with the manufacturers, who might try to update their firmware more aggressively, lock things down more, and threaten/sue people working on such things.

Blaming AI for burning the planet is like blaming guns for killing children in schools, it's people we should be banning!

One counterpoint - even with a weak speed to capacity ratio it could be very useful to have a lot of storage for incremental backup solutions, where you have a small index to check what needs to be backed up, only need to write new/modified data, and when restoring you only need to read the indexes and the amount you're actually restoring. This saves time writing the data and lets you keep access to historical versions.

There's two caveats here, of course, assuming those are not rewritable. One, you need to be able to quickly seek to the latest index, which can't reliably be at the start, and two, you need a format that works without rewriting any data, possibly with a footer (like tar or zip, forgot which one), which introduces extra complexity (though I foresee a potential trick where the previous index can leave an unallocated block of data to write the address of the next index, to be written later)

I think most of the work is in the fact that there often isn't an "equivalent call", and it can be quite a lot of code to make it work. One funny thing is the whole esync-fsync-ntsync issue, where synchronization is done differently on Linux and on windows, and translating it was a big performance hit, and difficult to do accurately. If I understood correctly, esync, fsync and ntsync were a series of kernel patches implementing additional synchronization code in the kernel, with ntsync actually replicating the windows style.

I might be wrong, but I don't think proton is either? It's running x86 instructions either way, wine just provides a way to load it from the windows executable and library formats, and together with proton they provide implementations of windows libraries for those executables to use.

Are you sure that site is trustworthy? It kinda reads like an LLM being told to explain the difference between two names for the same thing and basically rephrasing the same thing. I'd imagine it might just be a different name to get rid of a male-coded word.

That actually sounds like a fun SCP - a word that doesn't seem to contain a letter, but when testing for the presence of that letter using an algorithm that exclusively checks for that presence, it reports the letter is indeed present. Any attempt to check where in the word the letter is, or to get a list of all letters in that word, spuriously fail. Containment could be fun, probably involving amnestics and widespread societal influence, I also wonder if they could create an algorithm for checking letter presence that can be performed by hand without leaking any other information to the person performing it, reproducing the anomaly without computers.

I'm not a security expert, but to my knowledge that's the point - even a unique salt global to your site/service can help. Worth mentioning are rainbow tables, which are databases of hashes for known strings, so you can take a hash and look up the string, and very easily defeated by salts.

If the password is securely hashed, and the attack only includes data exfiltration, then there's theoretically no risk of breaking into users' accounts anyways. However, the issue is that if somebody can log into your Plex account, that means they got your password somehow - and if they did get that password, they can use it elsewhere. So if there's any reason to change your password on Plex, then there's just as much reason to change that same password elsewhere.