30 ms·

$HOME, not so sweet $HOME

251 points by delta_p_delta_x 3y ago

deleted 3y ago
[deleted]
maxique 3y ago
Archive link: https://archive.ph/pKW90 https://archive.ph/pKW90
- deleted 3y ago
  [deleted]
neverrroot 3y ago
Make that $HOME
- JadeNB 3y ago
  It's correct in the linked article; probably the title mangler got to it.
zh3 3y ago
I gave up on this fight some time ago; very interested to hear of better solutions than simply keeping a personal home elsewhere.
- gorgoiler 3y ago
  Pretty much everything I do on a daily basis is in ~/something, immediately in my home directory. It used to be ~/Projects/something but even that felt too organized. 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.
  - buildbot 3y ago
    Can confirm, as a digital hoarder with a medium size PC case with 8 16-20TB drives...No need for turning on the heat in the winter. Summer is a bit of an issue though!
    - justsomehnguy 3y ago
      Just place a bucket of cold water at the exhaust, free humidifier!
  - zlg_codes 3y ago
    Aha, I repurposed the XDG download directory to point to ~/scratch/, since most of those files are downloaded in my browser. Now I dump everything into that directory that hasn't been sorted into my hierarchy system (which is divided into ownership or source, then type or relevancy). 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 https://imgur.com/a/QVehjvy I love reading about people's directory or symlink structures.
  - zh3 3y ago
    That's close-ish to what I do, which is to have symlinks for frequently used directories in my home directory. And as most of those directories are actually on an NFS server, setting up a new PC is just mount the server, create the symlinks and then "cd someproject" or "cd ~/someproject' as usual (well, as long as you make sure you use the same UID/GID anyway).
  - gdprrrr 3y ago
    I have $HOME/tmp, for "temp but not tempfs"
psanford 3y ago
Yes, if you are writing new software please respect $XDG. But its a bit ridiculous to think that bash should respect some convention developed ~20 years after bash was released.
- LukeShu 3y ago
  I mean, Emacs respects the convention, developed ~40 years after Emacs was first released.
  - psanford 3y ago
    I'm not saying the developers couldn't support it. I'm saying you are not entitled to name call them if they choose to not support it.
  - lilyball 3y ago
    There are countless tools that write to the bash files though, which is not true for most programs. Bash changing its locations would break all of these. 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.
    - devnullbrain 3y ago
      >There are countless tools that write to the bash files though 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.
      - arp242 3y ago
        Whether it is or isn't terrible is sort of besides the point; the fact is that it exists, and that stuff would break.
tedunangst 3y ago
How is it not arrogant to say to an existing project "I hereby demand you move your config files to .config"?
- mschuster91 3y ago
  not adhering to a (reasonably well defined and accepted) standard kind of is a bug to me.
  - tedunangst 3y ago
    Resolved: the standard is for dot files to go in $HOME.
  - prmoustache 3y ago
    It is not reasonably well defined, it is even broken by design, and if it was so accepted we wouldn't have this conversation.
  - blueflow 3y ago
    Look up how XDG_RUNTIME_DIR gets set. Its a pam_systemd(8) thing and thus specific to GNU/Linux. So if you approach the non-glibc or *BSD folks with "please follow the XDG spec", you will likely not receive a nice answer.
- delta_p_delta_x 3y ago
  When the large majority of developers converges and compromises to reach an agreed-upon standard, it is arrogance to continue to stake it out by oneself, however old said existing project might be. 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.
  - toast0 3y ago
    > When the large majority of developers converges and compromises to reach an agreed-upon standard, it is arrogance to continue to stake it out by oneself, however old said existing project might be. 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.
toast0 3y ago
> Screw your conventions, we've always done it this way 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. [1] https://www.merriam-webster.com/dictionary/convention https://www.merriam-webster.com/dictionary/convention
- mschuster91 3y ago
  > 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.
  - vorpalhex 3y ago
    If you force me to migrate, I'm probably ditching your software. The inability to keep a stable user contract is a deep flaw that impacts too much software these days. Respect the user.
    - devnullbrain 3y ago
      Multiple options for configuration files is a well-trod, easy solution. You shouldn't have to migrate.
      - INGSOCIALITE 3y ago
        Everyone should do what emacs does (and a lot of software does): first look for .emacs for a config … not there? Check .emacs.d … still not there? .config/emacs …
stonogo 3y ago
Before this, when I wanted to remove a program's detritus from my disk, I did rm -rf $HOME/.program 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?
- delta_p_delta_x 3y ago
  > At no point in this article is a technical justification made... > 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?
  - rascul 3y ago
    > 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. 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.
    - comex 3y ago
      As another user, I do care, and I dislike the XDG directories. ~/.local/share/foo in particular is obnoxiously longer than ~/.foo, and the existence of the XDG spec means that if I don’t know where a program stores its files, I now have to check three possible locations (~/.foo, ~/.config/foo, ~/.local/share/foo).
