$HOME, not so sweet $HOME
gist.github.com
gist.github.com
1. $XDG_CONFIG_HOME/.op (if var is set) 2. $HOME/.config/op 3. $HOME/.op
I hate to be the dev who says “I don’t know why those other code bases find it so difficult that they put up a fight” but our `findConfigDirectory()` function isn’t exactly complicated, even when you consider all the operating systems that the 1Password CLI supports.
(Sorry for the formatting, I’m on my phone.)
I’ve got a script that I’m making conform to XDG, and it's a lot of work to make it work well because I have to know about three different roots for different things (configuration, temporary files, and persistent files). I’m not convinced that it's worth it, because it is no longer as easy as telling someone "uninstall this by doing `rm -rf ~/.PROGRAM`", but instead I have to say `PROGRAM self destruct` or something like that to clean up all the detritus (and what if it fails in the middle?).
But in part my point is that there's virtually no one who gets this correct either with Linux systems or macOS, which is what makes rants like the parent article so annoying.
The ones that don't are mainly lazy ports from Windows where that speration doesn't exist.
Temporary files often shouldn't exist. If it's less that a few megabytes why is it touching disk unless it will be needed persistently? In any case the detritus doesn't matter, if it's big enough to care I'll see the disk space is low and find it with baobab at some point.
It's not perfect, but it's not a major nightmare.
For my part, I don't always follow XDG specs, I often just create ~/AppName, but sometimes I'll make more than one to keep features within one app separate. I put IP cam recordings in ~/NVR by default, and stuff like that, because the main app dir is all stuff you would backup and restore, which probably doesn't include NVR recordings for a home user.
Xdg is also, .cache (xdg cache dir) for data that can be cleared on reboot allowing you to use tempfs for it (of course you can't because a bunch of shit uses it as a persistent cache for things they should be putting in .local/share/. (Xdg data dir).
This whole mess is so utterly fucked I gave up caring and just let the mess be.
Why? Using it makes macOS more similar to Linux, which I think is a good thing. It surely makes it easier to share configuration files between Macs and Linux machines.
Honestly, I don't see a single upside to using macOS's specific directories over .config/.cache/.local.
I'd prefer a multigigabyte download went in state or data dirs if you don't want to lose it regularly.
I also prefer XDG because it separates between XDG_DATA_HOME, XDG_STATE_HOME, and XDG_RUNTIME_DIR. The macOS convention does not.
I prefer `~/.config`, but it’s not where such configurations go on the Mac (and there are multiple applications that do it differently).
[1] https://specifications.freedesktop.org/basedir-spec/latest/ [2] https://wiki.gnome.org/action/show/Initiatives/GnomeGoals/XD...
User expectations differ. The correct place to put application detritus is `~/Library` on macOS (`/Library` if it’s system-level with no user-level). I am surprised when a cross-platform library uses `~/Library` instead of XDG, but I am not unhappy with it.
Frankly, most programs should have a command like `show-config-paths` (`--show-config-paths`) so that you can see where the configuration, caches, etc. are on the platform you’re on, and possibly be told (a) whether they are overridden from default and (b) how to override them. It would be useful to have that output for both human and machine reading.
Furthermore, when you do '--help', whenever it's half-way reasonable, I will show you what your currently resolved settings are for any flags/variables/configs next to the corresponding flag, as well as the default value. I actually don't know why this isn't common.
If people from this thread took notice we all could have a clean $HOME and there would be no need for this non-discussion. As you found out, it is incredibly easy to conform to the spec.
It's especially frustrating because it means you can't simply back up your entire `~/.config` (or wherever you pointed your `${XDG_CONFIG_HOME}`), you have to pick specific files & folders in there.
On Linux we separate stuff so you can for instance backup config without having to figure out for each of 100 applications where they have stored config in 100 heaps of mud.
And you are sidestepping the issue of control. With XDG you can easily and generically symlink your 100 balls of mud back with 3 lines of bash. That's because with XDG you have structure. The other way around you don´t. So don´t talk about `clean`.
I'm not. Lots of things in a directory is not inherently a mess. I mentioned exceptions, things such as bash and steam make a mess because they're not completely cleanly filed away in their own directory. In my experience most things (not all) that don't use XDG are happy to cleanly files their stuff away in its own directory, sometimes divided up further into subdirectories when it makes sense. Or a single file instead of a directory if there will only be one file.
> If you want to lump everything together then Linux is not your friend.
I don't need to be friends with a kernel, and anyway, this practice has been around on Linux longer than XDG has existed. I see no reason why it won't continue to work just fine in the future.
> On Linux we separate stuff so you can for instance backup config without having to figure out for each of 100 applications where they have stored config in 100 heaps of mud.
People use Linux in different fashions. You're free to use it how you want and I'm free to use it how I want it. Your backup scheme is not suitable for me, and I suspect mine is not suitable for you. And that's OK.
> And you are sidestepping the issue of control. With XDG you can easily and generically symlink your 100 balls of mud back with 3 lines of bash. That's because with XDG you have structure. The other way around you don´t. So don´t talk about `clean`.
Most applications in my experience have a mechanism to define where configuration is read from. That's control, not your symlink mess. Structure is done appropriately per application.
It's fine if you disagree with me. It bothers me when I'm told that my opinions are wrong, which is what your post reads like to me.
All of this is just a nightmare and I much prefer the simpler ~/.program or ~/.programrc approach. It's findable, it fits perfectly fine in the non-NFS use case, and just stop running "ls -A" on every invocation.
(Sadly, the Windows stuff really screws up running games through Wine, since it will default to connecting the Windows "Documents" to ~/Documents and ... ick. I disable this feature in Wine just to make it separate. They can muck up Wine's Windows folders as much as they want, it's invisible to me.)
Programs that put everything in .config or .local/share mess that up.
The XDG spec is so simple, if a software developer still lacks the mental capacity to adhere to it he/she might be better of finding different hobbies. Come on now.
I'm not convinced that one is unequivocally better than the other. For me personally, I prefer a flat namespace to having to hunt down directories in a tree of varying depth.
I manage $HOME, this is meant for valuable personal documents. I manage them manually. You as a software distributor better are not gonna clash with what I am doing there with your shitty engineering.
If you insist on making a mess of your $HOME, XDG allows for that. You can set all your XDG variables to $HOME. And even without doing so, you can create symlinks to make your $HOME like you want. That is an unfair advantage you get with XDG adherence.
XDG gives you as the user more control. If you don´t adhere to XDG, you take that control away from the user.
XDG allows for a superior partitioning. If you don´t like it, you are likely to complain about Linux as well. XDG separates config, run state, cache and data, which is quite reasonable for a Linux system as that is what Linux does.
---
> If I want a specific program’s config directory somewhere other than the XDG setting, that’s not possible.
1. $XDG_CONFIG_DIRS even allows for more multiple paths to be searched.
2. You could even override XDG-vars per application in a launch script or in the shortcut.
> If I want all my config, cache, and local stores in per-program directories, XDG makes that impossible.
You can set all the relevant $XDG_vars to $HOME and all your foo stuff ends up in $HOME/foo. Or symlink from $HOME.
The XDG world gives you options, while the non-XDG world doesn´t.
---
XDG could have opted for user overridable utils instead of variables. But you have already lots of options now.
That seems like it could easily lead to conflicts.
Besides, if you think that's polluted, then pushing it off to ~/.config and ~/.local/share is just sweeping it under the rug.
If you want to create a mess, you are free to do so with XDG variables. Read my other comments for that.
Stop pissing in my $HOME and don´t tell me I should have no problem with that. Just adhere to XDG, $HOME is for me and I decide what I want there. You don´t.
If you want to shit around in $HOME, you can make symlinks from $HOME or set your XDG-vars to $HOME.
In the non-XDG world we don´t have that control. Such software shits into $HOME, and it sticks there because it refuses to listen for user preferences (XDG-vars). As a user that deals with non-xdg software I don´t have control on the one directory that was meant for ME.
--
The only improvement I can think of is that XDG would provide functions that software could call into instead of vars to get dir paths. That way, the user could have very fine control (even per application) when they write their own bash override.
> If I want .chromium, .0ad, etc. instead of .config, I'm SOL.
Technically not SOL, you just need to set the launcher of whatever binary to set the XDG env vars to $HOME/.programname on launch.
Or use links.
What about $HOME/Documents? But yeah, I hear you, I gave up on $HOME as my personal space, I put my stuff in /data (I use my computer alone) and let any software pollute my $HOME.
Which makes sense in theory, but the execution is horrible. The ~/.cache directory is also on NFS now... You NEVER want cache on NFS.
>~/.local would stay on the local workstation
Never seen this in practice. This dir is also created on the NFS share, which it should be, since you need to bring these files to other machines as well. The standard is poorly thought out and poorly implemented.
And yeah, poor implementation means that ~/.local not roaming around with you just makes things worse, despite the obvious name and intention. Developers almost never know when to properly implement it.
XDG is just overcomplicated nonsense. The only part I like is ~/.cache. I don't buy for one bit the "clutter" argument about having some dotfiles (and no, setting $XDG_CONFIG_DIR=$HOME and $XDG_DATA_HOME=$HOME does not solve it; first, conflicts; second, files won't be prefixed with a dot).
I'm trying really hard not to end this flippantly with "go touch grass" but I think the mood fits. Escalating appeals to emotion are unhelpful and "cringe" when trying to convince open source developers to add your pet issue to their roadmaps.
Like I said: it's easy to just dump stuff in $HOME. It's a lot harder to properly handle paths, but it should be done anyway to be a good citizen. Ideally: check for a legacy path; if it doesn't exist, check for XDG paths; if that doesn't exist, create and use XDG paths. If a legacy path exists, notify the user of a migration and either warn them to do it, or attempt to do it for the user.
I really wonder how many programs will immediately break if I suddenly set my home directory permissions to 0100.
This isn't a problem where you can just copy and paste a deductively-proven-correct-for-all-inputs solution and be done. One way or another you're creating problems for existing users and existing scripts as soon as you start using the new location. A newly provisioned system with an old script (or an old user (and "old" meaning nothing more than "older than this change")) running on it is going to end up thinking that it's doing a create-or-modify on, say,`.bashrc`, when in fact it's doing an override (because existing config was in the new location).
"Ignorance" is being blind to that problem (and others). "Arrogance" is pretending like it's somehow obvious that that problem isn't worse than the benefits of unifying on this convention, especially when there are so many examples of estimable projects on both sides of the issue.
And what's this nonsense about "my computer, not the app maker's"? How do you think project governance works? Decisions are made, and every single time a subset of users are disappointed. That subset isn't having control of their computers taken from them. This stuff is happening out in the open, for free, and with express permission to override any behavior you want with your own patches. You can even distribute your patched version, also free of charge. It's downright humbling how free we are when it comes to bash and OpenSSH, and you have the gall to come out with "My computer is mind, not the app maker's"? Do you have any idea how low the bar is for user respect in the average app? How much money can be made if you're willing to disrespect your users? And the bash and OpenSSH folks would never, not ever consider any such breach. They have stayed firm, despite world-blanketing success, in their user-respecting free software ways.
And for a disagreement of where to put config files, you'd lump them in with the user-hating rabble that makes up the rest of the software industry. We're surrounded by people who actually do arbitrarily dismiss user concerns (because the users are the product). People who actually do believe your computer belongs to them when you use their software. Please, in the middle of all this shit, keep in mind who your best allies are and just have a civil engineering disagreement with them, without insulting them.
Could you give a couple of example reasons why a developer would choose to ignore community standards here?
Given how often tools like bash and ssh are used programmatically and not just interactively, it is very much conceivable that the right choice, the one that brings the least amount of harm to their users, for bash and OpenSSH is to stick to their existing conventions forever.
I should also note that $HOME/.program-name is very much a community standard that the XDG people decided to move away from. Or at least it used to be.
That doesn't mean every .dumb_tiny_cli_rc gets to do that as well.
> I should also note that $HOME/.program-name is very much a community standard that the XDG people decided to move away from.
So was every single inferior standard or convention, before it was replaced by a better one. It's called progress. It's a balance between improvement and breaking changes / disruption, but you need some improvement over time.
The xdg standard just introduced 3 additionnal .config .local .cache directories that do not solve the presence of the regular .dot directories/files. It didn't solve anything, just added more mess. Besides the stuff that end in .config is as messy as what was in ~/.dotdirs. I once was naive enough to think I could put my .config into a git repo...Quickly enough you realise that a lot of developpers put what the fuck they want, including stuff that should be in .local or .cache into .config and you end up writing a novel in your .gitignore.
XDG didn't solve that, it just added additionnal mess, which I didn't wish for.
If it was to end with that mess, I'd rather have it the old way and keep mt dot files at the root and separate my own files into a dedicated folder, and I AM THE ONE to choose if it has to be called files, documents, docs, translated or not, not some people pretending it built a (broken) standard that would solve every user needs.
Maybe I'm not most users, but I absolutely put my files in ~/.config/$my_namespace/
> It didn't solve anything, just added more mess.
Have you ever had to migrate/sync parts of a system across multiple hosts, or even just backup with very limited space and having to be choosy about what is stored? XDG makes it WAY easier to set up rules to include/exclude stuff, than a bazillion .programrc dirs (which make no config/data distinction). Cache can be completely ignored and usually (the more voluminous ) program data can be skipped. The app will usually generate it as needed, and if not, I know what to sync.
Every program and their dog barfing in $HOME is something I didn't wish for.
I myself simply want the software to work and not to suddenly change behaviour. If you're writing something entirely new, perhaps the holy edicts of the XDG are right for you. But to ask for OpenSSH to change shows a complete incompetence in software leadership and impact assessment. Anyone that suggests something that insane ought not to be listened to and all their ideas ought to be entirely disregarded.
It's buried in my gentoo config, but I wonder if there'd be a good way to make this useful on other distros.
[1]: https://github.com/search?q=repo%3Amid-kid%2Fgentoo-config%2...
[2]: https://github.com/mid-kid/config/blob/master/shell/.zprofil...
That way, I accept that the (My)Documents folder is full of other programs' crap, but the "files" folder is MY PRECIOUS and no-one but me decides what goes in there.
After this, it's an easter egg hunt to guess what dot-directories got spammed.
As far as I can tell, the XDG spec only benefits people who care really hard about how many hidden files are in $HOME. It definitely breaks behavior for people who DO want those per-app directories/files in $HOME, because the XDG spec does not mandate that the files created under e.g. .config/ are dotfiles themselves. So setting $XDG_CONFIG_HOME=$HOME just creates non-hidden files in the home directory.
At no point in this article is a technical justification made for this rigamarole, but this article goes to great lengths to accuse people against it of cowardice, ignorance, or arrogance. Just... why?
> Just... why?
Author here; I was under the impression the quote from the Vim issue tracker in §3.1 was a good cornerstone for the article, which is that accepting and implementing an existing standard—however hard it might be for developers now—is good for users in the long term, because it makes life easier for them.
And therefore developers should try to adhere to the standard even if it is difficult to implement, since software is written for users, first and foremost.
Genuine question: was that not clear enough?
In my opinion, ~/.something is easier for me as a user than using the various XDG directories. But in practice, I really don't care what scheme an application uses.
I like the XDG specs, but even programs that pretend to follow it don't follow it. CMUS, a music player, moved into ~/.config.. moved everything, including files that belong to .cache and .local/state. Google Chrome has 999 mb worth of files in its .config folder on my computer. The truth of the matter is that XDG only managed to encourage developers to move their files away from the root of $HOME but they didn't manage to make people respect a proper hierarchy of files.
This is a great point, honestly. XDG actually does specify where things are supposed to go, and distinguishes between config, cache, state, and strictly-user files, but devs don't respect that hierarchy, either.
I completely fail to understand this viewpoint. The non-config files that I intentionally put into $HOME are infinitely more valuable than anything I would want to backup from .config.
I have hundreds of gigabytes in non-hidden sub-directories of $HOME, such as all my family photos, all my health-related documents, all my email, and so on -- and they are backed-up every single day.
Why is backing up your actual files in $HOME a non-starter? What makes your .config more valuable than everything else in your $HOME?
If only the last stubborn applications would comply, I would have just 1 place to look for config, and one place to wipe caches.
There are programs that even manage to create multiple dirs, like .something1/ and .something2/. Some other programs are even worse and put files just into $HOME. Good luck with backups.
Backups are even harder now because I have to cherry pick what to backup from even more places. I don't backup all of $HOME because it's loaded with junk I don't want to waste backup space on.
A fellow commenter pointed out that it makes excluding cache files from backups much easier. That is a great technical justification, which hilariously does not apply to vim, which by default drops swapfiles in pwd anyway.
I further reject the notion that this is something being "done to the user" by the software. Software is a tool of the user, refusing to learn how the tool works and pretending that the program you chose to execute is some kind of rude houseguest is just wheelspinning.
That's configurable! Check out :h directory , or just add *.sw? as a filter in .gitignore.
Configurable is best. XDG peeps get what they want, the rest of us get what we want.
And I'm not sure, maybe you just didn't read the rest of my comment, but in it I explain that when XDG people get what they want, it becomes literally impossible to configure the software to revert to the previous norm. In other words, when XDG people get what they want, nobody else can.
It depends on how XDG dirs are handled by the software. If we're forced to use the env vars then it's not really optional anymore. But if the program can default to another location without those env vars set (trivial with an ldpreload script or something), then it supports both.
Vim can be configured to use XDG dirs, if you really want to. Does Neovim limit users to only XDG for its config? I can't think of many pieces of software that outright force XDG. Maybe GNOME stuff?
Imagine you have program "foo" which has config, cache, and so on. What XDG-basedir env vars can you set to make it use ~/.foo for all of that? If you try, then because software following XDG-basedir probably doesn't anticipate that XDG_CONFIG_HOME and XDG_CACHE_HOME might have the same value (and because your time is more valuable than auditing the code to find out whether they did anticipate this), you are left with .foo/config, .foo/cache, and .foo/local.
You have created a new "home", and, more importantly, you disallow "foo" from ever spawning a separate program that also uses the same XDG vars. Spawning programs is rather a central Unix principle if you have many tools that each do one thing well.
- ~/.config/foo -- only you write files here, so it's your detritus, not the program's :)
- ~/.cache/foo -- this is non-essential cached data, by definition detritus. Go ahead and clear out all of ~/.cache whenever you feel like it
- ~/.local/share/foo -- this is the program's user-specific data, data which it may have created or which you may have created. Whether it is detritus is up to you
I think the strongest justification for XDG is that it makes it stupid easy to configure backups so as to exclude cache files. And the separation of config from data also makes it easy to keep a git repo for all your ~/.config files.
That's not true.
> ls ~/.config/cef_user_data/Dictionaries
> en-US-9-0.bdic
That's a dictionary file written in a binary format. I don't even know what program wrote this crap there, only that it's embedding chrome (CEF).
> ls ~/.config/ibus/bus/
> dcf58003d1744e71aa86dd97e951d49d-unix-0 dcf58003d1744e71aa86dd97e951d49d-unix-1 dcf58003d1744e71aa86dd97e951d49d-unix-wayland-0
Files describing how to do IPC with current processes. They belong to ~/.local/state not .config.
This time, I won't even try to make a judgement as to what is "my detritus" as opposed to the program's because there are too many files involved, and will just show how much they occupy on my drive despite being in .config when 90% of them really ought to be in .local/share and .cache
> cd ~/.config/google-chrome
> du -h
> 999M .
Ahem. I think the idealism toward the XDG spec has not panned out.
By the way, Chrome does have folders in .cache :
> cd ~/.cache/google-chrome
> du -h
> 651M .
But, I believe it doesn't put "local storage" stuff from webapps there.
It doesn't use ~/.local at all.
~/.config is broken beyond belief and not the place where you just have "your config files".
The only sane way to manage "your config files" is to put them in a git managed folder and use a symlink farm program.
Another option is to ignore all files and selectively allow the ones you want to track. That's what I'm doing now.
> Files describing how to do IPC with current processes. They belong to ~/.local/state not .config.
XDG_RUNTIME_DIR (i.e.: /run/user/1000)
.local is rather new, so .config has been misused for what was meant to go there. Some applications are broken and stuff caches in there (Google stuffs shader caches in there it seems?), but minor misuses is one thing - .config and .local are conceptually very close for example - intentional disobedience another.
The spec is well adopted (I have hundreds of folders in ~/.config, only tens in ~), and there is no reason not to follow it - especially for cross-platform things where path logic must already exist. There are just some projects that decide to stubbornly go against community and user wishes and disallow improvements.
I understand your point, but there is a lot more going on than just "configuration that isn't human readable" unfortunately.
> (Google stuffs shader caches in there it seems?)
They also stuff web storage.
And despite their misuses of .config they also still pollute the root $HOME by creating $HOME/.pki. Deleting the folder and restarting Chrome will always create this thing.
This is what i do, so with `git status` i see all the shit that i didn't put there. So
> ~/.config/foo -- only you write files here, so it's your detritus, not the program's :)
... is obviously not true.
Also, it’s not “respecting your users” to change where their config is stored without giving them an option. Were OpenSSH to implement XDG, I may want .ssh to remain where it is, but the XDG spec would give me no way to specify that preference. Certainly a lot of tools would expect to find .ssh in $HOME but wouldn’t. And the systemd integrated stuff expects an active user session, which is not always going to be the case.
Sorry to say that it’s typical for folks like this to rant about respecting users while completely ignoring whole categories of use cases and insisting on breaking long-standing behavior for their own aesthetic sense of consistency.
Personally I have largely abandoned ~/Documents and keep all my work in a sub-directory of it that's under my control.
I'd expect the "less attractive" part is for when you do want users to find the data your program creates in general.
I hadn't given this much thought but now I am disappointed that the people who came up with these standards didn't do more UX research and trial & error with actual users. Perhaps if they paid attention to all the use cases and stakeholder needs it wouldn't be such a mess.
- ~/Library/Application\ Support/$app - sometimes used for configuration, sometimes used for support data, sometimes for other things entirely (including caches, but that is the wrong place); probably similar to $XDG_DATA_HOME.
- ~/Library/Caches/$app - equivalent to $XDG_CACHE_HOME.
- ~/Library/Logs/$app - no direct equivalent, but ~/.local/var/logs.
- ~/Library/Preferences/$app - mostly $XDG_CONFIG_HOME, but $app in this case could simply be a single plist if that's all you need.
I mostly find myself annoyed when command-line apps use those directories, because it makes shared configurations between Linux and macOS that much harder, even with chezmoi. At the same time, respecting that over the non-native XDG…is what this article is about, no?
Not that the author gives any time to macOS except an ignorant swipe at macOS windowing (you don't like it and you're not used to it; that doesn't make it wrong).
I don't find this weird or unusual at all, just different than how I've handled file management on computers since I was a child using the family computer; I did notice the way computers stored program data when I was first learning computers and while I had a vague understanding of how programs worked, the conclusion I came to as a child was "just don't mess with the stuff the OS uses and make your own folders instead."
Usually I have my personal documents in some folder(s) under / or on dedicated drives, separate from the OS/program directories entirely whenever possible, and I treat any pre-existing folder structure as "the OS' and programs' folders" and just don't use them at all (with the exception of ~/Desktop and ~/Downloads which more or less I use normally) I understood early on that developers might make their workspace just about anywhere so I don't particularly care about the system defaults and instead try to keep my data in its own location outside of any system defaults whenever possible. The before-mentioned ~/Desktop and ~/Downloads I treat just as temporary directories for me and fair-game for other processes, so my workflows specifically don't keep any personal or sensitive data in common system directories.
(Actually, it lives in a sub-directory of one of those directories, with a disused organizational scheme lurking around it, but, well, if you want more details on that there's a whole blog post: https://egypt.urnash.com/blog/2019/01/06/how-i-work-file-org... )
Back on the Amiga I had something like four partitions on a then-massive hard drive, one for the OS, and three for My Stuff, which I managed however the hell I pleased. But that's not really an option on a laptop.
It isn't. Well-behaved Mac programs use ~/Library/Application Support/ and ~/Library/Preferences/ for these sort of things.
GUI-based software that craps on my home folder doesn't last long on my system unless it must be there for some reason.
For Terminal-based software, though, unfortunately it is common, as it's just another bit of UNIX software.
I really want to have a home that isn't a clutter filled hell. Same thing with code repos. To me, the source is the first & most important thing. I want foo.ts at the top level. I'd opt to put all the buildconfig stuff in .config.
LD-preload-open* can be used for this, but it has some potential problems: https://github.com/fritzw/ld-preload-open/tree/master#potent...
Not supporting any "at" variants (like openat) is a pretty big one! I bet a lot of these could be tackled with a lot of work to track state, but some like symlinks not working well since they're handled at the OS level seem hard to imagine overcoming.
FUSE would definitely have some issues too, but I think a lot would go away.
And time and experience has shown that it is a subpar solution, especially when $HOME/.myapprc is effectively hardcoded, so you can't even reconfigure it, you gotta use links.
E.G: for python, the current go-to pypi module for this is platformdirs (https://pypi.org/project/platformdirs)
It's probably easier to promote the use of the module than explain the standard.
C and C++ still have strong roll-your-own culture, with the exception that C++ now has a decent filesystem module in the standard library but still no standard config file parser AFAIK, everyone usually imports nlohmann's JSON library.
That will respect platform conventions on Windows, macOS, and Linux/UNIX.
In XDG's favour, we can say that it is just a written convention that people are free to follow or not on a per-program and per-user basis. It is not a cancerous growth that tries to borg the whole system.
A systemd standard, we covered that. Great reason not to use it.
>It's absolutely no skin off your nose to adopt it
It is if I have to implement logic to support this shitty "standard".
>beneficial to you and your users if you do.
Poorly thought out and imposed standards are not beneficial to anyone.
"I use Ubuntu and develop in full stack JavaScript so everyone else does too."
No, it is not "practically universal". Alpine Linux, MacOS, FreeBSD, illumos UNIX distros, etc. do not follow this imposed "standard".
>Even if there's a Linux distro going out of it's way not to set them
You have this backwards. The systemd standard is imposed on Linux, not the other way around.
>In practice I've never encountered users with a distro that didn't have these variables set.
"I use Ubuntu and develop in full stack JavaScript so everyone else does too."
I really like this one's approach. These guys created a kernel module to enforce their hierarchy and hide directories, etc. Such an interesting project!
Playing with alternative structures is fine though.
It would make playing with alternative hierarchies kinda fun.
Aren't dot files just pretending to be hidden due to a bug in early Unix?
Unix v1 had a flat filesystem. Unix v2 added subdirectories. As an implementation detail, each directory contained two magic files, `.` for "this directory" and `..` for "the parent directory".
The command to list files was sloppily coded to skip them. If a name started with a dot, it was skipped.
Hey presto! Unix 2 had a way to hide files! It was a bug, but it was useful, so it stayed.
The history: https://tookmund.com/2022/03/rob-pike-shortcuts
So, Gobo doesn't use `/etc` and `/var` and all that 1970s nonsense, but it keeps them around, empty except for shortcuts, for sloppy code that assumes they are there.
But they are hidden, just like dot files are hidden on every Unix-like OS. Because it looks better, no other reason.
Nowadays homebrew on arm processors puts everything into /opt/homebrew instead by default...
I rather have a kernel-level filesystem remapper.
While the code is mundane and might not score any beauty points, it does offer a clear technical advantage. Namely, Nix doesn't require that packagers uniquely choose the installation path for each package. Instead, Nix guarantees that different package definitions result in a different installation path. This is one of the things that make Nix package definitions programmable because packagers don't have to manually resolve path conflicts.
Programmable package definitions mean more automation and customizability.
I don't understand this section heading. To me, software convention has the third meaning as shown on merriam webster[1]:
> 3 d : an established technique, practice, or device (as in the theater)
In that case, that we've always done it that way establishes the technique, and the established technique is the convention.
To argue that non-desktop software should apply a desktop specification that they weren't involved in developing seems rather insane, especially since they are and have been following the established convention.
So what, stuff changes over time - and it's not that hard to migrate, either warn the user, or do the migration at first start. Good software should move with the times, not be perpetually frozen.
Respect the user.
Either way, it had a clean break from Vim and didn't have to deal with people who have been using Neovim for decades (lots of things are different compared to Vim and it's not intended to be compatible in the first place).
How many documents tell you to configure ssh with something in ~/.ssh/config and if the change is made, will now need to be changed to say put your config in one of many paths depending on the version you use?
What if you migrate your config and then roll back to an earlier version?
What if you use your home directory on multiple systems, some which have varying versions of the tool, loading the config from various places (network mounted home directories are a practice in some companies)?
What if you don't upgrade for ten years, and the migration code is gone by then?
What if you operate on a mix of systems of various ages, some which have the new path and some which have the old?
What if the migration code has a security vulnerability?
Personally, I don't see where the benefit is that pays for anywhere near any of this cost. Maybe if you're a desktop app that is within the scope of standards put out by the XDG, you might want to consider accepting this standard of theirs too; and sure, if you're a new application, seems like a might as well?
And whether you agree with it or not, I doubt anyone understands "desktop" as meaning "GUI only" and not "for human users" in this context. I usually see it used contrastively as in "desktop" vs "server". Server software lives in `/usr` and writes to `/run` and `/var`, etc.
Config files don't apply to only human users either, though. Automation also uses configs. And they've got to be somewhere. Some automation is desktop oriented, I'll acknowledge.
If this standard came from Posix, sure, that applies generally across unix and linux to all programs great and small. If it comes from Linux Standards Base, I've got issues, cause I don't run Linux, but that at least clearly applies to all programs on Linux, packaged by a distribution and configuration file locations are obviously within the scope of LSB.
But XDG is more or less the Xorg/Freedesktop peeps; how are config files for everything under the sun in their scope? There's lots of stuff in their scope, but this just seems out of the blue. Being not an exclusively Linux organization is somewhat helpful, but still. How is the XDG an authority on where to place config files when there was already a servicable location to put them (and the specification documentation doesn't even have a discussion of who they are, why their spec matters, how the values came to be, etc)
I addressed this in the article: Linux devs not being able to accept some authority—in this case, XDG—is the source of the fragmentation in Linux and why even though we have a spec, there's still a solid 30%+ of programs that don't follow it.
Yes, OpenSSH isn't a 'desktop' program, but there are dozens of desktop programs which use it as a backend. Forget Linux, for a moment: it creates `.ssh`on Windows. Windows doesn't have dot-files, and it never had. This is arrogance.
I would say this is rather consistency accross OS.
Every openssh user knows where to find its config regardless of the OS, if it follows XDG, windows guidelines or if it is running on Haiku, SerenityOS, Redox or RiscOS.
There are plenty of windows specific ssh clients that follow Microsoft guidelines.
But I'm not seeing how that's a problem. One of the beautiful things about the Bazaar is that if you don't like one part of it, you can move to another where they do things a bit differently. If everyone is deferring to an authority, upon what virtues and rigors do we determine its validity? What powers does it have, and why should we just blindly follow others in one of the most creative human endeavors available on Earth?
Why should one accept authority? Where does the power of this authority come from?
I have similar ideas in society fwiw. I don't see a moral reason to defer to someone else. Is my will less important than the preferences of some other person or group? As long as it's my time and effort being put into making software, it'll be built to the specification of me and any legitimate stakeholders.
My opinions are probably a result of how and where I was raised.
That being said, I don't claim we should defer to authority for authority's sake. Authority is given by the people. In the case of the XDG Base Directories, for instance, I believe the specification is well-laid-out. It has gained enough traction and enough developers adhere to it that it has authority of its own accord: by accepting the specification, developers have voted to give XDG that authority.
That is how it works in democracies, no?
The concept of authority as democracy doesn't really make sense to me. Does that mean you adopt any and all conventions once they hit 50.1%? I think we as humans can do better than just follow or limit ourselves to standards that may be popular, but are not necessarily the best tool for the job. I struggle to find many popular and mainstream software practices to be quality, or fitting for me despite the one-size-fits-all that such popular things try to aim for.
What is your role in this 'democracy', if you are actively lobbying for a minority (the XDG) to seize control over the way desktop software is written in the community, by way of writing the piece and it getting shared? That strikes me as manipulating a narrative to get people to "vote for" XDG. It's not a legitimate vote if you and others are actively evangelizing. It's called social pressure and canvassing.
Such social and organizational efforts are completely oblivious to the fact that they are operating in a bazaar, and their methods are designed better for Cathedrals. Cathedrals are used to tightly integrated stacks and top-down decision-making, so standards are hardly different than marching orders to the monks.
The bazaar is the wild west. The only authority in a bazaar is whoever owns the land. In a digital space, there is no land. So how does any authority -- controlling environment variables, of all things -- intend to exert itself in force?
If it's truly a democracy, then the voice of those who resist XDG is equally valuable and valid.
165 packages support XDG; 164 partially support it, where partial support really just means they have a way to configure the config path to an arbitrary file and if you tell it with an environment variable, it works; and 128 are unsupported. [1]
Based on that, if software is a democracy, the vote for XDG has failed, let's move back to dotfiles. Of course, moving config files is a lot of extra work and cost for users, so all the existing applications should get a pass for wherever their config files already are, but new application should follow the democratically elected choice of stuff dotfiles in the home directory.
Of course, I don't believe software is a democracy in the sense of voting and the will of the majority overriding the minority. Software is a democracy in the sense that the tools are open, so anyone can build what they want. Less restrictive source licenses allow you to take other people's work and build upon it how you want. Someone could fork all of the programs they use that don't follow the convention of their choice and "fix" them, and users could pick which one they like, software distributors could choose which one they'd like to distribute; etc.
From earlier:
> I addressed this in the article: Linux devs not being able to accept some authority—in this case, XDG—is the source of the fragmentation in Linux and why even though we have a spec, there's still a solid 30%+ of programs that don't follow it.
All authorities naturally have a scope. We don't all follow the style guides of the New York Times or the Chicago Manual of Style, although those are common to adopt in the United States because writing a style guide is hard and might as well pick one someone else did the work for. On the other hand, if you tell a UK person that they didn't follow a US style guide so they're arrogant, they'll quite rightly tell you you're arrogant and the standards of another country don't matter.
Sure, if you're writing new software, you should look around for the relevant specifications and consider picking one. If you're existing software, switching specifications is a breaking change, and you should consider what you get. You've said you find the XDG Base Directory Specification well-laid-out; but I find it lacking a declaration of objectives, justifications, and scope; those issues are non-starters for me, so I would chose the dotfile specification instead, unless I was writing something under the scope of the XDG.
[1] votes counted by separating out the tables, and grep -c '<tr>'; this is a poor way to run an election, but it's the data I have available, and the amount of effort I'm willing to expend
The person who wrote pam_systemd(8) als co-authored the XDG basedir spec.
- use some form of $APPDIR variable convention
- using some app-specific $MYAPP_CONFIG variable (ick, but at least it's configurable)
- just dump it in $HOME and pollute that top level namespace
For example this should be in .cache:
3.3G .config/microsoft-edge/Default/Service Worker/CacheStorage/
But wait, there is a .cache/microsoft-edge :
608M .cache/microsoft-edge/Default
552K .cache/microsoft-edge/PnaclTranslationCache
But it is deceptively small compared to the one in .config. Not sure what the MS engineer are smocking to be honest but it is good stuff.
Also last time I used visual studio code, I had stuff in .vscode.
https://gist.github.com/sharadhr/39b804236c1941e9c30d90af828...
An example: My own "Free Hero Mesh" software can be made to find its files in the same directory as the program file, but by default it is compiled to not do that if it is in your PATH. It will first look at the HEROMESH_PREFIX environment variable; if that is not set, then HOME will be used instead. (You can still override it with command-line switches, and by doing what I mentioned above. You can also configure it at compile time.) However, the only file it creates itself automatically is one that the other file (which you must manually create) can optionally override its path, so you should not need to worry about automatically created files in your home directory. (I do not currently target multiple operating systems. Others are free to try to port it if you want to do so (and I can answer any questions), but I do not expect to do it by myself.)
In fact, I too would want it; if I want a configuration file I should just create it by myself; this is how X resource manager is working and I think that is good. Unfortunately some programs insist to do it automatically themself anyways; in those cases I change the permissions of those files so that they are read-only so that the program doesn't automatically update the configuration file in this way (for example, this is the case with xdvi).
One, Red Hat is one of the major contributors to XDG, and is pulling developers away from XDG projects. To what extent I am not fully aware. We've learned time and time again that for-profit entities should not be in charge, or highly influential, in standards. They will inevitably steer them to favor their own ideas.
Two, what luck has the greater community had in getting their ideas adopted to the 'standards'? Standards are not meant to be inflicted; if a standard cannot gain enough consensus, and lacks authority to control who publishes software to a platform, then what good is it? XDG comes from the GNOME and KDE crowd, meaning Red Hat/IBM, Trolltech, and maybe Canonical or a few other token companies. Notice the complete lack of real community input or control? If I wanted to defer to a standards body, I wouldn't be interested in software. I don't think software is about bending to the will of some third party group's idea of how computing should be done.
Three, kind of a nitpick, but they adopted the Contributor Covenant CoC which is problematic for people who respect compartmentalization of social spheres. I don't care if there's a dipshit bigot on a dev team as long as he or she keeps it out of the work environment.
I have sidestepped the issue (in my mind) by putting all personal files in a `~/me` subdirectory, and create symlinks in `$HOME` to point to the relevant files in `$HOME/me`. It keeps things separate, and anything that's put inside an XDG folder that I want to hold onto can be migrated to ~/me and symlinked. I keep a short bash script that I use to (re)create the symlinks for me, as needed.
A distro that feels really strongly about XDG could patch, or refuse to package anything that doesn't adhere to XDG. I wonder how far that approach would go.
In short, I am just not impressed with the way XDG is handled, nor the literature that gets pushy about people adopting it. The author used a sleight of hand to imply that XDG is an authoritative standard or that it has universal consensus. It is not, and does not. This dishonest representation of the XDG standards are part of why I am turned off by them. It's the same social approach that PulseAudio and systemd used.
If things are good, they will be adopted on their own without any advocacy needed.
(Edit: added third concern after checking their site more)
You're completely erasing the community involvement in KDE and GNOME. Moreover, it's grassroots that push utilities to follow the basedir-spec.
> Three, kind of a nitpick, but they adopted the Contributor Covenant CoC which is problematic for people who respect compartmentalization of social spheres. I don't care if there's a dipshit bigot on a dev team as long as he or she keeps it out of the work environment.
Again a misrepresentation. The CoC says to be tolerant of all contributors, and not doxx folks. Hardly burdensome. These are rules which nobody would ban an eyelid in a professional context.
What community involvement in KDE and GNOME? The GNOME guys tend to be dismissive of anything not fitting into their grand vision. I'm not sure what distinction you're trying to make on the grassroots comment. If a project has a majority of paid devs on it, it's de facto controlled by a company. The users don't really have a choice or an influence in those two projects.
They also don't have a choice if a bunch of people come together to force their idea of proper standards on the greater ecosystem. It's simply toxic social behavior.
> Again a misrepresentation. The CoC says to be tolerant of all contributors, and not doxx folks. Hardly burdensome. These are rules which nobody would ban an eyelid in a professional context.
Firstly, not a misrepresentation:
> This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
Look at that little wiggle room -- when you're representing the project. When does that apply? Who decides that? What's stopping FD.o and other CC CoC consumers from declaring that all contributors represent the project at all times?
This precise verbiage has been used to cause ruckus and harass people, because there are different customs and expectations between contributors as to where the line is on when you are representing the project.
Morally speaking, a project has little justification for punishing or ousting a contributor for any conduct that occurs outside of its infrastructure or community.
I don't care what the professional context is. That's another word and concept that means different things to different people, and is better used as a bat to shame people with than to form any reasonable standards of behavior that respect personal liberties and variety of expression. "Professional" people care far more about appearances and prefer to deliver their poison in etiquette-approved containers.
How often does one see behavior or words labeled as "unprofessional", without any logical or rhetorical backing? Personally, I see it every time it's accused.
I'm interested in reading about any community-driven features or standards that XDG has collaborated with the community on in good faith. i.e. something that was added without the need for a company to sponsor or approve it.
You or interested readers could use GNU stow to do that.
I use Stow myself to source music files from multiple root directories, it's a great piece of software that I simply could not wrangle to pull off what I was after.
Here's a link to the hacky script: https://git.zlg.space/linkfarm/tree/linkfarm.sh
Thanks for mentioning Stow, though; it doesn't get enough love and if you're smart with it, you can do some crazy things that, manually, would take hours or days.
This is particularly strange in light of number 3, which basically says "I don't care about process; only the final result".
I am against the solution because it requires yet more environment variables that need setting if you don't want a bunch of Windows-looking folders in your $HOME.
There are a great many things 'well-intentioned' in this world. I'm simply less convinced and more aloof to efforts that steer the way we compute.
The article and discussion have already shown that even proponents or adherants to XDG can't decide where things go. Data and cache get used interchangeably, and if I or a group of hackers want to improve or influence the standard, we will be stopped by the big desktop makers.
Usually, adopting standards comes with great benefits for everyone. The big guns win control if we capitulate to their way of building software.
I honestly see little reason we can't have competing 'standards' on file paths. That practice would encourage software to simply make its config path changeable at runtime.
There are too many people trying to turn GNU/Linux into one monolithic thing that's the same for everyone, and that defeats the moral point of free software. If I was required to follow these standards to get my software into a distro, I'd have moved on a long time ago.
The 'problem' with freedom is it lets you keep the pieces if things break. What you do with the pieces -- lean to XDG, switch OSes, make your own hierarchy -- is up to you.
Maybe the culture and community needs to be forked. There's clearly a group of hackers that loves bureaucracy and consensus before code is written, and another that doesn't really care for either of those things.
If others choose to look solely at the technical, then they will be led on like fools by the socially-targeting people, who aren't just looking to solve technical problems.
So what was the point of claiming I have no problem with the solution when I've not communicated that?
Wrt point 3, it's how one is supposed to act while in a group. You don't know them outside of the group, and it's none of your business what they do outside of the group. Some may claim that's overly tolerant, but in my opinion if a bigot behaves while working, it shows they know their ideas are unpopular and they have the tact and decorum to not bring it up. How they act outside the group is not up to the group.
Trolltech has very little control over KDE. KDE is about as decentralized as they come.
To the people not getting that reference: Check out who is the third-listed author's name https://specifications.freedesktop.org/basedir-spec/latest/
The guy works at Microsoft now. That ought to tell you where his values were for free software this whole time.
You probably can't get the individual directories for different purposes (.cache/.config/.local) because offending apps are unlikely to have these concepts (otherwise they probably wouldn't be offenders to begin with...) but you can just slam everything from $HOME/.foo into e.g. $XDG_CONFIG_HOME/foo and go.
Heck, git adopted ~/.config/git years ago, and yet just last week I ran across a tool that created and wrote to ~/.gitconfig instead of my ~/.config/git/config. If Bash tried to change then we'd be dealing with the fallout probably forever.
Which is terrible, btw. Configuration using untyped, unchecked files, readable & writeable by almost everything is one of the worst parts of Linux. Especially when it exists in a directory the user should expect to be their exclusive domain.
$HOME/.ncmpcpp -> $XDG_CONFIG_HOME/ncmpcpp
The correct way to handle this, for any projects forcing the change, is to use a staged deprecation period:
* first, you add support for XDG
* second, wait at least one version to give people time to get used to it
* third, switch the config location search order so it checks XDG before .whatever
* lastly, after an announcement and deprecation period, and at least 2-3 releases, remove support for the .whatever folder.
(To be fair, it's totally possible that my upgrade path with ncmpcpp skipped over some steps and they actually did it correctly. Will have to check when I care enough to dig through commits.)
Well, I'd rather their attempt at writing to my shell config breaks.
This is one of the many reasons why you should, if you haven't yet, manage your dotfiles with version control. Many tools assist in giving you some sugar over the process, I use homeshick which will move files away into a git controlled folder and create symlinks.
That way you can introduce the new guidelines while not breaking stuff to those who want the old bash.
First, I don't like tools overwriting my configuration. My dotfiles belong to me and I have things configured the way they are for a reason. Tools should inform me if changes are required to my configuration, and not just go and change it by itself.
Second, it prevents users from making their configuration files read only. This affects users of Home Manager by the way, which deploys configuration files as symlinks to read only files under /nix/store.
Even more egregious are files that write mutable state to configuration files, which makes them unsuitable for version control. Unfortunately, Docker is guilty of this and stores mutable state in config.json.
Finally, as mentioned, it interferes with XDG adoption.
Personally, I'm all for breaking tools that write to user configuration files. They cause too many headaches with no clear benefit.
This is fair behaviour IMO, because migrating configs automatically might break user setups.
I would then say emacs supports XDG, but doesn't use it by default, right?
Refer to section 50.4.4 (How Emacs Finds Your Init File) of the manual for more information.
My home directory also accumulates an ungodly amount of shite over the course of mere months. I refuse to use /tmp — what if I need this again at some point in the future?
x.txt that gets shared in chat, PATCH_broken? for an idea given to me that I couldn’t apply to master, image0001.jpeg and friends showing screenshots I dumped into code review and forgot to delete, notes816_review.md thrown together in haste in a meeting, xx.txt, AAA, AAAA, AAAAAA, v.sh, vrewrite.py, etc etc.
Every few months something creeps in with a massive filename and breaks ls’s tidy columnar output. At that point I bundle everything up into a directory called ~/Projects/Scrap/2023-08-16.
Over time you end up with these lovey scrapbooks of mostly crap but occasional gems like screenshots of growth stats graphs from 2008 or a PDF of Leuchturm’s product catalogue in 2011 or an example.c that helped solve an obscure bug or a list of yays/nays for a house party.
I am a hoarder of the worst kind. Real digital hoarders at least have racks of drives to keep their house warm. This stuff is barely 400MB.
Having strewn files about is so stressful for me, I have to squirrel it away in one place or it will drive me batty. I'd rather have one directory holding all of that crap, so if I ever have a "screw it" day, I can `rm -rf ~/scratch/*` and be done with it.
Have you tried to sit down and create a hierarchy that makes sense for your way of thinking? I spent a weekend working on it a year or two ago and it's made things SO much better. I won't suggest any particular structure, but here's a rundown of what I put together: https://imgur.com/a/QVehjvy
I love reading about people's directory or symlink structures.
This also applies to game engines and their own conventions. For example Unity has Application::persistentDataPath[1], which uses $XDG_CONFIG_HOME (still a bit meh, since I wouldn't treat savefiles as "config", but at least some convention). However, some games tend to write those into Application::dataPath[1] (or even other random directories they see fit), which is supposed to be read-only and could possibly be outside of $HOME.
Fortunately the single one advantage of antivirus software out there seems to be that the above seems to break with some AV, so developers either tell their players to disable AV or they simply fix the issue. I made countless bug reports on this issue and so far it exclusively got fixed because of AV, so I'm using that as an argument for future reports.
While at least most of the Unity games I've packaged seem to adhere to these conventions, other games and game engines are a mixed bag and I've seen games dumping their stuff into $PWD to games writing to Windows paths (eg. /home/foo/SomeVendor\Somegame).
Patching these games is also very tedious, since some of them tend to get updates, so patching needs to be done in a way to be forward-compatible.
For example here is a patcher I wrote to get Factorio to adhere to XDG:
https://github.com/openlab-aux/vuizvui/blob/4690494feee20a62...
Here is an example for patching a Unity3d game that writes to Application::dataPath:
https://github.com/openlab-aux/vuizvui/blob/4690494feee20a62...
[1]: https://docs.unity3d.com/ScriptReference/Application-persist...
[2]: https://docs.unity3d.com/ScriptReference/Application-dataPat...
well that's certainly an opinion.
I'll second it, too! I've never seen an interesting argument in favor of macOS' app-centric model of task switching or stupid 'zoom' behavior, and have only discovered two features that I like in that whole system (menu bar searching and rebinding menu bar hotkeys).
Why would we want cache file in our home directory when we have a /var directory for this kind of stuff and especially a /var/tmp directory which has the sticky bit ? Who decided that cramming stuff into ~/.cache was a good idea instead of putting it in /var/tmp/usercache-<username> directory?
Why would we want a .config and .local directories full of binaries, artifacts and config files within our documents when we have /usr/local for that? Put that into /usr/local/<username> instead!
And then comes the terrible folder list:
Desktop : this one is largely unused by me, why putting icons in a screen when they will be mostly obscured by windows while I am using my computer? Do we have to replicate all bad ideas of Windows?
Documents : this one is okayish, but why isn't my whole homedir a documents homedir if we can clean it up from all the config, binaries and cache shit eh? Aren't Pictures, Music, Videos or what I download documents too?
Downloads : that one may be useful, although /tmp would be more interesting to me. For the most part if I don't use the files I download immediately I will never look for them or they will be possibly obsolete by the time I find them. It forces me to do housekeeping while having them in /tmp would clean the shit at next reboot.
Music: ok I suppose but nowadays lots of people are using streaming, I mean I can create it myself if I want to.
Pictures: this one is stupid, why is a picture not a 'document' and why would we need to separate it? What do I do if I want to put pictures asset in my markdown document? Should I point it to some obscure directory here or should I put it in myproject/assets/ ? OK some would argue this is a good place to auto import your photos from your camera but wait. If one day I use digikam but then I later decide it is not so great and want to use something else it is likely to make a mess.
Public: most people never use that. It is for file sharing purpose I reckon but it can be created whenever you need to by the 0.2% of people who will use it.
Templates: same as public, people are never that organized and will rarely put templates there instead of next to their docs. I never saw any app making use of that, most of the builtin templates are provided with the package and are stored in /usr/local
Videos: same stupidity as Pictures. My Videos ARE documents. Besides, what if I want to keep the videos of one event or my vacations next to the Photos? Why would I want videos of my kids playing on the beach be next to regular movies, porn, videos from a sports event I participated at or screen recordings?
All these folders are meant to target a majority of users but in the end create a fake sense of organization that doesn't really work for anyone, everybody end up having files everywhere and/or only partially following those conventions which end up with the same mess as having just the regular mess /home/<username> or /usr/local/home/<username>
But then we'd be running into another cobbled together standard, with an even uglier history: The Linux Standard Base hierarchy. Which I just learned died a few years back. Huh. Turns out the filesystem is not something easily wrangled... System paths are something I've thought would benefit more from being configurable with env-vars (maybe even in the kernel argument list on boot, or via grub?). The major differences between distro filesystems would be abstracted away to their boot settings.
/boot/grub/linux-dirs.conf when?
I see some benefit in abstracting utility directories behind an interface so application developers don't have to worry about it, but the way it's gone about seems backwards and highly dependent on your environment containing the right variables. It probably needs to be handled below the user/application layer.
While it is not dead, Gobolinux failed probably because it was still advertised as linux, so people expect linux to follow some standards. I have no idea how redox, haiku and serenityos are handling that stuff, I hope they have been smarter.
You want a radical idea? May I try to explode your brain?
We have persistent memory now. You can put a few terabytes of nonvolatile storage in your DIMM slots, and it's cheaper than RAM.
If your computer's memory map is entirely directly-addressible storage, every byte of every file is right there in the address space, all the time...
Then you don't need indirectly-addressed storage any more. No drives of any kind. No files of any kind. It's all in RAM all the time. You can dispense with filesystems completely and just manage it via an in-memory database or something.
No more folders. No more 2-dimensional tree. Every block of data can be found in 26 different indices if you want. Individual blocks of data can be in multiple programs, or documents, at once.
All that '70s hard disk stuff can just go away now.
But we're too scared. All we know how to do are disk drives and files in folders.
Memory corruption could be more disastrous due to its persistence, but given the RAM bus is faster than SATA... This might work!
https://www.theregister.com/2022/08/01/optane_intel_cancella...
In general the tech is called Persistent Memory:
https://www.netapp.com/data-storage/what-is-persistent-memor...
Can't use fixed paths in tmp dirs, that's either a security issue or a denial of service attack waiting to happen. I can `mkdir /var/tmp/usercache-prmoustache`.
> Put that into /usr/local/<username> instead!
Not writable to regular users, and not meant for that.
Well we don't even need a fixed dir, a session generated dir with an env variable set to it is enough.
Or we could put that somewhere else in var. We created /var/run/<users> dirs, there is no reason we couldn't do other directories for other uses.
>> Put that into /usr/local/<username> instead! > >Not writable to regular users,
fixable
> and not meant for that.
I am pretty sure I have used some BSD in the past where the home directories were in /usr/home and /usr/local is a pretty good spot to put what is -- wait for it -- local to the machine!
There is no reason we couldn't have all our user owned binaries in /usr/local/<username>/bin and /usr/local/<username>/lib and our configs in /usr/local/<username>/etc
It would just have to be created at user creation with correct user rights but that is no big deal.
Users would just put their files in their /home, be able to sync it accross machines/ possibly different OSes without necessarily synchronising config files that do not apply to it or worse, unneeded cache files. Their /usr/local/<username>/etc could be a git (or other versionning system) repo Their /usr/local/<username>/bin lib share whatever could be saved and restored easily
And all the variable/ephemeral shit/cache could go to var where they belong.
What I also know however, is that creating a custom template is not something most users have been waiting for not something they use expect maybe for a tiny fraction that looked for that possibility and read the corresponding doc.
And that tiny fraction of power user could have created that directory when needed while currently it is just an empty dir that sits unusead on probably 99% of the users homedirs.
Real-world equivalent: the imperial system of units dates to ancient Rome or older. The English used it throughout their empire. On the other hand, the SI units in their most modern form are barely a century old, and yet 95% of the Earth's population lives in a fully metricated country. Most metrication efforts happened in the last 50 – 70 years.
Didn't the large majority of developers converge and compromise to stuff dotfiles into my home directory directly? I've got 41 dotfiles in ~, one of which is from the software project known as config, which apparently has settings for glib-2.0?
Of course, I'm not running a desktop environment.
You just decided it was so, on your own.
I'm looking at you, MariaDB and WireGuard.