Hacker News Reader

Comment by adhoc_slime | Hacker News Reader

Hah I was literally just complaining about applications not following the XDG directory spec today.

there's a non-exhaustive list of applications on the archwiki [0] that put their config/data in dotfiles in the home directory. surprisingly, there's also lots of pushback from maintainers of projects who don't want to change this, for whatever excuse they can produce. a Reddit thread has some list of issues where the change is brought up [1].

Anyway, I'll look forward to testing this out.

[0] https://wiki.archlinux.org/title/XDG_Base_Directory

[1] https://www.reddit.com/r/linux/comments/971m0z/im_tired_of_f...

View on HN

The dotfiles and dotfolders directly in the home folder is "the way it was always done", and now some "new kids" came and want changes done to software which has existed before they were even born. People have muscle memory for those folders, some have hardcoded those paths in other scripts, others just don't care, and things stay as they always were.

On one hand, it's great to have all the stuff in the same place, on the other hand, we used to have this, before the ~/.config folder too.

Also, it's not just in one place anymore, but in many places -- so to completely remove a programX, it's not enough to just remove ~/.programX, but you need to remove a folder from ~/.config/, and another one from ~/.local/something, and another form ~/.cache,...

So yeah, i understand 'the old guys' too... maybe because i'm not 20-something anymore.

The XDG base directory specification[0] was initially introduced in 2003; 20 years ago now. Yes there's plenty of software that existed before 2003 which didn't respect XDG, but most all of the Linux software dumping dotfiles in my homedir where written not just after 2003, but many years after 2003. For example, the following pieces of software all have dumped garbage in my homedir, and all are much less than 20 years (or even 15 years) old:

    vault
    flyctl
    yarn
    npm
    vscode
    terraform
    rustup
    kubernetes
    fzf
    eclipse
    docker
    cargo
    aws (cli)

There's no excuses for these programs not respecting standards that are 1. Well established by the time the software was written and 2. short (seriously, the standard's contents fit entirely on three A4 pieces of paper)

[0] - https://specifications.freedesktop.org/basedir-spec/basedir-...

But why should developers conform to that specific standard, if (for them, and many of their users) it makes more sense to use a "~/.wine" (or whatever other) folder?

If i want to completely remove wine from my profile, how many folders do I have to delete doing it the old way? One - ~/.wine. How many using the new? One in .config, then .local/share, probably one in .cache... oh wait, .local/state too.. Probably.. well, maybe, I'd have to check manually. Same for other software. One folder to remove, one folder to backup, one folder to restore.

Following the standard does not require you don't have a single folder, it can all be changed with 4 simple environment variables. If you want to have everything dumped horrendously in your home folder nothing is saying you can't, it just wouldn't be the default, because it's simply not an orderly way to organize the files.

The biggest problem is programs that don't even let you change where they store the stuff, so even if you're okay with the default not being XDG you dont even have the option to make it respect XDG base directory specification.

Whenever I install directly instead of using e.g. apt (typically because I want a more current version than the distro has), I use GNU stow [0], for precisely this reason. It works at the system level, at the user level, within projects, wherever. A simple "stow -D" is all it takes to clean out all the directories.

[0] https://www.gnu.org/software/stow/

If, as you say

> most all of the Linux software dumping dotfiles in my homedir

then is it really true, that the standard is in fact "well established"?

Right now I have in my home folder 4 undesirable dot something which should be somewhere else and I can't change it. Meanwhile, I have 63 folders in my .config which means most of the applications I'm using do respect the XDG base directory specification, only a few entitled or extremely legacy ones don't.

Out of curiosity, what are the misbehaving ones?

.mozilla - Firefox
.npm - NPM
.pki - Chromium-based software
.SpaceVim.d - My fault, I should write my own vimrc but I'm lazy
.steam and .steampath and .steampid - Steam
.vscode-oss - VS Codium

.w3m - w3m cli browser

These are the ones I couldn't change the behavior of, in my dotfiles I've managed to fix at least a dozen of programs that were previously misbehaving but offered environment variables to change their behaviors.