egypturnash 3y ago
Apple tries to fight this by providing ~/Library as a place for applications to put whatever support files they need, but there is still a shit-ton of garbage dumped in ~/Documents by various applications. The fact that ~/Library is hidden by default probably doesn't help make it an attractive place to put all the junk your app generates. Personally I have largely abandoned ~/Documents and keep all my work in a sub-directory of it that's under my control.
- bobbylarrybobby 3y ago
  Wouldn't it being hidden make it much more attractive? You can put junk it in and users won't complain, and if they do want it you have a help article on your site.
  - mulmen 3y ago
    It being hidden means the devs might not even know about it. And that support article has to survive the biannual website redesign.
  - badsectoracula 3y ago
    I remember asking a games porter (from Windows to Mac) once why they put savefiles in the Documents folder instead of Library (some older games of theirs did put them there) they replied that because after Mac OS X changed the Library folder to be invisible they had people contacting support being unable to find the savefiles, so they put it in a place where it was visible. I'd expect the "less attractive" part is for when you do want users to find the data your program creates in general.
    - winternewt 3y ago
      That's an interesting use case. I guess there's a class of users who are smart enough to want to manually copy/backup files but not smart enough to know about hidden folders or standard directories. Windows has a similar situation with its hidden AppData directory, and Unix with its hidden dotfiles. 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.
devnullbrain 3y ago
The multiple references to Microsoft being unable to follow their own design are shocking. If even the developers dogfooding can't find these conventions, how can they expect the peanut gallery to manage?
- prmoustache 3y ago
  Additionnally, Microsoft stuff on linux only partially follow XDG guidelines. 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.
  - dikei 3y ago
    Those `Default/Service Worker/CacheStorage/` directory are inherited from Chromium, it's the same for every Chromium code base.
- yencabulator 3y ago
  I refer you to the organization diagrams in section 4.2.1. https://gist.github.com/sharadhr/39b804236c1941e9c30d90af828ad41e#421the-microsoft-irony https://gist.github.com/sharadhr/39b804236c1941e9c30d90af828...
jauntywundrkind 3y ago
Part of me thinks the solution to some of these trenchant apps is to make a FUSE pass through filesystem driver that has silent redirects. Don't report .vim or .ssh in directory entry lists. But if someone goes to open the path, silently redirect them to .config/ssh or whatnot. 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.
- RunningDroid 3y ago
  > Part of me thinks the solution to some of these trenchant apps is to make a FUSE pass through filesystem driver that has silent redirects. LD-preload-open* can be used for this, but it has some potential problems: https://github.com/fritzw/ld-preload-open/tree/master#potential-problems https://github.com/fritzw/ld-preload-open/tree/master#potent... *: https://github.com/fritzw/ld-preload-open https://github.com/fritzw/ld-preload-open
  - jauntywundrkind 3y ago
    Huge shout out to the list of issues ld-preload-open documents. Really great to have gathered such a laundry list of topics, really expands the technical knowledge of the audience by showing off a lot of interesting interaction points between app & os. 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.
rcoveson 3y ago
Why all the moralizing? Deciding when to make breaking changes is hard. Deciding it's more trouble than its worth for the developers and the users usually shouldn't be ascribed to one of "ignorance, arrogance, or fear". It's just an engineering disagreement. 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.
- delta_p_delta_x 3y ago
  No moralising here. I'm directly calling out developers who are completely okay with writing thousands of lines of code from scratch for a fancy new feature, but can't be bothered to directly lift proper directory handling code from other open-source projects and reuse it almost verbatim. 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.
  - rcoveson 3y ago
    How is lampooning people who disagree with you as "arrogant" not moralizing? Arrogance is a moral accusation. 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.
slater 3y ago
> the macOS windowing system sucks well that's certainly an opinion.
- pxc 3y ago
  And not a very controversial one among this crowd. 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).
mkenyon 3y ago
Staff dev on 1Password’s developer tools here. We screwed this up in our first few releases of the 1Password CLI, largely out of ignorance. Those releases stored config in $HOME/.op at first. But early feedback pointed us to XDG, so we migrated. Now we check: 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.)
- halostatue 3y ago
  And yet you impose XDG (originally a GNOME specification) on macOS (completely unrelated to GNOME or Linux). On macOS, you should be looking in ~/Library/Application\ Support/op and ~/Library/Preferences/op/config. 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?).
  - JoBrad 3y ago
    Sounds like they have a single place to fix it, though, which is nice.
    - halostatue 3y ago
      Yes. I think that the plugins should probably not be in $XDG_CONFIG_HOME, but in $XDG_DATA_HOME, if I’m reading correctly. 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.
      - 3y ago
