How to install software on Linux

You’re sitting in front of your new Linux computer, filled with both excitement and trepidation. Maybe you’ve gone out and bought one of the few rare laptops that came with Linux pre-installed (more on that on another article). Or maybe you sat in silent anxiety watching your neighbor and (hopefully) friend defrag and repartition your virus-filled bloated Windows system and setup Linux to dual boot. Or maybe your more adventurous persona found an unused desktop, wiped it clean (physically and digitally) and dared to install Linux on your own. So what do you do next? Why explore the wonderful and sometimes maddening world of Linux software without fear or viruses, malware, or things going wrong. Well, almost.

Get gooey with GUIs

Depending on the distribution, the easiest way to install a Linux program would be through a graphical tool. Unfortunately, different distros, even those with the same lineage, have different tools. And even more unfortunately, not all of them might be reliable. Instead of having a dozen or so screenshots and tutorials for those different GUIs, let’s try to take a look under the hood at the tools those interface use behind the scenes anyway.

Easiest and safest: Distribution packages

App stores might be en vogue today, both on mobile and desktops, but Linux has been using that system years, even decades before them. They just used a geekier “repository” terminology rather than “market” or “store” that people will always equate with paid software. Throughout those years, Linux hasn’t fundamentally changed and the most recommended way to get and install software is through your distribution’s repositories. These are packaged, tested, and vetted by people presumably more knowledgeable and more trustworthy than you neighbor (no offense to your neighbor). It’s pretty much like Google Play Store or Apple App Store, without suspicion of tracking or ulterior motives.

There are many Linux distributions and some come with their own package managers. Most of them, however, have their roots in one of three major binary distributions: Debian, Red Hat/Fedora, and Arch Linux. So we’ll mostly cover these three.

Debian and its derivatives, which includes Ubuntu, rely on the Advanced Package Tool or APT. That hasn’t changed over the years but its face has. APT is actually composed of a number of command line programs, all starting with apt-. That has become rather cumbersome too us so recently, a new single “apt” frontend was used. To install programs, one only has to enter (as root or with sudo):

apt install <package name>

Uninstalling software is just as easy with:

apt remove <package name>

Red Hat’s names for its package managers (yes, plural) is a bit more interesting and confusing. It’s equivalent to Debian’s APT is YUM, which is the Yellowdog Updater, Modified. It was based on an older package manager developed for Yellow Dog Linux, hence the name. While YUM continues to be used, it has practically been supplanted by DNF, the Dandified Yum, especially on Fedora. APT and YUM/DNF actually share a common, familiar syntax, so the way to install and remove programs are almost exactly the same:

dnf install <package name>
dnf remove <package name>

Things get slightly more complex with Arch Linux, which is why some consider it the advanced binary distro. Where APT and YUM/DNF use spelled out commands, Arch Linux’s pacman, short for package manager, uses single-letter flags. Saves on the typing but could make commands less understandable at a glance. Plus, combining different flags, sometimes the same letter with different cases, can become a bit confusing. Anyway, to install a package using pacman, you use the -S (Sync) flag:

pacman -S <package name>

To remove the same, use the -R (Remove) flag instead:

pacman -R <package name>

Fast and messy: DEBs, RPMs, PKGs

APT, YUM/DNF, and pacman are actually what’s called high-level package managers. Without going into too much technical details, what that means is that they handle tasks like figuring out what packages depend on which, checking if there are updates available, and automating all of those so you won’t have to manually do them. Sometimes, however, you might have to. Especially in times when a program isn’t available in any of the repos, official or not, and the source only distributes single binary packages. Times like those, you’ll have to go low-level.

Debian’s package format is actually DEB (ten guesses on why). You can’t use APT when dealing with individual Debian packages and you’ll have to use DPKG, the Debian package manager, to do that:

dpkg -i <deb file>
dpkg -r <package name>

Red Hat/Fedora has two ways to skin the poor cat. At its most basic level, you can install an RPM package using the RPM package manager like so:

