Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dotfile madness

0x46.net

Post reply on HN
Print view View original

341–350 of 534 posts

Re: Dotfile madness

#341

Post by git-pull »

quotemstr wrote: post #213
git-pull wrote: post #147

My project cihai ( http://cihai.git-pull.com/ ) and unihan-etl ( https://github.com/cihai/unihan-etl ) both use the XDG specification. The reason I like it is it provides directories to use across platforms (edit: Not sure about Windows), relative to the user. Since the applications download a file (UNIHAN database [1]) to bootstrap, we want to store it in the user's files, not the systems. The other thing I do that'…

> $HOME/.local/share Just look at that path: "$HOME": It's my home directory. Cool. ".local": It's in my home directory, but local to it, and not somewhere else? This doesn't make a lot of sense, but er, Okay. "shared": For Christ's sake, what is this? It's in my home, and local within it, but also shared ? With whom? How? Why? I give up. Why would anyone want to do this? What concrete benefit does this path give us?…

Some things XDG is trying to do that's not readily apparent:

~/.local:

It's intended to be /usr/local in the user's home directory. There's a bit of a backstory here though: Linux distros don't follow `/usr/local` as well as BSD's, not much may be there.

~/.local/share:

Same idea, for /usr/local/share. But on many linux distros, this is `/usr/share`. XDG is trying to do is mirror the system directories in the user's filespace.

Let's assume there's going to be a lot of applications: they won't agree on where cache, config, and data storage is kept at within ~/.myprogram. With XDG, if someone wants to clean out all their cache files? rm -rf ~/.cache.

The other thing is: Typically the user won't be looking at ~/.local/share/myprogram - it's for data the application itself is going to use. It doesn't really count against it. What I think we will be looking at though: configuration files. That's where I think XDG is kind of original - but it's really close to what /etc is.

As for ~/.myprogram: I'd be okay with that, if it were purely configuration. But XDG serves the article writer's purpose fine: Keeping $HOME clean. I kind of think splitting between ~/.config, ~/.local/share, and ~/.cache ends up feeling more consistent with how linux/bsd organizes files.

Re: Dotfile madness

#342

Post by jorvi »

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…

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

Re: Dotfile madness

#343

Post by int_19h »

joshvm wrote: post #172
franky47 wrote: post #34

Earlier quoted context omitted.

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.

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

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

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.

Re: Dotfile madness

#344

Post by int_19h »

MereInterest wrote: post #285
AnIdiotOnTheNet wrote: post #124

Earlier quoted context omitted.

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.

Re: Dotfile madness

#345

Post by int_19h »

avip wrote: post #176
Jaruzel wrote: 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 .

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

Re: Dotfile madness

#346

Post by int_19h »

macjohnmcc wrote: post #304

I'll take dotfile madness over registry madness. I have been trying to figure out where in the registry Visual Studio 2015 puts its install location so I can remove that registry value when I reinstall it to put it in it's default location. So far I've wasted a ton of time trying to accomplish this. A single file .VS2015 would be preferable.

Just delete this entire key:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0

Re: Dotfile madness

#347

Post by int_19h »

sowbug wrote: post #74
bauerd wrote: 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 avoids the realization that you have been paying AWS to back up ~/.cache and ~/.local for the last 6 months.

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.

Re: Dotfile madness

#348

Post by JetSpiegel »

afiori wrote: post #286
gnomewascool wrote: post #151

Earlier quoted context omitted.

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

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

Config is the personal, but public data. "Data" is personal private data.

Re: Dotfile madness

#349

Post by mistercow »

kazinator wrote: post #79
saagarjha wrote: post #4

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

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.

Re: Dotfile madness

#350

Post by SllX »

AdmiralAsshat wrote: post #243
saagarjha wrote: post #4

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

>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 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.
Post reply on HN