4 ms·
> 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
by 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.
- Izkata 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. When I first switched from Windows to Ubuntu, I considered it an amazing feature for discoverability, especially since there was a pretty reliable pattern of using the executable's name for the dotfile/dir.