6 ms·

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

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 put data in `$HOME/.Application Data/Local/` on Linux. Why would macOS get bundled in with Linux? Because it's a unix? That's silly. Personally, I have my zsh config repoint those directories into `~/Library/Application Data`, though (as some have pointed out) it's probably better to put some of those folders in `~/Library/Preferences`.

delta_p_delta_x 1y ago
> 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:49 .get_iplayer d---- 26/8/2025 01:07 .gk d---- 26/8/2025 01:07 .gnupg d---- 31/12/2022 15:12 .gradle d---- 30/3/2025 15:10 .ipython d---- 22/10/2021 07:59 .librarymanager d---- 9/6/2025 17:53 .local d---- 26/11/2024 12:58 .lucid d---- 31/12/2022 15:14 .m2 d---- 3/11/2022 06:14 .matplotlib d---- 9/10/2024 20:24 .minio d---- 20/4/2023 13:16 .ms-ad d---- 4/5/2023 10:48 .nuget d---- 7/9/2024 02:05 .ollama d---- 2/9/2021 15:14 .omnisharp d---- 15/7/2022 06:10 .platformio d---- 18/6/2024 19:10 .redhat d---- 7/11/2023 12:49 .runelite d---- 2/7/2024 11:17 .sonarlint d---- 10/7/2025 04:42 .ssh d---- 27/12/2021 14:46 .templateengine d---- 9/2/2023 11:35 .thumbnails d---- 10/6/2023 09:15 .vscode d---- 3/4/2023 11:30 Calibre Library d---- 12/8/2022 18:56 dotTraceSnapshots d---- 22/8/2025 22:51 hdos d---- 9/11/2022 02:27 Heaven d---- 6/11/2023 17:29 jagexcache d---- 9/6/2025 17:53 pipx d---- 1/6/2023 07:52 RenPy d---- 1/9/2024 13:16 source d---- 22/8/2021 02:15 Tracing d---- 26/11/2024 16:31 Zotero -a--- 9/2/2023 04:13 53 .git-for-windows-updater -a--- 26/8/2025 00:45 1170 .gitconfig -a--- 16/8/2023 08:07 2413 .kdiff3rc -a--- 26/8/2025 00:59 20 .lesshst -a--- 6/9/2024 18:15 27 .node_repl_history -a--- 6/11/2023 17:29 90 jagex_cl_oldschool_LIVE.dat -a--- 22/8/2025 23:49 74 jagex_runescape_preferences.dat -a--- 22/8/2025 22:51 24 random.dat -a--- 6/11/2023 17:29 24 random2.dat -a--- 20/4/2023 13:50 0 Sti_Trace.log -a--- 22/8/2025 23:49 1 tfa.dat Observe how not a single dot-directory has the hidden attribute set[1]. This is classic Linux-first development. [1]: https://github.com/MicrosoftDocs/win32/blob/27277910169f4e1bfc81fe6edaccab50464bb4d8/desktop-src/FileIO/file-attribute-constants.md?plain=1#L54 https://github.com/MicrosoftDocs/win32/blob/27277910169f4e1b...
- smcleod 1y ago
  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.
  - delta_p_delta_x 1y ago
    > 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 bother releasing stuff for Windows? Because it checks the 'here's your Windows release, now bugger off' box? As a parent commenter says, > it is because they thought 'with -target darwin I don't get any compilation errors. ship it!' What happened to actually caring about users, their expectations, and user-friendliness, without worrying about platform dogmas? As an aside, Windows has the objectively superior filesystem permissions model. It supports a massive variety of access modes, uses ACLs by default, and this is what allows straightforward fleet management with AD. It is easier to map down Windows ACLs to POSIX octal file permissions than to map up the reverse.
    - smcleod 1y ago
      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.
      - delta_p_delta_x 1y ago
        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.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp https://web.archive.org/web/20141205101508/https://plus.goog...
codazoda 1y ago
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 the GUI even existed. A command line application is still an App in my mind. --- It looks like Finder only treats files with an .app extension as "App Bundles" by showing an icon for them. But Apple seems to be careful with their language around macOS and (usually) calls these either "App Bundles" or "Bundles" and not "Apps" or "Applications". That's not always the case though. Here are some quotes from their docs: > A bundle is a directory with a standardized hierarchical structure that holds executable code and the resources used by that code. > In this document the term app refers to a main executable packaged in a bundle structure. This encompasses apps, app extensions, App Clips, system extensions...
- colejohnson66 1y ago
  It's even in the name: a command line application. The disconnect comes from Apple adopting the term "app" when they launched the App Store in 2008. And the aggressive marketing campaign with phrases like "there's an app for that". The word changed (in some minds) from meaning "any executable" to one that is on a phone.
