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

Doc Pain Member since:
2006-10-08

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.


I think you're right, I just wanted to illustrate what /usr is today.

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?


This is correct. Traditionally, /etc resided on the / partition and contained essential binaries to run and maintain a system at a low level, for example, when problems occur mounting further partitions. So you did have things like /etc/INIT, /etc/rc, /etc/mount or /etc/fsck, all of them in the same directory. At some point, there was a consensus to use /etc for the system startup scripts and their configuration, and later on, for configuration of installed application (Linux: sometimes /etc; BSD: /usr/local/etc).

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


This is not due to the concept in general, but to the developers, maintainers or distributors not following recommendations and standards (it you may call them this way), or just by their different interpretation about how to use existing structures. Again, BSD is more clean here than Linux, but not generally, as I have to admit.

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.


While projects like GoboLinux have interesting approaches of abstraction, most of the good GUI solutions still have the mess you described under the hood. If you can't get the developers to develop a reasonable consensus, this mess will only get worse, I believe.

Reply Parent Score: 3