rpm -I <rpm file>

Actually, the recommend syntax is:

rpm -Uhv <rpm file>

so that RPM will install or update an already installed package (-U) and give more verbose and helpful output (-h -v). To remove (“erase”) a package, do it like so:

rpm -e <package name>

That said, you can actually use YUM and DNF to also install single RPM files with the same command. The advantage here is that YUM/DNF will pull in the necessary dependencies if it knows the package, like if it’s just an update version of one that’s already in the repos. Otherwise, it will just use RPM like above.

Arch Linux is surprisingly straightforward in this regard and uses the same pacman to install local packages, just with a different flag:

pacman -U <pkg.tar.xz file>

Sandbox playgrounds: Flatpak, Appimages, Snappy

Linux has always prided itself for its (previously) unique software management systems, avoiding the DLL Hell of Windows or the insecurities of OS X (now macOS). That system, however, is far from perfect and the distro-centric package management not only puts the burden on distributions but also keeps both users and upstream developers beholden to them. In other words, there are few safe and secure ways to get more updated versions of some programs or make sure one program can run on all the hundreds of differing distros.

That’s why three new app distribution systems have recently emerged. Of the three, Appimage is the easiest to use. It requires nothing else other than the program that comes in an Appimage file. You don’t even need root/sudo to run it. Simply mark the the file as executable and run it using your choice of command line or graphical file manager:

chmod 755 filename.appimage
./filename.appimage

Appimage is able to do its magic because it contains everything an app needs to run. Think of it like a CD or DVD or almost something similar to OS X/macOS applications. Its simplicity, however, comes at a price. By default, the Appimage program will have access to everything that the user has and can potentially wreck havoc on the user’s files. You can run it in a sandbox but that isn’t the default and you have to take extra steps to do so.

Almost on the opposite side of the security and complexity scale is Flatpak, designed to be more of a cross-desktop effort. While Flatpak applications are more or less self-contained, they do rely on common libraries found in “runtimes” to make management less hairy. Applications run sanboxed from the system and from each other, making it more secure. The disadvantage is that using Flatpak is a bit more involved and almost mirrors how you distro package managers. Not only do you need to install flatpak itself, you also have to add repositories as well. While the young FlatHub does make it easier, it still isn’t a straightforward matter.

flatpak install <repository> <package name>

Snappy or Snaps are somewhere in the middle but are also all over the place. Created by Canonical, snappy was designed to mirror the app distribution systems found on mobile platforms, a.k.a. app stores. In fact, snaps are used extensively on Ubuntu Touch as its default app format. Like Appimage, snaps are self-contained compressed images that have everything an app needs to run on any Linux systems. Like Flatpak, it needs to be managed by a snapd daemon and programs aren’t run directly. Snaps are also sandboxed but to the point they can’t even access the user’s own dot/hidden files. Snappy, however, is still at its infancy though its use doesn’t seem to be as widespread as the other two outside of Ubuntu’s reach.

To install a snap, you have to run this command as root or with sudo:

sudo snap install hello

Fortunately, running it doesn’t require elevated privileges and can be run like any installed program:

hello

Nightmare waiting to happen: Binaries

Some software sources do not even bother properly packaging their programs in even DEB or RPM formats. Rather, they expect users to execute “installers” and trust them. That is, of course, a security exploit, especially for those that only provide compiled binary programs. But even if they use a BASH script, it eventually boils down to how much trust you can give to the source. This is where Linux can become like Windows if you’re not careful what you’re chmod’ing and sudo’ing.

Use the Source, Luke: Compiling

And finally, there’s the most ancient method of installing software on Linux: compiling it from source. For small programs that are no longer available on modern repos, it’s perfectly fine. But do prepare yourself for a world of pain. In the past, compiling programs was almost a standard affair using just three commands:

./configure
make
make install

Of course, that’s more or less a myth. make install may or may not require root privileges and configure can always be fed some flags. These days, however, some things have become both simpler and more complex with different build systems involved. When in doubt, always README.