I am having trouble understanding Linux executable formats and software distribution packages. There are so many different distributions of Linux itself, and it seems like every software package has been compiled separately for each distro. Why is this? I understand that some "packages" are made to install on different distros, but is the executable format for the software different?

Also, why do many Linux users prefer the command prompt versions of applications vs GUI versions? I can understand the need for small footprints, but even GUI apps can have small footprints if they're coded right.


Package Managers & Dependencies

Most Linux distributions use package managers for software installation and removal. Package managers provide some benefits such as the possibility of using a central repository from which (almost) any piece of software can be downloaded, the organization of pieces of software into bundles that can be installed as one cohesive group, and the main benefits: automatic dependency handling and tracking what changes packages make so they can be uninstalled.

Certain pieces of software might require certain libraries or other programs to perform duties that would be redundant if it was re-implemented in that piece of software. Packages allow for the expression of these dependencies.

Differences: package formats and strategies

There exist several different package managers. Each was created because the existing ones did not meet the needs of some people. Each package manager requires packages in its own format.

Furthermore, different distributions have different requirements of the software that is included. There are a number of pieces of software that can have differing capabilities depending on options that are given when it is compiled from source code into a machine executable. Some distributions want to provide full feature sets and a rich experience while others want to provide as lean and simple an experience as possible, and there is everything in between. Also, the distribution may decide to format its directory structure differently or use a different init system. They may decide to bundle the software differently: there may be a package called "dev-utils" in two different distributions, but one version of that includes yacc while the other doesn't. Because of these different needs, the distributions choose to compile the software in different ways.

This is why even if you have a package in the correct format for your package manager, it may not work if the package was intended for a different distribution. For instance, that package might rely on yacc being installed, and it expressed that dependency through requiring the "dev-utils" package, but your "dev-utils" doesn't include yacc. Now there is a package installed with an unmet dependency.

It's not really a problem.

A big part of being a Linux distribution is maintaining a central software repository. The distribution takes care of maintaining all of this for you. This actually makes it very easy to install software. You typically use the package manager to search for and select some packages, then tell it to install them; it takes care of the rest for you. The Windows software installation process includes hunting for software on 3rd-party websites, trying to locate the appropriate download link, downloading, virus-checking, and running an install program which then asks you a bunch of irrelevant questions. That whole mess isn't the standard on Linux.

The repository can't possibly include everything

Now, there may be cases where a piece of software you require is not in your distribution's repository. The packages that are supplied by a software repository is one of the differentiating features of distributions. When you can't find the software you need in your distribution's repositories, there are three possible avenues (really, two plus a way to really screw things up).

Community Repositories

Many distributions have unofficial repositories that are maintained by people not associated with the distribution. Ubuntu calls them PPAs, Fedora calls them Fedora People Repositories. Arch Linux doesn't have a specific name for third-party repositories, but it does have its AUR, which is a collection of "recipes" for packages (note: there is only one AUR). You might first try installing a package from one of these sources since it is easy to un-install them if they don't work.

Compile from Source

