The arrogance is pretending that user configs and wishes can be arbitrarily dismissed because you can’t be bothered to adhere to them. My computer is mine, not the app maker’s.
You're assuming your concerns were dismissed arbitrarily. Why? Is it possible that your concerns were considered, pros and cons were weighed, and the final decision was simply not in your favor?
And what's this nonsense about "my computer, not the app maker's"? How do you think project governance works? Decisions are made, and every single time a subset of users are disappointed. That subset isn't having control of their computers taken from them. This stuff is happening out in the open, for free, and with express permission to override any behavior you want with your own patches. You can even distribute your patched version, also free of charge. It's downright humbling how free we are when it comes to bash and OpenSSH, and you have the gall to come out with "My computer is mind, not the app maker's"? Do you have any idea how low the bar is for user respect in the average app? How much money can be made if you're willing to disrespect your users? And the bash and OpenSSH folks would never, not ever consider any such breach. They have stayed firm, despite world-blanketing success, in their user-respecting free software ways.
And for a disagreement of where to put config files, you'd lump them in with the user-hating rabble that makes up the rest of the software industry. We're surrounded by people who actually do arbitrarily dismiss user concerns (because the users are the product). People who actually do believe your computer belongs to them when you use their software. Please, in the middle of all this shit, keep in mind who your best allies are and just have a civil engineering disagreement with them, without insulting them.
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.
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.
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.
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.
Honestly, I see some arrogance here but not where you put it. Just like your computer is yours, the developer owns their application. Use it or not, but don't blame them for arrogance if it does not behave exactly like you wish.
Then, by using XDG variables, the user can get precisely what they want, but only from those programs which follow the XDG spec which is designed specifically to enable user control of the locations where files go.
Some here complain about a convention (not using XDG vars) which removes user choice. Others here recognize that the convention to use XDG allows for user-defined configuration.
If a user's wish is different from the XDG default convention, they can change its configuration. If a user's preference is different from the $HOME/.$program convention and the maintainers don't use XDG vars, the user is SOL.
Most users don't care because they do the same with their own files.
The xdg standard just introduced 3 additionnal .config .local .cache directories that do not solve the presence of the regular .dot directories/files. It didn't solve anything, just added more mess. Besides the stuff that end in .config is as messy as what was in ~/.dotdirs. I once was naive enough to think I could put my .config into a git repo...Quickly enough you realise that a lot of developpers put what the fuck they want, including stuff that should be in .local or .cache into .config and you end up writing a novel in your .gitignore.
XDG didn't solve that, it just added additionnal mess, which I didn't wish for.
If it was to end with that mess, I'd rather have it the old way and keep mt dot files at the root and separate my own files into a dedicated folder, and I AM THE ONE to choose if it has to be called files, documents, docs, translated or not, not some people pretending it built a (broken) standard that would solve every user needs.
> Most users don't care because they do the same with their own files.
Maybe I'm not most users, but I absolutely put my files in ~/.config/$my_namespace/
> It didn't solve anything, just added more mess.
Have you ever had to migrate/sync parts of a system across multiple hosts, or even just backup with very limited space and having to be choosy about what is stored? XDG makes it WAY easier to set up rules to include/exclude stuff, than a bazillion .programrc dirs (which make no config/data distinction). Cache can be completely ignored and usually (the more voluminous ) program data can be skipped. The app will usually generate it as needed, and if not, I know what to sync.
Every program and their dog barfing in $HOME is something I didn't wish for.
You computer is yours …and you are not forced to use maker's app. Well sources are opened, so you can change things to suit your needs instead of considering makers as your slaves can't you? :)