The thing that bothers me most about these is that most of these folders are simply cache and logs, I can always delete them and the application will keep working, but of course the folders will be recreated. It's truly mind-numbing.

Firefox

  # Save shell wrapper as '~/.local/bin/firefox'

  { while kill -0 $$ 2> /dev/null; do rm -rf $HOME/.mozilla; done; } &
  /bin/firefox --profile $XDG_DATA_HOME/firefox $@

NPM

  # set env variable
  export NPM_CONFIG_USERCONFIG=$XDG_CONFIG_HOME/npm/npmrc

  # and in npmrc:
  prefix=${XDG_DATA_HOME}/npm
  cache=${XDG_CACHE_HOME}/npm
  tmp=${XDG_RUNTIME_DIR}/npm
  init-module=${XDG_CONFIG_HOME}/npm/config/npm-init.js

Steam

  Steam actually creates only symlinks for backward
  compatibility as some games (may) expect them in $HOME.
  You can safely launch it with modified HOME variable:
    $ HOME="$XDG_DATA_HOME/Steam" steam
  (and/or put it into a wrapper script like with Firefox)

Vim

  I don't know how it's with SpaceVim,
  but with regular vimrc you can make it follow the spec:
    https://blog.joren.ga/vim-xdg

w3m

  export W3M_DIR="$XDG_DATA_HOME/w3m"

What the hell you may have just changed my life. The NPM one I was aware of through xdg-ninja but last time I tried it didn't work because I also use nvm which doesn't support that, honestly not an issue with NPM, I should've noted in the comment. The Steam one however is a total life-changer, if I ever find you in the street someday remember me I owe you a beer (or some non-alcoholic beverage of your preference).

If only.

There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME.

There is a single base directory relative to which user-specific configuration files should be written. This directory is defined by the environment variable $XDG_CONFIG_HOME.

Neither of those environment variables is defined on a stock Ubuntu 22.04.1 LTS.

$XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.
$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

$XDG_STATE_HOME defines the base directory relative to which user-specific state files should be stored. If $XDG_STATE_HOME is either not set or empty, a default equal to $HOME/.local/state should be used.

https://specifications.freedesktop.org/basedir-spec/basedir-...

I like this system overall, but this particular aspect seems like a mistake [0] to me. Instead of a simple rule like "use these envars", it has this more complicated logic that must be replicated in all apps supported by all developers. Users would have more agency if they could inform apps of their preferences by simply setting some envars. [1] If this simpler, more user-friendly regime had been in the spec, we would have seen better adoption initially and also two decades later.

[0] of course one shouldn't assume that a totalitarian decision is a mistake, because it's just as likely that the decision-maker has priorities other than "support users"

[1] yes of course users have agency with respect to where XDG is implemented, but the simpler rule would also have given them agency with respect to whether it is implemented

And the variables should not be set if the user/distro wants the default (probably to force developers to handle the default case which is needed for compatibility anyway).

Sure, XDG was introduced in 2003, but why would you expect developers to start to follow its rules instantly? At best, it started to gain some traction 4 or 5 years after that, but still today, it is far from universally accepted.

But take a step further back: why should anyone care about what the XDG says in first place? This isn't a dictatorship, and things were doing just fine long before a handful of people who wrote the XDG thought their ideas were the best approach.

It's been my observation that good standards can be adopted broadly and quickly with little controversy or need for advocacy. The fact that the XDG file layout still isn't universally used suggests it doesn't have as much value as its proponents think.

> But take a step further back: why should anyone care about what the XDG says in first place?

Because their users are asking them to not pollute the home directory? This isn't bikeshedding config locations without reason, there is a clear motivation for letting users a) specify where data should go and b) separate different types of data.

> It's been my observation that good standards can be adopted broadly and quickly with little controversy or need for advocacy.

The XDG basedir spec has been adopted broadly amongs many organizations and individual devlopers including all major desktop environments. It is not adopted universally yet, but few things are.

> There's no excuses for these programs not respecting standards that are 1. Well established by the time the software was written and 2. short

