I hate having dotfiles in ~/ for the same reason why I hate "My Documents" in Windows: because it's supposed to be my space that I organize, not a generic dumping ground for your config files, brand-named folders, or other nonessential garbage.
I want my space to be mine. Keep your app's stuff out of there!
I am using a manually created /data partition as my personal space. Many dotfiles and 'dotdirectories' are distro+release specific. With having all my personal data in a separate partition makes switching distros (or using multiple ones) a breeze as I start with all my data intact and a virgin /home which I can populate with my dotfiles as I see fit.
My Documents was never meant to be a storage space for application settings. Application Data / AppData is the place for this. Of course, whether an application complies with this depends on the developer, and many applications break that rule
Your homedir equivalent on windows (since Windws XP) is /Documents and Settings/username, or the modern shortened equivalent. That has subdirectories for documents and application settings. Apps that put config data in My Documents are using behaviour dating back to Windows 95.
It's the same on Mac OS - /Users/username has a Documents subdirectory. Mac spps tend to be better-behaved, but a few manage to pollute the Documents directory. On Linux you may roll your own or use a ~/Documents directory created by your desktop environment. The fact is your homedir is the home of pretty much anything that is user-specific, and you either need to collect all the config data into some sort of config directory, or do your own organising in a subdirectory, or both.
I think the case of hidden dot files is a good example of 'convention over configuration'[1].
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.
If early users, had found the consequence a handicap, it would have been fixed long back.
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).
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.
Why? Seems like a brilliantly simple quick solution that would be rather easy to roll back in the future and lacks any real downsides besides being a tad weird.
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."
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 am always pleasantly surprised when programs follow XDG. One notable example is the fish shell. Most shells put dotfiles in $HOME, like .bash_profile or .zshrc. Fish puts everything in .config/fish/.
Somehow .dotfiles work just fine under Windows :). As such they are somehow more "portable"
Emacs saves them under %USERPROFILE% - I have in there - .alice, .android, .easyhg, .eclipse, .gstreamer-0.10, .lighttable, .m2, .matplotlib, .... .VirtualBox, .zenmap
Also in "Application Data" - .emacs.d, .mc, .subversion
My point is - this system works somehow even under non-unixy systems.
I would have preferred if it did not rely on environment variables since almost nobody sets them which means there will be untested code in applications implementing the specification.
I notice the $XDG_DATA_HOME environment variable isn't set in my Intrepid install. Maybe its set in later Ubuntu version.
But the value not being set for me means implies to me that it not being set is pretty common. Thus it seems like supporting this standard is going to involve supporting a fall-back of whatever you would do otherwise.
So I don't see "easy" at all but rather extra BS. Sorry.
dotfiles are not perfect, but to have this very negative vision on a feature that also helped is a bit a revisionist attempt IMHO.
Dotfiles provided a poor, but at least simple 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.
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.
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.
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 cat dotfile | grep option you enjoyed the positive effects of single-file plaintext configuration.
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 "<option> <value>", that's better than some XML or other hard to type format (IMHO JSON itself is not good for humans).
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 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.
They work well with per-directory settings. It's a simple convention and it works really well for things like .git, .gitignore, language-specific settings files and so on.
Putting files and directories like this inside another directory would not win you much, especially if you only have one in a given location (e.g. you only have a .git directory). But you wouldn't want to keep tripping over your .git directories either!
However, having a dedicated directory for configuration files applying to a user or the whole system is a different story. I would much rather just have a ~/config directory than a home folder full of dot files.
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.
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.
Yes, very organic. The original programming shortcut accidentally created a sort of ecological niche, in which all sorts of things started to take root. Now, nobody can bulldoze the lot because there's too much stuff growing there.
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.
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.
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.
[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.
A bit off topic, but is it just me or is the quality of comments on public G+ posts is absolutely terrible? Within a few hours there has been more than 100 replies. Most are inane, rude, of the useless “great post!” type, or just plain old spam. I could only manage to glean about 8 or 9 insightful replies.
Is this something intrinsic to G+? Is it a function of the author's popularity? The discussions here are normally much more sensible, but I would expect HN's readership to have a fairly similar demographic to that of Rob Pike's G+ subscribers.
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.
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.
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.
That said, dot files maybe the wrong way to do it. I like ~/Library in OSX. That's one good way.
Edit: Note that I'm talking about a general trend in the post's comments and on here. Not the author's opinion.
That’s nice, shame it’s not maintained. On the other hand, one the goals of XDG is to differentiate between application cache, actual settings etc. If FooApp stores 2GB cache file in .foo, redirecting it blindly to .config just makes my backups that much harder.
"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?"
Sigh, if only most of us had worked on a software system that has lasted as long as that.
[+] [-] acabal|13 years ago|reply
I want my space to be mine. Keep your app's stuff out of there!
[+] [-] gnufs|13 years ago|reply
[+] [-] mavroprovato|13 years ago|reply
[+] [-] rm445|13 years ago|reply
Your homedir equivalent on windows (since Windws XP) is /Documents and Settings/username, or the modern shortened equivalent. That has subdirectories for documents and application settings. Apps that put config data in My Documents are using behaviour dating back to Windows 95.
It's the same on Mac OS - /Users/username has a Documents subdirectory. Mac spps tend to be better-behaved, but a few manage to pollute the Documents directory. On Linux you may roll your own or use a ~/Documents directory created by your desktop environment. The fact is your homedir is the home of pretty much anything that is user-specific, and you either need to collect all the config data into some sort of config directory, or do your own organising in a subdirectory, or both.
[+] [-] Foy|13 years ago|reply
"My Documents" is a nightmare... I think only one folder (out of nearly a dozen) and only one file are actually of my making.
[+] [-] chris_j|13 years ago|reply
[+] [-] zapu|13 years ago|reply
[+] [-] rehack|13 years ago|reply
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.
If early users, had found the consequence a handicap, it would have been fixed long back.
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).
[1] http://en.wikipedia.org/wiki/Convention_over_configuration
Edit: Grammar
[+] [-] caf|13 years ago|reply
[+] [-] jlgreco|13 years ago|reply
[+] [-] mseepgood|13 years ago|reply
http://en.wikipedia.org/wiki/Job_Control_Language
[+] [-] keyist|13 years ago|reply
It's easy to understand and requires only a marginal increase in effort/code.
[+] [-] moe|13 years ago|reply
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.
[+] [-] oofabz|13 years ago|reply
[+] [-] malkia|13 years ago|reply
Emacs saves them under %USERPROFILE% - I have in there - .alice, .android, .easyhg, .eclipse, .gstreamer-0.10, .lighttable, .m2, .matplotlib, .... .VirtualBox, .zenmap
Also in "Application Data" - .emacs.d, .mc, .subversion
My point is - this system works somehow even under non-unixy systems.
Because it's simple.
[+] [-] jeltz|13 years ago|reply
[+] [-] joe_the_user|13 years ago|reply
But the value not being set for me means implies to me that it not being set is pretty common. Thus it seems like supporting this standard is going to involve supporting a fall-back of whatever you would do otherwise.
So I don't see "easy" at all but rather extra BS. Sorry.
[+] [-] yaix|13 years ago|reply
[+] [-] antirez|13 years ago|reply
Dotfiles provided a poor, but at least simple 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.
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.
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.
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 cat dotfile | grep option you enjoyed the positive effects of single-file plaintext configuration.
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 "<option> <value>", that's better than some XML or other hard to type format (IMHO JSON itself is not good for humans).
[+] [-] ajanuary|13 years ago|reply
[+] [-] seanalltogether|13 years ago|reply
I would like to hear a good argument for why hidden files and folders are a good thing.
[+] [-] frossie|13 years ago|reply
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.
[+] [-] tikhonj|13 years ago|reply
Putting files and directories like this inside another directory would not win you much, especially if you only have one in a given location (e.g. you only have a .git directory). But you wouldn't want to keep tripping over your .git directories either!
However, having a dedicated directory for configuration files applying to a user or the whole system is a different story. I would much rather just have a ~/config directory than a home folder full of dot files.
[+] [-] tedunangst|13 years ago|reply
[+] [-] bdunbar|13 years ago|reply
They keep users from monkeying with stuff until they are smart enough to find the hidden files.
[+] [-] ilaksh|13 years ago|reply
[+] [-] mturmon|13 years ago|reply
[+] [-] skeletonjelly|13 years ago|reply
[+] [-] voltagex_|13 years ago|reply
[+] [-] chj|13 years ago|reply
[+] [-] mcgwiz|13 years ago|reply
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.
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.
[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.]
[+] [-] eliben|13 years ago|reply
[+] [-] saljam|13 years ago|reply
Is this something intrinsic to G+? Is it a function of the author's popularity? The discussions here are normally much more sensible, but I would expect HN's readership to have a fairly similar demographic to that of Rob Pike's G+ subscribers.
[+] [-] lmm|13 years ago|reply
[+] [-] 89a|13 years ago|reply
[+] [-] dsrguru|13 years ago|reply
[+] [-] adambratt|13 years ago|reply
Little did I know.
[+] [-] emperorcezar|13 years ago|reply
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.
That said, dot files maybe the wrong way to do it. I like ~/Library in OSX. That's one good way.
Edit: Note that I'm talking about a general trend in the post's comments and on here. Not the author's opinion.
[+] [-] SCdF|13 years ago|reply
[+] [-] UK-AL|13 years ago|reply
[+] [-] tyrmored|13 years ago|reply
[+] [-] deno|13 years ago|reply
[+] [-] malkia|13 years ago|reply
[+] [-] leothekim|13 years ago|reply
Sigh, if only most of us had worked on a software system that has lasted as long as that.
[+] [-] specialist|13 years ago|reply
Their content is XML. What's wrong with project.xml and classpath.xml?
[+] [-] garfee|13 years ago|reply
[+] [-] 89a|13 years ago|reply
oh well nothing of value was lost.
[+] [-] mproud|13 years ago|reply