Linux filesystem hierarchy: time for a overhaul?

tux_compAn important aspect that often decides the success of a software is simplicity – how easily can end users understand and use it? Does it have a steep learning curve? While there are numerous Linux software which are a delight to use, the Linux filesystem probably doesn’t fall under this category because of its hierarchy and nomenclature.

The Linux filesystem structure and naming need to be simpler.

Most of the end users are not from a technical background and shouldn’t have to be ‘technically smart’ to use a solution. They shouldn’t have to bother about /usr/local/sbin, /bin and /usr/bin. While it makes perfect sense to a developer, an end-user shouldn’t have to figure out that he needs to run man hier or which/find to understand the nomenclature or quickly locate a particular program or file. It’s great to have many useful tools around to increase the number of ways to a solution but a solution needs to be complete to a certain degree of usability by itself. Microsoft Windows makes a perfect sense to end users when they see C:\Program Files but the Linux filesystem hierarchy needs a deeper understanding, at least the first hour isn’t enough for the majority. Why not something as simple as /Software? The same holds good for a user’s home directory. The root user has his files under /root and others have their corresponding home directories under /home. It probably makes more sense to have a /Users to locate home directories of all users easily.

While I don’t have a problem with this as I am using Linux for years now, I see the problems surface when I introduce Linux to a friend or someone who has heard great things about the OS and is interested in trying it out. It is quite different from what they are used to or how they store their files. Once a friend from Arts background asked me “/dev is for developers right? Linux being a highly hackable OS and all?”. I took some time to get out of the initial shock and explain that it stands for “device files”. How hard is it to name it /Devices instead?

Changing the filesystem hierarchy and nomenclature doesn’t seem to be a mammoth task. The filesystem internal structures and logic do not need to undergo any change. It has more to do with how you name the directories and where you want to place them. Of course, apps with hardcoded paths will have the overhead of changing them. Moreover, a filesystem tree with less branches definitely can simplify things further.

It would be great if the major Linux distributions consider this area and re-think the hierarchy as well as the nomenclature. After all, a common goal of all the generic distributions is to deliver the best user experience.

9 thoughts on “Linux filesystem hierarchy: time for a overhaul?”

  1. You have to remember that the switch won’t be that easy. You seem to underestimate the number of programs with hard-coded paths. There are thousands, probably ten-thousands of them, and changing them would take years, if not more.

    Also, normally end users will only spend time in their home-directory. I don’t know a reason why somebody who doesn’t even exactly know what a file-system is would do in /dev or in /usr. Then there are a lot of sysadmins and programmers who are used to the current naming. And, finally, it is fast to type, which I consider a huge advantage.

    1. There are distros which have done that.
      “I don’t know a reason why somebody who doesn’t even exactly know what a file-system is would do in /dev or in /usr”
      – you should not underestimate the end user as well. They do not know today because the names are obfuscated and uninteresting.

      1. I don’t think they changed all paths in all makefiles for every single unix-command ever written. That’s a mammoth task. They probably reworked the most-used commands, which is probably fast, but they did’t change everything ( I guess ).

        And if you did, to stay consistent, you would have to rename most of the commands. Why ‘ls’ instead of ‘List’? Microsoft did that, and I don’t consider ‘Print-Directory’ a good name for a command. It is too long, too hard to type, and so on. Also, I consider the structure of the Unix file system very good. /usr is bad, it was originally used for users, but now has become something like a replicate of / , but the rest like /bin, /var, /sys and so on are pretty well designed.

        And if you’re an end user and keen to learn something,you are probably willing to invest some time. As a sysadmin, I would be really pissed if I had written around 200 scripts and would have to change and debug them again, as well as learn the new structure. I know that I wouldn’t like that very much.

        1. Also, I don’t consider the Windows structure as a good example. I wouldn’t know where to find the documentation for a program, or a dictionary, or a file with random contents.

          1. That’s your personal opinion. With all due respect, 96% of PC users would disagree. Probably they wouldn’t if they used Linux from the beginning. But now it’s the other way round and end users want simplicity.

        2. I am not suggesting that the older structure should be discarded. Symlinks would keep applications that do not change to newer structure working.
          Well designed doesn’t necessarily mean well-usable.

          1. eah, sorry, I understood your comment wrongly.

            A thing I liked about the naming is that it was consistent in all places (at least in the old Unix V5 or so). The functions of the C-standard library follow the same naming convention like the file system or the commands, short, 2-10 lower-case letter names that are easy to type, but still carry the meaning. When we would change that, this consistency would vanish, because changing the naming in all places is extremely hard.

            Also, I agree that learning the naming of the structure is not easy, but using it is a great pleasure. At least, it is a structure, isn’t it?

            As far as I can see, there are two other things we could do: finalizing the structure so that there is only _one_ directory for binaries, one for libraries, and so on. That would make it all so much easier, because always remembering if your stuff was in /usr/bin or in /bin/ or in /usr/local/bin or another place is extremely bad.

            Or we could make it the other way around: making a directory /prg where every program has an own directory (like Programs in Windows), a directory for coreutils, x11, and so on, where the structure within coreutils or x11 is something like x11/lib and x11/bin and x11/share. That would be cool as well, but here the structure would have to be very consistent, because otherwise it wouldn’t work.

Leave a Reply

Your email address will not be published. Required fields are marked *