I guess you could have an integration test that validates that your installer puts the man pages in a directory that man searches in? It's a bit far-fetched but also not entirely outlandish.
> My best guess for why is that it's a way to not be wrong.
It's also often used to make things seem better or worse than they actually are. "Thousands of dollars" sounds like it's far more than for example $2,108.
Do you have any references that elaborate on that? From an outsider perspective, the time64 transition in Debian seemed to have been relatively uncontroversial and smooth. Way better than e.g. the /usr-merge.
I'm continually impressed by Debian. My Debian systems are pretty boring, so maybe it's to be expected, but as an end-user neither the /usr merge or time64 transition broke anything for me, and I'm using Testing.
Requiring a timezone seems sensible to me, but I don't understand the choice to make it a required part of the expression, instead of a separate parameter. Most software specifies the timezone separately from the expression (e.g. k8s has separate `schedule` and `timezone` keys).
Nah, you still have those dependencies, they're just integrated in your interpreter. That has advantages (you're now only trusting a single source) and disadvantages (you always get all the goodies and the associated risks with that, even if you don't need them).
Your computer doesn't actually know what the keys for WASD are. It just receives a number (commonly called scan code) for the pressed key from the keyboard, and has to use the mapping to determine which key that actually was.
There's some convention for which scan code to use for which physical position on a keyboard, but that's not correlated with what's actually printed on the key caps. E.g. on common QWERTY keyboards the "A" key will have scan code 4, but on AZERTY keyboards it will have scan code 20.
Games can probably get away by listening for the scan codes of the keys in the position commonly used by WASD, but it's a bit fragile, and they can't actually tell you what's printed on the keys they're listening to. The lack of consistenency is certainly annoying, though...
> Games can probably get away by listening for the scan codes of the keys in the position commonly used by WASD, but it's a bit fragile, and they can't actually tell you what's printed on the keys they're listening to. The lack of consistenency is certainly annoying, though...
The operating system knows how to map scan codes to characters based on the keyboard mapping the user has selected.
Hell, glfw nicely wraps all of these up with glfwGetKeyName.
Stop reading character codes directly, use the scan code and when displaying them map it using the system API so people see the right freaking binding. It's not rocket science,
Scancode vs character code is what they are describing:
Games SHOULD use scancodes for positional mappings (like WASD) and rely on the system keymap to decide what letter to display them as. There is no "probably" here, the scancode is the scancode and the keymap is the keymap.
Games OFTEN use the character codes directly regardless if it's for a positional mapping or not. This requires explicit support in the game for each possible system keymap, otherwise you end up with nonsense mappings.
Instead of writing out "no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty" in the authorized_keys file; you can use the "restrict" keyword to enable all current and future restrictions.