chungy 3y ago
The XDG config/data spec was made to manage systems that mount over NFS; ~/.local would stay on the local workstation, ~/.cache matters so little it could be on tmpfs, and ~/.config is the permanent romaing storage (and being config, could be on a slower server than the rest of $HOME). Quite a lot of programs don't ever care for these distinctions. "All in ~/.config" or "all in ~/.local/share" are both common and both wrong (programs that do this usually ignore that ~/.cache exists). Sometimes they're split over seemingly arbitrary and nonsensical reasons, and are inter-dependent enough that you have to really double check all three locations if you want to clear or modify a program's config outside of the program itself. 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.)
- thayne 3y ago
  I find the split into three directories useful for different reasons. I keep .config in a VCS. I include .local/share in periodic backups. And I don't backup .cache at all. Programs that put everything in .config or .local/share mess that up.
- exceptione 3y ago
  $HOME is for my documents, don´t pollute it with 30+ .$program folders please. Can we as users have just at least one sanctuary place for our own docs that will not be messed with by stupid programs? 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.
  - chungy 3y ago
    I think it only appears "polluted" if you keep listing with "ls -A" all the time. If you don't list hidden files, you don't have a real problem. Besides, if you think that's polluted, then pushing it off to ~/.config and ~/.local/share is just sweeping it under the rug.
K7PJP 3y ago
> (I haven't used a Mac in ages, but I assume the situation is very similar there, too). 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.
zzo38computer 3y ago
I don't use the XDG directories (I deleted most of them, and I created many of my own directories). However, sometimes I do override HOME for some programs in some circumstances; for example, I have made up a separate home directory for configuration files for pinball games so that I can use separate configuration for pinball games in the Game Boy (and Game Boy Advance) emulator. This would also be possible with other programs, even if they do use XDG. 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).
pxc 3y ago
This is great! Also super helpful to me as someone with way more experience in one OS than the others. I will definitely be referring to this in the future.
BiteCode_dev 3y ago
I'm guessing every language has a module to abstract that. E.G: for python, the current go-to pypi module for this is platformdirs (https://pypi.org/project/platformdirs https://pypi.org/project/platformdirs) It's probably easier to promote the use of the module than explain the standard.
- thayne 3y ago
  Many of the programs complained about are written in C. I'm sure that there are libraries for c that abstract this, but there isn't one that is common enough that most c programs can depend on it.
- dwrodri 3y ago
  Would love to see examples for Rust, Go, NodeJS, C# and Java so that I can add them to my GitHub stars. I could find a few results for XDG support in Go, Rust, and NodeJS, but none of the aforementioned languages supported standards across all of macOS/Windows/Linux. Hopefully it's just my Google-fu failing me and people can correct me in the comments? 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.
  - JoshTriplett 3y ago
    For Rust, use the "directories" crate: https://crates.io/crates/directories https://crates.io/crates/directories That will respect platform conventions on Windows, macOS, and Linux/UNIX.
  - spixy 3y ago
    C#: https://chat.openai.com/share/f28ea616-1f7d-4108-9967-27eadfbe089d https://chat.openai.com/share/f28ea616-1f7d-4108-9967-27eadf...
alexhornby 3y ago
https://crates.io/crates/directories https://crates.io/crates/directories is a good crate for handling cross platform config locations for rust based tools
denysvitali 3y ago
If you use Go: https://github.com/adrg/xdg https://github.com/adrg/xdg
Aeolun 3y ago
I think this whole rant is the ‘arrogant’ they’re talking about. I think a lot of authors have a perfectly good point when they say they don’t need the complexity, or want to stick to many decades long conventions.
- jasonmp85 3y ago
  [dead]
- pbhjpbhj 3y ago
  There complexity of storing config files in a user's config directory?
  - larschdk 3y ago
    There is complexity in making the change and diverging on different platforms. ~/.myapprc was there first and it was XDG that came along and wanted everything to change.
  - tsimionescu 3y ago
    The user's config directory, on Unix, has long been $HOME.
    - kortex 3y ago
      This is just appeal to tradition. 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.
      - tsimionescu 3y ago
        My point was that apps that put dot files in $HOME are following a convention. You can argue that XDG is better or that it's worse, but you can't accuse the app developers of ignoring conventions in general. It's not like OpenSSH creates its own dirs in / or something.
zlg_codes 3y ago
The problem with XDG is three-fold: 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)
- orra 3y ago
  > 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? 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.
cassepipe 3y ago
Makes me remember of the late Gobolinux. Sad it never catched on : https://gobolinux.org/ https://gobolinux.org/
- zlg_codes 3y ago
  What's late about it? It's out of date maybe, but as far as I can tell it's still alive. Did I miss an announcement? 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!
  - arghwhat 3y ago
    Yeah, using a kernel module to pretend you have a certain file structure gives off a bad smell... Playing with alternative structures is fine though.
    - zlg_codes 3y ago
      Fair enough, it's a mess mostly due to old conventions, the LSB, etc. I would be more satisfied with a kernel or init system or whatever that can configure where libraries are, temp data, cache, local software, system software, global configuration, etc. Then the primary difference in pathways for Gobo vs, say, Debian would be what paths they configured for Linux's main types of OS data. It would make playing with alternative hierarchies kinda fun.
    - lproven 3y ago
      Does it, though? 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 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.
