OSNews

This doesn't happen in Linux, as there are only two standard ways to install software: compiling and installing packages. Such methods can be inconsistent and complicated for new users, but I am not going to write about them, as it has been done in countless previous articles. Instead i am going to focus in writing about why it is difficult for developers to provide a simpler way.

So, why can't we install and distribute programs in Linux with the same ease as we do in other operating systems? The answer lies in the Unix filesystem layout, which Linux distros follow so strictly for the sake of compatibility. This layout is and was always aimed at multi-user environments, and to save and distribute resources evenly across the system (or even shared across a LAN). But with today's technology and with the arrival of desktop computers, many of these ideas dont make much sense in that context.

There are four fundamental aspects that, I think, make distributing binaries on linux so hard. I am not a native english speaker, so i am sorry about possible mistakes.

1-Distribution by physical place
2-"Global installs", or "Dependency Hell vs Dll hell"
3-Current DIR is not in PATH.
4-No file metadata.

1-Distribution by physical place

Often, directories contain the following subdirectories:

lib/ - containing shared libraries
bin/ - containing binary/scripted executables
sbin/ -containing executables only meant for the superuser

If you search around the filesystem, you will find several places where this pattern repeats, for example:
/
/usr
/usr/local
/usr/X11R6

You might wonder why files are distributed like this. This is mainly for historical reasons, like "/" being in a startup disk or rom, "/usr" was a mount point for the global extras, originally loaded from tape, shared disk or even from network, /usr/local for local installed software, I dont know about X11R6, but probably has its own directory because it's too big.

It should be noted that until very recently, unixes were deployed for very specific tasks, and never meant to be loaded with as many programs as a desktop computer is. This is why we don't see directories organized by usage as we do in other unix-like OSes (mainly BeOS and OSX), and instead we see them organized by physical place (Something desktop computers no longer care about, since nearly all of them are self contained).

Many years ago, big unix vendors such as SGI and Sun decided to address this problem by creating the /opt directory. The opt directory was supposed to contain the actual programs with their data, and shared data (such as libs or binaries) were exported to the root filesystem (in /usr) by creating symlinks. This also made the task of removing a program easier, since you simply had to remove the program dir, and then run a script to remove the invalid symlinks. This approach never was popular enough in in Linux distributions, and it still doesn't adress the problems of bundled libraries.

Because of this, all installs need to be global, which takes us to the next issue.

1. "Linux Binaries, Part I"
2. "Linux Binaries, Part II"