6 ms·

> they refuse to see it this way That's why the long-term future of app development is containers. It is not possible, on a human level, to convince people to

> they refuse to see it this way That's why the long-term future of app development is containers. It is not possible, on a human level, to convince people to lift even the lightest of fingers for the common good. Consider https://specifications.freedesktop.org/basedir-spec/latest/ https://specifications.freedesktop.org/basedir-spec/latest/ The XDG specification has been around for 22 years. It has real benefits for users. It's trivial to implement. Yet even in the year of our lord two thousand and twenty five I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME. I've long given up on solving technical coordination problems by appealing to the universal goodness of humanity. The only thing that works is to sandbox applications at tightly as possible and direct all their access to the external world through narrow interfaces that do their best to limit shenanigans.

happymellon 1y ago
It's a shame that MacOS doesn't have an equivalent for Boxxy.
Gigachad 1y ago
How is it even common good though? The articles main argument is that the author didn't expect the files there, not that it was causing any kind of issue. The problem is that people disagree where a config file should go, and there's no compelling reason why either of them are right or why it even matters.
eklavya 1y ago
I have absolutely no opinion on "common good" or "standard" here. I wholeheartedly agree about the containers part though, just have everything within a folder in a container somewhere so I don't have to keep googling where X stores Y and still failing half the time.
bayindirh 1y ago
> That's why the long-term future of app development is containers. That kind of "sweep under the rug" attitude is even more wrong than putting a file to wrong location. Containers are good for some stuff, but duplicating code and letting badly developed software to proliferate in its own enclave is a defeatist approach. > I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME. I normally use this phrase sarcastically, but this time they really deserve it. It's a skill issue, moreover, PEBKAC. If there's a standard, you SHALL obey it, esp. if you're a prominent programming language. I mean, even my small utilities obey that. But that's Microsoft... > I've long given up on solving technical coordination problems by appealing to the universal goodness of humanity. Thanks for the good fight, we can take the torch from here and continue the challenge. No hard feelings here. > The only thing that works is to sandbox applications at tightly as possible Don't be so defeatist, though.
- quotemstr 1y ago
  If people have refused to do the right thing for 20 years, they're not about to start now just because you say so. A mature technologist must be pragmatic if he wants to get anything done. Isolation technologies work. Scolding doesn't. We tried.
  - bayindirh 1y ago
    > If people have refused to do the right thing for 20 years... From what I have seen, not every human being is same. Categorizing them as clones of each other is falling into a false dichotomy. > they're not about to start now just because you say so. There's a quote I'm quite fond of: "You don't have to cut with the sword of truth, you can point with it, too". I don't "say what to do" to people and expect them to obey me. I produce examples, and put them out, and tell them politely. If they take the example, that's good. If they leapfrog me and show me a better one, that's great. If they ignore me, that's OK. Not everyone will follow, and that's OK. Even I get upset by some people who doesn't do the correct thing. That's OK too. We should be different, try different things, and find the correct way by mistake, or reach dead ends by doing everything right. My experience says both is possible, and even though the process is infuriating, that's OK too. This is called life. We can't control and know everything. > A mature technologist must be pragmatic if he wants to get anything done. There are places to be pragmatic, and there are places to experiment. Again, another false dichotomy. I did go great lengths by mixing the two, for example. > Isolation technologies work. Yeah, I also use them in various use cases, but never to sweep my incompetence under a proverbial rug. Instead, I skill up, do better. Surpassing myself in every iteration is the best dopamine hit I can get. > Scolding doesn't. You shouldn't be scolding anyone over any mortal matter like programming though. There are better ways to communicate, again from my experience. YMMV, IANAL. > We tried. You may have tried and I deeply respect that. But I'm a dense person who doesn't understand sometimes and do as I please, and apparently it helped me go places. So, I'll continue to be a dense person.
- GoblinSlayer 1y ago
  >But that's Microsoft. They do the same on windows. Recent microsoft tools are written linux-first, even dotnet.