prmoustache 3y ago
ATMO the XDG standard is broken by design, and has been designed by drunk people who wanted to emulate the bad behaviors of windows users. 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>
red_admiral 3y ago
My own solution on windows is to make a separate folder such as c:\users\redadmiral\Documents\files and have my documents live in there. Then I make my own start menu / taskbar shortcuts that point to that (I have Win+E set to open "My Computer", as I use USB drives a lot, and have pinned the folder there too). 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.
- Kiuhrly1 3y ago
  I've had "Documents/actual documents" for years.
blueflow 3y ago
By the way, XDG_RUNTIME_DIR is a thing from pam_systemd(8), so this XDG vs dotfiles is somewhat the systemd debate in disguise. The person who wrote pam_systemd(8) als co-authored the XDG basedir spec.
- kortex 3y ago
  Not really at all. Anything can use the XDG spec, it has absolutely no coupling to systemd. Really it's about apps chosing between - 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
  - deleted 3y ago
    [deleted]
  - deleted 3y ago
    [deleted]
mid-kid 3y ago
I keep a small series of patches for various software on my system, to fix, or at least relocate, config files to XDG locations[1]. I do this for applications I care about keeping their state. For other applications I either set the environment variables or remove the dirs on login[2]. Of course, the complexity of the project and my familiarity with the language also affects whether I bother with it. Not gonna be able to change ~/.cargo or ~/.dotnet soon (unless someone has patches for those?) 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%20xdg-basedir&type=code https://github.com/search?q=repo%3Amid-kid%2Fgentoo-config%2... [2]: https://github.com/mid-kid/config/blob/master/shell/.zprofile#L9 https://github.com/mid-kid/config/blob/master/shell/.zprofil...
- junkblocker 3y ago
  Regarding ~/.cargo (and other tools), I've had some success with following suggestions from https://github.com/b3nj5m1n/xdg-ninja https://github.com/b3nj5m1n/xdg-ninja
aszlig 3y ago
For games, I think it's even worse on GNU/Linux systems, since most game developers mainly target Windows and sometimes completely ignore conventions for other platforms (possibly since some game engines have that "Build for Linux" button). 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/4690494feee20a62c4f0c67a5f7f175fdc6ad332/pkgs/games/gog/factorio/patch.py 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/4690494feee20a62c4f0c67a5f7f175fdc6ad332/pkgs/games/gog/war-for-the-overworld.nix#L16-L84 https://github.com/openlab-aux/vuizvui/blob/4690494feee20a62... [1]: https://docs.unity3d.com/ScriptReference/Application-persistentDataPath.html https://docs.unity3d.com/ScriptReference/Application-persist... [2]: https://docs.unity3d.com/ScriptReference/Application-dataPath.html https://docs.unity3d.com/ScriptReference/Application-dataPat...
skywhopper 3y ago
While I strongly support the idea of allowing users to control the location of their config files, I don’t really like the XDG spec, specifically the part where setting nothing ends up putting files in two or three disparate directories. 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.
Anon_Forever 3y ago
XDG is a systemd standard that's not universally used across Linux distributions. It's most definitely not used in other UNIXy systems like FreeBSD and MacOS. XDG, like systemd, likes to believe it's universal but it's not.
- enriquto 3y ago
  > XDG, like systemd, likes to believe it's universal but it's not. 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.
- bitwize 3y ago
  XDG is a freedesktop standard that's been adopted by systemd, Wayland, and other important projects. It's absolutely no skin off your nose to adopt it, and beneficial to you and your users if you do.
  - deleted 3y ago
    [deleted]
  - Anon_Forever 3y ago
    >XDG is a freedesktop standard that's been adopted by systemd 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.
- brnt 3y ago
  Practically universal. Even if there's a Linux distro going out of it's way not to set them, many tools, including big ones, support it anyway (also on non-Linux Unices). In practice I've never encountered users with a distro that didn't have these variables set.
  - 3y ago
JeremyNT 3y ago
One "solution" to this problem in Linux is to use something like bwrap[0] and manually redirect offending software to the desired location with the "bind" option. 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. [0] https://wiki.archlinux.org/title/Bubblewrap https://wiki.archlinux.org/title/Bubblewrap
ablyveiled 3y ago
Seeing as I cannot control all the software I have on my computers, I just gave up. Everything in $HOME that I care about is in ~/my. $HOME itself is anarchic, and that's okay with me. I have better things to do than micromanage this.
butz 3y ago
Most infuriating when you run VS Code in "portable" mode and it creates at least 3 directories in $HOME. Sadly, the only solution is to use Flatpak and prevent application access to $HOME, by redirecting to alternate locations.