This isn't a standard, it's a convention at best. A freedesktop.org specification. Basically a scheme Red Hat people thought up and implemented widely in the open source software projects they control. It may be a useful abstraction but there's absolutely no obligation to conform to it. There doesn't have to be an "excuse" or any form of justification at all. "I just don't like it" is enough. I don't like those unsightly XDG variables either and it's entirely within my power as a software developer to trash the entire concept of XDG and do things in any way I see fit.

https://www.freedesktop.org/wiki/Specifications/

> freedesktop.org produces specifications for interoperability, but we are not an official standards body.

> There is no requirement for projects to implement all of these specifications, nor certification.

This is the world of Unix, there's very little obligation to do anything other than convention. That's technically true, just like you can write your software to ignore all signals, or write your software such that it assumes it's always run as root for your convenience. That may be more convenient for you the developer, it's true.

But those are all generally poor ways to write software, and a great way to get your users to complain. So it is with ignoring XDG.

To put configs in ~/.program is the convention I learned, not ~/.config/. That came later, and I see 0 reason to pick it up. It's an annoying new hierarchy which I don't even like as a user, so I certainly wouldn't follow it as a developer.

If the programs in question implement the XDG base directory spec properly, then putting `export XDG_CONFIG_HOME=$HOME/.program` in your .profile will make them put config files in .program, not .config.

Charming idea :) I'm not actually that annoyed that I will set XDG_CONFIG_HOME to $HOME, but I'll keep it in mind.

> This isn't a standard, it's a convention at best.

So is, like, basically all of userland in a UNIX system. Maybe we need to start looking at that as a problem instead of an excuse.

It is within your power as a developer to delete the user's home directory if you want to as well, that doesn't mean you should do it!

The really fun part is when you have a program that has ~/.programX, but also ~/.programXy, ~/.programX_cache, ~/.programxrc, ~/.programx_init, ~/.programx/a_whole_directory, ~/.otherthing, ~/.maybe_a_database_for_good_measure.sqlite, ~/.and_the_kitchen_sink_too. And that's not even getting into questions like "can I nuke ~/.programX_db to clear the program's cache without losing my configurations?". I agree that the XDG spec isn't an improvement for programs that have _precisely_ one config file, but it's a _major_ improvement for programs that need multiple config files, config directories, separate configs and caches, and more, and it's not a _regression_ from single-file configs.

That's why that kind of software uses a .programX directory, where everything like that can be put in.

Look at ~/.wine for example... config files, whole C drive, everything in one simple folder. Want to upgrade to an alpha version to test something, but don't want to break anything that's now working? Just backup that one single folder. Restore or migrate configuration to another computer? One single folder. Remove any trace of that app? Again, one simple folder.

Want to do the same with google chrome? .config/google-chrome... oh wait, what if there's something in .local too? Still doesn't work? Oh wait, you forgot the .cache directory, and have been loading an old version of something.

If you have a mass of cached data that shouldn't be backed up would you rather just exclude .cache or investigate what files/directories every individual app uses.

> Look at ~/.wine for example... config files, whole C drive, everything in one simple folder

Except it isn't really. Just a few days ago I tried to purge Wine from my system. Uninstalled through pacman, cleaned up orphaned dependencies. Killed the ./wine folder and various other leftovers too, because depite your claim, there they were, though I didn't commit to memory exactly where and what. Removed some autostart shortcuts, cleared a few icons from desktop, and manually edited the Plasma menu to remove some stubborn links.

And yet ... I still get suggestions to open my jpg's and png's with something called Wine Internet Explorer. Which i don't really believe is distro specific, since I've seen the same thing happen in both Debian and RedHat derivatives.

This is probably because Wine created a .desktop file in the directory for registering default applications. I don't remember what the directory path is but your package manager is responsible for it, not Wine. They can't put it in .wine because it's a standardised location.

Just FYI, in case it is useful for you: Here's the information that you would want for cleaning that up.

https://wiki.winehq.org/FAQ#How_do_I_clean_the_Open_With_Lis...

