Live data from Hacker News

macOS dotfiles should not go in –/Library/Application Support

becca.ooo

171–180 of 223 posts

Re: macOS dotfiles should not go in –/Library/Application Support

#171

The Go standard library uses ~/Library/Application Support as well [1]. Given the Unix credentials of Golang's top folks, I would assume there's a good argument in favor of this decision? [1] https://pkg.go.dev/os#UserConfigDir

which is some damn irony given:

  $ ls -ld ~/go
  ls: /Users/mdaniel/go: No such file or directory
  $ go install -v "github.com/jmespath/go-jmespath@latest"
  go: downloading github.com/jmespath/go-jmespath v0.4.0
  package github.com/jmespath/go-jmespath is not a main package
  $ ls ~/go
  pkg/
And, while not _exactly_ related to this topic, this has also always rubbed me the wrong way:

  $ rm -rf ~/go
  rm: /Users/mdaniel/go/pkg/mod/github.com/jmespath/go-jmespath@v0.4.0/.travis.yml: Permission denied

  $ rm -rf ~/go 2>&1|grep "Permission denied" | wc -l
     686

Re: macOS dotfiles should not go in –/Library/Application Support

#172
post #39

Earlier quoted context omitted.

Why is that soc guy so angry and rude about it?

I assume they've made up their mind and are now just tired of discussing it. I don't know why they refuse to even consider an option for it.

The library addresses your use case: provides location to store configs. You're asking for your personal feature.

Re: macOS dotfiles should not go in –/Library/Application Support

#173

I disagree with this. macOS isn't Linux, and as much as I _absolutely support_ the XDG BaseDir spec, I don't think it's fair to try and apply it to macOS. Linux has no 'proper' directory for storing configuration, cache and application user data. macOS and Windows _do_. It's only proper to support those systems in the way that they intend. I wouldn't put stuff in to `%HOME%\.config` on Windows any more than I would p…

> I wouldn't put stuff in to `%HOME%\.config` on Windows Haha, and yet so many (usually Linux-first) applications do. Here's `gci $env:USERPROFILE -Force` on my computer: d---- 3/6/2022 04:39 .android d---- 6/9/2024 18:14 .cache d---- 31/7/2025 11:10 .claude d---- 16/8/2024 01:38 .config d---- 2/3/2022 07:25 .dlv d---- 7/8/2025 18:20 .dotnet d---- 19/7/2022 07:15 .eclipse d---- 1/4/2022 16:29 .fop d---- 12/10/2024 23…

On the other end, when Windows first started having multiple users and locking down write access to system directories (*), lots of video games (and some other programs besides) decided to just dump their files anywhere. Just looking at my own system, I see all of the following used:

  %userprofile%\Documents (which used to be called "My Documents")
  %userprofile%\Documents\My Games
  %userprofile%\Documents\Saved Games
  %userprofile%\Documents\SavedGames
  %userprofile%\Saved Games
  %appdata%
  %userprofile%\AppData\LocalLow
  %localappdata%
As far as I can tell, there's no rhyme or reason to any of this. I know the three AppData folders have distinct meanings, but I don't think video game developers are using them according to their proper meanings. Also, I'm being generous with my use of variables above. Some programs have hardcoded the drive letters and paths.

* = I'm well aware of the real history of Windows NT but from the consumer perspective it went from 98/Me -> XP

Re: macOS dotfiles should not go in –/Library/Application Support

#174

Earlier quoted context omitted.

I kinda wonder if this is an age thing as the English language morphs over time. I'm a bit old school, I like the XDG standard, but the arguments against "~/Library/Application Support" don't make sense to me. The people arguing against it are saying that a program that uses the CLI is not an "App". That argument seems wrong. App is short for "application" and I've been using the long form of that term since before t…

Before they rebased onto UNIX, Mac files had two parts: a data fork and a resource fork. Data had the binary. Resource had strings, images, and other assets that the binary needed. It was great for local portability: you could put the file wherever you wanted, and it would still be colocated with its stuff. It was bad for network portability, because a lot of transport layers didn't respect the forks. So Apple migrat…

On the 68K Mac applications, the executable code was also a resource ('CODE'). When they switched to PPC, PPC code went into the data fork.

Re: macOS dotfiles should not go in –/Library/Application Support

#175

Earlier quoted context omitted.

> 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/ 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 ou…

> 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 ju…

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.

Re: macOS dotfiles should not go in –/Library/Application Support

#176

Earlier quoted context omitted.

> 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/ 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 ou…

> 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 ju…

>But that's Microsoft.

They do the same on windows. Recent microsoft tools are written linux-first, even dotnet.

Re: macOS dotfiles should not go in –/Library/Application Support

#177

Earlier quoted context omitted.

> 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 ju…

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.

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

Re: macOS dotfiles should not go in –/Library/Application Support

#178

Earlier quoted context omitted.

Imagine having built some software, abiding to a standard that to your understanding is the standard to abide to. Then comes people who ask you to break that standard and change your software. Again and again they come. Others ridicule your stance on social media and forums like these. It's burning out. It's free and open-source for heaven's sake! If you don't like it, fork it, patch it, make your own custom version.…

> But stop pestering maintainers with demands. I don’t see any “pestering” in the linked issues. They’re polite and well-written with supporting links. This is how it’s supposed to be done. Suggestions for improvements or issues noticed go into issue requests for discussion. If the maintainer doesn’t want to do it, a polite and concise explanation is typical. The refrain of “just fork it!” is a cop-out. Forking softw…

Then maintainer will stop maintaining and you will have to fork anyway. So it's lose-lose for everybody.

Fork and move on with your life.

Re: macOS dotfiles should not go in –/Library/Application Support

#179

Earlier quoted context omitted.

> 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 ju…

>But that's Microsoft. They do the same on windows. Recent microsoft tools are written linux-first, even dotnet.

Do they started to respect the standards and lore of the operating system they used to loathe*?

That'd be interesting, honestly.

*: I have seen it all. I don't buy the OpenWashed Microsoft of today.

Re: macOS dotfiles should not go in –/Library/Application Support

#180
post #104

Earlier quoted context omitted.

> 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/ 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 ou…

> 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 ) 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…

Just dumping everything in ~/.config instead of home will be a good start. It can be improved incrementally from there.
Post reply on HN