deleted 3y ago

[deleted]

maxique 3y ago

Archive link: https://archive.ph/pKW90 https://archive.ph/pKW90

deleted 3y ago
[deleted]

neverrroot 3y ago

Make that $HOME

JadeNB 3y ago
It's correct in the linked article; probably the title mangler got to it.

zh3 3y ago

I gave up on this fight some time ago; very interested to hear of better solutions than simply keeping a personal home elsewhere.

gorgoiler 3y ago
Pretty much everything I do on a daily basis is in ~/something, immediately in my home directory. It used to be ~/Projects/something but even that felt too organized. 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.
- buildbot 3y ago
  Can confirm, as a digital hoarder with a medium size PC case with 8 16-20TB drives...No need for turning on the heat in the winter. Summer is a bit of an issue though!
  - justsomehnguy 3y ago
    Just place a bucket of cold water at the exhaust, free humidifier!
- zlg_codes 3y ago
  Aha, I repurposed the XDG download directory to point to ~/scratch/, since most of those files are downloaded in my browser. Now I dump everything into that directory that hasn't been sorted into my hierarchy system (which is divided into ownership or source, then type or relevancy). 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 https://imgur.com/a/QVehjvy I love reading about people's directory or symlink structures.
- zh3 3y ago
  That's close-ish to what I do, which is to have symlinks for frequently used directories in my home directory. And as most of those directories are actually on an NFS server, setting up a new PC is just mount the server, create the symlinks and then "cd someproject" or "cd ~/someproject' as usual (well, as long as you make sure you use the same UID/GID anyway).
- gdprrrr 3y ago
  I have $HOME/tmp, for "temp but not tempfs"

psanford 3y ago

Yes, if you are writing new software please respect $XDG. But its a bit ridiculous to think that bash should respect some convention developed ~20 years after bash was released.

LukeShu 3y ago
I mean, Emacs respects the convention, developed ~40 years after Emacs was first released.
- psanford 3y ago
  I'm not saying the developers couldn't support it. I'm saying you are not entitled to name call them if they choose to not support it.
- lilyball 3y ago
  There are countless tools that write to the bash files though, which is not true for most programs. Bash changing its locations would break all of these. 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.
  - devnullbrain 3y ago
    >There are countless tools that write to the bash files though 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.
    - arp242 3y ago
      Whether it is or isn't terrible is sort of besides the point; the fact is that it exists, and that stuff would break.

tedunangst 3y ago

How is it not arrogant to say to an existing project "I hereby demand you move your config files to .config"?

mschuster91 3y ago
not adhering to a (reasonably well defined and accepted) standard kind of is a bug to me.
- tedunangst 3y ago
  Resolved: the standard is for dot files to go in $HOME.
- prmoustache 3y ago
  It is not reasonably well defined, it is even broken by design, and if it was so accepted we wouldn't have this conversation.
- blueflow 3y ago
  Look up how XDG_RUNTIME_DIR gets set. Its a pam_systemd(8) thing and thus specific to GNU/Linux. So if you approach the non-glibc or *BSD folks with "please follow the XDG spec", you will likely not receive a nice answer.
delta_p_delta_x 3y ago
When the large majority of developers converges and compromises to reach an agreed-upon standard, it is arrogance to continue to stake it out by oneself, however old said existing project might be. 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.
- toast0 3y ago
  > When the large majority of developers converges and compromises to reach an agreed-upon standard, it is arrogance to continue to stake it out by oneself, however old said existing project might be. 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.

toast0 3y ago

> Screw your conventions, we've always done it this way 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. [1] https://www.merriam-webster.com/dictionary/convention https://www.merriam-webster.com/dictionary/convention

mschuster91 3y ago
> 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.
- vorpalhex 3y ago
  If you force me to migrate, I'm probably ditching your software. The inability to keep a stable user contract is a deep flaw that impacts too much software these days. Respect the user.
  - devnullbrain 3y ago
    Multiple options for configuration files is a well-trod, easy solution. You shouldn't have to migrate.
    - INGSOCIALITE 3y ago
      Everyone should do what emacs does (and a lot of software does): first look for .emacs for a config … not there? Check .emacs.d … still not there? .config/emacs …

stonogo 3y ago

Before this, when I wanted to remove a program's detritus from my disk, I did rm -rf $HOME/.program 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?

delta_p_delta_x 3y ago
> At no point in this article is a technical justification made... > 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?
- rascul 3y ago
  > 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. 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.
  - comex 3y ago
    As another user, I do care, and I dislike the XDG directories. ~/.local/share/foo in particular is obnoxiously longer than ~/.foo, and the existence of the XDG spec means that if I don’t know where a program stores its files, I now have to check three possible locations (~/.foo, ~/.config/foo, ~/.local/share/foo).

