Linked by Thom Holwerda on Fri 30th Mar 2007 20:44 UTC, submitted by theosib
Linux The founder of the Open Graphics Project writes: "Good design and usability are very important. I haven't paid enough attention to the discussions between Linus and GNOME developers, so I can't address it directly. But what I can say is that a learning curve is not a bad thing. While it's good to think about the total novice, it's even more important to have consistent and logical mechanisms. This way, if someone has to learn something new to use the computer, they have to learn it only once. This is why I think it's good that Apple and Microsoft have UI development guides that encourage developers to make their apps act consistently with other apps in areas where their functionalities conceptually overlap. And this is where I start to get disappointed with GNU/X11/Linux systems."
Permalink for comment 226104
To read all comments associated with this story, please click here.
Doc Pain
Member since:

"There is nothing "standard" about .something in the user's home directory. For one thing, it would be more sensible to store them in their own directory so that they don't clutter the home director."

Don't you think directories like "New Folder 1", "New "New Folder 2", "New Folder 3" ... "New Folder n" do clutter a user's home directory more than hidden .foo/ directories the user does not even notice?

There is a certain reason for this: Different users may have different settings, and they can edit them by their own. (To edit them, they do not need to access the files itself; the respective program does it for them.) With "their own directory" you're refering to the directory the program is installed to, right? This would require the user to have write permissions to this directory. This is fine as long as the program is installed locally to the user (inside his home directory), but gives problems for centralized installed programs where one wrong click could destroy the whole installation. At backup time, files ~/.* are backed up (backupped?), but /usr/local/share/foo/* isn't. Centralized individual configurations (attention: contradiction!) would be lost. So, in my opinion, this is not a good solution.

"Secondly, and more to the point, they all use different formats.... there is no standard."

As I tried to point out, this is irrelevant. The configuration is read and written by the respective program, it knows the format. The user does not have to, nor has another program.

"Consider, however, Apache configuration. You configure it in files in /etc. Where those files are located has moved around from version to version. Installing Apache and PHP together doesn't always let Apache know that PHP is there, and every upgrade to either one causes settings to get lost."

I see this problem. Maybe you can encounter it in Linux with the /etc vs. /usr/local/etc mix. In a more tidy system (just to mention BSD), where all these files are located in /usr/local/etc, the problem won't exist. But I can't tell for sure, I never encountered such a problem, but I know it sometimes exists.

Reply Parent Score: 5