Live data from Hacker News

Use the XDG Base Directory Specification

xdgbasedirectoryspecification.com

151–160 of 214 posts

Re: Use the XDG Base Directory Specification

#151

Somebody should tell that to the Rust people. They have a .cargo and a .rustup folder in ~, plus an extra heavy target folder for every project. Would be much nicer if they put the cache one .cache But they don't seem to care https://github.com/rust-lang/cargo/issues/1734 https://github.com/rust-lang/rfcs/pull/1615 https://github.com/rust-lang/cargo/pull/9178

> But they don't seem to care

While I've not fully dug into all of those links, that is rarely the case and it makes the conversations harder when people over simplify situations like this. Generally, I've found when people make assumptions like this, the underlying requirements are a lot more involved and its not a high enough priority for the small group of overtaxed individuals.

Re: Use the XDG Base Directory Specification

#152
post #151

Somebody should tell that to the Rust people. They have a .cargo and a .rustup folder in ~, plus an extra heavy target folder for every project. Would be much nicer if they put the cache one .cache But they don't seem to care https://github.com/rust-lang/cargo/issues/1734 https://github.com/rust-lang/rfcs/pull/1615 https://github.com/rust-lang/cargo/pull/9178

> But they don't seem to care While I've not fully dug into all of those links, that is rarely the case and it makes the conversations harder when people over simplify situations like this. Generally, I've found when people make assumptions like this, the underlying requirements are a lot more involved and its not a high enough priority for the small group of overtaxed individuals.

You're right. I apologize. The fact that there was a PR actually shows that some people care.

Re: Use the XDG Base Directory Specification

#153
post #150
post #138

Earlier quoted context omitted.

Does systemd really hardcode "/home" rather than use the user's actual home directory?

Systemd needs the common parent directory of the home directory of all users on the system, in order to protect all user home directories from services. There is no “the” user.

I did misplace the apostrophe. There is no guaranteed common parent directory of all users other than `/`.

Re: Use the XDG Base Directory Specification

#154
post #151

Somebody should tell that to the Rust people. They have a .cargo and a .rustup folder in ~, plus an extra heavy target folder for every project. Would be much nicer if they put the cache one .cache But they don't seem to care https://github.com/rust-lang/cargo/issues/1734 https://github.com/rust-lang/rfcs/pull/1615 https://github.com/rust-lang/cargo/pull/9178

> But they don't seem to care While I've not fully dug into all of those links, that is rarely the case and it makes the conversations harder when people over simplify situations like this. Generally, I've found when people make assumptions like this, the underlying requirements are a lot more involved and its not a high enough priority for the small group of overtaxed individuals.

In my experience, the usual reason for a project not using the XDG Base Dir spec is because somebody on the project simply doesn't like it, particularly XDG_CONFIG_HOME defaulting to $HOME/.config. Resistance to the XDG Base Dir spec really does seem to be rooted in personal preference, I've never seen an objection to it on any technical basis.

The best arguments against it that I've seen are "many other projects don't use this spec, so why should we?" (e.g. our project should be the last to adopt it.. but why?) and arguments along the lines of "XDG_BIN_HOME isn't in the spec, therefore we shouldn't use XDG_CONFIG_HOME", which just seems like a lame excuse.

Re: Use the XDG Base Directory Specification

#155
Considered opinion from decades of desktop computer usage:

Trying to use paths to meaningfully separate data by type is a fool's errand and no one will ever get it "right". It is the primary thing UNIX systems got extremely wrong that not only holds them back in the personal desktop space, but through cultural cross pollination has been ruining other desktop OSs too.

Original single-user desktop OSs had the best solution: keep everything related to the application functionality with the application. The application (in AppDir/file with resource fork/whatever form) itself can be wherever the user feels like putting it, and saved documents go wherever the hell the user feels like putting them. The only exception should be cache and temp data, which should go somewhere global.

This has the benefit of being clear and obvious to the user.

The obvious objections:

> but multiuser!

Is a use case that basically doesn't exist in personal desktop space. To the extent it was ever a useful concept it was during a time when a desktop computer was the only way to access the internet and they were too expensive and bulky to justify more than one in a home. Even then, we managed fine without OS level multiuser support.

To the extent that anything like a multiuser desktop exists it is certainly a niche, and therefore we should handle its problems with virtualization, containerization, filesystem overlay hackery, etc.

> but ease of backup!

Depends entirely on what cross section of things you care about backing up. As it is you already have to search dozens of places for including what you want and have rules for excluding what you don't and no standard is ever going to fix that. Applying those same things to the "everything with the application" model is, at worst, not any worse than things already are.

> but if I copy the application, it also copies the config.

