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 very much a feature, trust me.
Moreover I personally much prefer them to global configuration directories because they are always local to the thing being configured and you can always override a global configuration by using them.
In fact I think they are a very elegant way to handle "hidden options" - stuff you want to expose to the power users but not bother newbies with.
OSX, because of its big corporate watchdog, and the separation of the 'GUI' layer and the unix layer, has the cleanest directory structure by far IMO. Most of the times you don't even need a manpage or google to find out how to repair a misbehaving application - just delete its plist in ~/Library/Preferences, possibly also its ../ApplicationSupport directory. The OSX defaults system is so well designed, every time I need to do support on other systems I just ask myself why not every OS works this way. I can understand why Linux is the way it is and I like that too (for other reasons), but it at least shows why the Windows Registry is such a bad idea.
Why can't I reply to some comments? That comment about the new sandboxed folder structure made me realize he's right. What's going on with all those symlinks inside the container directory?
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. Is there even a security benefit vs. pure unix permissions if you sandbox the filesystem but then you link in tons of crap that could be potentially attacked?
It's to do with comments that get deeply nested quickly, presumably to prevent back and forth flame wars and the like. If you really want to reply to such a comment, click "link" and there is a reply link on the that page, or just wait.
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.
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.
Negative. A lock or shield will convince a user that they're not to touch it, ever... Unless they are too dumb to understand the connotations, in which case they'll simply break it anyway. Hidden files are a good way to go - Out of sight, out of mind for most people, but not impossible to show them when they do need to touch.
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.
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..).
What is actually in them is an entirely different matter.
Moreover I personally much prefer them to global configuration directories because they are always local to the thing being configured and you can always override a global configuration by using them.
In fact I think they are a very elegant way to handle "hidden options" - stuff you want to expose to the power users but not bother newbies with.
tl;dr: I am not convinced they are a misfeature.