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 327754
To view parent comment, click here.
To read all comments associated with this story, please click here.
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

tyrione Member since:
2005-11-21

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

Seeing as more than just programs reside under /usr you'd have to be more specific.

Reply Parent Score: 2

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

ari-free Member since:
2007-01-22

good point. Imagine if computer languages were redesigned for non english languages. In some sense you have to know at least some english before you can really get into the computer.

Reply Parent Score: 2

wannabe geek Member since:
2006-09-27

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


Well, I do. But I also see the implications go much further than some admit.


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?

In short, if properly done, it would only mean that you have to set the correct locale in the instance of Konsole where you are about to copy-paste the advice you've just seen in a forum, mailing list or IRC channel. For instance, if your system is localized to Italian, but you are asking in an English forum, the pieces of code you copy from there will have English localization, so you have to open a terminal and set English localization (just) for that instance of the terminal. Languages and locales should be like skins.

Yes, that's not how it works now. Not just in system directories, but also in programming language and all kind of technology infrastructures.

I've often heard the following "reductio ad absurdum": If system directories should be localised, then why not APIs, keywords in programming languages and so on? Good point, but you know what, I'm willing to bite the bullet.

The idea that you have to learn some keywords in a foreign language if you want to program is so pervasive that most people give it for granted, but it's just a product of the monolingual environment in which most of the programming standards were established (hello, ASCII, I'm pointing at you!).

If the first programming languages had been developed in, say, Canada, their authors would have realized that the first thing a parser should do is check the locale of the program, and that every program should declare its locale (at least when distributed outside its original locale).

One crucial activity of national standards bodies should be to establish translations for such keywords. But even if no "official" translation is available, it should be straightforward for users to define their own mappings, let their systems do the translation and interoperate with everyone else about as easily. If, for some reason, a new keyword only has translations to some languages, it should be possible to still use it in a program localized to a language where this keyword is missing, for instance by prefixing its name with a locale-setting expression.

The only people giving some serious thought to the need of localization in programming, AFAIK, are those involved in semantic web technologies. Maybe that's because ontology building is sufficiently close to natural language that the unfair advantage of being a native English speaker is most evident.


As I said in other posts, I have nothing against English, I find it nice and all. What upsets me, in this case, is the attitude of carelessly hardcoding a particular language into technology, and then expecting people to learn the language if they want to use the technology, as if said hardcoding were the most sensible thing to do.




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)


It's still "who cares about non-AngloSaxons" talk, just one by a non-Anglosaxon ;)

Reply Parent Score: 2

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

Adam S Member since:
2005-04-01

That whole "/usr" = Unix System Resources is not really confirmed. Most people think that's a "backronym" which was invented long after the /usr structure was in effect.

And what the hell is "etcetera!?" I know what the term means, but if 50% of a usable Linux system lives there, that's poor categorization, no?

Frankly, the current layout sucks. From one system to another, the same program could be installed in ten different locations (/bin, /sbin, /usr/local/bin, /opt ,to name a few common ones).

Whatever the changes, something should be done about this obscene mess. The only logical argument to keep it is that millions of programs follow its ridiculous rules.

Reply Parent Score: 1

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

netpython Member since:
2005-07-06

If all the applications install correctly and get their menu entry then who gives a rats ass where the binairy resides?

As long as the application can be upgraded or get fixes when necessary via a sane package manager.

Reply Parent Score: 3

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