Dotfile madness
0x46.net
0x46.net
But nowadays, lots of applications seem to think it's OK to put normal files in my home folder without asking first. This is just outright barbarism. In particular, Ubuntu now seems like it's all-in on snaps, and if you use snaps, they create a non-hidden "snap" folder in the user's home folder. Madness! And when people complain, the devs have the gall to suggest that this is all fine:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053
I like the idea of snap/flatpak in the abstract, but until they get their act together, and stop creating non-hidden files in my home folder without asking first, I am never going to use snaps.
And of course, all this is on top of the new fashion for the OS to "helpfully" create Documents, Music, Video, etc folders in my home folder, and set the XDG environment variables to point to them. Noooooope.
But at least in that case the user can change the environment variables and delete the stupid folders. No such luck with ~/snap.
You're complaining on a really high level and nobody suggested "this is fine". They suggested "wishlist" is fine according to their definition of "if it's not immediately broken and a fix is not trivial"
If you have an issue with default folders that are quite normal in a modern desktop environment I suggest you move back to Arch or wherever you came from and install i3 again?
I'll drop "/etc/papersize" in return. If you are not familiar with this and do not print to letter paper then you will find it very, very useful.
My life at home is now worth living every time the wife hits print. Such a simple idea - brilliant.
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053...
Also, the bug was first reported in 2016, and Mark Shuttleworth himself has commented on it. And yet it's still not fixed. That gives me the impression that the devs don't consider it super-important. Which is odd to me, since I consider not doing this kind of thing to be 'table stakes' for any application that wants me to take it seriously.
> If you have an issue with default folders that are quite normal in a modern desktop environment I suggest you move back to Arch or wherever you came from and install i3 again?
Ummm, I came from Linux before they started having default Documents, Videos, etc folders. And, like I said, the nice thing is that, in Linux, I can change the XDG environment variables and delete the (IMHO) foolish Documents, Music, Videos, etc folders.
That said, for something like source code, it makes sense to go into $HOME, so I don't understand this particular complaint the other poster made.
It's weird that the Go developers were working in such isolation that they didn't pick up on this. All programming languages that I know of that work on modern tooling (Haskell, Rust, Node.JS, even C#!) adopted the Ruby style dependency management when it turned out to be correct years ago.
I can't remember the last time I had a version management problem in Ruby, though the ecosystem is so stable right now not many backwards incompatible things happen any more.
If you do deeply nested paths (as npm used to do) then you can run against the old MAX_PATH limit that limits paths to 260 characters, but the correct solution is to either choose a flatter directory structure or use the newer APIs that allow paths with 32,767 characters.
Steam should have worked to figure out a better approach to UAC years ago. At this point it is one of several big tech debt issues with Steam that has my confidence in Valve at an all time low as a consumer.
C:\Users\username\AppData\Local
Or even better to work with localization
%LOCALAPPDATA%
I also have C:\CMD for my own batch files.
Every single program should be fully contained in its own directory including all the settings,logging,configuration etc...
No touching of any common resource or repository.
It should be enough to delete single tree to fully uninstall program with all the garbage it created along the way
\Programs\VendorX\ProgramY\code
But it seems because of the idea that some people may want to back up data and config separately, we end up with stuff scattered everywhere, with some even hidden away in the Windows Registry. Makes backups ridiculously complex.
I don't know how I did this.
I have huge amounts of cache files in both .cache and .config. It's supposed to make my life easier by being able to backup .config and dump everything. but in reality this doesnt happen.
Backing up .config for just the user defined configs is a massive PITA. you have to put so many gitignore exceptions and I'm not even talking about the gigs of data all the chromium derivatives put into that folder.
Browsers tend to work fine. Some apps just fail badly like rofi (command history stored there oof)
For what it's worth I also tmpfs+asd .nvm, .npm, and */node_modules, without any major headaches. I did have to fix a couple minor pathing dramas but nothing too drastic.
Yeah but chrome devs half-assing the trivial xdg spec doesn't mean that xdg sucks - its just not implemented properly.
Here you are referring to separating the config and data? Is this actually a problem? I can see how for things like games it would be valuable to have a special location for thing like saves games, like how you can move the roaming save for minecraft from a computer to another; but I never understood the net gain from splitting the application files in config/data
It also has an option to ignore entries listed in your .gitignore.
mkdir ~/real_home
Ew.
But just dropping stuff in my home directory--look, if I'm in a hurry and my defenses are down, you basically just encouraged me to clutter things up.
The last software I found that does this is a "download helper"...even though I have a Downloads folder that my distro already set up, that Chrome and Firefox know to use, this download helper thinks I want those downloads dumped in my home folder. I hope some generous person changes this behavior, meanwhile I forgot to charge it manually for the last batch and I have a bunch of cleanup to do.
/home/user/Documents/
/home/user/Downloads/
/home/user/Pictures/
/home/user/Videos/
Let me know what I'm missing.
https://wiki.archlinux.org/index.php/XDG_user_directories
It looks like maybe the "official" documentation is here:
http://user-dirs.freedesktop.org/releases/xdg-user-dirs-0.17...
But I haven't gone through that carefully.
I strongly prefer apps default to the previously used directory, and the home directory otherwise. IME apps are wrong 99% of the time when they guess their own save location.
Much better than storing them in C:\Windows or C:\Program Files, as was the case a decade ago, before windows introduced UAC and blocked write access to these.
All this kind of stuff is what Appdata\Roaming and Appdata\Local are supposed to be for.
Users often need to back them up. Backup systems often include Documents by default but not AppData.
Files in AppData are hidden, and you would not expect users to find them.
Further, many save games can be opened with a text editor just fine :)
My witcher saves were 10GB, until I realize that problem and deleted them, no wounder backups were slow. Skyrim is not that far off.
Pretty sure backup is already integrated in steam for these two games.
In the witcher 1 there is also an uncompressed BMP thumbnail with each save that is about a megabyte. It's PNG compressed in the witcher 2. They learned from their mistake.
Chrome's cache is in AppData/Local/Google/Chrome/User Data and Firefox's cache is in AppData/Local/Mozilla/Firefox/Profiles/. The only big offender on my system is npm with a cache in AppData/Roaming/npm-cache
I don't even get what you want to say.
Finding the directory requires new APIs introduced in Vista and Server 2008. See SHGetKnownFolderPath
I just tried to use the API. I literally couldn't find a working example on the internet in 2 hours so I guess noone figured it out in a decade.
[0] https://docs.microsoft.com/en-us/windows/desktop/api/version...
I'm surprised that these new IsWindows...() functions claim compatibility down to Windows 2000. Doubt microsoft knew how they would name their next release 20 years ago. A Google search indicates that they are in fact broken.
If IsWindows... doesn't work then you can use the VerifyVersionInfo function directly.
The user folder exists for a reason. Drop your crap in there.
I just looked at my Win10 profile dir, and it has 36 dot-prefixed folders, and 7 more files on top level. Offenders include .gitconfig, .rustup, and .vscode, just to name a few.
15 year Mac user (re)exploring Windows due to bad hardware...
Nevertheless there are alternatives. One liked by many are Norton Commander alike file managers like Total Commander or even Far. I am not too much in favor of them though.
I like to use Directory Opus. It is powerful and flexible. Costs money though.
I actually tried the Snap thing too, I don't remember how it went but I would say it was bad. I think I couldn't find a way to search for packages from the CLI.
From my impression the answer was more "we set up things in a hurry because of deadlines and now we are stuck with this until we implement the epoch system"
If every desktop application that needed to store cross-invocation state asked for permission we'd probably say it was an invasion of bad-design huns.
Yuuuup. It baffles me how Linux users can simultaneously complain that 'its never the year of the Linux desktop' and then at the same time rile against basic usability tenets. The average users wants/needs Documents, Pictures, Videos, etc folders, and it wants the OS to be aware and use these as such. Now I'm okay with being able to set a specific flag that doesn't make these folders during install, but by default they absolutely should be there, unless you're doing a server install.
And I guess I would call it a "basic usability tenet" that the computer does what I tell it to. Documents, Music, and Videos folders violate this, because if I do the seemingly-obvious thing of just deleting them, the applications that want to use them will just recreate them unless I edit ~/.config/user-dirs.dirs. So, if developers really think they need to 'help' their 'average users' by creating these folders by default, they should finish the job and honor my desire to not use them, which I've expressed by deleting the damn things.
Also, if I want to rename them, the system should honor that. E.g. if I rename "Music" to "music", applications should not then go and re-create a "Music" folder.
Or, you know, they could just simplify my life and theirs by not creating these 'special' folders in the first place.
If it’s hard to change, you should’ve either fixed your architecture from the start, or thought a bit harder about the implications of magically creating a new directory in $HOME.
At this point, Guix and Nix seem the most promising for cross-distro packages.
Other "new" softwares that fail to follow best-practices by putting top level files into ~/ just on my laptop are: npm, Ansible, pylint, docker, steam, rustup+cargo, vscode, IDEA IDE, Zoom, AWS CLI. These applications have no excuse.
Also I agree on the Documents, Music, Video, etc. I hate upper case letters in my folders, so when I do a reinstall I delete those and restore my backups from the lower-case versions.
https://www.freedesktop.org/wiki/Software/xdg-user-dirs/
The Arch wiki has more instructional docs:
A video game can read my tax forms. WTF.
Mobile & tablet OSs solve this. Everything has to follow.
Until then, basically every app should run in a docker container. Then it can do what it wants.
Indeed the capability exists (unix/linux pioneered it?), but it relies on manual containment by the user. It should be automated, with prompts at install or execution time, like on mobile OSs.
An idea is each file should have its own user, basically, with both relative and absolute file creation/modification permissions. If you run an arbitrary executable as a user there's great security risk since it can do anything you can (without sudo of course).
It seems like the natural progression from
Run everything as root ->
Separate root and day-to-day user ->
Don't use root and achieve things with sudo ->
Each file has its own permissions (i.e. essentially its own user) set by the parent user
Permissions should be both for individual actions and permanent classes of actions, on the user's discretion (i.e. allow it to create this file or always allow it to create files)
This approach is even naturally hierarchical, executables could create other executables as long as they have permission to do so, and set the child permissions to at most its own. In this context an executable asking for permissions can be akin to sudo: it really is a file-user asking for its parent file-user for expanded permissions.
To give a real life allegory, consider a Technician in a company wants to make a tool purchase, so he asks the Engineer. The Engineer doesn't have permission, so he denies or asks the Manager. Finally the Manager either denies or asks the CEO which has permission over everything.
I don't trust many of the apps on my phone (all of Google, FB, messaging, etc). I trust the open source apps (example K9 email) and I'm replacing proprietary apps with open source ones.
I trust almost all programs I use on my PC, which I install with apt-get from Ubuntu or other open source PPAs (no snap, no flatpack). There are a few proprietary programs I might doubt of, for example NVidia driver, Skype, TeamViewer, Telegram. I understand that one is enough to compromise all the PC.
I'm ok with separating untrusted apps/programs but I don't want to get permissions in the way of programs I trust. Software development would be a nightmare if emacs and vim and all GNU userland and interpreters, compilers, etc would run in different environments.
That's because you have to. I trust all my programs too, because I wouldn't install them if I didn't trust them. We've spent decades telling people only to install applications they trust, and not to click on suspicious executables. The result is that they are very resistant to install new programs, unless the programs are from organizations they already know and trust.
That's partly why web applications are so popular: it requires less trust to use a website than to run a native application. If native applications were less dangerous, people might be willing to use more of them.
1. Desktop OS's have awful security
2. Therefore you're VERY careful about what you install
3. Because you're VERY careful about what you install, you don't need the extra security, it would only be an hassle.
A concept I find useful is that there are two kinds of security:
-- Accidental security
-- Malicious security
Permissions help with both. Not only you don't want 3rd parties to invade or disrupt your system, you don't want users to invade or disrupt your system (or their own systems) accidentally.
A classic example I believe is an user wanting to delete all files in current directory, typing
$ sudo rm ./*
$ sudo rm /* #(delete *all files*)
> The command rf requests root access for file deletion at /
> Accept? (y/N)
> User's administrative password:
> The command rf requests access for file deletion at /home/user/cache/
> Accept? (Y/n)
You may not be particularly worried about malicious security for system programs, but even professional administrators could be worried about accidental security and best practices (if they're not they could easily select persistent full permissions). I get the impression the last thing e.g. sysadmins want is mess up production systems, and wouldn't mind a few more prompts when doing things manually (which should be rare?), or assgining scripts the exact permissions needed for their job.
But -- speaking from experience -- they are painful to use; most users prefer convenience over heightened security.
Agreed.
If you simply must, use a VM or AppArmor or SELinux. Don't inconvenience everybody because you're too lazy to be responsible for your own data.
Besides, untrustworthy apps will bypass the protections anyway. Judging by the popularity of "curl <url> | sudo bash" lately, they'll probably just ask for root directly.
Running untrusted programs is the default way we do computing. No one has time to audit every single program they run. The current desktop security model comes from when people mostly ran the programs that came with the OS and programs they wrote themself. Its vastly inappropriate for modern computer usage.
Even that isn't particularly safe.
In general, everything in computing will keep going in the direction of "trust everything as little as possible for it to do its job" forever, I think, and probably has to.
So basically no apps at all.
I still see a lot of Mac apps that basically say "disable system protection first."
No no no NO!!!!
Think of all the things you can't do on a mobile device that you can do on a PC, or which require ridiculous workarounds like uploading from one app to some server on the Internet and then downloading again into another. Effortless data interchange is what makes computing great, and stops proprietary walled-garden data-silos from becoming the norm.
If every normal app has to ask for permission to use your disk, you’re just going to click “Okay” when malware asks. Then the whole system was for naught.
Implementation really really is key when it comes to the UX here though. Windows actually already has this feature (Controlled folder access) but it's done so badly you'd almost think it's a joke. Take this as a warning of how bad things can be if you just sandbox everything without thinking. Enabling the feature accidentally is deceptively simple without any warnings on how difficult it is to use: "Protect files from unauthorized changes by unfriendly apps" is all it says, who wouldn't want that? After that havoc breaks loose. You can only have ONE group of folders protected, you must have Documents protected. Whenever a new program tries to write in a protected folder the program just fails, then 15 seconds later you get a confusing prompt saying excel_32_broker_confusing_name.exe tried to write to protected area, clicking the prompt takes you to a page where you can't simply press yes to allow, you have to manually browse to find the exact program location, good luck finding c:\program files(x86)\office\bin or whatever they decide to call the exe.
One should/must/can not build an operating system on trust alone, as especially the mobile software space consistently continues to show with its numerous malware apps (imagine that on the desktop! "oh sure, have root/admin '50 smileys FOR FREE'", "oh sure, be able to read and write all my user's files <insert dubious clicker app>").
Mobile OSs have become vastly better (not perfect still) than this than desktop OSs.
I would like to see desktop Linux's application management adapt a minimum necessary permissions policy: Allow access to some ressource/API/permission only if the app needs it (and the user allows it of course) and offer mechanisms to allow permission management and ways to enable inter-application communication. This also modularises applications more by bundling up their connections to the rest of the platform and their effects in a central location.
For instance sandboxing applications into their own empty folder would make it simpler to operate on files these applications created (backup, migrate, autocreate <- NixOS would benefit from these especially, allowing finer grained declarative control). It would still be okay then for application developers to follow their own conventions within that sandbox.
Nowadays files are all bunched up in arbitrary folders and nobody knows where they're coming from. It's become so much harder these days to coordinate so many projects that need to create files in the home folder on Linux by trying to introduce standards versus taking that capability away from programs transparently; this should also be much more efficient man-hours-wise.
That said, this is going to be a nontrivial project with how many implicit connections between applications exist. Executing untrusted (or buggy!, I'm looking at you, Steam) software should no longer have to make me afraid my system gets messed up.
For now I think it's best to simply not run untrusted programs and creating regular backups... I wish I had the time/skills to work on something like this.
Why does it have to be "Docker"? Any other container framework should do as well, no?
Note that systemd can create cgroups and namespaces for processes it manages: http://0pointer.de/blog/projects/security.html
This doesn't help with installation, obviously, but it helps with cleanup.
http://osxdaily.com/2010/10/12/find-out-where-a-file-was-dow...
[0] https://textslashplain.com/2016/04/04/downloads-and-the-mark...
It's not easy to implement nicely, though.
It would be harder to make it so that all the tag-oblivious programs, like mv or vi, to say nothing of rsync, would preserve the attributes when moving or modifying a file.
f = open("the_file.new")
write(f, new_contents);
close(f);
rename("the_file", "the_file~");
rename("the_file.new", "the_file");
This has a number of advantages, but does not play well with any extended info the old file used to have, unless they are copied explicitly. And in a tagging-oblivious program, they won't be.
f = open( "the_file.new.$$" );
write( f, new_contents );
close( f );
rename( "the_file.new.$$", "the_file.new" )
Backups often take place, too, like you mentioned, depending on editor.
fstat the fd, get st_dev and st_ino.
rename
stat the new name. Compare st_dev and st_ino.
If the value matches, you renamed the right file. If it does not match, you renamed a wrong file. Without holding the fd, it is impossible to know if it is the right file.
I have to deal already with these on file shares, specifically for Apple: .DS_Store, .Trashes and .AppleDouble, or for Windows: Thumbs.db, $RECYCLE.BIN (for some reason Windows sometimes ignores the fact I've disabled the recycle bin on a share and creates this instead) and desktop.ini. Please don't drop crap around directories where there exist a multitude of tidier alternatives.
It gets annoying real quickly because you see the "crap" files of all the OSes you're not using. And you delete them, you only have to insert the stick and they're back. This happens in different ways for all of Mac, Windows, Android and certain Linuxes.
https://linux-audit.com/configuring-and-auditing-linux-syste...
In my research team, we used a tainting tracing mechanism to understand the behavior of malware. Basically, we installed a malware on a clean phone and we then traced all information flow originating from the APK to processes, to files, to sockets, etc. It helped reverse-engineering the malware.
What's not quite so straight forward is how you query the system. The worst implementations of file tagging only implement retrieving a list of all files that have a given tag. Slightly better than this are tagging systems that will return the intersection between two or more tags. Most tag systems never go beyond this.
Going slightly further, tag exclusions are powerful and are sometimes implemented (given a set of files from some subquery, exclude all files that have a given tag.) What you rarely see are systems that allow you to exclude one subquery from another.
However what you almost never see implemented is a system for preferential tags; given a subquery, reorder the results such that files with preferred tags are raised to the top, ordered by how many of the preferred tags they have. Once you implement this, the system's UX changes dramatically because the user no longer has to make strong assumptions about how well their files have been tagged. Many files might be missing relevant tags and the user may not be sure if the file they're after is one of these incompletely tagged files. When using a system with preferential tag querying, the user will receive files in their result list that don't match all the tags listed, but most of them. This is a bigger deal than it may sound, since the main drawback of using tags for file management is incomplete tagging. By addressing this drawback, you stand to bring file tagging to the next conceptual level, which is rendering hierarchical file management obsolete.
Consider that hierarchical file management is a strict subset of file tagging. You can model file hierarchies inside a file tagging system. To demonstrate this by example, consider /home/joesixpack/Documents/seventh-novel.pdf For each level of the hierarchy, we can create a new tag, such that this document has the tags: '/home/', '/home/joesixpack/', '/home/joesixpack/Documents/'. But because we're using file tagging, we can also automatically tag that file with things like 'pdf' or maybe even 'Documents'.
Now before I go on, there is something to be said about the number of tags in the system exploding when you model a tree as a tagset. In practice this probably isn't the approach any real system should take, if only because most of those tags will be useless and because there is a great deal of redundancy in trees that wouldn't exist in a native filetagging system. Consider /home/joesixpack/Documents/ and /home/johnsmith/Documents/. We have two different Documents directories because they exist in different parts of the hierarchy. However in a file tagging system we'd ideally only have a single Documents tag and one tag per user, such that querying the intersection between 'joesixpack' and 'Documents' returns the files that would otherwise be in /home/joesixpack/Documents. Some tags, such as the user tag, could be implicit; such that if joesixpack simply queries 'Documents' the tag 'joesixpack' is automatically intersected with the results presented to him.
With that out of the way, consider how we can go further if we apply straight forward statistics to the tag system. Suppose 99% of joesixpack's 'Documents' that are 'pdf' are also 'novel'. When joesixpack creates a new file that's in the tags 'Documents' and 'pdf', what are the chances that file should also be tagged with 'novel'? We could analyze the contents of the file if the system has a semantic understanding of what 'novel' means, but let's not go there. Tag systems created by the likes of Facebook and Google do this sort of analysis, but it's heavy, tricky, goes wrong in ways that create PR disasters, etc. We can get pretty good results by ignoring the contents of the file and looking instead at merely what that file is already tagged with. If a file is tagged with 'joesixpack', 'Documents', and 'pdf', it _probably_ should be tagged with 'novel' as well. Probably, but not necessarily. So the system can expose to joesixpack the suggestion that he tag that particular file with 'novel'. By presenting suggestions like that to the user, you greatly reduce the UX friction needed to tag files well and therefore increase the usability of the tagging system, while at the same time improving the quality of the tag suggestions in the future. What we create here is a 'virtuous cycle' of sorts that gives back to the user more as it's used more. Such a tag suggester can be implemented as multi-label classification using naive bayes; it's fairly straightforward.
Going further; if we have such a tag suggester, and an appropriate caching scheme, tag suggestions can be used by queries. If joesixpack queries for 'pdf','novel', the system could return to him the intersection of 'pdf','novel', but also return to him files that are tagged with 'pdf' but not tagged with 'novel', in cases where the tag suggester indicates there is a high likelihood that the file should be tagged with 'novel'.
That last paragraph may or may not play out well, I haven't experimented with it extensively yet. But getting back to my original point: if you're going to implement file tagging in a filesystem, you should think carefully about how the users will query that system, and whether the query system will be extensible in userspace to facilitate new powerful methods of querying it. It would be a total tragedy if the system only supported basic tag intersections and the only way to extend it was to implement a new kernel module.
This would require a ton of difference from how modern desktop and mobile OSes handle files / documents. Maybe some time later, some research OS would implement it.
Getting file tagging into the kernel level to replace directory hierarchies would be a huge paradigm shift, a very dramatic departure from Unix. To be honest I'm not sure whether or not getting such a system into a kernel would be appropriate or not. Traditional hierarchical file management seems more than sufficient for "system files". But I'm really interested in replacing hierarchical file management from the users' perspective. More or less, put ~/Documents, ~/Downloads, ~/Desktop, etc under control of the tagging system but leave the rest of the system as-is. At least for the proof of concept.
I think a demonstration system could be implemented as a custom desktop environment running on regular old linux, where the open and save dialogs of GUI applications have been replaced with tagging/querying windows. Instead of the user clicking through a few directories to find a file to open or find a directory to save something, they would instead click or type in tags to add or query. The GUI file manager would likewise be replaced with the GUI frontend to the tagging system.
The problem is file manager. Tracker/Finder are several steps ahead of Explorer. Under Linux, its a greater mess even though there are no technical limitations.
Surprising Explorer is so bad at it since they're good at getting EXIF data and ID3 tags into the Properties tab in Explorer.
I only ever sold one license, but I was 12, so I was pretty excited.
dpkg -S .foo
apt-file search .foo
rpm -qf /foo/barIsn't what you describe basically the file extension? Not so much what program created the file, so much as what program is meant to handle/open the file.
These people are arrogant shitheads and I’d like to know who they are so I can avoid their software. I assume if they do crap like this their software does other nefarious things.
Wow, this is really assuming the worst in people. It’s much more likely to be ignorance because the other developer doesn’t know where the file came from either (some compiler flag on a library accidentally enabled), or also doesn’t ls -a in their home.
Yes, I am. I'm fed up with programs that spam my system without asking: install plug ins, menu items, directories on the desktop, dock items etc for "convenience" -- it's convenient for them, not me. It's especially painful when I pay for an app and it sprays shrapnel through my filesystem.
> It’s much more likely to be ignorance
Indeed, but if they can't be bothered to learn basic system hygiene how can I be confident the rest of their package is safe to use?
A big driver for sandbox/containers in user systems is not protection against malign actors per se but against the lazy and ignorant.
Have I written bugs into code? Of course I have, I'm human. But at least I try to get things right up front; to be a good citizen.
(there are additional reasons for containers in server systems, hence my qualification of "user systems" above).
Perhaps having all parts of this chain called "shithead" is extreme but they would all have responsibility and disrespect for the user.
However, since it has not been mentioned, I would like to shout out to the Python "appdirs" module[1], which neatly solves this issue for those writing programs in Python with minimal effort. The best part is that it uses the platform's native standards, so XDG on Linux, plus whatever macOS and Windows call their implementations.
Sadly I am not aware of comparable options for other programming languages. I think having high-quality easy to use libraries for this sort of thing would go a long way.
https://developers.redhat.com/blog/2018/11/07/dotnet-special...
Many of these are named Windows-centric because of the history of the API. But where possible, they still map to something reasonable elsewhere. Looking at the mapping table, I can't think of anything it doesn't cover.
Boo. Apps not using XDG on macOS drive me mad anyway; 1000 times more so when they do on Linux, but use Library or whatever stupid place on macOS despite the presence of XDG environment variables.
[0]: http://egorsmirnov.me/2015/05/04/global-gitignore-file.html
[0] https://en.wikipedia.org/wiki/.DS_Store
[1] https://support.apple.com/en-us/HT208209
[2] https://e-rave.nl/disable-creation-of-ds_store-files-on-samb...
No idea how to prevent them (except on networked folders.).
This is the type of low hanging fruit that Apple evidently doesn't care about anymore, but would go really far towards improving user sanity. It's like when you go to a restaurant and order the cheapest thing on the menu as a way to gauge the overall quality of the food there.
https://eclecticlight.co/2018/03/03/how-macos-tracks-your-fi...
so I can't see any conceptual reason to keep .DS_Store.
Nor can it preserve that metadata across other devices, network drives, etc. without copying it across somehow; the easiest solution was to store that data in hidden files and let Finder handle their automatic transfer.
Failure of your imagination isn't failure on someone else's part.
I'd be curious to test this, by zipping folders, copying them to other machines, etc. My gut feeling is that Apple probably missed something and it doesn't quite preserve the metadata like it should (most likely due to version incompatibilities or duplication of state somewhere else in the OS that overrides it). I'd be pleasantly surprised if it did work though.
It brings up another point however, that probably metadata is as important as data (and sometimes more important, if you look at how we organize data today). The earliest filesystems probably should have implemented multidimensional storage somehow, similar to the metadata in the BeOS filesystem. I'm not familiar with how it's implemented, and it probably also breaks when files are copied to another filesystem, unfortunately:
This is an unfair comment, showing you don't know _why_ those files exist. They're an ugly tradeoff, but they serve a purpose.
Dot files and .DS_Store files are meant to replicate the movement of metadata that Classic Mac OS achieved with creator codes and whatnot, as well as the layout settings for the folder. Those files need to be in the same directory as the files/folder because Finder knows to copy those files as well.
Finder saves the layout options and settings for each individual folder, harkening back to the spatial Finder of Classic Mac OS. It's an integral feature of the system enabled by default. It would be an absolutely terrible idea for Apple to put the preferences for every single folder to which the user has navigated in one preference file, especially given that it would need to be updated whenever files/folders undergo any CRUD operation.
> but would go really far towards improving user sanity
99.9% of the time, users don't notice this at all. Those files are currently everywhere on a macOS system, but nobody sees them. The only time they really come up is when you're using ``ls -A`` or copying files to Windows; apart from then, they're truly invisible.
What Apple should do is provide an option to not copy the dotfiles and .DS_Store files to USB sticks, especially if they're FAT32 or ExFAT format. That's a better solution than one huge preference file of shame.
* CPU: We'll just have this web page peg the user's CPU running gobs of code because our designer wants to unnecessarily animate this thinggy or our ad network wants to mine bitcoins. (Related resource: Mobile phone battery)
* Memory: We'll just use this web framework and embedded browser that uses up 1GB of the user's RAM, for a one-window chat application we're writing because we can't be bothered to learn anything but Javascript.
* Disk/Storage: We'll just cache 20GB of easily-regeneratable internal data so the app seems faster than it is, dumping it somewhere for the user to find and clean up.
* Network Bandwidth: Our shopping cart web page load is larger than the full installation of a 2000-era video game because we have to have 6 layers of framework abstraction and taking the time to optimize/minimize it wouldn't let us release fast and "crush it" in the market!
Nobody seems to care. "Oh, Xyz is cheap, programmer time is expensive!" is the rallying cry. So let's push the cost our shitty practices to the user and make her buy more hardware.
Definitely a unix developer.
Requiring files in your home directory that do not have a dot at first (with a fixed name) is no good, though.
To those of you reading this: I beg you. Avoid creating files or directories of any kind in your user's $HOME directory in order to store your configuration or data.
My immediate response was pretty much "where the hell else should they put them then?"
What exactly else is the /home dir even for otherwise?
The purpose of home is for user-level persistent files. Giving it access to something else means giving random programs write access to some global part of the file tree, and I'd rather not allow that except when actually necessary. As it is I hate having stuff that manual installs in /opt, or the way too many programs on Ubuntu are configured to require sudo to work.
I'm actually totally on board with more stuff that installs entirely local only, especially if it's from outside the distro's package system. I don't like stuff mangling the global tree with no clear standardized path for removal and uninstallation. At least if it's in /home, I can just delete it myself without even needing to go sudo.
And the purpose of .dotfiles in /home is because it prevents those user configuration files and other such local data from cluttering your directory when doing a plain ls for regular user files.
This article just sounds like a misunderstanding of how the file tree is even supposed to work.
He didn't mean to avoid $HOME as a whole. Just the root of the $HOME directory.
I too much prefer having programs write their config files to $HOME/.config/program-name instead of $HOME because it's less clutter and now I can think "ok, $HOME/.config is where all of my app's configuration is", instead of having a bunch of files littered in $HOME while other apps use $HOME/.config/file_name or $HOME/.app_name.
It bothers me that .pypirc exists in $HOME, rubygems credentials are in $HOME/.gem/credentials and Docker's credentials are in $HOME/.docker/config.json. That's 3 different location styles for an app's config file. They should all be in $HOME/.config/$app_name/relevant_file_name for whatever the config is for.
This is not true. Even if the distribution sets global xdg variables (none that I've come across do) - the user can always override them.
> While their recommendation is all in the home directory, I wouldn't put it past some of these distro developers to make some crazy /var/users/{uid}/config directory
This sounds like a strawman. Are you aware of any existing distros doing this? Users don't have write access to system directories in the vast majority of distributions.
It’s so nice to see this article at the top of HN. I had long thought I was the only one who felt this way.
Then if you try to make a dotfile through powershell, it has a different text encoding than *nix, which some programs (git) rely on
It does, rename it .dotfile. so with an extra . at the end.
it has a different text encoding than nix,*
You don't specify how you do this, but most text output commands out there have an -Encoding parameter. Or else set it globally to what you want, good read here: https://stackoverflow.com/questions/40098771/changing-powers...
(I never used MacOS, but from the article it seems not the case for MacOS?)
It's a laziness issue, it won't be solved solely by making is easier to access the right locations on each system/platform, but that would be a step in the right direction.
Part of the problem in Windows is that Program Files is write protected for security, so you can't store a local configuration file relative to the exe. So where does it go?
I assume there must be documentation from Microsoft and Apple about best practices for this... I hope?
To answer your last question: in Qt you can use QSettings and it'll write to a canonical platform-specific location. Useful for storing eg the last accessed folder in a GUI, or things which users don't reallty need to change regularly.
This hasn't been a problem since the first version of Windows that had a filesystem with such protections - that would be Windows NT 3.1.
The correct location for such stuff is %USERPROFILE%\AppData\Roaming or ...\Local, depending on whether those settings are machine-specific, or should be synced across all devices for that user accounts (in environments where this is appropriate, such as domain networks). This particular location is in use since Vista - before, the names were slightly different ("Application Data"), but in any case a well-behaved app is supposed to use Win32 API to retrieve the correct path, rather than hard-coding it - which also worked on Win9x.
> I assume there must be documentation from Microsoft and Apple about best practices for this... I hope?
Of course.
https://docs.microsoft.com/en-us/windows/desktop/shell/known...
https://developer.apple.com/library/archive/documentation/Fi...
The problem is that so many apps just straight up ignore all those guidelines.
The fact it happens so often suggests that the documentation isn't good enough.
> Of course.
At least Apple's pages is pretty clear and has some nice diagrams.
I think this page is more appropriate: https://docs.microsoft.com/en-us/windows/desktop/shell/csidl
It's reasonably well documented for UWP, though I can't find an equivalent for Windows: https://docs.microsoft.com/en-us/windows/uwp/design/app-sett...
Hence why I suggested that Qt has the right approach. It also has http://doc.qt.io/qt-5/qstandardpaths.html which abstracts out standard paths for cross-platform applications.
Any library or framework author knows that documentation is never enough. ~ On Windows, though, there's also historical reasons - back in Win9x days, there was no practical reason for apps to bother if they didn't anticipate running on NT, which is why it was so common to just dump configs next to the .exe (and even to this day, Windows uses FS virtualization to make this work for old apps). When 2K and especially XP became popular, and everyone was rapidly porting their stuff, people often didn't bother looking up docs and all, and just used the "least significant change" approach to fixing things. And that kind of set the background for later - why bother being nice, if nobody else does?
> I think this page is more appropriate: https://docs.microsoft.com/en-us/windows/desktop/shell/csidl
This page describes pre-Vista, deprecated APIs. Unless you need to target XP, a desktop app should use the known folder mechanism.
Actually the current documentation refers you to the CSIDL list if you want to know what any of the GUIDs actually mean. The new docs just provide a list of IDs with minimal information.
See https://docs.microsoft.com/en-us/windows/desktop/shell/known...
Madness.
Hardcoding paths is a bad idea, since they can change - indeed, they have already changed once in Vista, and the paths that you suggest are obsolete on Vista and above - it's %UserProfile%\AppData now (although it still provides symlinks for compatibility).
Also this annoyance is easy to solve, just make one dir in home (my is called after my name) and put all your own files in there.
If I change my .zshrc, I have to re-source it in each running instance of zsh. Sure, I could automate this. But I'd also like the same done in vim. And in weechat. And in mpv. And in everything using GNU Readline... you get the picture.
This is probably at the top of my list "biggest complaints that won't be resolved for numerous reasons." It sure would be nice though.
Home directory is the default directory for terminal emulators, and having it polluted to me feels like sitting in a dirty room.
~/.cache can burn, though:)
So I guess if any of your applications have important data, you better back it up! (I learned today)
* My definition of "garbage" in this context is stuff I don't miss if I wipe the machine, reinstall the OS and the app, and sign in again.
My comment wasn't meant as a criticism of the basic idea of a standard directory scheme; it was a reply to someone asking why anyone would ever care about files you can't see.
Even the $XDG_ env variables still require the user to set that up, or the OS maintainer needs to set it up. If the OS maintainer sets it up, the user probably won't know where to find configuration.
The reason $HOME is so commonly used is because the developer knows with almost 100% certainty that the unprivileged user will 1) be able to read/write to it without superuser privileges and 2) it keeps all configuration data contained in the user's home directory for portability, instead of throwing it all over the file system in locations nobody will know.
That portability will come in handy when you're backing up or restoring from backups, which I just did yesterday. It means restoring is as simple as copying your entire home directory back. I don't need to tell each app where my configuration is, it just knows it will be in $HOME.
And that assumption will be correct for almost any *NIX-based operating system.
I do agree that non-dotfiles should not be created in $HOME, that is a nuisance.
The default is there to allow users and OS maintainers to not worry about it. It still goes in your home directory, but at least it's organised.
But it would have been so nice just to move it into a ~/cfgs or fine... even a ~/.cfgs or whatever.
I'm guessing engineers went, "ewww, I'd have to walk down the tree to find the next most relevant config file to use and then go UP into a directory when I hit home."
https://wiki.archlinux.org/index.php/XDG_Base_Directory#Hard...
I can axe my home folder and rebuild it with `nixos-rebuild switch`, it's pretty minimal.
(just an example, not actual)
environment.etc = {
"qemu/bridge.conf".text = ''allow br0'';
"username/.inputrc".text = ''
\$include /etc/inputrc
"\e[A": history-search-backward
"\e[B": history-search-forward
set show-all-if-ambiguous on
set completion-ignore-case on
'';
to write configs into /etc proper and my home folder.
I haven't used home-manager, but it looks like a bloated thing that I don't need in my life.
Some of us would like to manage our systems, and processes like backups, transfer to a new system, etc., in something resembling an orderly process.
The very concept that architects, designers, &/or programmers think it's OK to just litter our systems with their stuff wherever happens to be convenient to them to code up this afternoon is no better than people just deciding to crap wherever they feel. When I see software doing this, I automatically downgrade them in my assessment of what I want to use going forward.
The simple concept is that there are a few categories of storage used -- these should each be kept separate & independent, under the USER's control.
Why is this a difficult concept?
Program code, system-config, per-user-config, user data. A simple table of the default and user-overridden location for each.
If you as a coder have a problem with this, I really have to wonder what other complexity you will handle badly.
If this simple system is a mess, why would I expect other parts of your system to be any good?
Now I just mount the home directory with rewritefs and try make the mess more or less compliant to the spec. It's not ideal: it's a hack and it causes a performance hit but I can be at peace in my ~.
I actually like that there are applications that actually still have preferences. My biggest pet peeves are applications WITHOUT preferences. Careful what you wish for.
In a long battle to be more intentional about what I keep around, I wanted ~/ to function both as my desktop and downloads directory, on both macOS and nixos. Using it like this would force me to deal with cruft quickly, and avoid crap silently piling up out of sight until its origin is forgotten (though desktops will hide the .dotfiles; those could still accumulate unnoticed).
It was easy to set this up on nixos, but I found the handful of apps dropping non-hidden files there grating. Magic folder behavior on macOS didn't work as well with this.
I ended up replacing ~/Desktop and ~/Documents with links to ~/Downloads. The naming isn't sensible, but I'm happy with how this works on both systems so far.
Computing power is so cheap now, that we don’t need to share machines when working in the cloud, either. We can, and do, log into our own VMs, work on data and software and commit back to an intermediary before final merge into a shared repository.
Perhaps it’s time to return to some version of single user OSes and clean up the relics left behind by no-loner-needed multiuser environments.
I believe the article itself is an existence proof that it is in fact, not bizarre.
i.e., New standard directory `~/personal`, new environment variable, $PERSONAL.
If we could come up with a default `~` like character for globbing to `$PERSONAL` like `~` does to `$HOME`, say, `@` (obviously that isn't the char to go with and I'm not a BASH expert to be able to pick one not already occupied). All your personal dotfiles are in `~`, all your personal files are in `@`. Default `cd` without args to `$PERSONAL`. No worries about tons of files that are in `~` because you live in `@`.
“There is no problem in computer science that can't be solved using another level of indirection.”
A game's save should be $XDG_DATA_HOME, misuse is exactly that, misuse. I have hundreds of games installed on my linux machine and not a single one has put it's save files into my $XDG_CONFIG_HOME folder. On the other hand many DO outright ignore XDG and dump all their garbage into .game_name/.dev_name folders (looking at you Factorio). I think you are exaggerating the issue.
> Making dotfiles under $HOME is a simple approach that's worked for a long time and that doesn't cause serious problems, and I see no need to adopt the XDG approach, which I see as overengineered.
What exactly is over engineered here? It's just a set of environmental variables, developers ALREADY use $HOME to spam up my home directory. The only real effort a developer needs to put into this is making sure they separate their config, data and cache folders which is something most already do within their cute .program_name folders.
while maybe not "serious" I certainly do find it do be quite the problem that all user-specific program data is randomly dumped into poorly named hidden folders within my home directory. *Nix systems at a root level already divide config files into /etc, cached files into /var and /tmp, and data files into /usr. Why can't there be at least a little symmetry with how the home folder is handled?
The conventional dotfile approach is just fine: there's an application and it puts state under a directory named after itself.
$XDG_CONFIG_HOME is equivalent to /etc. It has small files you probably want to back up.
$XDG_DATA_HOME is equivalent to /var. It has potentially large files you might want to back up.
$XDG_CACHE_HOME is equivalent to /var/cache. It has potentially large files you probably don't want to back up. You can delete them if you need space.
Warning, its Windows support is all theorycraft so far (Travis CI + Windows is totally broken for Node projects right now). PRs welcome if anyone wants to give it a try.
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0
It makes things completely controllable and you know where to look for configuration files.
Home directories have become the *nix version of the Windows Registry.
https://wiki.archlinux.org/index.php/XDG_Base_Directory_supp...
But, I sure do agree with the frustration. My work machine has nearly a hundred hidden things. My Chrome usually downloads things to ~/Downloads/ but Firefox often likes to store the file in ~ which then is often hard to find when I jump over to a console.
I've made an effort to clean things up. Trying to set firefox to download to the Downloads folder, deleting everything personal out of the home folder. But, of course, then that just goes to prove that I do not have control of my ~ folder. I'm doing everything I can to keep my own stuff out of it. Which is sad.
If you want to override the defaults of this command line program, create a .programrc file in your home directory.
and
Thanks for trying out this program, I'll just create a whole directory structure of config files and caches in your home directory.
Just don't put anything you care about in home directories: in the modern world people own computers not user accounts, you likely have ultimate control over your system, therefore designate your own "home" directory, don't give the other "developers" the choice to polute it by making it non-standard.
I like to be able to nuke my user-home directory whenever I like, I achieve this without pain by additionally placing my hand picked application configurations that I care about into a read only XDG config directory.
This trend is killing the usefulness and practical aspects of having a home folder.
With this I can also more easily sync my files across machines.
The "old" way forced program developers to put things in a very specific place. The new way allows then to interpret the XDG standard however they want and scatter everything all over the place.
It's also possible that the author runs a lot of scripts from various projects from github and sometimes those scripts' authors are not careful about running npm/yarn within their projects. I guess I don't play around with OSS enough. :)
I think to be upset over that is just looking for a fight.
It works across all of my OS's, I know its config specific to the app, and if I want to jump in and get some info it is just a ~/ away...the overhead is so low I've spent more time thinking about it in this statement vs all the time ever wrestling through them or battling tribal knowledge.
I guess I just don't see a strong enough argument here.
Than I create my personal folders ~/{src, docs, bin, porn, anime etc}. ~ is for temporary files I'll delete after use like windows users do with their Desktop folder.
Also my ls isn't an alias with -a flag...I'm alone here? :|
This would also allow you to test if something there is causing issues or if you wanted to format and reset things. Just delete that directory or set the variable to another path.
I don’t set ls to ls -a, but sometimes I create hidden folders and files on ~/ so it’s not distracting. Scanning through a lot of things because everything is dumped there is a mess.
I've spent some of my career building packages from source and I know the assumptions you get stuck with because the app developer hard-codes certain things. So it makes sense they just go for what is most standard and expected.
[1] https://en.wikipedia.org/wiki/Freedesktop.org
[2] https://specifications.freedesktop.org/basedir-spec/basedir-...
Sounds like there’s a bigger problem.
Anything where your own way of seeing it creates the problem, and you can't describe the problem any other way, you're not ready to pitch it as a problem to other people. Find some harm independent of your perception, and then you've got a reason for people to listen.
FTFY.
If you don’t want to follow the spec, keep your program’s data in your program’s directory. If another program needs the data it can follow the $PATH, or ask the user.
Even better, ask the user at first run. You know, when asking people to accept some Byzantine EULA, license, and permission to track their grandmother.
Until there is 500 dotfiles, some long forgotten.
The logical conclusion is that it ought to live somewhere in home which meets the above criteria. Its obviously cleaner to store data in $XDG_* but keep in mind that some of the apps creating said files are actually older than linux and certainly older than such standards.
From dev and user perspective it would be nice to have them updated to follow the standard but in practice the practical effect is nil so lots of stuff doesn't bother.
When the program starts up, it needs to know what its configuration is. This is not stored in the code. So it has to find its configuration data somewhere. Ideally, you'd let the user configure where they want the config file. But then the program has to read the config file to find out where the config file is, and it doesn't know where to look.
(So it seems like you pretty much have to put config data in the same place on every computer, or use environment variables.)
If you don't know about the XDG Specification in the article (I didn't), a $HOME/.myconfig file is by far the simplest and most robust solution.
End developer is inexperienced, temporary, not valued and hence his deliverables
The reason I like it is it provides directories to use across platforms (edit: Not sure about Windows), relative to the user. Since the applications download a file (UNIHAN database [1]) to bootstrap, we want to store it in the user's files, not the systems. The other thing I do that's helpful is using sqlite (which is often built with Python).
This combination gives a database, and a place to store configuration, downloaded/built files, in an organized way across systems.
The nice things XDG "standardizes" which I'm using:
$XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.
$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.
$XDG_CACHE_HOME defines the base directory relative to which user specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.
Why the implementation is helpful:
It defines a common directory for cache/data/config files, with applications inside them, e.g. ~/.config/i3, ~/.config/tmuxp, rather than adding more stuff to ~/.i3, ~/.tmuxp. When standards aren't being followed, programs end up storing their configurations / data / etc all over.
Another thing is it defines directories relative to the user themselves and for the system files. Dotfiles may imply configuration / artifacts in the users home directory, it doesn't have. The thing I like is I can check for configuration in user files (for instance ~/.gtk-3.0/), then fall back on checking the system files (/etc/gtk-3.0).
The benefit of user files is they're writable out of the box, so if there's going to be any file generated that the user needs to keep (like an unzipped version of UNIHAN) that can be cached so they don't have to download it again.
(XDG Link: https://specifications.freedesktop.org/basedir-spec/basedir-...)
Just look at that path:
"$HOME": It's my home directory. Cool.
".local": It's in my home directory, but local to it, and not somewhere else? This doesn't make a lot of sense, but er, Okay.
"shared": For Christ's sake, what is this? It's in my home, and local within it, but also shared? With whom? How? Why? I give up.
Why would anyone want to do this? What concrete benefit does this path give us? What specific thing does it let you do that ~/.myprogram doesn't? The article is bad, and the XDG standard is bad. The traditional approach is fine.
~/.local:
It's intended to be /usr/local in the user's home directory. There's a bit of a backstory here though: Linux distros don't follow `/usr/local` as well as BSD's, not much may be there.
~/.local/share:
Same idea, for /usr/local/share. But on many linux distros, this is `/usr/share`. XDG is trying to do is mirror the system directories in the user's filespace.
Let's assume there's going to be a lot of applications: they won't agree on where cache, config, and data storage is kept at within ~/.myprogram. With XDG, if someone wants to clean out all their cache files? rm -rf ~/.cache.
The other thing is: Typically the user won't be looking at ~/.local/share/myprogram - it's for data the application itself is going to use. It doesn't really count against it. What I think we will be looking at though: configuration files. That's where I think XDG is kind of original - but it's really close to what /etc is.
As for ~/.myprogram: I'd be okay with that, if it were purely configuration. But XDG serves the article writer's purpose fine: Keeping $HOME clean. I kind of think splitting between ~/.config, ~/.local/share, and ~/.cache ends up feeling more consistent with how linux/bsd organizes files.
1) Mozilla
2) Gnome
3) Gimp
4) GPG
5) Thunderbird (Why is there a sep directory and not under .mozilla)
6) mplayer
I guess one reason why this occurs is that it's easier for to be carelessly cross-platform this way. Except you'd expect better from mozilla, specially because they store Windows stuff very well inside %localappdata%
Good thoughts
You can just change the default: if .gnupg exists, write everything to it. If not, write to $XDG_CONFIG_HOME/gnupg/ and $XDG_DATA_HOME/gnupg/ as appropriate (deciding how to carry out the split is not obvious, but can be done).
I agree, though, that calling it "shaming" is neither justified, nor useful.
For this reason I like better the windows distinction, that (if I understand in correctly) distinguishes between machine-dependent files and machine independent files. for something like gnupg I would not really say what is data and what is configuration
For vim... yeah, AFAIK "vim" does that, but neovim uses ~/.config/nvim :)
And to your general point... yes, many of these programs predate XDG. I happily support keeping them backwards compatible (which should be easy; checking multiple places in order is a time-honored tradition). But I honestly don't think this was a good idea even decades ago, and "we've always done it this way" is a terrible reason to not even support a newer, cleaner approach. Again, there's no reason to break existing systems; just support an additional location, probably make it the default, and everyone will be happy.
I am not saying it is the best way. But I don’t think it is malicious or lazy.
https://wiki.archlinux.org/index.php/XDG_Base_Directory#Hard...
and now the most fun:
bash, zsh, git, gtk, man, wget, xorg
That's what /opt is for!
There are actually consultants who advise organisations on cleaning up their file systems.
that's the basic misunderstanding, the user folder is for everything that's not system wide on a multiuser system; it's not there for your convenience, it's there to allow programs a writable space that doesn't conflict with everyone's else.
instead of subdirectoring everything else pretending programs to follow some weird never agreed upon specification, just add a "document" folder and put your user generated content there, problem solved.
Edit: apparently even on "hacker news" the mentality of forcing everyone else into obeying instead of solving minor inconveniences the only logical way has taken hold. Not even on widows with their nice buckets and environment variables could solve this, resulting in an exposion of games, my games, three app datas, documents/pictures/videos with apps doing whatever (i.e. shadow play putting screenshots under videos) but no, Rando comes over recycling three environmental variables that are specific of a program and everyone sucks up to it ignoring all the technical, social and other issues to the approach, while shitting upon the only sensible action that can and will work.
So much for applied brains.
In my opinion, having a conventional place to look for user configuration in plain text is a good thing, not a bad thing, and of course I would want it to be in the directory on my system where I'm the sole owner. As somebody else mentioned, this means backing up my personal settings and files is braindead simple, too.
Asking programmers to respect $XDG_HOME_CONFIG is not a bad idea, but it's no replacement for home directory hygiene. I believe that ultimately, cleanliness is a personal responsibility.
Edit: reduced smugness quotient while trying to preserve my argument. I apologize for the pre-edit tone issues with this post.
How about the other way is I’ll just stop using your product/service/business that doesn’t respect my machine?
Not to mention that most of these are free and open source, so building according to convention is the best way to keep their userbase happy (as fiddlerwoaroof pointed out, $HOME was the original conventional dotfile location pre-2003.)
So if your program doesn't respect my machine (meaning allow me to configure it to prevent unwanted behavior) then yes absolutely, into the bin with it. And rm -rf its dotfiles after.
This is from a fresh install 3 months ago, do I need 2 dot-folders for dropbox?
That place is $XDG_HOME_CONFIG (~/.config)