- bsimpson 1y ago
  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 migrated to bundles - magic folders that look like a single file in the Finder, but contain all the resources it might need.
  - ksherlock 1y ago
    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.
lucideer 1y ago
> 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.
- ndegruchy 1y ago
  > 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. This is a fair take, and something that I've considered when going down the obsessively organized path. Does it _ultimately_ matter? No, of course not. A file is a file is a file and if it's located in $HOME or $HOME/.config is immaterial to the OS and, generally, a program. Just so long as it can be read and written to is ultimately what _matters_. However. Insofar as directories are a construct for humans to mentally parse out and organize data that may be just abstractly written to any number of non-consecutive sectors on a disk, _I'd_ like to at least have a clean mental image of "where" that data is. Apparently, enough people had that same idea and started the excellent XDG spec. > This isn't silly. At all. I will grant you that it's pedantic. Both are POSIX-esque systems and to a large degree, talk the same way and expose the underlying infrastructure in a similar manner. However, I think ignoring the platform's preferred organizational methodology is doing a disservice to the end user. If the user wants a vomit of hundreds of .<whatever> files in their home directory, fine, I'm not your mom. You do you, but I think you should follow the law of least surprise and put things where they're _supposed_ to go, first, then if over-riden, then follow the user. > but Windows isn't a monolith It is the very definition of said. There is only one version of Windows, and any marketing faff about different editions are just different coats of paint on the same underlying system. Windows is Windows. You don't have Windows on ARM supporting %HOME%\.datadir\local\system\noreally instead of "AppData". You have AppData and that's it. You can bank on it being the same across all versions of Windows that are still in production, even going back a long way. WSL1/2 are bolt ons that should behave differently. They're emulating a foreign system, configuration should be stored within, to whatever specification that happens to be.
hulitu 1y ago
> Linux has no 'proper' directory for storing configuration, /etc ? > cache /var/cache, /var/tmp ? > and application user data. /var ?
- adastra22 1y ago
  Those aren’t writable for users.
  - cmurf 1y ago
    ~/.var is writable for users, which leads to ~/.var/app/$APP/cache per app.
    - adastra22 1y ago
      In my 40 years on this planet I have never once seen a ~/.var directory.
    - ndegruchy 1y ago
      You only really see ~/.var for flatpaks.
- ndegruchy 1y ago
  It's a stretch to say /var is for application _user_ data. For a certain value of "user" sure, like MariaDB or Redis. They're "users", and have data in /var but it's a non-interactive session. User data is stored in the user's $HOME, of which none of those locations are, generally, writable to an end-user, and wouldn't be a place to permanently store that data.

delta_p_delta_x 1y ago

> 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:49 .get_iplayer d---- 26/8/2025 01:07 .gk d---- 26/8/2025 01:07 .gnupg d---- 31/12/2022 15:12 .gradle d---- 30/3/2025 15:10 .ipython d---- 22/10/2021 07:59 .librarymanager d---- 9/6/2025 17:53 .local d---- 26/11/2024 12:58 .lucid d---- 31/12/2022 15:14 .m2 d---- 3/11/2022 06:14 .matplotlib d---- 9/10/2024 20:24 .minio d---- 20/4/2023 13:16 .ms-ad d---- 4/5/2023 10:48 .nuget d---- 7/9/2024 02:05 .ollama d---- 2/9/2021 15:14 .omnisharp d---- 15/7/2022 06:10 .platformio d---- 18/6/2024 19:10 .redhat d---- 7/11/2023 12:49 .runelite d---- 2/7/2024 11:17 .sonarlint d---- 10/7/2025 04:42 .ssh d---- 27/12/2021 14:46 .templateengine d---- 9/2/2023 11:35 .thumbnails d---- 10/6/2023 09:15 .vscode d---- 3/4/2023 11:30 Calibre Library d---- 12/8/2022 18:56 dotTraceSnapshots d---- 22/8/2025 22:51 hdos d---- 9/11/2022 02:27 Heaven d---- 6/11/2023 17:29 jagexcache d---- 9/6/2025 17:53 pipx d---- 1/6/2023 07:52 RenPy d---- 1/9/2024 13:16 source d---- 22/8/2021 02:15 Tracing d---- 26/11/2024 16:31 Zotero -a--- 9/2/2023 04:13 53 .git-for-windows-updater -a--- 26/8/2025 00:45 1170 .gitconfig -a--- 16/8/2023 08:07 2413 .kdiff3rc -a--- 26/8/2025 00:59 20 .lesshst -a--- 6/9/2024 18:15 27 .node_repl_history -a--- 6/11/2023 17:29 90 jagex_cl_oldschool_LIVE.dat -a--- 22/8/2025 23:49 74 jagex_runescape_preferences.dat -a--- 22/8/2025 22:51 24 random.dat -a--- 6/11/2023 17:29 24 random2.dat -a--- 20/4/2023 13:50 0 Sti_Trace.log -a--- 22/8/2025 23:49 1 tfa.dat Observe how not a single dot-directory has the hidden attribute set[1]. This is classic Linux-first development. [1]: https://github.com/MicrosoftDocs/win32/blob/27277910169f4e1bfc81fe6edaccab50464bb4d8/desktop-src/FileIO/file-attribute-constants.md?plain=1#L54 https://github.com/MicrosoftDocs/win32/blob/27277910169f4e1b...