If you ever want to prevent this integration from happening in the first place, you can do it by editing the registry in a given wine prefix. You can run regedit with the usual command, `wine regedit`, then locate the key:

HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices\winemenubuilder

Set it to empty to disable the integration entirely. Or, just remove the `-a` switch and you will still get desktop icons, just not file associations.

It is unfortunate that it has to be outside of the WINEPREFIX, but there's no way around it, since those various files need to be in their respective locations to reasonably be picked up. (Maybe it could use symlinks instead, but even if it did, they'd need to get cleaned up by something when the target gets deleted.)

> It is unfortunate that it has to be outside of the WINEPREFIX, but there's no way around it

There is a way around unwanted and unexpected associations though: make the integration opt-in instead of opt-out and/or filter associations that the user is unlikely to ever want (like standard file types that will almost certainly already be handled outside Wine). Wine's Internet Explorer is there for compatibilty with Windows programs that expect IE, exposing it outside the Wine environment does not make any sense.

Since I use multiple prefixes, including temporary ones, editing registry in each one of them is not an option so I have my package manager set not to install winemenubuilder at all.

I believe another approach is to edit the default registry settings in /usr/share/wine/wine.inf so that new prefixes have the desired setting. Of course, then when updating the package it has to be reconciled. But it does have the advantage of being able to allow e.g. the settings that would only produce launcher icons and not file associations. There's another method using environment variables too, though I think that one basically works the same as removing the package entirely and can't be used to customize the behavior.

I kind of agree with you that the defaults are not great, or at least if things haven't changed. We could always see if maybe they'll accept patches to filter out more stuff by default.

IMO, Wine desktop integration should be off by default.

Like with privacy issues, once you realize you want to opt out the mess has already been made.

> Just backup that one single folder.

Backups are the main reason why I want programs to follow the XDG Base Directory Specification. I don't want my backups to includes gigabytes of files that should be in ~/.cache, which is a directory I never back up. The shell script that I wrote to back up my PC includes dozens of rsync exclusions for files in ~/.mozilla, etc. that should be in ~/.cache.

> That's why that kind of software uses a .programX directory, where everything like that can be put in.

You mean, this is why that kind of software should use a .programX directory. Evidently many don't. And of you think about doing it, just move it into .config for good measure...

Crap like wget just keeps shoving files directly into my home instead. When they added hsts support they had the chance to finally create a directory, ideally in .config, so if they need to add even more files in the future they wouldn't have to clutter $HOME even more. But no, that would be too forward-thinking. Just put the hsts file in home and be done.

> some have hardcoded those paths in other scripts

My sympathy is lacking, as is my respect for those running projects that hardcode paths. Stop hardcoding paths and the world will be a better place.

eg. ~./bashrc has existed there for 30+ years, changing stuff just because someone doesn't like seeing a file in a folder is imho stupid.

A hidden file, even. Stop using "ls -A" and you'll be fine.

To be pedantic, if we're going to cite Unix history, then technically there is no such thing as a "hidden" file. As I understand, the original implementation of tools like ls would not show the current directory "." in the listing. The quickest way of doing this in C was checking whether dentry.name[0] == '.'

This also had the side effect of hiding entries that had names beginning with ".", and over time an implementation bug/quirk became accepted behaviour, and was post-hoc rationalised as "hidden" files.

Who cares how the feature of hidden files came to be, when it has been what it is now for so many years?

As a defence of hardcoded paths might go, I could've done better myself. What else from your OS 30 years ago might you keep just because it's 30+ years old?

I keep it because it's worked for 30 years without issues and it's still working. Must you always replace something, just because a newer thing is "out there"? On the other hand, this is hackernews, and rewriting everything, from a text editor to a file browser, into a <language of the week> (ruby, go, rust,...) is a thing.

Try moving all of those directories and files somewhere else that you would prefer and then see which programs break, which apps and libraries won't install, and then wonder why hardcoding is something the devs for these projects cling to.

