Installing vs Compiling
There are actually two steps involved in getting running software. The first step is known as “compiling”, and this is when the developer of the software converts all the source code of the program into the program itself. On Windows, this results in a .exe file. On Linux, we simply call the equivalent file a “binary”, because it is in binary code that the computer can interpret, but not humans (easily). Oftentimes, a single .exe or binary is the result of hundreds or even thousands of files of source code, and some of that source code calls libraries that may or may not even exist on your computer.
Once the program is compiled, it can theoretically be run on a system. So what then, is the process of installing? Well, there are a few reasons we typically (but not always), need to install software instead of just running it. As mentioned above, oftentimes software calls functions in libraries that aren’t normally available on a system. Therefore, those libraries need to either be provided with the software, or installed separately. An example of this would be video games needing DirectX installed. Sometimes, if it’s a very common library like DirectX, you are expected to have a standard installation of DirectX that is available in the same spot, and so all software that needs DirectX knows exactly where to look for it. Other times, if the libraries are less common, they are distributed with the software so it knows exactly where to look for it. On Windows, these are often .dll files in the folder with the binary itself. On Linux, libraries are usually system-wide, so if you install something through your distributions package manager (apt or zypper or Discover), it will install the necessary libraries (called “dependencies”) along with the software, in a system-wide way. If you already have those necessary libraries, it will skip installing them again.
Another advantage to installing is that you can choose where to keep the files so they are easier to manage. On Windows, programs are usually installed to C:\Program Files, and a shortcut is made from your desktop or Start Menu to the .exe file in C:\Program Files<somedir>. On Linux, the installation location depends. If it’s something that’s considered a core system application, its often installed to somewhere like /usr. From there, your Linux system will link it to your desktop or start menu. However, if you place software yourself in a local folder (somewhere under /home), you’ll usually need to add those desktop and start menu entries yourself. So that is the difference between compiling (turning source code into a program) and installing (making sure you have the right libraries, and putting the files in the right place).
One very important thing to note is that if you download just binaries on Linux, they will not be “installed”. Some distributions have a / home//bin folder to place downloaded binaries into. Others recommend that you use the root-level folder /opt instead. You can run a non-installed binary by either double-clicking on it (your distribution may or may not prompt you to make it “executable”, which means allowing it to run), or navigating to it in the command line and entering ./<executable_name>. You can also create a start menu or desktop entry depending on your desktop. That is simply the equivalent of making a shortcut on Windows. Another thing to note is that if you download pre-compiled binaries, they may look for libraries you have in different places. That’s why sometimes you need to compile the binaries yourself, so that the compilation software knows where those libraries are. As a gamer, you should never really have to compile software, as all commonly used software is usually available in a pre-compiled format that is compatible with your system.
Most Linux distributions come with two package managers. One is the default distribution package manager that is accessed over the terminal/command line. On Ubuntu, this is apt, while on openSUSE this is zypper, or on Arch this is pacman. These are just programs that manage the installation of software on that distribution. This software checks a software repository (a place in the cloud software is stored) for that distribution, and installs from it. Software on a repository for your Linux distribution will know where to install, and will also install necessary libraries and other dependencies. Software needs to be packaged for each individual repository. That means for an app like Steam or Discord, someone needs to package it for openSUSE to have it available on openSUSE. The Arch or Ubuntu packages won’t work, and won’t be on the openSUSE repository. Sometimes there are auxiliary 3rd party repositories you can use depending on your distribution. Anything installed from a repository will also auto-update when you run your update program.
There is also PackageKit available on most distributions. This is the backend package manager for the GUI stores. GUI stores like Discover use the native repository for your distribution, but simply use a different program to install it. For most distributions, there’s no major difference between using a GUI powered by PackageKit, or the terminal/command line program, to manage your software. It is worth pointing out that installing software from your distributions repository is almost always preferable if it is available, because it will handle all libraries and other dependencies, and automatically make shortcuts.
In the even that software isn’t available through your native distribution repository, or any auxiliary repositories for your distribution that you have enabled, you may have to download it and install it manually. This can go a few different ways. You can download the binary directly, or an installer for specific distributions, or you can download a Flatpak, Appimage, or Snap.
If you download the binary directly, it will run out of wherever you place that binary. Binaries are usually distributed in .tar.gz format, and must be extracted and run. You can place that binary wherever you want, and run it from there, but as mentioned before, most people have a subdirectory in their home folder, or place it in /opt. If you want it on your desktop or in your start menu, you must make a shortcut to it, and it will also not be auto-updated. This is the least preferred method of installing, because it is harder to manage and requires more user intervention. The software may also simply fail to run, if it can’t find its dependencies.
If you download something like a .deb or .rpm, these are specific installers, similar to .exe files on Windows, but for specific Linux distributions. For instance, .deb is for Debian or Ubuntu, while .rpm is for Fedora or openSUSE. These can be installed by double clicking, or through the command line. If they are the only option available and you have a compatible system, they are nice, but if you are running a more obscure system that doesn’t support them, you are simply out of luck.
Recently, there have been developments in the Linux space that are new ways of distributing software without using distribution repositories and distribution specific packaging. One of these is called AppImage. AppImages are basically the equivalent of Windows .exe’s. When you download them, they contain all the dependencies they need. Because of this, they can be easily run on any system or distribution without having to worry about compatibility. There is also software called “AppImageLauncher” that will essentially install this software for you – moving it to a predetermined location, and adding desktop and start menu shortcuts. However, the downside about AppImages is that there’s no central repository, no easy way to find them, and no auto-updating. They also lead to lots of wasted storage, because many of them contain the same dependencies, even if you already have those dependencies on your system.
There is also a distribution method called “FlatPak”. FlatPak is similar to AppImages in that they are able to run on any Linux distribution. However, one advantage of FlatPak is the “Flathub” repository that contains most of the known FlatPaks, and is compatible with many GUI software management tools, and also enables auto-updating. Furthermore, FlatPaks will share dependencies if they can find them, and so that can save on space. FlatPaks also will also attempt to sandbox the application depending on configuration settings, which can prevent the application from seeing sensitive files. You can manage this configuration with the application Flatseal. Sandboxing can occasionally lead to things like the application not respecting your system-wide theme, or being able to see files you want it to see. Snap is similar to FlatPak, but right now only really used on Ubuntu systems. If a package is not available via your distributions repository, the Flathub repository and FlatPak is generally the next-best way to install.