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

Rob Pike: the origin of dotfiles

plus.google.com

Post reply on HN
Print view View original

141–150 of 156 posts

Re: Rob Pike: the origin of dotfiles

#141

Post by vrotaru »

moe wrote: post #16
keyist wrote: post #2

Instead of putting a dotfile or dotdir in the user's home directory, do follow the XDG Base Directory specification: http://standards.freedesktop.org/basedir-spec/basedir-spec-l... . It's easy to understand and requires only a marginal increase in effort/code.

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.

    find .local/  | wc -l
    618
So I guess it depends on your Linux flavor. Mine is Ubuntu 12.04.

Re: Rob Pike: the origin of dotfiles

#142

Post by yaix »

keyist wrote: post #2

Instead of putting a dotfile or dotdir in the user's home directory, do follow the XDG Base Directory specification: http://standards.freedesktop.org/basedir-spec/basedir-spec-l... . It's easy to understand and requires only a marginal increase in effort/code.

On my system (Xubuntu), these environment variables are empty. Seems not to be much of a standard.

Re: Rob Pike: the origin of dotfiles

#143

Post by yaix »

johnny22 wrote: post #66
tedunangst wrote: post #50

Earlier quoted context omitted.

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

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

Isn't that what /tmp is for? Why not put cache files into /tmp/ with 0700 permission?

Re: Rob Pike: the origin of dotfiles

#144

Post by saljam »

yaix wrote: post #142
keyist wrote: post #2

Instead of putting a dotfile or dotdir in the user's home directory, do follow the XDG Base Directory specification: http://standards.freedesktop.org/basedir-spec/basedir-spec-l... . It's easy to understand and requires only a marginal increase in effort/code.

On my system (Xubuntu), these environment variables are empty. Seems not to be much of a standard.

To be fair, that's how it works. They have default values when they're not set. These are for when you want to override them, e.g. to keep cache files local instead of over your net mounted home directory.

Re: Rob Pike: the origin of dotfiles

#145

Post by saljam »

moe wrote: post #140
mcpherrinm wrote: post #135

Earlier quoted context omitted.