Or perhaps Bash for 30 years was using a sub-optimal solution and now when a better approach has emerged it just stubbornly refuses to adapt?

I'd say bashrc and profile and friends are one of the few examples in which using hardcoded paths is OK. Same with SSH, GPG, and PAM.

But when people are talking about compliance, and hardcoding very few people are talking about those applications - there are hundreds of other applications do the wrong thing, and some scripts hardcode things as a result.

No, but don't keep doing it that way for new software, or even new files. You existing config file is in ~ because it's 30 years old. Fine.

If you get to the point where you need another file for something, put it in a directory under .config so whenever you need to add even more, you don't keep cluttering my home.

Home is where the .bashrc is <3

> Also, it's not just in one place anymore, but in many places -- so to completely remove a programX, it's not enough to just remove ~/.programX, but you need to remove a folder from ~/.config/, and another one from ~/.local/something, and another form ~/.cache,...

OTOH if you want to completely remove your cache, or completely backup your config...

I don't see the problem. There's no reason to choose one or the other when we can have both. Many programs try several options. Git for example tries ~/.gitconfig and ~/.config/git/config.

Do people seriously resist such non-destructive improvements just because they think it's offensive when younger programmers have opinions on legacy software?

Personally I see a lot of young people use emacs and BSD licences, but because I'm an older engineer and have the wisdom and experience of time, I use vim and GPL.

I honestly can't imagine not using vim. It fits like a glove. Sometimes I find myself typing <Esc>;wq to try and send messages.

Another man with the wisdom of ages, irrespective of the date of your birth. Your choice of text editor reveals that you must also be quite good looking.

Exactly, except for a minor typo. :s/vim/nvim.

What age are those who use nano?

/hides

hi!

I'm also a Vim user; in my Vim wisdom and experience I made it follow the damn XDG spec; if hidden files are a feature, I want it to be a feature for my use-cases, not program clutter.

I use nvim like the user (backers.md baby!) so I get to use `master` with `~/.config/nvim/init.vim`. Of course, I also donated to Bram's Ugandas or wherever, so I think you are a wise and attractive person. Your choice of actions reveals that your soul is deep and beautiful.

> now some "new kids" came and want changes

I realize that you wrote "new kids" in quotes, but these "new kids" might have grandchildren at this point given that the initial draft of the XDG Base Directory Specification was published in 2002.

If we want to flex gray hairs, the idea that an application should put it's configuration files in dotfiles cluttering the home directory is regarded as a mistake by the people who are responsible for it.

https://web.archive.org/web/20180827160401/https://plus.goog...

Obviously, we are now stuck with dotfiles as a "feature", but that doesn't mean we need to have more of them than necessary. Cluttering the home folder with a disorganized mess of files with different modalities next to eachother is ridiculous, pointless, and a collective waste of time.

Almost all of the apps people are complaining about not following XDG were created long after the XDG base directory specification existed. It's time to move on.

P.S.: it'd be preferable also if it wasn't simply implied that everyone who's been around Linux/UNIX for a couple decades hates change. Churn for the sake of churn is bad, but churn is not all wasted. Standardizing once-disorganized directory hierarchy is certainly not a waste of time.

Considering the spec is 20 years old, having "muscle memory" is a bit of a weak excuse at this point.

Having a couple of directories to clean up is a bit annoying, but they used to stick the config file in your home and then make an application directory so we were already having to deal with multiple locations.

That's usually not a problem though.

The software can look at $XDG_WHATEVER/tool/config first and ~/.toolrc second. Everyone who wants the clutter can keep using that.

Can I also soapbox about the XDG_CONFIG_HOME (~/.config) folder having gigs of temp data in it?

