Dotfile madness • Hacker News Board

Re: Dotfile madness

#231

Post by rovr138 » Sat, Feb 02, 2019, 9:17 PM UTC

georgeecollins wrote: post #107

sandov wrote: post #90

Earlier quoted context omitted.

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.

Multiple users too. Where would you store all that if not inside the user directory. But Saved Games is definitely a better location.

Re: Dotfile madness

#232

Post by ljm » Sat, Feb 02, 2019, 9:18 PM UTC

nycticorax wrote: post #119

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

This strongly reminds me of installing software on Windows, where most games and programs would use My Documents as a dumping ground.

Re: Dotfile madness

#233

Post by user5994461 » Sat, Feb 02, 2019, 9:26 PM UTC

ljm wrote: post #232

nycticorax wrote: post #119

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

This strongly reminds me of installing software on Windows, where most games and programs would use My Documents as a dumping ground.

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.

Re: Dotfile madness

#234

Post by pseudalopex » Sat, Feb 02, 2019, 9:29 PM UTC

quotemstr wrote: post #206

yesco wrote: post #173

Earlier quoted context omitted.

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

XDG just extends the traditional Unix approach to home directories.

$XDG_CONFIG_HOME is equivalent to /etc. It has small files you probably want to back up.

$XDG_DATA_HOME is equivalent to /var. It has potentially large files you might want to back up.

$XDG_CACHE_HOME is equivalent to /var/cache. It has potentially large files you probably don't want to back up. You can delete them if you need space.

Re: Dotfile madness

#235

Post by diegoperini » Sat, Feb 02, 2019, 9:29 PM UTC

johnchristopher wrote: post #227

diegoperini wrote: post #214

Earlier quoted context omitted.

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.

Did you add your user to the docker group ?

Nope, just installed and started to use.

Re: Dotfile madness

#236

Post by kevinpet » Sat, Feb 02, 2019, 9:31 PM UTC

To me, there's a big difference between:

If you want to override the defaults of this command line program, create a .programrc file in your home directory.

and

Thanks for trying out this program, I'll just create a whole directory structure of config files and caches in your home directory.

Re: Dotfile madness

#237

Post by chatterbeak » Sat, Feb 02, 2019, 9:31 PM UTC

I like the way Windows does it with the AppData folders

Re: Dotfile madness

#238

Post by miguelmota » Sat, Feb 02, 2019, 9:31 PM UTC

What's the equivalent of $XDG_CONFIG_DIRS for macOS and Windows?

Re: Dotfile madness

#239

Post by ecnahc515 » Sat, Feb 02, 2019, 9:34 PM UTC

weberc2 wrote: post #164

dijit wrote: post #126

Earlier quoted context omitted.

Same for the default gopath. That was horrifying the first time. At least you can override it.

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.

Re: Dotfile madness

#240

Post by ecnahc515 » Sat, Feb 02, 2019, 9:36 PM UTC

netsec_burn wrote: post #71

nine_k wrote: post #60

Earlier quoted context omitted.

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.

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.

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.