Fedora project proposes major changes to filesystem hierarchy

Red Hat developers are proposing a fairly significant change to the Linux/Unix filesystem hierarchy. Find out what they're trying to fix, and what it could potentially break, if it goes forward.

For many years, Linux and Unix-like operating systems have adhered to a particular way of organizing files, but with the evolution of the OS, this system has grown in complexity and, some would say, downright messiness. This has led two Red Hat developers, Harald Hoyer and Kay Sievers, to propose a solution. But even though the current filesystem has some inherent quirks that can make it confusing for some, trying to clean it up introduces its own new set of problems.

First, here's a quick snapshot of the root filesystem:

  • bin: Essential command binaries
  • boot: Static files of the boot loader
  • dev: Device files
  • etc: Host-specific system configuration
  • lib: Essential shared libraries and kernel modules
  • media: Mount point for removeable media
  • mnt: Mount point for mounting a filesystem temporarily
  • opt: Add-on application software packages
  • sbin: Essential system binaries
  • srv: Data for services provided by this system
  • tmp: Temporary files
  • usr: Secondary hierarchy
  • var: Variable data

In a nutshell, the Fedora change would "move all executable files into the /usr/bin directory and their libraries into /usr/lib or /usr/lib64, as needed," as reported by IT World's Brian Profitt.

While most agree that the changes make good sense, the problem is that it goes against the Filesystem Hierarchy Standard (FHS) based on Version 7 Unix and Sun operating system/ Solaris. In addition, it has repercussions for shell scripts. Profitt goes on to explain the dilemma:

A lot of shell scripts have #!/bin/sh as their first line (or #!/bin/bash or what have you). If /bin went away, any script with a call like this inside would break. Some scripts might use env to locate the script interpreter, and since env is already in /usr/bin/env, these won't have problems.

Then there's the convention used to override shell built-ins by calling the full path to the non-built-in version. If the full path is used and the built-in has been relocated, that's going to break, too.

This is an experiment that developers will definitely want to keep tabs on. What do you think of this proposal?