It's often worse on Windows, since dotfiles aren't hidden and meny dev tools assume they'll be running on *nix even when they support Windows. https://imgur.com/a/Im6G20B capture from my windows box of my $HOME.
It's just ~/Documents, which I symlink to ~/Desktop so that if any asshole developer dumps a file into it I'll be able to see it and remove it immediatelty.
Also on macOS, where [~]/Library/ApplicationSupport is the designed and recommended place to store config files, logs, preferences and all kinds of persistent data, the home directory still gets cluttered.
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.
I would honestly like to blacklist my home folder. Do you want to create a new file/folder? I am notified with a popup and if you ask to often I am gonna stop using that. Not really workable but one can still dream...
This is actually possible (on Linux, at least, probably Mac/Windows too) with something like selinux. It ends up being a huge headache though, both because selinux is kinda hard to configure, and because you will get a constant barrage of requests.
That's how sandboxed apps (=app store apps) on macOS work. They can only access files and directories that the user has explicitly selected (through the system file dialogs or drag and drop)
At this point the right solution is to just not allow applications to choose. Give each their own view of the file hierarchy but keep all the crap they spew out in a location obviously related to them from the user's view of the file hierarchy.
While this cleans up the file hierarchy, it absolutely destroys any interoperability between programs. If a program cannot output files that other programs can see, then it cannot output files that other programs can use as input. Between having a messier file hierarchy on the one hand, and not being able to open a Microsoft Word document outside of Microsoft Word, the former is by far the lesser evil.
For GUI apps, this is trivially solved by requiring the standard Open File/Folder dialog to be used. The system can then control the presentation, and once the user has picked a file, provide the app with a security token that encodes that permission (or even just an open file descriptor). So apps can see each other's data, but only when user explicitly directs them towards it. This is more or less how it works in Win10 UWP apps.
Using the filesystem for primitive “interoperability between programs” is increasingly recognized as a serious security problem. As someone else in this thread pointed out, a video game can access their tax returns.
This was a bigger problem in the earlier days of OS X (I even created a "Actually My Documents" folder inside the Documents folder to work around it), but now I'm down to two offenders - Adobe and DVDFab.
Windows also has an app data folder that contains a whole mishmash of stuff. And of course you have the registry.
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.
> 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?
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?
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.
> The fact it happens so often suggests that the documentation isn't good enough.
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?
> 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.
Respectful Windows apps should call SHGetKnownFolderPath() with FOLDERID_LocalAppData or FOLDERID_RoamingAppData.
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).
It’s a LAZY place to store user data that works across platforms.
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.
Except isn't there a specific directory for such things now in $XDG_CONFIG_HOME? Or is this not standard at all? Either way, $HOME/.config makes perfect sense to me!
That's an intellectually lazy thought. If everyone had that attitude we wouldn't have modern society at all (grow your food, don't expect someone else to grow it for you).
Nobody is forcing you to interact with those "new users", if you don't like them, ignore them.
Frankly, if everyone had your attitude, your Linux community will be dead and gone in a few short years as time progresses, and your old users pass away.
I've been a Linux user for a long time, I and many other long time Linux users do not share this persons opinions. New Linux users, keep coming, the vast majority of us are not elitist.
In order to have per user settings you have to have one dir per user. For practical purposes and security it ought to be somewhere only user has access it. Optionally it would be nice if you could back up all user settings and files in one place.
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.
I developed a utility for my own use and found an answer to your question.
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.
One thing I’ve been thinking about is that it would be nice to tag files with the program that created them. Aside from the clutter in my home directory, I have a lot of files that I have to guess as to where they originated from based on metadata like modification timestamps or permissions, but it would be nice to see something like “~/.config was created by some-tool”.
I think saagarjha's point was that an even simpler standard would be for the creating application to use file metadata to annotate the files. And a simpler standard is generally more likely to be followed, especially if it's unilateral.
This doesn't help with installation, obviously, but it helps with cleanup.
Why wouldn't it to be easy to implement? You could probably make a global LD_PRELOAD library that hooks into all open() CREAT calls and tags the inode's xattr with the program that created the file. You could use an attribute like, user.created_by.
Adding an interface to access the tag store won't be very hard.
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");
So the old file is never modified, it's renamed to the backup copy, and an entirely new file is created to take its place.
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.
Thanks for teaching me this! I wasn't aware. So, the original xattr (and the program that created it) would be deleted and replaced by vi for example. Still technically right, but I'm unsure how you'd keep a history.
f = open( "the_file.new.$$" );
write( f, new_contents );
close( f );
rename( "the_file.new.$$", "the_file.new" )
If not implemented like this, then something that attempts to read "the_file.new" may get partial contents, normally truncated along the file system block size.
Backups often take place, too, like you mentioned, depending on editor.
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.
Please no. This article is literally "Dotfile madness", don't make it worse!
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.
Because when you have multiple OSs accessing the same shared folder, they all create their own crap, which is then visible to the other OSs, and fills up directories with stuff that confuses normal users.
I don't run multiple OSes, but I do use USB sticks and SD cards on other people's computers and vice versa. I'm pretty sure that is "normal user" behaviour.
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.
Sidecar files for storing file tags make querying the tag system a huge chore; it totally kills performance. I understand the conceptual appeal but it's just not the way to go.
Programs can use programs like 'touch' to create the files so you'd have to get meta into a chain of process ownership or something while exempting the user's shell.
I think touch is a generic example, but not a practical one. The idea is that program A can launch program B, and you'd have to recursively search for the parent. But it's not easy to find which parent is the true owner, maybe an exception can be made for init but shells can't have that exception as they are sometimes the owner.
Why such a hack? This is a solved problem already. Try Linux audit API. You can set it up for tracking various actions, and you'll get a log with all the information including a process name.
I believe the question was asking for a method of storing the metadata, I was just suggesting xattrs. This will work at the expense of running a daemon.
Can audit be configured to only log file creation, not modification or access? Last time I didn't find a way to do that and I don't want to write a log file entry for every file access.
MacOS does something sorta like this. It uses extended attributes to mark where a file came from in some cases, such as when an executable is downloaded from a browser, it will mark it as "unsafe" and when you attempt to run it, this causes it to fail to run and you have to whitelist it via security preferences.
There's an entire research field dedicated to the information flow control which could solve just that (if it were actually used).
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.
I'd love something like this on program level. Given contents of a variable, I'd like to know where they came from - which pieces of code contributed to the result. I'd also love to be able to mark a piece of data, and see what code touched it or derived new data from it. A programming equivalent of injecting radioisotopes into the body.
I’d suggest looking into taint analysis tools, though those are usually aimed more at finding things like unsanitized input ending up in a call to system.
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 Fac...
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.
I've implemented the above in userspace for my own experimentation (not yet ready for public release, but maybe soon.) Nearly everything I've described above can be implemented with relatively straight forward SQL queries and SQLites performance has been everything I could have asked from it (in the neighborhood of ten thousand tags and hundreds of thousands of files.)
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 story I heard was that performance sucked. Granted it could have sucked for other reasons, as other failed efforts like writing more OS components in C# were happening at the same time.
BeFileSystem (Haiku)
HFS+ and APFS
Even NTFS has attributes.
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.
Apple's Macintosh did this in 1984. Files were tagged with 32 bit codes: one for the "creator" (the associated app) and one for the type. These were often made up out of readable characters: a so called "fourcc" (four character code). The "fourcc" persists in cross-platform media formats.
The first software I ever sold online was an app that would change the creator code of a file to whatever application you wanted. For some reason, there was no obvious built-in way to do that in Mac OS 8 (besides opening the document in the other application and saving it, or changing it in ResEdit).
I only ever sold one license, but I was 12, so I was pretty excited.
not sure if this is the exact solution to your problem, but rcm (https://github.com/thoughtbot/rcm) allows you to create dedicated dotfiles in a .dotfiles directory which are being symlinked back to files, and it has a -t option to create and restore dotfiles with tags. mkrc -t emacs .emacs.d would create a .dotfiles/tag-emacs/ folder and rcup -t emacs restores it.
If we start sandboxing applications and give each one its own UID, like Android does, we get this feature for free. It's kind of silly to associate exactly one security context with exactly one user.
>One thing I’ve been thinking about is that it would be nice to tag files with the program that created them.
Isn'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.
File extensions are trivial to fake, don’t really have a strong association with the application that is supposed to handle them, and in this case often doesn’t even apply because most of the files in my home directory seem to lack an extension.
File extensions are more nomenclature than file type indicator. More than one file type might share the same extension, more than one application might be used to open the file according to its extension. They mostly work, but file extensions != file types != file creators.
The XDG directories are by default under your home dir only, so you can keep the same backupability properties. Better ones, even, since the files of things supporting it are in one place.
I just keep my home folder in /etc/username and use this construct:
(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.
To name and shame some culprits (the one's who have shame, I won't name java because I won't expect them to care)
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%
Which is especially sad as supporting the standard described in my post is a non breaking change if you are still going to read the old location of the configuration and data files as well.
Why not _shame_ openssh? Or vim? Or emacs? I would advise not calling for shame on any of these projects because they have a pattern to support that has been in place longer than the XDG standard has been in place. You can change gnupg's home dir, but it would break a lot of currently functional setups if it just moved.
I guess I was being nice to old programs. Also, these are programs that a lot of external tools interact with. Nobody cares about where firefox stores its data- except the now almost dead flash plugin.
Yes, very good point I do think that the older programs/projects have to plan a migration which really can be challenging. I think there are some that might care for example selenium might have the mozilla directory as a default and some might hard code it. The orchestration of such a change is difficult because I don't think too many people read changelog or really keep up with upstream modifications.
> You can change gnupg's home dir, but it would break a lot of currently functional setups if it just moved.
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.
> (deciding how to carry out the split is not obvious, but can be done).
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
I'm personally willing to give SSH a partial pass because I feel like having it separate makes it easier to reason about from a security perspective (this would also apply to GPG).
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.
Speaking of Windows, their situation is worse. I remember installing a couple of games and suddenly my "My Documents" folder had "EA", "EA Games", "Electronic arts", "Rockstar games" folders.
Games do that by design so that they can be cleanly uninstalled without removing saved games and preferences. Also you should be able to backup your documents folder and not your programs folder and be safe. A good uninstaller should ask if you want to save them and remove them if you don’t.
I am not saying it is the best way. But I don’t think it is malicious or lazy.
^ This. And the amazing thing is it's probably the least common place for games to put save data. I think I've played exactly one game that ever used it.
It’s probably because Windows makes the actual home folder somewhat difficult for the average non-technical user to see. They effectively made the My Documents folder the home folder for most of their userbase.
I don't get the problem. Why bother where dotfiles are written to? GUI file managers and userland tools hide them by default. What would I gain by having them written outside of $HOME?
Preferences files tend to be pretty small; I'd be rather surprised even if a 128MB thumb drive couldn't store them all. The bulk of the space will almost certainly be consumed by other things.
You cannot and should never assume that dotfiles are just preference files. They might be directories, and those directories might be chock full of big files — or worse, temp files that should really be in /tmp.
My partner has to manage having a 500MB quota on their home directory at work. A couple of times a month something decides to dump 300+ MB of data in there and break everything.
Apps use dotfiles or dotdirs for caching data. Think browser caches. That's the point of the standard... All the non essential caching data lives in one place and so is easy to prune when needed.
Easier to version your configs if they're all in one place. Easier to find a config file, less guess-work. Generally helps keep the home directory tidy of cruft. Not a huge deal, obviously, but programs should be well-behaved programs.
Point of order: Some of us really want ~/.local backed up or otherwise persisted; I've got the equivalent of a second /usr in there, and I only don't worry about "backing it up" because ~/.local/etc is in version control, and the rest is installed by my setup scripts.
The whole point of .cache is that it's supposed to be that one folder that you know you shouldn't back up. As opposed to a dozen different app-specific ones that we have today.
Yes, it's a great idea in principle -- and would be even better if its location were configurable, per the XDG spec.
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.
This is a symptom of a bigger problem, which is that programmer respect for resources that belong to the user is at an all-time low.
* 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.
Slight tangent, but I wish there was a standardized way to tell running processes to re-read their dotfiles.
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.
From a user standpoint, a lot of of unrecognizable things show up if you pass that -l flag.
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.
That's my point exactly. Most of these programs have command line flags you can pass to indicate the configuration file that should be used. Doing that, and then by default putting my configuration in the most reasonable place for it--a dotfile-- is, in my opinion, the most respectful way a programmer can treat someone's 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.
you could check if ~/.local/share and ~/.config exist. also there is a difference between files that the user is supposed to interact with and inner configuration of random apps. ~/.ssh is fine, I need to look at it for many .emacs.d is fine as is something you are expected to edit manually, but I don't even know what some of these are:
.aspell.en.prepl .dmrc .dropbox .dropbox-dist .gtkrc-2.0 .joe_state .oracle_jre_usage .pdfsam .pylint.d snap .texlive2016 .wget-hsts .vscode .xdvirc
This is from a fresh install 3 months ago, do I need 2 dot-folders for dropbox?
I’ve been using Linux long enough that things moving to the freedesktop specification disrupts my expectations. Plus, it’s not obvious that having to traverse the extra directory is worth it: it’s nice to be able to do vim ~/.prog<tab> and save a couple keystrokes when editing commonly edited config files.
Plus, the backwards compatibility issues of changing standardized pathnames has a pretty high cost in terms of updating existing shell scripts and such.
node_modules and yarn.lock etc. in the location where the tool was run is a feature, not a bug. Ask any python user digging to find where pip decided to drop it this time.
I was going to say, I've been actively working with nodejs for a few years and I've never had node_modules, package-lock.json and yarn.lock in my home dir, on either Linux or macOS. If you run npm/yarn commands in your home dir for some reasons, then you should expect those files there. On the less than handful of times where I ran npm in my home dir accidentally, I make sure to immediately go and delete those files.
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 most of that can be chalked up to someone simply mistakenly running those commands in the wrong directory (root of $HOME). I've never heard of a JS app just randomly storing a global node_modules or yarn.lock to the root of $HOME.
I think it makes a lot of sense to have all apps run in a sandbox or container by default. Everything is segregated and easy to monitor and track what its doing.
On my fedora ec2 created with a standard ami, docker doesn't work without sudo (didn't try to reconfigure, so it may if I hack), so that behavior is understandable, though not desirable.
The lack of useful names on the files is IMHO the most egregious issue. (OK using names that don’t start with ‘.’ is worse). I don’t ls -A my homedir as much, but what the hell are .517827.padl? Who created .android (I don’t use android and don’t develop for it) etc.
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.
> These people are arrogant shitheads and I’d like to know who they are so I can avoid their software.
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.
> Wow, this is really assuming the worst in people.
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).
A "compiler flag on a library" that leads to garbage in your home directory => bad library => developer's failure to vet and research their dependencies.
Perhaps having all parts of this chain called "shithead" is extreme but they would all have responsibility and disrespect for the user.
That's why I never use $HOME for personal files. All of my files are in the Dropbox folder or another custom folder on my work PC. It's nonstandard, so no one litters in it besides me.
I have been fighting this but I gave up: people just don't care or are somewhat opposed, even when presented with a backword compatible patch.
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 ~.
Crazy idea: what if we were to just nest a personal directory within ~?
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 `@`.
.files are very useful. I like the consistent idiom for where your "global" settings go for virtualenv, npm, tslint, flake8, git, whatever.
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."
One of the advantages, though, is per-user config for the same program, e.g. the .bash files. It's pretty common to have separate /home and / partitions too, and less common but doable to dual-boot different distros but share the same /home partition. Which is itself actually a reason to be very careful with back-compatability of dotfiles
To me, the real problem is not the dotfiles, but the regular (i.e. non-hidden) files that applications surreptitiously create in my home folder. (Which the author does mention as being particularly bad.) dotfiles in the home folder are not a new thing on Linux (e.g. .bashrc, .profile, .emacs, etc.), even if it would be better if more applications used the XDG folders. And if I don't see them when I "ls", they don't bother me.
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:
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.
>And when people complain, the devs have the gall to suggest that this is all fine.
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've only been using Linux for around 10 years as my only desk and laptop OS and this is the first I heard of XDG user dirs! This laptop runs Arch. Thanks for the heads up.
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.
It really does make CUPS, Libre Office and all the rest believe you when you say "I want to print on A4, yes A4, no not fucking Letter, A4, end of!" Obviously, substitute your paper size of choice. It probably even lends itself to some form of scripting and perhaps could be changed in reaction to events from say NetworkManager. Whatever.
My life at home is now worth living every time the wife hits print. Such a simple idea - brilliant.
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.
Default gopath was just a way to let newbies get up and running quickly; it originally required you to specify where to put it. I imagine they put it at ~/go so it would be glaringly obvious. Hopefully modules will render it all moot anyway.
They put it at ~/go because that's what every official document used as the example $GOPATH, before it had a default value, so it's largely just to minimize change from what they previously recommended.
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.
Other people's code shouldn't be in my $HOME if I didn't put it there explicitly. If it's part of the dependencies of a project, it should be either in a cache directory of that particular project, or in the cache directory of the build tool (that preferably conforms to XDG), like all sane build tools do. GOPATH is an incomplete (thus incorrect) solution to a problem that was being solved correctly and completely in other languages (like Ruby).
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.
In my comment I say that it's better than the way Go did it, and Go is switching to the Ruby style, so maybe you could add some kind of argument why it's actually not better than that in any other language?
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.
On Windows Golang defaults to install to C:\. Had no problems running it from Program Files instead. It's crazy that a new programming language cannot follow decades-old conventions!
Python did this until very recently too. Windows has a problem, because people expect to use those programs in the command line and the %PATH% has a size limit and is a bit difficult to set-up properly.
The sum of the length of all environment variables has to be below 32767 characters. That doesn't seem like a good excuse to save 14 characters by putting your program's folder in C:/ instead of C:/Program Files/
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 is doing just fine writing into C:\Program Files (x86)\Steam\steamapps from an unpriviledged process. It just gives all users full rights over that folder. (whether that's a great idea is a different question, but UAC isn't a problem if you just set your access rights correctly)
If the user never had admin priviledges then you can't install in C:\ either and the program should just install in AppData\Local (as my sibling poster correctly stated)
Steam has definitely been handling Program Files wrong for as long as Program Files has existed. It's a marvel that there isn't more historic Malware intentionally targeting Steam install paths, though it looks like that storm is brewing on the horizon as I've seen references to such malware in the process of becoming a problem.
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.
The problem there is "how lazy is VendorX"? With \Program Files\ Microsoft has a ton of top level ACLs to lock down access to the directories that everything just inherits by default. How much work does the OS need to do to allow something like "folders named `data` under \Programs\ have ACLs XData and `code` have ACLs YCode"? Does it need to watch for silly mistakes like Devs that localize `code` (`Código` for instance) or misspell it (`ocde` or `coode`)?
Also would make it easier to backup the program and its data or copy them to a new system.
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 always thought it was because that space in “Program Files” was troublesome for a lot of programs, particularly command-line ones. IIRC, older versions of MinGW for instance would simply not work at all if installed in a path containing a space, because some of their startup scripts didn’t properly quote all parts of the path.
Do you just have a /snap directory and no $HOME/snap? Normally, snap creates /snap for the binaries (shared among all users) and $HOME/snap for the per-user configuration/data files.
This is particularly weird, since click (snap's "predecessor" at Canonical/Ubuntu) was fully XDG compliant, even encouraging developers to separate data from cache etc. (unlike flatpak which just dumps everything in ~/.local/share/[...], though that is still infinitely better than using ~/snap).
I personally don't like xdg. I have bin files from pip and other stuff in ~/.local/bin.
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.
You can try. I mount .cache as tmpfs. You need at least 500mb for your browser alone.
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.
I think xdg has an issue of being obtuse when I googled it a while ago, it was very confusing, and I didn't find any real definitions. However I didn't look that hard.
XDG does indeed seem like shite, calling for such nonsense as this:
"a default equal to $HOME/.local/share should be used."
NO. Nobody should be creating HIDDEN directories and files. That's just a lazy, sneaky way of trying to hide turds from the user. Either you're storing legitimate config files that should be visible to the user but kept in a tidy location, or you're littering his storage with turds that should, likewise, be kept elsewhere.
Apple's history of polluting every visited volume is a great example. Their excuse was storing file-browser state (for example, which directories were expanded) as invisible files all over the place, even on shared network drives. Of course, this design is a failure, because the next person to visit that volume will overwrite the turds. Not to mention the arrogance of polluting everyone ELSE's system, instead of just storing all this crap as URL/state on the local machine in one directory designated for that purpose.
> unlike flatpak which just dumps everything in ~/.local/share/[...]
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
Curated configuration generally outlives data. If storage space becomes an issue, there is value in recovering storage space but config is generally small and much more important in the long term.
I have a slightly different pet peeve. I don't like applications that default to saving files to my home folder. I wish they would look for e.g. /home/user/Documents or whatever else seems appropriate and even semi-standardized given the type of file.
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.
That’s what the article talks about. How applications should use $XDG_DATA_HOME, $XDG_CONFIG_HOME and $XDG_CACHE_HOME and some defaults if they’re not set.
I can't find "official" XDG documentation of this, but the Arch Wiki describes, for instance, the XDG_DOCUMENTS_DIR and XDG_VIDEOS_DIR environment variables:
You should be able to change the default settings for these directories by changing /etc/xdg/user-dirs.defaults (system-wide) and ~/.config/user-dirs.dirs (users override)
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.
It's fair to store documents and saved games in My Documents.
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.
It's senseless to store files that don't have user-facing meaning in My Documents. I know games that use it varyingly for web caches, shader caches, binary config files, debug logs, Lua scripts, downloaded mods, and even executables. And while arguably most gamers understand what save files are, they can't be double-clicked to open them, so I don't consider them documents (Maybe this is pedantic).
All this kind of stuff is what Appdata\Roaming and Appdata\Local are supposed to be for.
I understand not backing up AppData/Local, but everything in AppData/Roaming is supposedly important enough to sync it over the network (if you use domains or another mechanism to give you the same Windows account on multiple computers). Any default policy which doesn't back up AppData/Roaming seems ill advised.
Nope, Witcher 1 saves are just really large (for some reason in addition to all the flags they also contain some locale data and such). 10GiB is actually pretty reasonable for a Witcher playthrough.
It's similar in the Witcher 2, 3 and Skyrim. The saves start small and they grow to 10MB as you progress in the game. I guess there is a lot of world state and items to hold in an RPG. Count a few hundred saves, manual or autosave and that's a lot of space.
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.
My AppData/Local is 14GB, mostly caches from Chrome, Firefox and Spotify. My AppData/Roaming is 3.3GB, mostly my emails (with my Browser's localstorage a distant second).
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
Thunderbird infamously places the local copy of IMAP mails (i.e. Effectively a cache) into Appdata\Roaming. It's the single largest directory I have there. Everything else is quite reasonable in size.
A game's exe dir is a long-lived but potentially replaceable thing, like a car. Saved games may be persisted across game versions, so you don't necessarily want them to be in the same directory. Admittedly not the best analogy, but was just observing that it's strange and incongruent to store the 2 together.
You can't do it as a runtime check. You have to compile the software with the flags to import and link to the latest windows library. The program will hard crash if run on an older version.
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.
You won't have the chance to call anything. If the executable is statistically linked to the latest API, the executable won't be able to load on older systems.
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.
You won't be able to compile with the function imported using the modern lib (because it doesn't exist on XP) but you can conditionally link it at runtime with LoadLibrary/GetProcAddress.
If IsWindows... doesn't work then you can use the VerifyVersionInfo function directly.
Why did they have to narrow it down to games? Could just go with "Saved config (and data)", so other apps could just dump small config files which can be effectively backed up.
If it's the entire game, it might be to allow kids to install the game without administrator privilege (read: parental knowledge/consent), though I agree that letting people choose would be best.
What? I'm not sure how that connects to my comment. I'm saying that some games install to "My Documents" to avoid requiring administrator privilege for users who might not have that privilege.
Windows actually has the same dotfile infestation problem these days. I mean, you still get stuff in Documents that shouldn't be there, but on top of that you get apps - often Unix ports - that believe that %USERPROFILE% (i.e. one folder above Documents) is the appropriate place for their configs and such (it's not - that should also go into AppData\Local or \Roaming as needed). And they usually use a dot-prefixed name, just because.
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.
On Windows, you could move the configs elsewhere, make a symlink to them in the old place, and mark the symlink as hidden so you don't see it in explorer. Too bad this can't work on Linux because the hidden-state is encoded in the filename.
Well, the hidden-bit on Windows is really semantically equivalent to dot-prefix on Unix, and people set up their file managers to show such files for similar reasons (I don't even use Explorer, mostly). In Win10, it's even exposed as a setting in Settings | For Developers
Compared to 15 years ago I think Explorer is much better now, it could be even called usable.
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.
For actual file management, and generally working in the terminal, I'm firmly in the "two blue panes" club, so it's Far Manager on Windows (and Midnight Commander on Linux). Far is probably the most advanced text-mode file manager in general right now.
Which is sort of an improvement from the past, where user-level config data was thrown into the actual app directory in "program files." So if you ever wanted to back-up those settings, you needed to track down every single unique location for each app.
Lots of programming languages and IDEs seem to do this. Rosegarden (the sequencer) and Steam (last time I tried anyway) both create folders right under my home folder as well. Barbarism is right.
I don't understand the whole Snap thing. Not a single snap has ever worked in any of my computers in the past 5 years (I've tried maybe 5 or 6), and they always say they'll add themselves to the system. Add where? Where are these beasts hiding?
I just «snap install pycharm» and it shows up ready for work. Never had an issue with a snap. Can’t recall where it’s stored, but that’s easy to determine with «which». This is on ubuntu 1{6,8}.04 fwiw.
Oh, I was talking about AppImage, not Snap. Sorry.
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.
If you're speaking of AppImage, what do you mean by "where are they hiding"? AppImages are quite literally exactly where you put them and nowhere else.
Probably that was appimaged, the daemon that handles some convenience things like menu integration and attempting (but usually failing) to show appimage files with icons. appimaged is entirely optional.
> And when people complain, the devs have the gall to suggest that this is all fine
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"
> 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.
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.
Well, I know that I hate them. And I know a lot of other people that hate them. And I'm pretty suspicious of 'features' that allegedly make life easier for naive users by definitely making life harder for experienced users.
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.
Damn straight. Where does the system get off trying to tell me how I should organize my stuff? Keep system stuff in a folder for system stuff and the rest of the file hierarchy is mine, because it is my goddamned computer. The original Mac got this right and no one else has since.
I have great difficulty understanding why the snap developers think the excuse “it’s hard to change!” flies.
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.
It shouldn't be hard to change unless the string "/snap" is hardcoded all over the codebase. There should be a function like "get_app_dir" or "get_install_dir" or some other config string lookup that doesn't use a static string.
Snaps sound good in principle and aren't a horrible solution when they work, but despite the tagline ('Snaps are universal Linux packages') it's not clear that they work well outside of Ubuntu: they aren't sandboxed unless Apparmor is present, and despite their touted 'universality' have a hard (and unnecessary) dependency on systemd.
At this point, Guix and Nix seem the most promising for cross-distro packages.
Yeah it is crazy when I noticed Ubuntu created a ~/snap folder that is required when anything is installed via snap. People defend placing application data/config folders in ~/ because they're old and it's always been like that, but Snap is brand new and they still neglected to follow the modern standard.
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.
I'm not surprised, I left ubuntu a decade ago because their way of doing things was causing me headaches and they did not seem to care, all that seemed to matter was bug 1 : becoming microsoft in place of microsoft.
It seems to me that distros are in the right position to nudge this in the right direction. For example, Fedora did the /usr merge, moved to systemd, wayland, etc. The great dotfile cleanup would probably work by patching all packaged software to do config files the right way, plus sending the patches upstream. Then in a few release cycles this would be more or less solved.
538 comments
[ 3.2 ms ] story [ 348 ms ] threadThen 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).
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.
As time progressed it has become easy enough folks who dont know what they are doing can use many of the distributions.
Those folks are destroying what used to be a wonderful intelligent linux community.
It is time we started doing that
Nobody is forcing you to interact with those "new users", if you don't like them, ignore them.
Frankly, if everyone had your attitude, your Linux community will be dead and gone in a few short years as time progresses, and your old users pass away.
I've been a Linux user for a long time, I and many other long time Linux users do not share this persons opinions. New Linux users, keep coming, the vast majority of us are not elitist.
Not my fault you dont run it there ;)
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.
This doesn't help with installation, obviously, but it helps with cleanup.
[0] https://en.wikipedia.org/wiki/Creator_code
[1] https://en.wikipedia.org/wiki/Type_code
In reality, I have both.
In practice, I commit go the vesion control only the dotfiles I care about. And I ignore the rest.
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.
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.
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 Fac...
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.
Isn'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.
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.
I can axe my home folder and rebuild it with `nixos-rebuild switch`, it's pretty minimal.
(just an example, not actual)
environment.etc = {
};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.
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
[0] https://fishshell.com/
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.
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...
* 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.
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.
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)
export XDG_HOME_CONFIG=$HOME/. might work for some broken programs but it would be a hack.
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. :)
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.
https://bugzilla.mozilla.org/show_bug.cgi?id=1146157
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.
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.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.”
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...
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.
"a default equal to $HOME/.local/share should be used."
NO. Nobody should be creating HIDDEN directories and files. That's just a lazy, sneaky way of trying to hide turds from the user. Either you're storing legitimate config files that should be visible to the user but kept in a tidy location, or you're littering his storage with turds that should, likewise, be kept elsewhere.
Apple's history of polluting every visited volume is a great example. Their excuse was storing file-browser state (for example, which directories were expanded) as invisible files all over the place, even on shared network drives. Of course, this design is a failure, because the next person to visit that volume will overwrite the turds. Not to mention the arrogance of polluting everyone ELSE's system, instead of just storing all this crap as URL/state on the local machine in one directory designated for that purpose.
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.
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.
Wrote https://stackoverflow.com/a/54499257/5994461
[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.
https://www.farmanager.com/screenshots.php?l=en
https://www.gpsoft.com.au/
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:
https://wiki.archlinux.org/index.php/XDG_user_directories