Linked by Thom Holwerda on Mon 18th Aug 2008 23:33 UTC, submitted by Charles Wilson
Editorial GoboLinux is a distribution which sports a different file system structure than 'ordinary' Linux distributions. In order to remain compatible with the Filesystem Hierarchy Standard, symbolic links are used to map the GoboLinux tree to standard UNIX directories. A post in the GoboLinux forums suggested that it might be better to turn the concept around: retain the FHS, and then use symbolic links to map the GoboLinux tree on top of it. This sparked some interesting discussion. Read on for more details.
Thread beginning with comment 327242
To read all comments associated with this story, please click here.
There is nothing new under the sun
by jack_perry on Tue 19th Aug 2008 00:47 UTC
jack_perry
Member since:
2005-07-06

One of the nice things about the Amiga OS is that the user was taught to expect certain files in certain "assigns": system commands in C:, scripts in S:, libraries in LIBS:, device drivers in DEVS:, etc. (I think "assigns" were roughly equivalent to symbolic links to directories in Linux.) Developers followed a convention of installing their software in their own drawers and creating a new label (an "assign") by which the user could easily access it, like FINALWRITER: or DOPUS: or whatever. See http://en.wikipedia.org/wiki/AmigaOS#Conventions_of_names_of_device...

Two things amaze me about this system: (1) Amiga developers followed this reasonable convention nearly unanimously, and (2) no other platform seems to have noticed, or else no other platform's developers seem to respect whatever conventions there might be.

Reply Score: 8

sorpigal Member since:
2005-11-02

This is a good example of what's wrong with Linux and the Unix FHS replacement efforts.

It's not enough to have something that can work. It's not enough to have something that works for all use cases. It's necessary to have something where it's *obvious* what is correct.

Let me give an example: What goes in /usr/local and what goes in /usr? Depending on the Linux distribution or *nix variant, it varies. What about /opt? Again, it varies. Sometimes it varies per-application. The developer--much less the user--has no idea what should be put where, or where to look for what. Since nobody can figure out what to do, or figures out something different, everyone does it their own way.

There has to be a right way to do things AND it has to be an *obviously* right AND people have to actually follow the convention. With few or no accepted conventions and little agreement even on the conventions that exist the developer and user is left hopelessly confused.

Gobo has an interesting approach, but it is far more useful as a conversation-starter than a final solution. What we need more than anything is this amiga-like consistency that you mention: A way of doing things which (1) makes sense, (2) is obvious, (3) everyone knows, (4) everyone uses.

Without that everything will always be a mess.

The Elektra project is an example of an attempt to solve this problem for configuration. It has its issues--including the fact that it is culturally offensive--but represents an understanding of the idea that having well-defined and "correct" ways of operating makes life easier for everyone. Violations of convention are always going to happen, but hopefully they happen when it makes sense and are the exception rather than the rule.

A nice thing about open source in general is that if you believe you can do it better you don't have to convince anyone, you can just *do* it. But, sooner or later, for your idea to really win it has to be adopted and 'take over'. Gobo presents an idea about the FHS and how Linux can be more desktop-user friendly. It works, but *everything* works, even the bad-old traditional way. Gobo has failed as an initiative because it has failed to 'take over'; it's just Yet Another *incompatible* idea about how to do things.

The other nice thing about open source is that, in general, ideas survive on their merits *only*. Gobo didn't take over because it has deficiencies that are too broad and are all too clear. I don't think its *idea* was very bad, but the specific solution was insufficient. The thing to do next is to take what we've learned from Gobo and from people who hate Gobo and try again, and again until the solution's advantages outweigh the disadvantages AND trump the transition costs.

Some things will never change and some people will never switch to any 'improved' FHS, but if a plurality of users and distributions can be convinced then real progress can be made. Here's another example: Upstart. Everyone knows that sysv init sucks, or at least has its problems. Several attempts have been made to introduce improved replacements. Upstart is Yet Another attempt, but... it solves enough problems and has few enough disadvantages that it is now gaining broader acceptance. It's also relevant because it unifies and standardizes in a meaningful way that which was previously very, very nonstandard.

Reply Parent Score: 2