XDG gang, rise up!
Also, I know that this community and dot-files in general are Unix based, but this holds true for Windows development as well. You should be putting app files in the users’ APPDATA directory, not their user folder. It’s probably even more important since Windows doesn’t autohide dot files.
The My Documents / Documents folder on Windows is a dumping ground for game saves and random applications. I no longer use it for saving my documents anymore…
I don’t touch it either for two reasons that go together.
- It’s a pig sty before I even get there.
- Nothing in there will ever be included in backups for that reason.
My cloud drive has SO much random flstudio crap in it. That’s the worst program in the world when it comes to that. If you install their program they think they own your hard drive.
Also while I’m bitching about windows folders, why did they make it so weird to get to your home folder? It feels like we aren’t supposed to know it exists anymore.
To be honest, pretty much all my files that actually matter are under my Dropbox folder. Everything else is ephemeral. I mostly depend on Steam or the likes to backup game saves. Not much else I care about. I’ve upgraded my PC a few times (with no full backups) and never missed a single thing that got lost in the upgrade.
One of my proudest accomplishments is contributing to the XDG Base Dir spec. I fixed a typo.
I just write my config files directly to random unused blocks on /dev/sda, filesystems are overrated.
You still have devices?
I’m over here chilling with my a
- Rental flat, where I can’t make any modifications or else I’ll be evicted.
- Free TV that serves me ads, on the condition I don’t tamper with it.
- Leased car with a heated seat subscription.
- Vendor-locked iPhone that came with my mobile plan.
- Netflix subscription that still shows me ads.
I’d say the only thing I own is the clothes on my back, but those were repossessed yesterday for nonpayment.
/s
I just leave all config in memory. If the user really cared, they would never reboot.
I just hard code all config in the source code. If the user really cared, they would recompile from source.
I deliberately run / and /home as tmpfs. Then everything I want to persist across boots gets symlinked in at system start, and anything I didn’t opt in to saving gets deleted every boot.
I absolutely despise the following directories: Documents, Music, Pictures, Public, Templates, Videos. Why? Because applications randomly dump stuff into these directories and fill them with junk files. I don’t want any application putting anything into directories I actually use, unless I explicitly tell them to. It is not possible to keep your files organized if applications randomly dump trash files into them.
Same shit happens on Windows. Games will just install their shit literally all over OS with no rhyme or reason to it.
Why can’t the save game and config.ini just be in the main god damn game directory? Nobody knows.
Actual reason is system permissions.
Most the default installation path is Program Files. That needs elevation to write to. Fine when you’re installing something, but not something you want to need just to run the game.
Writing to %APPDATA% or really anywhere in %USERHOME% is guaranteed to have the right permissions for this user.
Granted, a lot of home PCs and gaming PCs are single-user environments. The “personal” computer. In that case there’s no reason games and applications can’t be installed in %LOCALAPPADATA%, and in fact, I think windows has an environment variable or registry setting for that.
It’s no different in Linux. You don’t want users writing to /etc. And you may expect multiple users. So all of that stuff goes to dot files in $HOME.
Granted, a lot of home PCs and gaming PCs are single-user environments. The “personal” computer. In that case there’s no reason games and applications can’t be installed in %LOCALAPPADATA%, and in fact, I think windows has an environment variable or registry setting for that.
I tried setting up my main windows gaming machine with a separate admin and user accounts, and tried to set it up to be multi-user. It didn’t work well. Most games worked but some random games had all sorts of bizarre issues, from only being able to run as admin, to requiring messing with directory permissions to just plain strange behavior but working sometimes. Steam also really didn’t like if I tried to run games as a different user and got very confused at times by the multiple user accounts
Microsoft OWNS not just gaming companies, but one of the largest gaming hardware companies and many of the largest game developers.
You’d think by now we’d get a dedicated Saves folder to organize this shit after this long.
C:\Users\Username\Saved Games is a thing. Not a lot of games use it though.
There’s also C:\Users\Username\Documents\My Games which seems more popular with some devs. Though some devs inexplicably use the base Documents folder, which is just obnoxious.
But yeah, a lot of devs still use AppData. I read a post from a dev once that explained the advantages and disadvantages to each Directory, though I can’t remember the specifics, there is at least logic to why saves get stored in so many odd locations.
I have my own directories on windows. I never use system provided directories for my own stuff, it always sucks. And if I want to move directories between drives or just change permissions, all hell breaks loose because everything depends on the default locations… So I just leave them be if I can.
Y’know what’s worse? When there’s no dot. Worse than that, it’s an undotted directory used to store a single config file. Ugh, unpleasant memories. 😒
That’s just the default location for what it’s worth. You can move GOPATH wherever you want.
If you care, please take time to upvote or file bugs on packages that don’t follow XDG. Or even better, make PRs.
Those bugs and PRs would just get closed without comment. Nobody is going to move a dotfile as a breaking change in any established software. You either get it right the first time or probably never.
The software can read from both locations in a backwards compatible way. Many tools already do this.
The best way to handle this is to have the next version move the old directory (if it exists) and then start reading from there.
That way it’s in compliance from then forward.
A UI notice is nice but will probably be ignored.
Nobody is going to move a dotfile as a breaking change in any established software
We have oodles of counterexamples to this. GIMP did it, Blender did it, DOSBox did it, Libreoffice did it, Skype did it, Wireshark did it, ad nauseum. It’s not really as big a deal as you make it to be (or a big deal at all). You have a transitional period where you look for config files in both locations, and mark the old location as obsolete.
It’s not really as big a deal as you make it to be (or a big deal at all).
It’s a big deal to developers who were inconsiderate enough to do it in the first place. To do it in a non-breaking, non-confusing way requires slightly more care than doing it correctly to begin with. Hence why your $HOME is still a giant mess.
I mean if the code is well written it shouldn’t be hard in the first place. You likely have a sinlge code var for the config path already so instead of hardcoding it to be in $HOME make it check if the file is in XDG_Config, if not check if it’s in $HOME. If the file is in neither of these it does not exist -> create a new one in XDG_Config. If it does exist in $HOME -> Move it to XDG_Config.
They will if enough people whine about it.
In the old days (I’m 50+) tumbleweed drifted through ~/ apart from my drivel and I’d have a folder for that so /home/gerdesj/docs was the root of my stuff. I also had ~/tmp/ for not important stuff. I don’t have too much imagination and ~/ was pretty clean. I was aware of dot files and there were a shit load of them but I didn’t see them unless I wanted to.
This really isn’t the most important issue ever but it would be nice if apps dumped their shit in a consistently logical way. XDG is the standard.
I know developers are busy, and I don’t mean to berate them for their choices or work. I only have a two year Computer Information Systems degree and haven’t programmed a lot for a while, but supporting the XDG specification and remaining backwards compatible doesn’t seem to be very difficult or would cause so much breakage (of course, the amount of work would depend on the software and how the hardcoded path is implemented). I look up git repository issues for the software and tend to find ubiquitous examples like vim to be resistant to such change: https://github.com/vim/vim/issues/2034
This is really frustrating and leads me to find alternative software, such as neovim/doom emacs instead of vim, nushell instead of bash, etc., just to be able to clear up my home directory. I don’t mind if I have to wait for XDG to be supported, but many important projects just label the issue as “won’t fix”. I totally understand where you are coming from.
List of software with hardcoded paths at this time: https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcoded
I’ve made about 5 MRs changing dotfile locations, and not once has it ever been declined
I don’t care.
You can add the proper location to the list of possible dirs. Fhen you can movd your dotfile
If you install config files to the new location and prefer the new config file location over the old, you risk accidental misconfiguration when a system has both config files (e.g. in a build pipeline that installs the software and then copies the config to the old location). It is not impossible to solve, but there are questions that require some care if you have a large userbase and solidified codebase. More care than it takes to do it right the first time.
A (very well used) program I use places files in $HOME. Someone argued for changing to $XDG_CONFIG or at least add that as an option. The dev, being used to the old school way, gave the exact opposite reason: that .config was just an extra level of organization when dotfiles are what the home dir is for. So I’m not sure how successful you would be with that approach.
To be clear, I am clearly on the side of XDG, myself.
XDG is a Red Hat thing.
Stuff outside of their influence is unlikely to change, like OpenSSH or ZSH.