egypturnash 3y ago

Apple tries to fight this by providing ~/Library as a place for applications to put whatever support files they need, but there is still a shit-ton of garbage dumped in ~/Documents by various applications. The fact that ~/Library is hidden by default probably doesn't help make it an attractive place to put all the junk your app generates. Personally I have largely abandoned ~/Documents and keep all my work in a sub-directory of it that's under my control.

bobbylarrybobby 3y ago
Wouldn't it being hidden make it much more attractive? You can put junk it in and users won't complain, and if they do want it you have a help article on your site.
- mulmen 3y ago
  It being hidden means the devs might not even know about it. And that support article has to survive the biannual website redesign.
- badsectoracula 3y ago
  I remember asking a games porter (from Windows to Mac) once why they put savefiles in the Documents folder instead of Library (some older games of theirs did put them there) they replied that because after Mac OS X changed the Library folder to be invisible they had people contacting support being unable to find the savefiles, so they put it in a place where it was visible. I'd expect the "less attractive" part is for when you do want users to find the data your program creates in general.
  - winternewt 3y ago
    That's an interesting use case. I guess there's a class of users who are smart enough to want to manually copy/backup files but not smart enough to know about hidden folders or standard directories. Windows has a similar situation with its hidden AppData directory, and Unix with its hidden dotfiles. 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.

devnullbrain 3y ago

The multiple references to Microsoft being unable to follow their own design are shocking. If even the developers dogfooding can't find these conventions, how can they expect the peanut gallery to manage?

prmoustache 3y ago
Additionnally, Microsoft stuff on linux only partially follow XDG guidelines. 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.
- dikei 3y ago
  Those `Default/Service Worker/CacheStorage/` directory are inherited from Chromium, it's the same for every Chromium code base.
yencabulator 3y ago
I refer you to the organization diagrams in section 4.2.1. https://gist.github.com/sharadhr/39b804236c1941e9c30d90af828ad41e#421the-microsoft-irony https://gist.github.com/sharadhr/39b804236c1941e9c30d90af828...

jauntywundrkind 3y ago

Part of me thinks the solution to some of these trenchant apps is to make a FUSE pass through filesystem driver that has silent redirects. Don't report .vim or .ssh in directory entry lists. But if someone goes to open the path, silently redirect them to .config/ssh or whatnot. 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.

RunningDroid 3y ago
> Part of me thinks the solution to some of these trenchant apps is to make a FUSE pass through filesystem driver that has silent redirects. LD-preload-open* can be used for this, but it has some potential problems: https://github.com/fritzw/ld-preload-open/tree/master#potential-problems https://github.com/fritzw/ld-preload-open/tree/master#potent... *: https://github.com/fritzw/ld-preload-open https://github.com/fritzw/ld-preload-open
- jauntywundrkind 3y ago
  Huge shout out to the list of issues ld-preload-open documents. Really great to have gathered such a laundry list of topics, really expands the technical knowledge of the audience by showing off a lot of interesting interaction points between app & os. 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.

rcoveson 3y ago

Why all the moralizing? Deciding when to make breaking changes is hard. Deciding it's more trouble than its worth for the developers and the users usually shouldn't be ascribed to one of "ignorance, arrogance, or fear". It's just an engineering disagreement. 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.

delta_p_delta_x 3y ago
No moralising here. I'm directly calling out developers who are completely okay with writing thousands of lines of code from scratch for a fancy new feature, but can't be bothered to directly lift proper directory handling code from other open-source projects and reuse it almost verbatim. 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.
- rcoveson 3y ago
  How is lampooning people who disagree with you as "arrogant" not moralizing? Arrogance is a moral accusation. 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.

slater 3y ago

> the macOS windowing system sucks well that's certainly an opinion.

pxc 3y ago
And not a very controversial one among this crowd. 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).

mkenyon 3y ago

Staff dev on 1Password’s developer tools here. We screwed this up in our first few releases of the 1Password CLI, largely out of ignorance. Those releases stored config in $HOME/.op at first. But early feedback pointed us to XDG, so we migrated. Now we check: 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.)

halostatue 3y ago
And yet you impose XDG (originally a GNOME specification) on macOS (completely unrelated to GNOME or Linux). On macOS, you should be looking in ~/Library/Application\ Support/op and ~/Library/Preferences/op/config. 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?).
- JoBrad 3y ago
  Sounds like they have a single place to fix it, though, which is nice.
  - halostatue 3y ago
    Yes. I think that the plugins should probably not be in $XDG_CONFIG_HOME, but in $XDG_DATA_HOME, if I’m reading correctly. 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.
    - 3y ago

chungy 3y ago