(I'm looking at you, Slack!)

How awesome would it be to be able to back up my custom app configs just by copying around one tiny folder? Or throwing it in a git repo and knowing what config changed when? :\

    $ du -sch ~/.config/Slack
    846M $HOME/.config/Slack
    846M total

... this is on a two day old machine. WTF, Slack? Junk cached data belongs in ~/.local/share ($XDG_DATA_HOME), not ~/.config.

I think you mean `~/.cache`.

a bunch of windows stuff does this too putting config in appdata/local and huge cache assets in appdata/roaming. anything that depends on good behaviour is doomed imo like Google wave circles

What’s really frustrating are the number of first-party Microsoft products which do this.

Yeah. It annoys me to no end that the new powershell didn't take the opportunity to move the config out of My Documents and into roaming app data which in theory is where that sort of file should be.

It's things like that which have made me give up on %USERPROFILE% (and to a lesser extent $HOME), and I now put my files that I care about into a completely separate folder outside of the normal hierarchy.

Could you elaborate on that? I too am quite unhappy with the mess my %USERPROFILE% has become.

Oh, it's really not anything impressive. I've just decided to treat %USERPROFILE% as for machine generated files only. I then have a new directory on C: where I put my documents/projects/etc (all in appropriate sub folders).

My config files are a bit more interesting, and are stored in a chezmoi[^1] repo. If I tinker with a program enough, I generally move its config into there so I can keep track of it and the changes (to make this easier I have a bat file in shell:sendto to add files/folders to chezmoi).

Thinking about this, I should probably move the chezmoi repo into my personal directory, and symlink it back to it's normal location.

[1]: https://www.chezmoi.io/

Should've kept Slack in a containered in a browser tab where it belongs so it can't go messing with your system or prevent you from blocking their tracking.

And then I've seen websites hoggi g gigs of local storage after you visit them once a blue moon. The trend is blatantly towards no optimization whatsoever. Apart from profits and squeezing the last drop off your customers by any means necessary

The fault lies with Electron [0]. Open issue since 2016 to fix this behavior only for it to devolve into a morass of, “What is cache?”

[0] https://github.com/electron/electron/issues/8124

One of the best things about no longer using macOS is not having to fight 'but Application Support/Resources/Nonsense/Foobar.app/Resources/config is the standard location on this platform!' ... The XDG base dir spec makes a lot more sense even on macOS for developer tools, but I'm glad not to have to worry about that any more.

On Linux that excuse is gone, so it's just either 'oops yes will fix' or 'agh, sorry, legacy'. Nobody (that I've ever seen) tries to claim something else is fine or better.

Some of these programs also spam the home folder on Windows instead of using the path specified in the %APPDATA% environment variable.

Some also put it in %HOMEPATH%/.name because they are bad ports from Unix. I'd argue that it's better than in My Documents though.

Yep, this does my head in. I really feel like there's no excuse for it in 2023.

I mean, from the perspective of a person that hasn't heard about it before, this is just another standard[0].

I opened your links. There's no easy way to judge the traction or popularity of this. Why do you think maintainers should just apply another standard that's thrown at them?

I don't mean to be dismissive nor criticize the standard itself. I'm trying to give you a glimpse of what a person that hasn't heard about XDG before sees, when they open your links.

[0]: https://xkcd.com/927/

What are the competing standards to XDG? Stick everything in $HOME? Stick everything in $HOME/.config?

Those 2 aren't standards and aren't helpful.

Yes, sticking everything into `$HOME/.toolname` is what most cross-platform software is doing, and I imagine that's just fine for the vast majority of users.

Short, memorable passwords like one's birthday or favourite pet's name are "just fine for the vast majority of users". It's a meaningless metric of quality - or more to the point - it isn't a metric of quality.

Weak passwords have securities downside.

I struggle to see what the issue is with ~/.programName ?

Your lack of imagination is not a compelling argument.

First and foremost, that I don't get to decide where things go on my own machine, and that if I do regardless, because developers didn't follow a simple standard and instead decided to hardcode things that shouldn't be hardcoded - which is just about the first thing every dev is taught not to do - things will break.

You may not find it important but is it an issue or not?

1. It doesn't separate program's config, data, and cache; so it is impossible to backup excluding cache, impossible to reset your config without data-loss.

2. It assumes home is infinite, if you are running out of space in home you can't move program files to other partitions. E.G. Flatpack hardcodes its apps data in `~/.var` so if you have a small/almost-full home partition you simply can't install certain Flatpacks.

