3 ms·

>Is it possible that your concerns were considered, pros and cons were weighed, and the final decision was simply not in your favor? // Could you give a couple

>Is it possible that your concerns were considered, pros and cons were weighed, and the final decision was simply not in your favor? // Could you give a couple of example reasons why a developer would choose to ignore community standards here?

tsimionescu 3y ago
As has already been pointed out, plenty of existing scripts and users know that SSH keys and other configs are in $HOME/.ssh/. If OpenSSH moved to XDG, such a script or user would come to a new machine using XDG and not be able to find the SSH configurations. A user might be able to learn where they are, but a script wouldn't. Similarly for .bashrc. Given how often tools like bash and ssh are used programmatically and not just interactively, it is very much conceivable that the right choice, the one that brings the least amount of harm to their users, for bash and OpenSSH is to stick to their existing conventions forever. I should also note that $HOME/.program-name is very much a community standard that the XDG people decided to move away from. Or at least it used to be.
- kortex 3y ago
  The way I handle it on my systems, certain programs such as ssh and bash get "special status". They are so deeply fundamental that they get a pass when I gripe about .rcfile proliferation. You get .ssh/, .netrc, and .bashrc, I'll allow it. That doesn't mean every .dumb_tiny_cli_rc gets to do that as well. > I should also note that $HOME/.program-name is very much a community standard that the XDG people decided to move away from. So was every single inferior standard or convention, before it was replaced by a better one. It's called progress. It's a balance between improvement and breaking changes / disruption, but you need some improvement over time.
  - tsimionescu 3y ago
    The poster above was making two claims that I responded to: 1, that apa writing their configs in dot files under $HOME is "breaking community standards", and 2, that there is never a good reason to do so.
LastTrain 3y ago
Have you never worked on a legacy product with lots of paying customers? The not-so-hard to imagine case is where updating your code to be Pure and Wonderful would have a negative impact on thousands or millions of existing deployments.

tsimionescu 3y ago

As has already been pointed out, plenty of existing scripts and users know that SSH keys and other configs are in $HOME/.ssh/. If OpenSSH moved to XDG, such a script or user would come to a new machine using XDG and not be able to find the SSH configurations. A user might be able to learn where they are, but a script wouldn't. Similarly for .bashrc. Given how often tools like bash and ssh are used programmatically and not just interactively, it is very much conceivable that the right choice, the one that brings the least amount of harm to their users, for bash and OpenSSH is to stick to their existing conventions forever. I should also note that $HOME/.program-name is very much a community standard that the XDG people decided to move away from. Or at least it used to be.

kortex 3y ago
The way I handle it on my systems, certain programs such as ssh and bash get "special status". They are so deeply fundamental that they get a pass when I gripe about .rcfile proliferation. You get .ssh/, .netrc, and .bashrc, I'll allow it. That doesn't mean every .dumb_tiny_cli_rc gets to do that as well. > I should also note that $HOME/.program-name is very much a community standard that the XDG people decided to move away from. So was every single inferior standard or convention, before it was replaced by a better one. It's called progress. It's a balance between improvement and breaking changes / disruption, but you need some improvement over time.
- tsimionescu 3y ago
  The poster above was making two claims that I responded to: 1, that apa writing their configs in dot files under $HOME is "breaking community standards", and 2, that there is never a good reason to do so.

LastTrain 3y ago

Have you never worked on a legacy product with lots of paying customers? The not-so-hard to imagine case is where updating your code to be Pure and Wonderful would have a negative impact on thousands or millions of existing deployments.