Linked by Thom Holwerda on Sat 23rd Aug 2008 15:37 UTC
Editorial Earlier this week, we ran a story on GoboLinux, and the distribution's effort to replace the Filesystem Hierarchy Standard with a more pleasant, human-readable, and logical design. A lot of people liked the idea of modernising/replacing the FHS, but just as many people were against doing so. Valid arguments were presented both ways, but in this article, I would like to focus on a common sentiment that came forward in that discussion: normal users shouldn't see the FHS, and advanced users are smart enough to figure out how the FHS works.
Thread beginning with comment 327753
To view parent comment, click here.
To read all comments associated with this story, please click here.
elsewhere
Member since:
2005-07-13

So, /etc could have the 'humane' name '/settings' or '/system settings'.


But how does that improve the situation for non-English speaking users? Seems to me it only makes it worse for them, or we have to use some sort of an abstraction layer on top of FHS for language-specific directory names.

All of this talk about human-readable directory names seems to imply that linux users should all learn English, in order to simplify things for English speaking users.

Reply Parent Score: 5

Thom_Holwerda Member since:
2005-06-29

All of this talk about human-readable directory names seems to imply that linux users should all learn English, in order to simplify things for English speaking users.


Why?

As soon as you have a set of standard human-readable names, translation only gets easier - not harder. How on earth do you translate /usr? Or /etc? Compare that to /settings. Or /programs. Or /system.

The desktop environment and cli can easily be aware of the locale and language settings and change the names displayed accordingly. Heck, even non-Latin alphabets could be used. It'd be a massive improvement in localisation.

Yet another advantage.

Edited 2008-08-23 19:09 UTC

Reply Parent Score: 3

irbis Member since:
2005-07-08

As soon as you have a set of standard human-readable names, translation only gets easier - not harder. How on earth do you translate /usr? Or /etc? Compare that to /settings. Or /programs. Or /system. The desktop environment and cli can easily be aware of the locale and language settings and change the names displayed accordingly.

Well, if translation is needed, and let's say your locale was English, couldn't you as well translate /usr as /programs and /etc as /settings etc. too - if you want intuitive file hierarchy system? Just a thought.

Unix and Linux file hierarchy system with its /etc, /usr, /dev etc. can indeed look cryptic. at least if you are not an experienced user yet. But at least /etc and /usr etc. are short which can be a big plus if you want to see full paths to files and use commandline a lot.

Having said that, I do like the Gobo Linux ideas like its file hierarchy system and have often considered that I would like to give that distro a try.

Reply Parent Score: 4

devurandom Member since:
2005-07-06

Please. We don't really want to localize a system hierarchy, isn't it?

Do you imagine how things start to become terribly complex and fragmented if each computer can have a different name for the /settings directory, based on its locale? And what about people using more than one locale?


(begin rant) Probably I don't get it because I simply don't understand the real point of localization. It seems a terrible waste of time to me. Computers are tools. Tools should need knowledge to be used. One of these knowledges is (basic) English language.

To want to live in the modern world and to want to use modern technology without knowing the current Worldspeak -that is, English- is utterly beyond my comprehension.

The time spent localizing could be much better spent by teaching people needing localization proper English.

Notice that I am not of English mother tongue -I am Italian, in fact, living in Italy- so this is not "who cares about non-AngloSaxons" talk. (end rant)

Reply Parent Score: 6

Doc Pain Member since:
2006-10-08

As soon as you have a set of standard human-readable names, translation only gets easier - not harder.


But translation would have to be done completely (and not just parts, such as you can see it in KDE). Not only the directories would need to be translated. What about the system's utilities, the command? And their manpages? Maybe the kernel interfaces and library functions?

Personally, I prefer a comfortable english naming across the system than a subset of poorly done translations into another language.

How on earth do you translate /usr? Or /etc?


/usr = UNIX system ressources

/etc = et cetera (and others) - well, this is not easy to translate; /system_settings would be definitely a better name that explains what's inside this directory. But /etc has historical reasons. Anyone remembers /etc/mount or /etc/fsck?

Compare that to /settings. Or /programs. Or /system.


It would be good if those names would have the same relationship to their contents as the "old fashioned" names have - see the difference between, let's say, /usr/bin and /usr/local/bin; the difference is well intended: difference between purpose causes difference in naming convention.

The desktop environment and cli can easily be aware of the locale and language settings and change the names displayed accordingly. Heck, even non-Latin alphabets could be used. It'd be a massive improvement in localisation.


