Live data from Hacker News

Rob Pike: the origin of dotfiles

plus.google.com

41–50 of 156 posts

Re: Rob Pike: the origin of dotfiles

#41
post #19

Earlier quoted context omitted.

They are a natural segregator of novice and advanced users. If you have a limited level of interaction with the unix shell (remember than in the old days everyone in a science academic department used a Unix machine, even the dusty professors you kept in the back of the supplies cabinet), setting up their account and then making sure that they couldnt get into any trouble because they didn't know about 'ls -a' was ve…

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 reveal more skills as you learn and encounter progressively harder enemies. A good app should be usable at first launch (or only require minimal setup). Configuration and advanced features can come later.

Another great filesystem level example are OS X app bundles- an entire directory hierarchy appears as a single file/application. If you need to look inside (not likely), you have to know about right-click or the action widget, but for 99.9% of the time, you see only what you need. OS X and Windows also both completely hide "system" folders in Finder/Explorer as well.

Yes, hiding things can be confusing if it's not done right, but the alternative of showing everything always is definitely not the way to go.

Re: Rob Pike: the origin of dotfiles

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

Re: Rob Pike: the origin of dotfiles

#43
post #16
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.

It's only used by those few users that use SSH.

Re: Rob Pike: the origin of dotfiles

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

Re: Rob Pike: the origin of dotfiles

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

Re: Rob Pike: the origin of dotfiles

#46
post #19

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 would like to hear a good argument for why hidden files and folders are a good thing.

They are a natural segregator of novice and advanced users. If you have a limited level of interaction with the unix shell (remember than in the old days everyone in a science academic department used a Unix machine, even the dusty professors you kept in the back of the supplies cabinet), setting up their account and then making sure that they couldnt get into any trouble because they didn't know about 'ls -a' was ve…

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 of their time available to explain the situation.

Re: Rob Pike: the origin of dotfiles

#47

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.

Is there a preferred standard for using the SD/external storage on Android?

http://www.reddit.com/r/Android/comments/t3x0p/randroid_lets...

> I do find it odd that so many apps have this problem. It's trivially easy to get the proper location. Just call getExternalFilesDir() . Deletion at uninstall happens automatically. In fact, it's the ONLY way to make sure those files are deleted when you uninstall, because you can't run code at uninstallation.

Re: Rob Pike: the origin of dotfiles

#48
post #16

Earlier quoted context omitted.

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.

It's only used by those few users that use SSH.

? ssh keeps its files in ~/.ssh.

Re: Rob Pike: the origin of dotfiles

#49

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 would like to hear a good argument for why hidden files and folders are a good thing.

I type ls in my home directory quite frequently. Somehow stuff accumulates there and I need to find a better place for it. I never type ls -a, precisely because there are a million files I just don't care about. Some means of saying "this file is here if you want it, but it won't show up in a listing because it's unlikely to be the file you're looking for" is convenient.

Re: Rob Pike: the origin of dotfiles

#50
post #23
post #16

Earlier quoted context omitted.

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.

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

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.
Post reply on HN