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

elsewhere Member since:
2005-07-13

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


That's kind of my point. The emphasis should be on FHS transparency via the user interface.

Reply Parent Score: 2