Live data from Hacker News

Dotfile madness

0x46.net

201–210 of 534 posts

Re: Dotfile madness

#201
post #137

Oddly I feel completely the opposite about this topic. I think dot files in your home directory are exactly the way to go. Using the XDG standard leaves you with whatever the distro decides is the correct location for these files. While their recommendation is all in the home directory, I wouldn't put it past some of these distro developers to make some crazy /var/users/{uid}/config directory. This is important when…

Yeah, when I got to this: To those of you reading this: I beg you. Avoid creating files or directories of any kind in your user's $HOME directory in order to store your configuration or data. My immediate response was pretty much "where the hell else should they put them then?" What exactly else is the /home dir even for otherwise? The purpose of home is for user-level persistent files. Giving it access to something…

I had the same reaction, but by the end I think their main gripe is placing them in the root of the user's home directory.

Re: Dotfile madness

#202
All of this is a leftover from the days when *nix was a multiuser OS and used as such. It completely ignores the way we use machines now, with only one owner, and expectations of only one user. In fact, I can’t imagine loaning my work laptop to anyone, for security reasons, nor my personal laptop, because that’s just gross AND a security violation.

Computing power is so cheap now, that we don’t need to share machines when working in the cloud, either. We can, and do, log into our own VMs, work on data and software and commit back to an intermediary before final merge into a shared repository.

Perhaps it’s time to return to some version of single user OSes and clean up the relics left behind by no-loner-needed multiuser environments.

Re: Dotfile madness

#203
post #176
post #2

This isn't just a Linux problem. In Windows, the users /documents folder is polluted in exactly the same way these days.

Respectful Windows apps should drop their leftovers under %UserProfile%\Application Data or %UserProfile%\Local Settings\Application Data .

This x1000 but even Microsoft products are creating dotfiles in the users profile directory now and not in AppData where they should be.

Re: Dotfile madness

#204
post #137

Oddly I feel completely the opposite about this topic. I think dot files in your home directory are exactly the way to go. Using the XDG standard leaves you with whatever the distro decides is the correct location for these files. While their recommendation is all in the home directory, I wouldn't put it past some of these distro developers to make some crazy /var/users/{uid}/config directory. This is important when…

Yeah, when I got to this: To those of you reading this: I beg you. Avoid creating files or directories of any kind in your user's $HOME directory in order to store your configuration or data. My immediate response was pretty much "where the hell else should they put them then?" What exactly else is the /home dir even for otherwise? The purpose of home is for user-level persistent files. Giving it access to something…

> My immediate response was pretty much "where the hell else should they put them then?"

He didn't mean to avoid $HOME as a whole. Just the root of the $HOME directory.

I too much prefer having programs write their config files to $HOME/.config/program-name instead of $HOME because it's less clutter and now I can think "ok, $HOME/.config is where all of my app's configuration is", instead of having a bunch of files littered in $HOME while other apps use $HOME/.config/file_name or $HOME/.app_name.

It bothers me that .pypirc exists in $HOME, rubygems credentials are in $HOME/.gem/credentials and Docker's credentials are in $HOME/.docker/config.json. That's 3 different location styles for an app's config file. They should all be in $HOME/.config/$app_name/relevant_file_name for whatever the config is for.

Re: Dotfile madness

#205

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”.

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.

Re: Dotfile madness

#206
post #173

I have the opposite perspective. Dotfiles are fine, and I find the proliferation of XDG directories confusing, mostly because they're misused. Why should a game's save files be under .config? Making dotfiles under $HOME is a simple approach that's worked for a long time and that doesn't cause serious problems, and I see no need to adopt the XDG approach, which I see as overengineered.

> I find the proliferation of XDG directories confusing, mostly because they're misused. Why should a game's save files be under .config? A game's save should be $XDG_DATA_HOME, misuse is exactly that, misuse. I have hundreds of games installed on my linux machine and not a single one has put it's save files into my $XDG_CONFIG_HOME folder. On the other hand many DO outright ignore XDG and dump all their garbage into…

The XDG approach is over-engineered: it adds complexity and provides no benefit. What is the specific concrete advantage of putting some parts of foo's state in ~/.config/foo, some in ~/.local, and so on? All this approach does is scatter what's conceptually a single state blob across different parts of the filesystem. I dealt with this stuff in Windows for years, and we don't need it in the Unix world.

The conventional dotfile approach is just fine: there's an application and it puts state under a directory named after itself.

Re: Dotfile madness

#207
post #16

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 w…

cmake, conky, dlv, electron, electrum, gnome, gnutls, gradle, idea, ipfs, kde, maven, npm, ohmyzsh, sonar, steam, thunderbird, veracrypt, vim, visualvm, vscode, yarn.

and now the most fun:

bash, zsh, git, gtk, man, wget, xorg

Re: Dotfile madness

#208

Earlier quoted context omitted.

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.

There is literally a folder in every Windows profile (Vista onwards) called "Saved Games", it should all go there.

^ 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.

Re: Dotfile madness

#209
So, what's gonna happen on Wayland when these X-variables aren't defined? Am I going to lose config and have to copy directories from XDG to .config/ because that's new default?

Re: Dotfile madness

#210

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”.

Not a exact solution you are looking for, but a hack solutons:

   dpkg -S .foo
   apt-file search .foo
   rpm -qf /foo/bar
Post reply on HN