Live data from Hacker News

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

becca.ooo

141–150 of 223 posts

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

#141

Earlier quoted context omitted.

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

Are you playing runescape at work? Or developing at home?

Developing at home.

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

#142

Earlier quoted context omitted.

Why should it not. The easier case for me to defend is XDG_CACHE_HOME - if it defaults to ~/.Library/Caches then it makes life simpler on macOS as it means that you don't have to add other directories to be removed from your backups.

Regardless of the default value, I think we can all agree that supporting XDG_* would be a good start!

why are they named XDG_* like XDG_CONFIG_DIR?

Why not just CONFIG_DIR?

Doesn't matter. This whole situation is a mess, and it's still a mess in the year 2025. Clearly existing operating systems can't be changed significantly enough to change anything like this.

but we're all still afraid to write new operating systems. We cling to MacOS, FreeBSD, Linux, and Windows as if our lives depend on it. Our lives do not depend on it.

If we want a saner OS, we could have it, but we don't want it bad enough, I think. It's easier to just deal with the piles of horse manure that has been piled on top of everything. So we have a rather active bikeshed discussion on HN about whether or not to use XDG_*.

We want to bikeshed more than we want to fix anything. Like all communities, this one also disappoints me.

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

#143

Earlier quoted context omitted.

Had a chuckle at "classic Linux-first development", it's every OS except Windows - Windows is the outlier here, and I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem. So I guess in the same way that roads are "classic wheel-first infrastructure", you don't try to pave a swamp.

> Windows is the outlier here What about Android? The only thing Android shares with Linux is the kernel; the entire user mode environment is completely different, and this includes how 'users' and their data are handled. What about automotive stuff like VxWorks? > I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem. Good for you; then why even bo…

I was responding to your comment about hidden (.) files vs extended attributes. As much as I do not like Android - it does respect hidden files.

I don't 'bother releasing stuff for Windows', as I said - for me it's not worth the pain.

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

#144

Earlier quoted context omitted.

> [...] Linus has not bothered to write them down himself [...] He's a kernel hacker and a technical leader. He doesn't write specs for the userspace, that's the least of his concerns. Linux has very strong guarantees on syscall backwards compat - Go doesn't even use libc. This is all by design. Even the name "GNU/Linux" was something FSF tried to impose on distributions. The distributions being distributions, were f…

This is not a judgment. It is simply a fact. Linux uses cross-distribution standards, because of this fact; these standards should not be misidentified as cross-platform standards - which I believe TFA was doing - as that's not the purpose they exist for.

> has not bothered

> This is not a judgement

"did not" is not judgemental but "did not bother" strongly implies judgement.

I do think it's true, however, that had Linus expressed an opinion on this it would have been hard to ignore.

Edit to add: Bear in mind that XDG is a relatively new thing compared to Linux (more so compared to Unix).

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

#145

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…

> Why would macOS get bundled in with Linux? Because it's a unix? That's silly.

I'm somewhat on the fence about this topic in general & I think you've hit upon why. This isn't silly. At all.

Linux & Mac environments are by no means compatible but for anyone who cares about the location of their dotfiles, the two systems have demonstrably been "compatible enough". To the point that having coordinated standards on some aspects of (at the very least cli) applications would invariably be a net positive for users of both systems.

I run a Linux desktop & a Mac laptop between which I sync dotfiles & personal scripts. The scripts I sync work seamlessly on Linux & BSD systems because the incompatibilities are eminently manageable, so the topic of this post is definitely an inconvenience for me. I'm sure I'm not the only one.

Plenty of commenters are using Windows as a comparator stating "you wouldn't expect this in Windows" but in actual fact, I would like to have this in WSL2 (if I ever had a Windows machine). Powershell & CMD have never had anything resembling Unix compat so for those this is irrelevant, but Windows isn't a monolith.

In fact the more I read arguments against this in HN comments, the more I'm being persuaded to come off the fence & argue that XDG should be a *nix standard rather than a Linux one.

Though the flip side of my own subjective take here is that "home directory dotfile vomit" has just never seemed as big an issue to me as many make out.

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

#146
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…

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

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

#147

Earlier quoted context omitted.

> Windows is the outlier here What about Android? The only thing Android shares with Linux is the kernel; the entire user mode environment is completely different, and this includes how 'users' and their data are handled. What about automotive stuff like VxWorks? > I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem. Good for you; then why even bo…

I was responding to your comment about hidden (.) files vs extended attributes. As much as I do not like Android - it does respect hidden files. I don't 'bother releasing stuff for Windows', as I said - for me it's not worth the pain.

It's hard to tell how your commment was a sincere response rather than derision for anyone using or targeting Windows. There was nothing technical. Here's a technical response:

There's nothing 'hidden' about dotfiles on UNIX-likes, unlike on Windows where, as I mentioned, there is such a thing that is exposed by the OS filesystem API (it's a normal attribute and can be straightforwardly set/unset with right-click -> Properties; not an extended attribute which refers to a very specific thing).

That files and directories beginning with a full stop are hidden in `ls` was openly acknowledged as a bug[1] in the original implementation, that gave rise to 'a bad precedent'. Ergo all the repeated gnashing of teeth (see this very article) by UNIX-like consumers who end up noticing the dotfiles anyway, because a significant plurality of people use a variant of `ls -la` for the utility of its tabular output.

[1]: https://web.archive.org/web/20141205101508/https://plus.goog...

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

#148

None of the tools the author mentions as following XDG, actually follow XDG. No default tools shipped with macOS place files under .config or anything like that. There is a bunch of dotfile vomit in $HOME and that's it. Every tool that uses .config is one you manually install from an external source. The XDG spec is to coordinate the userspace of Linux software , meaning both CLI apps and windowed apps. Linux needs t…

> [...] Linus has not bothered to write them down himself [...] He's a kernel hacker and a technical leader. He doesn't write specs for the userspace, that's the least of his concerns. Linux has very strong guarantees on syscall backwards compat - Go doesn't even use libc. This is all by design. Even the name "GNU/Linux" was something FSF tried to impose on distributions. The distributions being distributions, were f…

Who writes .gitconfig?

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

#149

Earlier quoted context omitted.

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

Had a chuckle at "classic Linux-first development", it's every OS except Windows - Windows is the outlier here, and I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem. So I guess in the same way that roads are "classic wheel-first infrastructure", you don't try to pave a swamp.

> Windows is the outlier here, and I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem.

... But it's still much larger than everything else put together, no?

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

#150

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…

> Linux has no 'proper' directory for storing configuration,

/etc ?

> cache

/var/cache, /var/tmp ?

> and application user data.

/var ?

Post reply on HN