
Permalink for comment 327869
Member since:





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