7 ms·
I see no benefit. It's not at all easy to understand, nor easy to implement, nor does it have any tangible advantages. It's one of these superfluous pseudo-st
by moe 14y ago
I see no benefit.
It's not at all easy to understand, nor easy to implement, nor does it have any tangible advantages.
It's one of these superfluous pseudo-standards that do nothing but add needless clutter. But gladly nobody seems to be using it anyway, I see only one directory in my ~/.local: vlc.
- subway 14y agoCheck out your .config and .cache directories.
- keyist 14y agoI consider it good practice to allow users to customize where your program creates files. I don't like $HOME to be the default dumping ground for anything I run. A standard that uses environment variables means programs don't have to provide extra options for this customization (I've seen -f,--file , -c,--config and other variants). It allows for common code (libraries that implement the spec). If you poke around for feature requests for various open source programs, you'll find XDG basedir compliance come up occasionally (moreso for CLI utils). I wouldn't say "nobody seems to be using it"; quick scan of my folders includes Chromium, uzbl, htop. Git's next release will be compliant too.
- tedunangst 14y agoI don't particularly like dumping everything in home, but XDG is worse. Now, if I want to start over with a clean profile, there's a whole list of locations I have to zap. Spraying shit in three directories is worse than one.
- johnny22 14y agomy problem with that "one" directory is that i have to take care specifically to back it up. applications that at least use ~/.cache means i don't have to worry about backing up a bunch of useless stuff.
- yaix 14y agoIsn't that what /tmp is for? Why not put cache files into /tmp/<username> with 0700 permission?
- daxelrod 14y agoNo, that's not necessarily what /tmp is for. Consider a browser cache. /tmp is not guaranteed to be preserved between program invocations[1]. /var/tmp [2] might be a better place. /var/cache [3] is intended for exactly this kind of thing. Unfortunately, it can be far more useful for an administrator in a multi-user setup to want user-specific caches in home directories. That way, you get all of the infrastructure for managing user data for free, like quotas. Also note: if you're considering putting data into /tmp or /var/tmp, please honor the TMPDIR environment variable, if it is set[4]. [1]: http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFIL... [2]: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARTMPTEMPORARYFILESPRESERVEDBETWEE http://www.pathname.com/fhs/pub/fhs-2.3.html#VARTMPTEMPORARY... [3]: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICA... [4]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03 http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...
- anamax 14y ago> If you poke around for feature requests for various open source programs, you'll find XDG basedir compliance come up occasionally (moreso for CLI utils). What fraction of those requests are by XDG advocates? I ask because every standard comes with folks insisting that it be followed. While those folks claim to represent the interests of users, those requests are different.
- adbge 14y agoI have made this specific feature request on an application (Mangler) and I have no affiliation with XDG.
- sciurus 14y ago~/.local isn't primarily where you should look; check ~/.config
- darkarmani 14y agoIt's only used by those few users that use SSH.
- tedunangst 14y ago? ssh keeps its files in ~/.ssh.
- jlgreco 14y ago[jlgreco@local] ~ % find ~/.config ~/.local | grep ssh | wc -l 0 So.. no.
- aroman 14y agoActually, it is in considerably wide use for desktop linux applications. It definitely has tangible benefits as well -- it promotes the clear separation of app data and user configuration, and unclutters the home folder. And as pointed out by other replies, ~/.local is not the only XDG data dir. I'm curious, how do you find it not easy to implement?
- davvid 14y agoI see no benefit. How about consistency?
- lmm 14y agoWhen there are forty years of existing applications using ~/.appname?
- dfc 14y agoYou are running a modern linux distro with only one file/dir in .local?
- tammer 14y ago% cd ~/.local cd: no such file or directory: /home/tammer/.local % uname -s -r Linux 3.4.7-1-ARCH
- nucleardog 14y agoFreeBSD 7.1-RELEASE - No ~/.local, ~/.config FreeBSD 9.0-RELEASE - No ~/.local, ~/.config Linux 3.2.0-23 - No ~/.local, ~/.config Linux 3.0.0-16 - No ~/.local, ~/.config Linux 3.0.0-12 - No ~/.local, ~/.config Honestly, I'd never even heard of this scheme before today.
- dfc 14y agoI guess I should have said "a modern linux desktop environment." Are these shell boxes or desktops? In my experience the majority of propgrams that use this spec are gtk/qt programs. PS Listing a kernel version does not really provide any information about your modern linux distro.
- darkestkhan 14y agoInteresting... I have ~/.cache, ~/.local and ~/.config and all 3 of them have quite a lot of subdirs and dotfiles inside.
- gioele 14y ago> I see no benefit. The first benefit is that it removes clutters from your $HOME. The second benefit is that you can now manage and backup your settings in a sane way. * ~/.config contains config files (should not be lost, but if lost you can recreate them); * ~/.local contains user data files (save them often, never lose them for they are not replaceable); * ~/.cache contains cached information (can be tmpfs mounted, you can delete it any time you want, no loss in functionality, you just lose some optimization); * ~/.run is for temporary system files (must be tmpfs mounted or it must be cleaned during at shutdown or power on). Luckily most of the apps used on Linux systems now use it, you are probably using Mac OS X.
- onli 14y ago> The first benefit is that it removes clutters from your $HOME. Invisible clutter? That's a strange concept. But the rest of your point indeed makes sense. It still is easier and probably comment to backup the whole $HOME. But those points you can see as a benefit, though not obvious.
- deleted 14y ago[deleted]
- lubutu 14y agoAs Rob mentions in his post, the more dotfiles there are in $HOME the slower path resolution for any subfiles becomes. How do we navigate to ./src? We open the directory and read all the entries until we find the one called "src". What happens if we encounter a morass of dotfiles beforehand? src takes a while to find. The clutter may be invisible to you, but it does gum up the works.
- duaneb 14y agoUnless you have many thousands of files, I can't imagine you would ever notice a slowdown.
- kbolino 14y agoFor what it's worth, most modern file systems (JFS, XFS, ext4, reiserfs, btrfs, ...) have logarithmic (or better) directory lookup times. This is achieved using hashes and b-trees (or even hash tables).
- vrotaru 14y agofind .local/ | wc -l 618 So I guess it depends on your Linux flavor. Mine is Ubuntu 12.04.