I totally missed the EOL announcement. Not that I use it, but it is one on the few last big proprietary Unix. I thought their will always be enough paying customers to maintain it (even if sold to third party).
You can add your key to most UEFI system and don't require shim to have it to boot (or disable Secure Boot). You don't require a MS signed bootloader if you don't want to.
I don't understand why they want to put the RISC-V spec behind the ISO paywall. It will just complicate the access to the standardized version to confirm compliance with it.
> At that point Windows XP 32-bit was the most commonly used variant, and while you could run XP 64-bit (and IBM did have native support for it on the IntelliStation 9228), XP 64-bit had so many problems so most users were stuck with 3.9 GB of RAM. Therefore if we were to assume that UNIX and said UNIX hardware offered way more memory, it starts to make sense
Maybe it's just that the cost to set up the production elsewhere is too much for the expected market. The shortage of the drugs doesn't mean there will be enough buyer to cover the cost (and make enough profit).
In order to force the user to change their password more frequently (long term), the user is prevented from changing their password too frequently (short term).
I wonder whether the person who added that is actually confident that the benefits outweigh the drawbacks or is that a case of tunnel vision.
I like the ones that not only keep a history of your old passwords but will reject any password that is similar to any of your 30 previous passwords, which means they're storing either a plaintext or reversibly encrypted list of every password somewhere on the system. Talk about a goldmine for the hacker that dumps that database.
Something like that could probably be implemented by storing multiple hash of some automatically modified version of the password. For example, if your password is "PassWorD" they can additionally store the hash of the lowercase version of the password. So if you change it from "PassWorD" to "paSswOrd", they will see it has the same lowercase hash than the previous one without knowing it.
This doesn't seem practical at all. The combinatoral explosion would make the storage requirements impractical for everything but the absolutely most trivial cases like incrementing a number as the very last digit. Even in your simple example you're talking about storing 256 different hashes just to catch one possible mutation on a way too short password.
You can store a normalised form -- so if the password is `PaSsWoRd` and the user tries to change it to `pA55wOrD`, a normalisation that lower-cases, turns 1 and i into l, turns 2 and 5 into s, and turns 4 into a, would normalise both to `password`.
Or if you want a slightly more convoluted mechanism, when someone changes their password you have both in plain-text and you can take a copy of the old password at that point -- after all, it's not being used as a password any more! For bonus fun, submit all previous passwords to pwned passwords. Password reuse makes this a bad idea in general, specific policies attempting to mandate it will not be an issue notwithstanding.
Technical/pedantic answer: you can store a 'normalized' hashed form of the password, e.g. before hashing it, convert it to all lowercase, replace all digits with 0, sort the characters, … and then do the same to the new password before hashing it, so a whole bunch of stuff will compare "equal".
Practical/actual answer: this is stupid either way.
> Workers KV is in the process of being transitioned to significantly more resilient infrastructure for its central store: regrettably, we had a gap in coverage which was exposed during this incident.
I heard that it was a "mandatory dependency" to mitigate "insider risk" or something. There's no way it's going anywhere. Odds are they'll just enforce even slower rollouts "to catch things early".
Nohting prevent you to use the metric system and use 60cm (for example) as a base unit for your construction. So you can easily divide it by 12 if you want.