smcleod 1y ago
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.
- delta_p_delta_x 1y ago
  > 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 bother releasing stuff for Windows? Because it checks the 'here's your Windows release, now bugger off' box? As a parent commenter says, > it is because they thought 'with -target darwin I don't get any compilation errors. ship it!' What happened to actually caring about users, their expectations, and user-friendliness, without worrying about platform dogmas? As an aside, Windows has the objectively superior filesystem permissions model. It supports a massive variety of access modes, uses ACLs by default, and this is what allows straightforward fleet management with AD. It is easier to map down Windows ACLs to POSIX octal file permissions than to map up the reverse.
  - smcleod 1y ago
    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.
    - delta_p_delta_x 1y ago
      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.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp https://web.archive.org/web/20141205101508/https://plus.goog...

codazoda 1y ago

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 the GUI even existed. A command line application is still an App in my mind. --- It looks like Finder only treats files with an .app extension as "App Bundles" by showing an icon for them. But Apple seems to be careful with their language around macOS and (usually) calls these either "App Bundles" or "Bundles" and not "Apps" or "Applications". That's not always the case though. Here are some quotes from their docs: > A bundle is a directory with a standardized hierarchical structure that holds executable code and the resources used by that code. > In this document the term app refers to a main executable packaged in a bundle structure. This encompasses apps, app extensions, App Clips, system extensions...

colejohnson66 1y ago
It's even in the name: a command line application. The disconnect comes from Apple adopting the term "app" when they launched the App Store in 2008. And the aggressive marketing campaign with phrases like "there's an app for that". The word changed (in some minds) from meaning "any executable" to one that is on a phone.
bsimpson 1y ago
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 migrated to bundles - magic folders that look like a single file in the Finder, but contain all the resources it might need.
- ksherlock 1y ago
  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.

lucideer 1y ago

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

ndegruchy 1y ago
> 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. This is a fair take, and something that I've considered when going down the obsessively organized path. Does it _ultimately_ matter? No, of course not. A file is a file is a file and if it's located in $HOME or $HOME/.config is immaterial to the OS and, generally, a program. Just so long as it can be read and written to is ultimately what _matters_. However. Insofar as directories are a construct for humans to mentally parse out and organize data that may be just abstractly written to any number of non-consecutive sectors on a disk, _I'd_ like to at least have a clean mental image of "where" that data is. Apparently, enough people had that same idea and started the excellent XDG spec. > This isn't silly. At all. I will grant you that it's pedantic. Both are POSIX-esque systems and to a large degree, talk the same way and expose the underlying infrastructure in a similar manner. However, I think ignoring the platform's preferred organizational methodology is doing a disservice to the end user. If the user wants a vomit of hundreds of .<whatever> files in their home directory, fine, I'm not your mom. You do you, but I think you should follow the law of least surprise and put things where they're _supposed_ to go, first, then if over-riden, then follow the user. > but Windows isn't a monolith It is the very definition of said. There is only one version of Windows, and any marketing faff about different editions are just different coats of paint on the same underlying system. Windows is Windows. You don't have Windows on ARM supporting %HOME%\.datadir\local\system\noreally instead of "AppData". You have AppData and that's it. You can bank on it being the same across all versions of Windows that are still in production, even going back a long way. WSL1/2 are bolt ons that should behave differently. They're emulating a foreign system, configuration should be stored within, to whatever specification that happens to be.

hulitu 1y ago

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

adastra22 1y ago
Those aren’t writable for users.
- cmurf 1y ago
  ~/.var is writable for users, which leads to ~/.var/app/$APP/cache per app.
  - adastra22 1y ago
    In my 40 years on this planet I have never once seen a ~/.var directory.
  - ndegruchy 1y ago
    You only really see ~/.var for flatpaks.
ndegruchy 1y ago
It's a stretch to say /var is for application _user_ data. For a certain value of "user" sure, like MariaDB or Redis. They're "users", and have data in /var but it's a non-interactive session. User data is stored in the user's $HOME, of which none of those locations are, generally, writable to an end-user, and wouldn't be a place to permanently store that data.