But all those folders are different, so a single one would be annoying (or: require two layers.) .config can be posted online, and shared with others (like the many "dotfile" repos you'll see on github) .local needs to be backed up, and may have private data. .cache can be blown away (or tmpfs.) .run MUST be blown away on restart. This is simple, sane, and works well.

Yes, if you push me like that I'll say it: it's incompetently overdone. When your goal is to "reduce clutter" then 2 layers would be the minimum. You make another 4(?) folders in my home-directory and call that reducing clutter? And when I delete an app then I have to look in all of them? That is just utterly backwards for no conceivable reason. Due to the semantics you now suddenly need a cronjob or similar abominat…

When your goal is to "reduce clutter" then 2 layers would be the minimum. You make another 4(?) folders in my home-directory and call that reducing clutter?

I can see a clear and very useful difference between RUNTIME_DIR, CACHE_DIR, and CONFIG_DIR. Consider a scenario where $HOME is on a networked filesystem. RUNTIME_DIR has to be outside that, and local to the machine's namespace. That's because it references things inherently local to the machine. That is, pids and pipes. These wouldn't make sense on any other machine and will just make the application's job harder.

I also set CACHE_DIR to be local (/tmp/$USER.cache.) That's because caching performs terribly when it's flying over the network. Chrome is the main culprit for me. It also fills my file quota with hours of using it. However, it's still useful to keep that data in the medium term.

CONFIG_DIR and DATA_DIR, however, don't seem to be very different to me. I can't imagine a scenario where I want one but not the other. I might be using the wrong sort of applications. (For the record I have 8 files in .config, 10 dot files, and just 1 in .local/share.)

Due to the semantics you now suddenly need a cronjob or similar abomination that traverses all home-directories and picks out stuff ("MUST" be blown away).

Having RUNTIME_DIR on a tmpfs, like what most distributions do with /var/run, solves that problem. I map mine to /var/run/$user, even though I've yet to see an application actually use it. The spec BTW doesn't even specify the default value!

And what the heck is going in .local anyways? When the user saves a file then he pretty surely doesn't want it buried under some dot-directory.

I agree, the default values are silly. This, like most of Modern Unix, is an ugly hack which makes dealing with the rest of the ugly hacks a bit easier. If you want an elegant solution you'll probably have to throw away most of what was added during last 20 years. May I suggest starting with sockets?

Re: Rob Pike: the origin of dotfiles

#146

Post by ansgri »

nakkiel wrote: post #91
jlgreco wrote: post #58

Earlier quoted context omitted.

99% of all dotfiles that I am aware of are named for the programs that they are for. Bash's start with .bash, Zsh's with .zsh, mplayer is .mplayer, Vim's start with .vim, elinks is .elinks, screen's start with .screen, Dropbox is .dropbox... I'm not sure how any of that is hard to remember. The only real barrier to entry here is knowing that you should look for them in the first place (well, that and the new XDG crap…

Perhaps the op prefers to use the registry to store settings.. After all HKEY_XXX1230_APP_123 is so friendly.

Excuse me, but much more typical example is HKEY_CURRENT_USER\Software\MiKTeX.org\MiKTeX\2.9\Core. The registry has rather respected conventions.

Re: Rob Pike: the origin of dotfiles

#147

Post by Dylan16807 »

brianpan wrote: post #41
seanalltogether wrote: post #21

Earlier quoted context omitted.

I wonder if that is a good solution for separating novices and pros though? For me, hidden files and folders only help to reinforce the confusion people have about computers. It's one thing to provide a folder to a user with a lock or shield on it, it's another to completely hide it from them.

Hiding is absolutely good design at every level. Not seeing UI controls, preferences, or anything that is not relevant to the task at hand can make that task simpler, easier to understand, and more productive. If you need to see dotfiles, well, you might need to know about man pages or at least that commandline programs take flags. It's not like they're invisible. There are plenty of examples: video games slowly reve…

What games reveal skills you have always had, as opposed to unlocking better powers? I would be really annoyed by players-guide-only abilities.

Re: Rob Pike: the origin of dotfiles

#148

Post by mcgwiz »

The author's gripe seems to be that the hiding of dotfiles was unintended, ergo dotfiles are Bad. Whether they were intended is irrelevant; their wide usage vindicates the practice. After all, traction = value. The problem of program state/configuration/metadata storage is adequately met by dotfiles.

There are, no doubt, numerous unintended behaviors of programs. Most of these are simply ignored and certainly not leveraged the way the dot behavior is.

People don't go out of their way to abuse an unintended system behavior; they simply leverage all capabilities of a system ("intended" or not) to meet their needs. Had dotfiles not gained traction, some other solution would have been designed (or "engineered") to meet the needs of program state/configuration/metadata storage.

[Tangent: All of this reminds me of grammar freaks that harp on "correct" usage, completely oblivious to the fact that grammar changes, and "correct" is merely a lightweight pointer to the current norm.]

Re: Rob Pike: the origin of dotfiles

#149

Post by rahoulb »

DeepDuh wrote: post #138
rahoulb wrote: post #137

Earlier quoted context omitted.

> This just shows to me what a bad idea sandboxing is for those kind of apps that are supposed to interoperate with the whole system. Isn't the point of sandboxing specifically to prevent apps interoperating with the whole system? (I've not really paid it much attention so far)

Yeah but what's the point in making Preview.app sandboxed? It's a damn document viewer.

There have been numerous PDF exploits in the past (including jail breaking iOS) - sounds like it needs its scope limiting.

Re: Rob Pike: the origin of dotfiles

#150

Post by jlgreco »

Dylan16807 wrote: post #147
brianpan wrote: post #41

Earlier quoted context omitted.

Hiding is absolutely good design at every level. Not seeing UI controls, preferences, or anything that is not relevant to the task at hand can make that task simpler, easier to understand, and more productive. If you need to see dotfiles, well, you might need to know about man pages or at least that commandline programs take flags. It's not like they're invisible. There are plenty of examples: video games slowly reve…

What games reveal skills you have always had, as opposed to unlocking better powers? I would be really annoyed by players-guide-only abilities.

In the Quakes, various movement techniques are only available to those who know they exist. Worked very well I think, lend the games a much longer learning curve.
Post reply on HN