The XDG config/data spec was made to manage systems that mount over NFS; ~/.local would stay on the local workstation, ~/.cache matters so little it could be on tmpfs, and ~/.config is the permanent romaing storage (and being config, could be on a slower server than the rest of $HOME). Quite a lot of programs don't ever care for these distinctions. "All in ~/.config" or "all in ~/.local/share" are both common and both wrong (programs that do this usually ignore that ~/.cache exists). Sometimes they're split over seemingly arbitrary and nonsensical reasons, and are inter-dependent enough that you have to really double check all three locations if you want to clear or modify a program's config outside of the program itself. 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.)

thayne 3y ago
I find the split into three directories useful for different reasons. I keep .config in a VCS. I include .local/share in periodic backups. And I don't backup .cache at all. Programs that put everything in .config or .local/share mess that up.
exceptione 3y ago
$HOME is for my documents, don´t pollute it with 30+ .$program folders please. Can we as users have just at least one sanctuary place for our own docs that will not be messed with by stupid programs? 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.
- chungy 3y ago
  I think it only appears "polluted" if you keep listing with "ls -A" all the time. If you don't list hidden files, you don't have a real problem. Besides, if you think that's polluted, then pushing it off to ~/.config and ~/.local/share is just sweeping it under the rug.

K7PJP 3y ago

> (I haven't used a Mac in ages, but I assume the situation is very similar there, too). 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.

zzo38computer 3y ago

I don't use the XDG directories (I deleted most of them, and I created many of my own directories). However, sometimes I do override HOME for some programs in some circumstances; for example, I have made up a separate home directory for configuration files for pinball games so that I can use separate configuration for pinball games in the Game Boy (and Game Boy Advance) emulator. This would also be possible with other programs, even if they do use XDG. 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).

pxc 3y ago

This is great! Also super helpful to me as someone with way more experience in one OS than the others. I will definitely be referring to this in the future.

BiteCode_dev 3y ago

I'm guessing every language has a module to abstract that. E.G: for python, the current go-to pypi module for this is platformdirs (https://pypi.org/project/platformdirs https://pypi.org/project/platformdirs) It's probably easier to promote the use of the module than explain the standard.

thayne 3y ago
Many of the programs complained about are written in C. I'm sure that there are libraries for c that abstract this, but there isn't one that is common enough that most c programs can depend on it.
dwrodri 3y ago
Would love to see examples for Rust, Go, NodeJS, C# and Java so that I can add them to my GitHub stars. I could find a few results for XDG support in Go, Rust, and NodeJS, but none of the aforementioned languages supported standards across all of macOS/Windows/Linux. Hopefully it's just my Google-fu failing me and people can correct me in the comments? 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.
- JoshTriplett 3y ago
  For Rust, use the "directories" crate: https://crates.io/crates/directories https://crates.io/crates/directories That will respect platform conventions on Windows, macOS, and Linux/UNIX.
- spixy 3y ago
  C#: https://chat.openai.com/share/f28ea616-1f7d-4108-9967-27eadfbe089d https://chat.openai.com/share/f28ea616-1f7d-4108-9967-27eadf...

alexhornby 3y ago

https://crates.io/crates/directories https://crates.io/crates/directories is a good crate for handling cross platform config locations for rust based tools

denysvitali 3y ago

If you use Go: https://github.com/adrg/xdg https://github.com/adrg/xdg

Aeolun 3y ago

I think this whole rant is the ‘arrogant’ they’re talking about. I think a lot of authors have a perfectly good point when they say they don’t need the complexity, or want to stick to many decades long conventions.

jasonmp85 3y ago
[dead]
pbhjpbhj 3y ago
There complexity of storing config files in a user's config directory?
- larschdk 3y ago
  There is complexity in making the change and diverging on different platforms. ~/.myapprc was there first and it was XDG that came along and wanted everything to change.
- tsimionescu 3y ago
  The user's config directory, on Unix, has long been $HOME.
  - kortex 3y ago
    This is just appeal to tradition. 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.
    - tsimionescu 3y ago
      My point was that apps that put dot files in $HOME are following a convention. You can argue that XDG is better or that it's worse, but you can't accuse the app developers of ignoring conventions in general. It's not like OpenSSH creates its own dirs in / or something.

zlg_codes 3y ago

The problem with XDG is three-fold: 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)

orra 3y ago
> 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? 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.

cassepipe 3y ago

Makes me remember of the late Gobolinux. Sad it never catched on : https://gobolinux.org/ https://gobolinux.org/

zlg_codes 3y ago
What's late about it? It's out of date maybe, but as far as I can tell it's still alive. Did I miss an announcement? 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!
- arghwhat 3y ago
  Yeah, using a kernel module to pretend you have a certain file structure gives off a bad smell... Playing with alternative structures is fine though.
  - zlg_codes 3y ago
    Fair enough, it's a mess mostly due to old conventions, the LSB, etc. I would be more satisfied with a kernel or init system or whatever that can configure where libraries are, temp data, cache, local software, system software, global configuration, etc. Then the primary difference in pathways for Gobo vs, say, Debian would be what paths they configured for Linux's main types of OS data. It would make playing with alternative hierarchies kinda fun.
  - lproven 3y ago
    Does it, though? 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 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.