com2kid 1y ago
I've been using macos for years, I just learned .config was a standard in this thread, because damn nearly everything shoves files in ~ so I just assumed that is where config files go. Don't blame people for doing what 90% of apps do and assuming everyone else is correct.
str4d 1y ago
> The XDG specification has been around for 22 years. Indeed! > It has real benefits for users. I once believed this! > It's trivial to implement. Nope! I ranted about this a while back (https://bsky.app/profile/str4d.xyz/post/3lsjbnpsbh22i https://bsky.app/profile/str4d.xyz/post/3lsjbnpsbh22i) but the tl;dr is that the XDG specification is imprecisely written and internally inconsistent, and there has been confusion since at least as early as 2003 about what kind of data is meant to be stored in $XDG_CONFIG_HOME vs $XDG_DATA_HOME. A plain reading of the XDG Base Directory Specification implies (but does not explicitly say, which is part of the problem!) that $XDG_DATA_HOME contains read-only user-specific application data files (like documentation). But the spec is interpreted by many (source: I found a single blog post that seemed to be referenced in a variety of places, such as the Arch Linux wiki) as saying that $XDG_DATA_HOME contains mutable user-generated data (like password vaults). Those have very different properties, and it's impossible as an app developer for me to predict which of those two directories a user (or the tooling installed on their OS) is assuming can be safely deleted without consequence, and which must always be backed up. > Yet even in the year of our lord two thousand and twenty five I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME. My earlier rant arose from me spending several days attempting to follow the XDG specification for an app where I need to store mutable user-generated data, being unable to find any supporting evidence that it was safe to store this in either $XDG_CONFIG_HOME or $XDG_DATA_HOME, and deciding on ~/.appname instead. I do allow all paths to be overridden in the config file, so individual users can use XDG paths at their own risk (and with knowledge of their OS environment's behaviour).
- olddustytrail 1y ago
  The spec says "There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME" Where are you seeing "read-only"? And why would it not be safe? What kind of user specific documentation did you think should go there and even if you did, why would you think it could be randomly removed by something else?
- assbuttbuttass 1y ago
  I'm not sure where you got that XDG_DATA_HOME has to be read-only, I couldn't find anything like that > $XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored. And really, the difference between XDG_DATA_HOME and XDG_CONFIG_HOME is subjective anyway, each application will have its own requirements, so I'm not convinced it's even possible to define these completely precisely. Personally, I would pick between XDG_DATA_HOME vs XDG_CONFIG_HOME based on whether the application manages the files, or whether the user is expected to manage the files themself. This isn't based on any wording in the standard, but just a pattern I've commonly seen

happymellon 1y ago

It's a shame that MacOS doesn't have an equivalent for Boxxy.

Gigachad 1y ago

How is it even common good though? The articles main argument is that the author didn't expect the files there, not that it was causing any kind of issue. The problem is that people disagree where a config file should go, and there's no compelling reason why either of them are right or why it even matters.

eklavya 1y ago

I have absolutely no opinion on "common good" or "standard" here. I wholeheartedly agree about the containers part though, just have everything within a folder in a container somewhere so I don't have to keep googling where X stores Y and still failing half the time.

bayindirh 1y ago

> That's why the long-term future of app development is containers. That kind of "sweep under the rug" attitude is even more wrong than putting a file to wrong location. Containers are good for some stuff, but duplicating code and letting badly developed software to proliferate in its own enclave is a defeatist approach. > I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME. I normally use this phrase sarcastically, but this time they really deserve it. It's a skill issue, moreover, PEBKAC. If there's a standard, you SHALL obey it, esp. if you're a prominent programming language. I mean, even my small utilities obey that. But that's Microsoft... > I've long given up on solving technical coordination problems by appealing to the universal goodness of humanity. Thanks for the good fight, we can take the torch from here and continue the challenge. No hard feelings here. > The only thing that works is to sandbox applications at tightly as possible Don't be so defeatist, though.

quotemstr 1y ago
If people have refused to do the right thing for 20 years, they're not about to start now just because you say so. A mature technologist must be pragmatic if he wants to get anything done. Isolation technologies work. Scolding doesn't. We tried.
- bayindirh 1y ago
  > If people have refused to do the right thing for 20 years... From what I have seen, not every human being is same. Categorizing them as clones of each other is falling into a false dichotomy. > they're not about to start now just because you say so. There's a quote I'm quite fond of: "You don't have to cut with the sword of truth, you can point with it, too". I don't "say what to do" to people and expect them to obey me. I produce examples, and put them out, and tell them politely. If they take the example, that's good. If they leapfrog me and show me a better one, that's great. If they ignore me, that's OK. Not everyone will follow, and that's OK. Even I get upset by some people who doesn't do the correct thing. That's OK too. We should be different, try different things, and find the correct way by mistake, or reach dead ends by doing everything right. My experience says both is possible, and even though the process is infuriating, that's OK too. This is called life. We can't control and know everything. > A mature technologist must be pragmatic if he wants to get anything done. There are places to be pragmatic, and there are places to experiment. Again, another false dichotomy. I did go great lengths by mixing the two, for example. > Isolation technologies work. Yeah, I also use them in various use cases, but never to sweep my incompetence under a proverbial rug. Instead, I skill up, do better. Surpassing myself in every iteration is the best dopamine hit I can get. > Scolding doesn't. You shouldn't be scolding anyone over any mortal matter like programming though. There are better ways to communicate, again from my experience. YMMV, IANAL. > We tried. You may have tried and I deeply respect that. But I'm a dense person who doesn't understand sometimes and do as I please, and apparently it helped me go places. So, I'll continue to be a dense person.
GoblinSlayer 1y ago
>But that's Microsoft. They do the same on windows. Recent microsoft tools are written linux-first, even dotnet.

com2kid 1y ago

I've been using macos for years, I just learned .config was a standard in this thread, because damn nearly everything shoves files in ~ so I just assumed that is where config files go. Don't blame people for doing what 90% of apps do and assuming everyone else is correct.

str4d 1y ago

> The XDG specification has been around for 22 years. Indeed! > It has real benefits for users. I once believed this! > It's trivial to implement. Nope! I ranted about this a while back (https://bsky.app/profile/str4d.xyz/post/3lsjbnpsbh22i https://bsky.app/profile/str4d.xyz/post/3lsjbnpsbh22i) but the tl;dr is that the XDG specification is imprecisely written and internally inconsistent, and there has been confusion since at least as early as 2003 about what kind of data is meant to be stored in $XDG_CONFIG_HOME vs $XDG_DATA_HOME. A plain reading of the XDG Base Directory Specification implies (but does not explicitly say, which is part of the problem!) that $XDG_DATA_HOME contains read-only user-specific application data files (like documentation). But the spec is interpreted by many (source: I found a single blog post that seemed to be referenced in a variety of places, such as the Arch Linux wiki) as saying that $XDG_DATA_HOME contains mutable user-generated data (like password vaults). Those have very different properties, and it's impossible as an app developer for me to predict which of those two directories a user (or the tooling installed on their OS) is assuming can be safely deleted without consequence, and which must always be backed up. > Yet even in the year of our lord two thousand and twenty five I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME. My earlier rant arose from me spending several days attempting to follow the XDG specification for an app where I need to store mutable user-generated data, being unable to find any supporting evidence that it was safe to store this in either $XDG_CONFIG_HOME or $XDG_DATA_HOME, and deciding on ~/.appname instead. I do allow all paths to be overridden in the config file, so individual users can use XDG paths at their own risk (and with knowledge of their OS environment's behaviour).

olddustytrail 1y ago
The spec says "There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME" Where are you seeing "read-only"? And why would it not be safe? What kind of user specific documentation did you think should go there and even if you did, why would you think it could be randomly removed by something else?
assbuttbuttass 1y ago
I'm not sure where you got that XDG_DATA_HOME has to be read-only, I couldn't find anything like that > $XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored. And really, the difference between XDG_DATA_HOME and XDG_CONFIG_HOME is subjective anyway, each application will have its own requirements, so I'm not convinced it's even possible to define these completely precisely. Personally, I would pick between XDG_DATA_HOME vs XDG_CONFIG_HOME based on whether the application manages the files, or whether the user is expected to manage the files themself. This isn't based on any wording in the standard, but just a pattern I've commonly seen