But what We can do? Well, the macOS and Windows got it somewhat right, these OSes provide special paths for storing all configuration, caches, user-data, etc. in special, dedicated, and well known locations within user directories. It is like mentioned earlier FHS but for $HOME.
I’m on Windows and it’s really annoying how all the “cross-platform” Dev tooling ignores those paths and dumps dotfiles into my homedir anyway.
I totally agree. This is something that users should push hard through the application developers throats or otherwise we will always end with the semi-broken state where some applications “work nicely” and other “meh, whatever”. They need to learn that my $HOME is mine and only mine. They should not pollute it with whatever they want because it is fast and easy.
This is something that users should push hard through the application developers throats
The problem is applications, but the cause is library developers. The reason that this (mostly) isn’t a problem on macOS is that OpenStep does this right out of the box. Everyone who writes an OpenStep / Cocoa application uses NSUserDefaults for configuration. This implements a layered system out of the box where initial defaults come from the application, then these can be overridden by system-wide ones, then per-user ones (which are stored in a specific location inside ~/Library), and finally options specified on the command line. App developers don’t need to think about where to store configuration files, the infrastructure handles it automatically.
The main reason that nothing like this is in POSIX is that POSIX defines C APIs and C doesn’t have built-in types for complex structured data. NSUserDefaults stores dictionaries and arrays that can contain strings, numbers, dates, and a few other things. As I’ve said before UCL is a great solution for the part of actually storing the configuration, but it doesn’t automatically do the layering part.
On macOS the storage layer is built on top of the domain mechanism. When you look up a standard path using NSFileManager, you specify a domain (user, system, network) and a directory kind (application, configuration, caches, and a load of others).
Both of these parts were inherited from OpenStep and the OpenStep specification allowed implementers to pick their own locations for these things. For example, NSLibraryDirectory in NSSystemDomain might be /etc/, whereas NSLibraryDirectory in NSUserDomain might be ~/.config/{app name}. For extra fun, NSUserDefaults on the Windows NT implementation of OpenStep stored user defaults in the registry, with HKEY_LOCAL_MACHINE for NSSystemDomain and HKEY_CURRENT_USER for NSUserDomain.
I find it very sad that *NIX desktop environments spent so much effort building on top of copies of abstractions from Windows 3.x, rather than adopting and improving things from OpenStep. A modern Linux desktop and application development tools still lag behind a 1993 NeXT workstation in some important areas (thought, of course, many others are significant improvements).
Just want to note that Haiku has standard directories such as ~/config/settings, and programs are patched to use them! Of course, it’s still in beta and all, but it’s cool that they’re taking action on this. :)
Probably would not be too much work to whack together a FUSE filesystem that uses a whitelist. The whitelist would provide an optional rewrite rule and return EPERM to anything not on it.
…someone would have to wade through the PRs for updates to the list though.
Distributions should play a role in pushing back against this.
Basically, patch the programs to behave as per XDG, and push these patches to upstream. Or the simpler limited manpower option: Simply remove the inflicting packages until fixed.
If e.g. Debian, Fedora or Ubuntu did it, it’d stop being a problem real quick.
I’m sure this can be done while minimizing user annoyance.
Even with annoyance, it’s an investment. I’d think about it as paying technical debt. These dot directories should have been in the right paths as per XDG in the first place.
I’m on Windows and it’s really annoying how all the “cross-platform” Dev tooling ignores those paths and dumps dotfiles into my homedir anyway.
I totally agree. This is something that users should push hard through the application developers throats or otherwise we will always end with the semi-broken state where some applications “work nicely” and other “meh, whatever”. They need to learn that my
$HOMEis mine and only mine. They should not pollute it with whatever they want because it is fast and easy.The problem is applications, but the cause is library developers. The reason that this (mostly) isn’t a problem on macOS is that OpenStep does this right out of the box. Everyone who writes an OpenStep / Cocoa application uses
NSUserDefaultsfor configuration. This implements a layered system out of the box where initial defaults come from the application, then these can be overridden by system-wide ones, then per-user ones (which are stored in a specific location inside~/Library), and finally options specified on the command line. App developers don’t need to think about where to store configuration files, the infrastructure handles it automatically.The main reason that nothing like this is in POSIX is that POSIX defines C APIs and C doesn’t have built-in types for complex structured data.
NSUserDefaultsstores dictionaries and arrays that can contain strings, numbers, dates, and a few other things. As I’ve said before UCL is a great solution for the part of actually storing the configuration, but it doesn’t automatically do the layering part.On macOS the storage layer is built on top of the domain mechanism. When you look up a standard path using
NSFileManager, you specify a domain (user, system, network) and a directory kind (application, configuration, caches, and a load of others).Both of these parts were inherited from OpenStep and the OpenStep specification allowed implementers to pick their own locations for these things. For example,
NSLibraryDirectoryinNSSystemDomainmight be/etc/, whereasNSLibraryDirectoryinNSUserDomainmight be~/.config/{app name}. For extra fun,NSUserDefaultson the Windows NT implementation of OpenStep stored user defaults in the registry, withHKEY_LOCAL_MACHINEforNSSystemDomainandHKEY_CURRENT_USERforNSUserDomain.I find it very sad that *NIX desktop environments spent so much effort building on top of copies of abstractions from Windows 3.x, rather than adopting and improving things from OpenStep. A modern Linux desktop and application development tools still lag behind a 1993 NeXT workstation in some important areas (thought, of course, many others are significant improvements).
Just want to note that Haiku has standard directories such as
~/config/settings, and programs are patched to use them! Of course, it’s still in beta and all, but it’s cool that they’re taking action on this. :)It is inherited from the Plan9.
Agree with this – I was so annoyed by the situation that I did various things in the past to improve the state of the art for me and others:
$HOMEread-onlyProbably would not be too much work to whack together a FUSE filesystem that uses a whitelist. The whitelist would provide an optional rewrite rule and return EPERM to anything not on it.
…someone would have to wade through the PRs for updates to the list though.
Distributions should play a role in pushing back against this.
Basically, patch the programs to behave as per XDG, and push these patches to upstream. Or the simpler limited manpower option: Simply remove the inflicting packages until fixed.
If e.g. Debian, Fedora or Ubuntu did it, it’d stop being a problem real quick.
This is similar to Vista UAC solution. Annoy the shit out of the users to force developers to stop polluting whole system with crap.
I’m sure this can be done while minimizing user annoyance.
Even with annoyance, it’s an investment. I’d think about it as paying technical debt. These dot directories should have been in the right paths as per XDG in the first place.
This ALL-CAPS style makes it a terrible read.
Annoying as it is, I find all these dotfiles in $HOME far more annoying.
It is all monospace, not all-caps.
There’s a CSS property that makes the body text appear all-caps for me:
The “case” feature seems to be what’s controlling it. I’m using Firefox 75 on Ubuntu.
It changed since the time I looked at it. Previously it was all-caps.
Oh, actually it’s all-caps on Firefox 76, but not on Firefox ESR.