prmoustache 3y ago

ATMO the XDG standard is broken by design, and has been designed by drunk people who wanted to emulate the bad behaviors of windows users. 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>

red_admiral 3y ago

My own solution on windows is to make a separate folder such as c:\users\redadmiral\Documents\files and have my documents live in there. Then I make my own start menu / taskbar shortcuts that point to that (I have Win+E set to open "My Computer", as I use USB drives a lot, and have pinned the folder there too). 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.

Kiuhrly1 3y ago
I've had "Documents/actual documents" for years.

blueflow 3y ago

By the way, XDG_RUNTIME_DIR is a thing from pam_systemd(8), so this XDG vs dotfiles is somewhat the systemd debate in disguise. The person who wrote pam_systemd(8) als co-authored the XDG basedir spec.

kortex 3y ago
Not really at all. Anything can use the XDG spec, it has absolutely no coupling to systemd. Really it's about apps chosing between - 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
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]

mid-kid 3y ago

I keep a small series of patches for various software on my system, to fix, or at least relocate, config files to XDG locations[1]. I do this for applications I care about keeping their state. For other applications I either set the environment variables or remove the dirs on login[2]. Of course, the complexity of the project and my familiarity with the language also affects whether I bother with it. Not gonna be able to change ~/.cargo or ~/.dotnet soon (unless someone has patches for those?) 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%20xdg-basedir&type=code https://github.com/search?q=repo%3Amid-kid%2Fgentoo-config%2... [2]: https://github.com/mid-kid/config/blob/master/shell/.zprofile#L9 https://github.com/mid-kid/config/blob/master/shell/.zprofil...

junkblocker 3y ago
Regarding ~/.cargo (and other tools), I've had some success with following suggestions from https://github.com/b3nj5m1n/xdg-ninja https://github.com/b3nj5m1n/xdg-ninja

aszlig 3y ago

For games, I think it's even worse on GNU/Linux systems, since most game developers mainly target Windows and sometimes completely ignore conventions for other platforms (possibly since some game engines have that "Build for Linux" button). 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/4690494feee20a62c4f0c67a5f7f175fdc6ad332/pkgs/games/gog/factorio/patch.py 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/4690494feee20a62c4f0c67a5f7f175fdc6ad332/pkgs/games/gog/war-for-the-overworld.nix#L16-L84 https://github.com/openlab-aux/vuizvui/blob/4690494feee20a62... [1]: https://docs.unity3d.com/ScriptReference/Application-persistentDataPath.html https://docs.unity3d.com/ScriptReference/Application-persist... [2]: https://docs.unity3d.com/ScriptReference/Application-dataPath.html https://docs.unity3d.com/ScriptReference/Application-dataPat...

skywhopper 3y ago

While I strongly support the idea of allowing users to control the location of their config files, I don’t really like the XDG spec, specifically the part where setting nothing ends up putting files in two or three disparate directories. 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.

Anon_Forever 3y ago

XDG is a systemd standard that's not universally used across Linux distributions. It's most definitely not used in other UNIXy systems like FreeBSD and MacOS. XDG, like systemd, likes to believe it's universal but it's not.

enriquto 3y ago
> XDG, like systemd, likes to believe it's universal but it's not. 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.
bitwize 3y ago
XDG is a freedesktop standard that's been adopted by systemd, Wayland, and other important projects. It's absolutely no skin off your nose to adopt it, and beneficial to you and your users if you do.
- deleted 3y ago
  [deleted]
- Anon_Forever 3y ago
  >XDG is a freedesktop standard that's been adopted by systemd 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.
brnt 3y ago
Practically universal. Even if there's a Linux distro going out of it's way not to set them, many tools, including big ones, support it anyway (also on non-Linux Unices). In practice I've never encountered users with a distro that didn't have these variables set.
- 3y ago

JeremyNT 3y ago

One "solution" to this problem in Linux is to use something like bwrap[0] and manually redirect offending software to the desired location with the "bind" option. 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. [0] https://wiki.archlinux.org/title/Bubblewrap https://wiki.archlinux.org/title/Bubblewrap

ablyveiled 3y ago

Seeing as I cannot control all the software I have on my computers, I just gave up. Everything in $HOME that I care about is in ~/my. $HOME itself is anarchic, and that's okay with me. I have better things to do than micromanage this.

butz 3y ago

Most infuriating when you run VS Code in "portable" mode and it creates at least 3 directories in $HOME. Sadly, the only solution is to use Flatpak and prevent application access to $HOME, by redirecting to alternate locations.