Except it isn't most cross-plaform software doing that. It might be most of the cross-platform software you use but IME it's mostly it's corporate software plus a few holdouts too stubborn to add two lines to the code reading their config file.

> surprisingly, there's also lots of pushback from maintainers of projects who don't want to change this, for whatever excuse they can produce.

There doesn't need to be an "excuse" though. "I don't like it" or "I don't want to do it" is more than enough. They're the ones maintaining the damn things, the least we can do is respect them. They don't really need to justify anything, acting as if they had to is how you get pushback. They probably deny you just to prove that you have no power over them, because you insinuated otherwise with words like "excuse".

> They're the ones maintaining the damn things, the least we can do is respect them.

we don't respect maintainers who leave in buffer overruns or x-site scripting, why should we respect maintainers who don't respect users? yes, they're writing and maintaining, but undoubtedly also using tons of respectful opensource that other maintainers take care of.

it's like driving a car ("everybody faster than me is a maniac, everybody slower than me is a moron") and cursing cyclists, then jumping on your bike and running red lights, stop signs, crosswalks, sidewalks, you name it. To have a civilized society we all have to go out of our way a little bit for other people, throw away some trash that's not yours.

like forum/reddit moderator phenomenon, there is something about the power (and most definitely the nagging they get from impolite users) that makes the developers act like douches when they probably aren't the rest of the time.

but that's not an excuse for crapping all over my dotfiles and home directory tree.

> why should we respect maintainers who don't respect users?

Saying that using dotfiles instead of ~/.config means they "don't respect users" is a little dramatic, don't you think? Like it or not, unix has historically treated dotfiles as "hidden" and nobody expects you to get upset that they created a hidden file in your home directory without your consent. It's not really about respect, it's just convention you apparently don't like.

I currently have 60 dotfiles in my home directory and probably deliberately created less than 10 of those. The fact that anyone would be upset by this is news to me and most likely is news to a lot of the developers that created these things: cargo, dbus, docker, gem, gnome, gnupg, gphoto, java, kde, maven, mozilla, osquery, rpm, rustup, ssh, vagrant, vim, vscode, wget, yarn, zoom. Not that "this bad behavior is widespread" is a good excuse, but the point is that I don't think the world is at all in agreement that this is "bad behavior."

Just to clarify, it is not just about "hidden" files looking good. There are many reasons one may want to move config/data/cache files to other locations, E.G. in my case I have a computer with home on a small partition that simply can't fit all the crap those misbehaving programs try to put there. I simply can't install Flatpacks on that machine because they obviously won't fit in a small home and can't be moved because of a maintainer who is very disrespectful to users (the bugs full with messages of users pleading for him to allow them to move apps to other partitions is disheartening).

> Saying that using dotfiles instead of ~/.config means they "don't respect users" is a little dramatic, don't you think?

No I don't think so. For many applications (i.e. only config, no cache) it's literally an additional getenv and minimal logic when opening your config files. No additional dependencies needed. The amount of effort required is tiny compared to the benefit multiplied by the number of users that don't want dotfiles in their $HOME.

> we don't respect maintainers who leave in buffer overruns or x-site scripting, why should we respect maintainers who don't respect users?

Because they're the ones putting in the work. I could patch all the programs to use whatever paths I liked best if I really cared but the truth is I don't want to put in that much effort. So I just work with what I'm given instead.

Besides, dotfiles conventions are not even in the same category of technical decision as literal vulnerabilities. One puts people at actual risk, the other is just opinion on file system taxonomy.

I mean, I have opinions on proper file system organization too and they certainly don't match Unix "tradition" but I don't go to other people's issue trackers and shame other developers when they make "excuses" for not following whatever scheme I thought up. I have reasons and I can certainly try to convince others that I'm right but it's simply offensive to show up out of nowhere with an indignant tone demanding that others make changes of a subjective and frankly trivial nature and then criticizing them in other forums when they refuse.

Reply on news.ycombinator.com