[jessaustin]

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]

> 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]

Somehow 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]

How is an optional override "opt-out"? Who is "shitting on software"? This rant is inscrutable.