Live data from Hacker News

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

becca.ooo

161–170 of 223 posts

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

#161

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, 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?

Is it? Remember servers exist.

Personally (and most people I know) see windows as user stuff. Not developer stuff. So CLI tools etc are linux/mac-first. Lots of projects I find nowadays don't even have a windows build...

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

#162

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

I don’t think it’s unreasonable to be demanding when this refusal negatively affects a lot of other rust software

It's not an official package. Developers of other Rust software can always build the same functionality on their own or fork.

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

#163
post #3

I and others have brought this up with the dirs Rust crate maintainer but they refuse to see it this way: https://codeberg.org/dirs/dirs-rs/issues/64 . It's very frustrating. I now use a combination of xdg + known-folders manually: [target.'cfg(windows)'.dependencies] known-folders = "1.2.0" [target.'cfg(not(windows))'.dependencies] xdg = "2.5.2" to get the config directory: use anyhow::{Context, Result}; #[cfg(windo…

The maintainer's advice is correct, on mac you should store configs and other stuff in Library/Application Support, that's the mac convention to use on mac, just like xdg is linux convention to use on linux.

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

#164

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…

You must be aware that ACLs are well supported by all major UNIX operating systems (yes, Linux is UNIX, there are/were two general-purpose Linux distributions certified as UNIX). It's just that basically nobody is using them because they're rarely necessary, and there are easier ways to implement access control if you want something simpler, and also far more powerful mechanisms for when that's needed.

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

#165

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…

Free software developers are rarely interested in spending time on supporting unusual proprietary operating systems. You should be grateful all this software works there at all — some Windows users did not just moan on internet forums, but actually went and implemented support for their OS of choice in all these packages.

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

#166
post #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 ?

Those aren’t writable for users.

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

#167
post #3

I and others have brought this up with the dirs Rust crate maintainer but they refuse to see it this way: https://codeberg.org/dirs/dirs-rs/issues/64 . It's very frustrating. I now use a combination of xdg + known-folders manually: [target.'cfg(windows)'.dependencies] known-folders = "1.2.0" [target.'cfg(not(windows))'.dependencies] xdg = "2.5.2" to get the config directory: use anyhow::{Context, Result}; #[cfg(windo…

Sounds like it's time to make a fork of dirs-rs that actually follows the rules. Most libraries that use dirs-rs are doing so because they don't want to have to think about those things. So if there were a library that did it right, you'd probably have decent adoption if it's a simple crate replacement.

The maintainer of dirs-rs IS the one following the rules here…

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

#168
post #3

I and others have brought this up with the dirs Rust crate maintainer but they refuse to see it this way: https://codeberg.org/dirs/dirs-rs/issues/64 . It's very frustrating. I now use a combination of xdg + known-folders manually: [target.'cfg(windows)'.dependencies] known-folders = "1.2.0" [target.'cfg(not(windows))'.dependencies] xdg = "2.5.2" to get the config directory: use anyhow::{Context, Result}; #[cfg(windo…

I think there should be two crates in rust-land. The answer by @soc makes sense for apps , as the article discusses. Many (most?) people building Rust programs aren't making apps and so shouldn't be using this crate, which clearly and definitively only supports MacOS "Apps".

A CLI app is an app.

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

#169
post #150

Earlier quoted context omitted.

> Linux has no 'proper' directory for storing configuration, /etc ? > cache /var/cache, /var/tmp ? > and application user data. /var ?

Those aren’t writable for users.

~/.var is writable for users, which leads to ~/.var/app/$APP/cache per app.

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

#170
post #169

Earlier quoted context omitted.

Those aren’t writable for users.

~/.var is writable for users, which leads to ~/.var/app/$APP/cache per app.

In my 40 years on this planet I have never once seen a ~/.var directory.
Post reply on HN