Live data from Hacker News

Dotfile madness

0x46.net

51–60 of 534 posts

Re: Dotfile madness

#51
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…

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.

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

Re: Dotfile madness

#52

Earlier quoted context omitted.

Not everyone has a large $HOME directory. It might be mounted on a 128mb thumbdrive for all you know.

Even better; it means that your preferences will be literally portable.

Yep, until your program crashes because you weren't expecting a 10b file to run out of disk space.

Re: Dotfile madness

#54

On the one hand this is annoying, on the other it’s great that you can just backup your home dir and have all your files and settings in one go. 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.

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.

Re: Dotfile madness

#55
post #7
post #2

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

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.

Plus if you try to rename a dotfile through explorer, it won't let you

Then if you try to make a dotfile through powershell, it has a different text encoding than *nix, which some programs (git) rely on

Re: Dotfile madness

#56
post #21

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?

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.

Re: Dotfile madness

#57
post #21

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?

It is useful to have hidden files shown by default (.gitignore, .config, etc). And not everyone uses GUI file managers all day.

Home directory is the default directory for terminal emulators, and having it polluted to me feels like sitting in a dirty room.

Re: Dotfile madness

#58
post #46

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.

Was thinking about that when tinkering with docker: why are volumes created outside the user's home directory by default ?

Re: Dotfile madness

#59
post #14

Earlier quoted context omitted.

That is the exact problem that the standard I talk about was designed to solve (apart from the clutter in the home directory).

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.

The classic MacOS had exactly this concept: Creator Code[0], similar to the Type Code[1] but storing a file's creator rather than its "mimetype".

[0] https://en.wikipedia.org/wiki/Creator_code

[1] https://en.wikipedia.org/wiki/Type_code

Re: Dotfile madness

#60

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

A general tagging mechanism, reasonably supported across filesystems, would be great to have. Not only for media collections.

It's not easy to implement nicely, though.

Post reply on HN