Live data from Hacker News

Rob Pike: the origin of dotfiles

plus.google.com

91–100 of 156 posts

Re: Rob Pike: the origin of dotfiles

#91
post #58

Earlier quoted context omitted.

Lol, They are a natural segregator of novice and advanced users. Yeah, they let that guy in the computer lab who "really knows Unix" show his stuff. I remember encountering these dot-whatever files back in the day, how changing all the idiotic terminal settings depended on them and how remembering their names or interpreting their values was nearly impossible, and how the cool geeks of the lab had about six seconds o…

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.

Re: Rob Pike: the origin of dotfiles

#93
post #44

I really like it that G+ is becoming a "lightweight blogging" platform. There are too many of these around, and folding them into a "social network" seems like a good idea. I wish they would add more features that would make this easier, though, since in general I think it's in everyone's interest and will pull more traffic to the site.

I'd like it if I didn't need a Google account to read anything on it.

Re: Rob Pike: the origin of dotfiles

#95
post #44

I really like it that G+ is becoming a "lightweight blogging" platform. There are too many of these around, and folding them into a "social network" seems like a good idea. I wish they would add more features that would make this easier, though, since in general I think it's in everyone's interest and will pull more traffic to the site.

Adding a new one is not a good solution to "there are too many around". And I don't think consolidating everything into google is a good idea; these kind of posts belong on a different network to photos of my holidays.

Re: Rob Pike: the origin of dotfiles

#96
post #87
post #79

Earlier quoted context omitted.

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

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

Re: Rob Pike: the origin of dotfiles

#97
post #93
post #44

I really like it that G+ is becoming a "lightweight blogging" platform. There are too many of these around, and folding them into a "social network" seems like a good idea. I wish they would add more features that would make this easier, though, since in general I think it's in everyone's interest and will pull more traffic to the site.

I'd like it if I didn't need a Google account to read anything on it.

Well be happy then, you don't need a Google account, as can be seen by entering the url in an Incognito window.

Re: Rob Pike: the origin of dotfiles

#98
post #87
post #79

Earlier quoted context omitted.

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

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

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

Re: Rob Pike: the origin of dotfiles

#99
post #73

Earlier quoted context omitted.

$HOME/.local/share doesn't exist on OSX either.

XDG is a freedesktop standard. Meaning: checking that standard on OS X is a bit strange.

I thought we were talking about unix, not the "free desktop standard".

Re: Rob Pike: the origin of dotfiles

#100
post #98
post #87

Earlier quoted context omitted.

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

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

Unless you have many thousands of files, I can't imagine you would ever notice a slowdown.
Post reply on HN