That's what desktop environments /at least the "two big ones") already successfully do. They add a layer of abstraction that leaves the "old fashioned" infrastructures intact, while providing a "more humane" surface to the user.

The standardization on the english language enables help (with illustrating examples) across the language barrier. If someone from Russia asks how to do this and that, I (from Germany) can answer with a script to solve the problem that he can use 1:1 without needing to translate it from the german language to the russian one.

Yet another advantage.


That's why I think the desktop environments should put more emphasize on a good (!) translation, instead of adding features after features, just to scare a German user with an english error message that makes the user throw Linux out of the window. Yes, it it that way in my country - one english word and woosh! away it flies. Strange languages scare Germans. :-)

Reply Parent Score: 3

elsewhere Member since:
2005-07-13

"All of this talk about human-readable directory names seems to imply that linux users should all learn English, in order to simplify things for English speaking users.


Why?

As soon as you have a set of standard human-readable names, translation only gets easier - not harder. How on earth do you translate /usr? Or /etc? Compare that to /settings. Or /programs. Or /system.

The desktop environment and cli can easily be aware of the locale and language settings and change the names displayed accordingly. Heck, even non-Latin alphabets could be used. It'd be a massive improvement in localisation.

Yet another advantage.
"

As I said in my post, this basically entails an abstraction layer on top of the file system. Why? What's the point? What's the gain? Why is this any different from simply using symlinks to point /programs at /bin, or the equivalent language-specific symlink at /bin? At the end of the day, people are going to have to deal with /bin because it is the baseline.

Right now, somebody looking for support in ...insert distro... can find information regardless of language or environment, because it refers to /bin.

How does using language-specific references enable somebody that doesn't understand english, or understands it poorly, to use any sort of support or other google-generated information to understand that /programs should be translated to their specific environment settings?

How will anybody packaging applications using the current tools be able to have their applications layout properly when there are 100+ potentially different environment-based directories to deal with?

The only way this can happen is to have some sort of baseline point of reference that the system understands, whether it is dealing with environment variables for interpreting what directory names should be, or for installing packages. Which means we're using an abstraction system. Which means, ultimately, we're still relying on /bin as a baseline.

Trying to make FHS "user friendly" is no more useful than slapping lipstick on a pig. Yes, it's ugly, and yes, with the benefit of hindsight it can be implemented much more cleanly. But at this point, changing something substantial as the FHS will carry less benefit than the effort required to do it. As archaic as the FHS is, and despite the fact that linux distros have their own interpretations, it doesn't change the fact that there are decades worth of applications and documentation that rely on it to some extent. It also doesn't change the fact that at the very least, one common baseline is the fact that every user is dealing with equally archaic directory structures regardless of their language. The archaic nature is almost a universal language in it self.

I'm one of those people that believes that the average user should not have to deal with file structures at all. User interfaces should be abstracting this, not the platform itself. We're slowly reaching a point where file browsers will start categorizing files and information based on meta-tags and contextual references. This will ultimately make things more intuitive, and non-ethnocentric. That's what we should be aiming for.

And if anyone wants to touch the filestructure, they should know what they're doing. I don't see the benefit to changing such a core component, ugly as it is, to address perceived corner cases.

Linux and friends have much bigger hurdles to cross for wider acceptance and improvements of ease-in-use. Pointing fingers at FHS is like pointing fingers at Adobe for not porting Photoshop as a reason for holding linux back from further adoption. It's a popular deflection.

Sorry, but just my 2c...

Reply Parent Score: 4

fresch Member since:
2006-09-12

I don't think it is such a good idea to translate directory names.

For Example:
You, being dutch, run your $OS with locale set to dutch. Now, you have to explain to a chinese, in english (he doesn't speak dutch, you don't speak chinese), where he would find $PROGRAM or $FILE. He is, of course, running $OS with locale set to chinese.

You repeatedly tell him to go to his "Programs" folder. He keeps telling you, he doesn't have one. Let's assume that the translation from chinese to english for that very same folder is "Applications".

Now apply this to the entire directory tree.

It's even worse when naive or inexperienced developers make assumptions about existing directories. My Windows XP is set to german, and every once in a while there is a program that installs to "Program Files" instead of "Programme".

While translating, more often than not, you end up translating *concepts* rather than *words* because it's the only way to make sense.

While I do think I18N and L10N are really great and necessary, I also think they shouldn't be applied (naively) to file system hierarchies.

Reply Parent Score: 1