That's a decent point, but I would argue this is the obvious thing and also perhaps what is intended. Solution is to have a standardized mechanism of clearing out the config and other state from the application directory, such that it can be done with a right-click context menu. A factory reset of the application if you will.

> but I never use a mouse and only use the GUI as a really fancy tmux

That's fine, nothing about this model makes your life conceptually any harder. Keep all the applications in directories in your PATH. Factory reset of the application can be just as easily done with a command as a context menu entry. You can still put applications in repos and even overengineer a package manager for them if you really want to.

Re: Use the XDG Base Directory Specification

#156
post #69
post #23

One of the things that changed my life recently, that I hadn't seen before: NeoVim has a NVIM_APPNAME variable that lets you change the app name. So when I wanted to try AstroVim, I just set NVIM_APPNAME=astrovim, and dropped the files in ~/.config/astrovim instead of blowing up my existing (shitty) ~/.config/nvim. I really wish the idea of configurable appnames was a part of the spec! (or a well-known extension!)

It's a very recent neovim feature, so it has not been around to discover for that long

Yes, it's only a month old!

https://github.com/neovim/neovim/pull/22128

I actually have something similar in some of my old old projects. And I'd expect I ripped the idea off from somewhere. But I don't know who to cite. :(

Re: Use the XDG Base Directory Specification

#157

Does it really help that much in practice? > Easier to share configuration settings I want to share my nvim config between both my home Linux machine and my Mac at work, but I don’t want to share my config for gnome and its apps. So now I’ve got to maintain a script to go one more subdirectory deep to pick which dotfiles to sync and which to ignore... > Easier to temporarily ignore the config > It is easiest to set X…

> Easier to create backups i want to mess up with wine, now I just backup ~/.wine, do whatever, restore. With split folders, i'd have to backup a bunch of folders (.config/wine, .local/share/wine, .local/lib/wine or wherever the files, registry, dosdevices and other stuff would be put).

> i want to mess up with wine, now I just backup ~/.wine, do whatever, restore.

You can set WINEPREFIX to use a non-default prefix path (other than `~/.wine`).

Note that the prefix doesn't contain everything that wine spills all over your home. It adds (XDG `.desktop`) launchers & menu/desktop shortcuts, file type associations, icons, etc. to the usual locations.

Re: Use the XDG Base Directory Specification

#158
post #153
post #150

Earlier quoted context omitted.

Systemd needs the common parent directory of the home directory of all users on the system, in order to protect all user home directories from services. There is no “the” user.

I did misplace the apostrophe. There is no guaranteed common parent directory of all users other than `/`.

Systemd wants to provide an option of limiting services from writing, and optionally also from reading, in the home directories of all users. However, there is no reasonable algorithm to discover a single common parent directory which would not also risk encompassing other directories which should not be restricted, so the hardcoded /home is used by the ProtectHome option. If you have home directories somewhere else, but want the same protection by systemd, you will have to use the InaccessiblePaths or ReadOnlyPaths option for all individual system services which you want to restrict in this manner.

Re: Use the XDG Base Directory Specification

#159

Earlier quoted context omitted.

Luckily if you’re a developer on MacOS, you can have that too! In addition to ~/.config and a million .dotfiles and .dotdirectories from decades of unixy tools! Truly a cornucopia.

In Windows we get dotfiles from any tool badly ported from unixland, plus the myriad ways specified by various Windows standards over the past several decades, plus the innumerable ways that different entities have chosen to interpret those standards, plus whatever bullshit non-standard locations some asshole thought up and decided to ship. Where is the config for program X? It could be in the same directory as X, HK…

Yep. Makes backing up configurations on Windows systems somewhat nightmarish… it's most practical to just back up the whole install and then pray that you'll never have to go digging for any specific bit of config in particular.

Re: Use the XDG Base Directory Specification

#160
post #151

Earlier quoted context omitted.

> But they don't seem to care While I've not fully dug into all of those links, that is rarely the case and it makes the conversations harder when people over simplify situations like this. Generally, I've found when people make assumptions like this, the underlying requirements are a lot more involved and its not a high enough priority for the small group of overtaxed individuals.

In my experience, the usual reason for a project not using the XDG Base Dir spec is because somebody on the project simply doesn't like it, particularly XDG_CONFIG_HOME defaulting to $HOME/.config. Resistance to the XDG Base Dir spec really does seem to be rooted in personal preference, I've never seen an objection to it on any technical basis. The best arguments against it that I've seen are "many other projects don…

XDG_BIN_HOME is crucial, without it, not supporting the spec seems like the right call. Better to deal with the status quo until updates happen than to get stuck in bikeshed hell.
Post reply on HN