If you can't find an unofficial repository with what you need, compiling from source is not hard. You need to have your distribution's development package installed; this includes basic things like a compiler, linker, parser, and other tools that are usually needed for compiling software. Then you find the source code of the project (which is almost always packaged in a .tgz or .tbz (called a "tarball"). Download it into its own directory somewhere, extract it (using tar -xf filename.tgz, and usually go into the one directory it created. In that directory may be a file called README or INSTALL. If it exists, go ahead and read it; most of them tell you to do the same thing. The next few steps are done at a command line. Run ls, and look for an executable file called configure. If it exists, run it by doing ./configure; it can take a couple of minutes sometimes. That usually runs some tests to figure out how your distribution has things setup, and it makes sure you have the tools required to compile this piece of software. The next step is to run make. This actually compiles the software, and it will likely take some time - anywhere from a few minutes to hours depending on the size of the software you're compiling. Once that is done, you run make install. This installs the software, which involves copying the products of the compilation to the appropriate places in your filesystem. After that, the software is available for use.

This was a long section, but it's summarized as "README, ./configure, make, make install". That's the routine to remember.

Install a package from another distribution (don't do this)

I list this only because it is and alternative, but it will almost certainly not end well. It is possible to install packages for other distributions, and you might find yourself wanting to do that. Well, don't. Don't do it until you understand your system very well. In fact, I'm not going to put any commands here showing how to do it even though it's possible. If you do get to that point where it seems like this is the only option, don't install the package using the package manager; instead, pull things out of the package and place them in your system manually, along with notes about what you've done so that you can undo it if necessary.

The command-line bit

Some people prefer the command line for the advantages it gives them. These can be summarized into three things:

  • Ease of automation
  • Speed (compared to clicking all over the place in a gui)
  • Expressiveness

The biggest of these is expressiveness; there are things that can be done at a command line that are not possible in a graphical interface.

Finally, command-line instructions are frequently given in helpful forums such as this one because it is much easier to convey the correct information than giving "click-here-then-there-then-there" type instructions.


Sorry for the long answer. If you want the quick and dirty, just read the summary.


  • Executable format is the same.
  • There are different package managers that are not compatible, even if the packed up programs are. (You could see a package as an installer file like .msi files).
  • Basically different distributions/versions have different versions of core libraries, and for consistency and stability reasons applications need to be built against those versions. (Linux version of dll hell).
  • Different distributions do things in slightly different ways, and that can in some cases be a compatibility problem.
  • Command line can be faster, and the unix command line is vastly better than the Windows command line.

Package managers

First of all, package managers. The primary purpose of a package manager is to maintain a database of installed packages and the files that constitute that package.

Package managers allow for easy installation of packages, and generally also for easy removal. They also allow packages to specify various scripts that might need to be run at installation / removal to maintain system consistency (such as registering the package to some subsystem related database).

Different package managers

There are various different package managers with different strengths and weaknesses. Examples are rpm and the debian package manager (.deb files), but there are others. These package managers obviously need different formats and are thus not compatible.

Different distributions or versions

As the majority of a Linux distribution is open source there is much more code reuse than on Windows systems. An application might use a number of libraries for various parts of its functionality. Those libraries themselves often also do so, sometimes the same library.

Unfortunately, libraries exist in different versions and some of those are not compatible (especially binary compatibility for pre-compiled executables). Multiple versions can nicely coexist on Unix systems (less dll hell from that perspective), but in most cases using two different versions of a library in one running program is asking for crashes.

Binary distributions therefore often upgrade their own version to go on to new versions of various core packages (in other cases you need big updates).

Different other files

Distributions also differ in the way where particular files are located, and how the configuration is managed. Depending on the package that could have an impact on that package.

Command line

Unix primarily is a workstation and server operating system. This means that it is designed with professional system administrators in mind. Automation is an important part of the system administration toolbox and shell scripts are the way to do it. Try to add a leading 0 to 1000 file names in graphical file manager.

As administrators often administrate many machines they need to do the same things on a number of systems. Using tools like ssh it is extremely easy to perform the task on a number of systems in one go, and just wait to let the computer do the job.

Precise specification, automation and repeatability make command line much better in potential than graphical tools for administration tasks. Unix also has a number of different shells available and this competition has created extremely powerful shells that are almost incomparable with the windows command prompt.

Microsoft has actually understood this well, and offers powershell as a command line replacement, as well as the latest version of windows server is primarily command line administered.


The executable formats are all the same across distributions, but executables might require additional underlying software to work properly. If you look at Redhat-based distributions, the installation product is an rpm, which will include all of the requirements for a given piece of software, and will not by default install that software unless the requirements are met. (yum is an alternative to rpm and it is used by some Redhat-based versions). By definition, a GUI must have a much larger footprint than a command prompt interface. The underlying philosophy of UNIX is to simplify everything so that a given task will work as efficiently as possible. That is why there are so many utilities that will perform a single task with the output of that task being able to chain to the input of another task to do something else.

  • To be correct, yum is not alternative, it works above rpm providing nicier interace and features like repositories.
    – rvs
    Oct 29 '11 at 15:24

Different distros have different installation prerequisites. However, there are RPMs or DEBs (or other packages for other packet management systems), that work for more than one distro. The philosophy of Linux makes source codes readily available. When compiling your own software, it's pretty much the same routine on all distros, and it's always the same .tar.gz archive you use.

Compiled RPMs are more like part of the system; an application itself, as a stand-alone entity, is meant to be distributed and compiled on every target.

Your second questions is something completely different... Well, "a lot of Linux users" prefer CLI applications for many different reasons, small memory footprint is only one reason. When using SSH, CLI applications make more sense, especially when working off-site on servers. More often than not, those servers don't have graphical environments installed. When running non-daemonized programs, they're very easy to abort. Ctrl - c, and the program is gone. Also, many programs log to console, so it's easier to debug. When programming, you're doing most of the compilation in the console. It just makes more sense for quick compile debugging. It's either that, or reading log files, sometimes, reading the console is quicker.


Arch. Or FreeBSD, which is developed as a whole. (RHEL, SLES and similar are $upported as a whole.)

Laptop use: Mint

Usable hackability: Arch.

Sadistic hackability: Genoo.

Fun hackability: LFS.

Supportability (server): RHEL, Ubuntu LTS, FreeBSD (different than Linux).

  • You may want to edit your answer to make what you are trying to say, more clear, and to correct a couple of typos/grammar mistakes.
    – haziz
    Apr 24 '12 at 7:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.