10 ms·
This has always seemed sort of passive-aggressive on the part of the spec. "No, memorizing our various custom env var names is not sufficient. Developers must a
by jessaustin 5y ago
This has always seemed sort of passive-aggressive on the part of the spec. "No, memorizing our various custom env var names is not sufficient. Developers must also implement our custom logic, and immediately update whenever the logic changes!" That seems a bit much to ask. Why not just trust the user, who will set the env vars if she really wants to use this scheme and who will do something else if she wants something else?
- lights0123 5y ago> will do something else if she wants something else How should that be communicated by the user? A prompt when opening every application asking where you'd like the data, config, state, and cache dirs to live? And if so, how would the application figure out where that config is stored? These env vars are explicitly only (with the exception of XDG_RUNTIME_DIR) for when the user cares to override them.
- jessaustin 5y agoSomehow lots of software functioned before the advent of XDG. Lots of software that knows nothing about XDG still functions. These env vars are explicitly only (with the exception of XDG_RUNTIME_DIR) for when the user cares to override them. Yeah, sure, that's what the spec says, and that's what is passive-aggressive. There is a complicated system and it is opt-out, which is considered abusive whenever anyone else does it. I actually like XDG, and I use it even when I have to specifically tell packages to do so. I have contributed patches to unrelated software for XDG support. However, I don't agree with the common online strategy of shitting on software that doesn't follow a spec that is deliberately more complicated than it needs to be.
- remram 5y agoHow is an optional override "opt-out"? Who is "shitting on software"? This rant is inscrutable.