Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.

tl;dr: I am not convinced they are a misfeature.




OS X has a ~/Library directory that houses application settings and much else. It is hidden by default.

There is no question there is a need to have a place that "plebeian users" can't access. IMO, dot-files and dot-directories are as good as anywhere.


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.


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


To be fair, that filesystem structure was already available in NeXTStep.


had the cleanest directory structure until 10.8:

~/Library/Containers/com.apple.Preview/Data/Library/Application Support/Preview

~/Library/Containers/com.apple.Preview/Data/Library/Preferences/com.apple.Preview.plist


Isn't this change because of app sandboxing?


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.


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.


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 aren't hidden, completely or otherwise. Dotfiles are locked, '-a' is the key.


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.


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.


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.


Yes, thanks.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: