Rob Pike: the origin of dotfiles

I hate having dotfiles in ~/ for the same reason why I hate "My Documents" in Windows: because it's supposed to be <i>my</i> space that <i>I</i> organize, not a generic dumping ground for your config files, brand-named folders, or other nonessential garbage.<p>I want my space to be <i>mine</i>. Keep your app's stuff out of there!

I think the case of hidden dot files is a good example of 'convention over configuration'[1].<p>Point is accepted, that it came into being due to a lazy programmer. But surely early people might have just liked the unintended consequence of some files (dot files) being hidden. Just like most of us, whenever we learnt unix thought that it is by design.<p>If early users, had found the consequence a handicap, it would have been fixed long back.<p>Its similar to the use of hash-tags on twitter or the @for addressing which got adopted by users first and so became features (although the paths to them being considered features are different).<p>[1] <a href="http://en.wikipedia.org/wiki/Convention_over_configuration" rel="nofollow">http://en.wikipedia.org/wiki/Convention_over_configuration</a><p>Edit: Grammar

The fact that "." and ".." were allocated actual directory entries and were returned when reading the directory, rather than just being handled by the kernel when parsing pathnames seems like the original sin of expediency here.

He also writes why the dd command is so horrible: "dd is horrible on purpose. It's a joke about OS/360 JCL. But today it's an internationally standardized joke. I guess that says it all."<p><a href="http://en.wikipedia.org/wiki/Job_Control_Language" rel="nofollow">http://en.wikipedia.org/wiki/Job_Control_Language</a>

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

dotfiles are not perfect, but to have this very negative vision on a feature that also helped is a bit a revisionist attempt IMHO.<p>Dotfiles provided a poor, but <i>at least simple</i> way to store program-specific-user-specific configuration, since another standard was missing. After all it's a simple and decentralized system that worked very well with the concept of unix user and ACL: you write something inside your home directory, and this changes the behavior of your program.<p>Consider that this was invented many decades ago. Now it seems a lot better to have directories with sub directories. Maybe back then it was considered to be a waste of resources, inodes, and so forth.<p>We can improve it, create a new standard, and have something better than dot files, but dot files are better than many other over-engineered solutions that I can imagine coming out of some kind of design commission to substitute them.<p>Every time to passed your vim configuration to a friend you just copied a text file, sending it via email: you enjoyed one of the good points about dot files. Every time you did something like <i>cat dotfile | grep option</i> you enjoyed the positive effects of single-file plaintext configuration.<p>Also it's worth saying that dot files are not just the concept of an hidden file with config inside. A lot of dot files also have a common simple format of multiple lines "&#60;option&#62; &#60;value&#62;", that's better than some XML or other hard to type format (IMHO JSON itself is not good for humans).

<i>For those who object that dot files serve a purpose, I don't dispute that but counter that it's the files that serve the purpose, not the convention for their names.</i><p>I would like to hear a good argument for why hidden files and folders are a good thing.

The main takeaway I think is that the reason we are doing things the way we do them is because that is how we have been doing them, not because of some kind of genius design. And actually the whole thing can start out as a mistake, and then later on basically becomes a religion. Its very funny actually.

If not dot files lazy programmers would have just found another way. Just look at the results of lazy programmers on any Android SD card.

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.<p>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.<p>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.<p>[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.]

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.

That's really interesting. I always assumed hiding dotfiles was a deliberate convention, but to semi-quote one of the commenters, Rob's got a point. Or two.

If someone thinks hidden files are a misstep, then I don't want them designing a OS. Grandma really doesn't care about some conf file, or anything like that. She cares about the pictures of her grandkids.<p>The opinion that there shouldn't be hidden files comes from a perspective of someone who is a "power user" and who can't step back and see that most users really don't care for some .config file. To them it's clutter that gets in the way of finding what they really care about.<p>That said, dot files maybe the wrong way to do it. I like ~/Library in OSX. That's one good way.<p>Edit: Note that I'm talking about a general trend in the post's comments and on here. Not the author's opinion.

This is a problem that libetc is supposed to help solve: <a href="http://ordiluc.net/fs/libetc/" rel="nofollow">http://ordiluc.net/fs/libetc/</a>

"How many bugs and wasted CPU cycles and instances of human frustration (not to mention bad design) have resulted from that one small shortcut about 40 years ago?"<p>Sigh, if only most of us had worked on a software system that has lasted as long as that.

Tangent: I'm grumpy that Eclipse IDE uses the file names .project and .classpath. So they're hidden by default. Requiring special treatment.<p>Their content is XML. What's wrong with project.xml and classpath.xml?

omg!

Can't read without signing into Google…<p>oh well nothing of value was lost.