Software management systems overview - Linux Tutorial

- [Instructor] The Linux software packaging system used to seem fairly foreign to users of self-contained commercial operating systems where software packages came in boxes or had to be individually downloaded from websites. However, the advent of the app store on mobile devices where software is installed from remote servers via a software management application has made the Linux style software repository more familiar. The preferred method of installing software on Linux is to have a local software management application download software packages from a remote secure software repository. Software repositories contain software packages, as well as an index of what they provide. These indexes and the packages themselves can be cryptographically signed. If the signature is incorrect, meaning it has been compromised then the Linux package manager will reject it. Software from software repositories is easier to install, tested by the vendor, and harder to exploit by hackers. There are multiple different types of software package formats on Linux. Debian based systems use dot deb packages, Red Hat based systems and SUSE use dot rpm packages. Even if two distributions use the same package format it's no guarantee that they'll use the same tool to install those packages. Debian uses the advanced package management tool. Red Hat uses DNF, a replacement for Yum as its repository based package manager, and SUSE uses Zypper even though both Red Hat and SUSE used the rpm command for local software package management, they use different tools to manage software from repositories. There were even distributions in the past that used a version of APT, which is historically associated with Debian packages to install rpm packages. Software packages, whether they're Debs, RPMs, or Tarballs are an archive that contains binary programs, documentation and configuration files, along with instructions on where they're supposed to be placed in the file system. Some package formats also include scripts to run during the installation process. Package managers have built-in dependency systems that list other required packages. If you're installing a package and it has dependencies then they will be installed first from the software repository, and then the package will be installed second. This way, all necessary software is installed in one operation. To be honest, at this point in time, all systems operate very similar and there's not much to differentiate them. On occasion, software is not available in a software repository, and you have to download source code and compile it. The source code may be packaged in an RPM or Debian package or be just a Tarball downloaded from an FTP server. Once the source code is downloaded, users need to compile it using development tools. This method of installing software isn't really recommended if you can avoid it. However, sometimes in the case of kernel drivers you may need to revert to compiling source code. A new category of software packaging has appeared in recent years, Sandboxed applications. This type of software uses a container to include the software and all of its dependencies. The advantage to this is that each package can include software dependencies and even different versions of libraries. This creates software that can in theory be used on any distribution. The down follows that every package has a lot of redundant software in it because software that would normally be shared between applications has to be included in each Sandboxed package. Since Sandboxed applications are not distribution specific, many hope that all software package formats on Linux would be unified, but in true Linux fashion there are now different software container formats namely Snapd, Flatpak, and Appimage. Snapd is a project created by the developers of Ubuntu with the goal of unifying the Linux software installation systems. Snaps are installed from the Snap store. Snapd allows users to have multiple versions of an application installed at the same time. Snapd is designed to be able to replace traditional software packages, even for the operating system. There is support for snap packages on Ubuntu, Debian, Linux Mint, and Red Hat Enterprise Linux. Flatpak is another distribution agnostic packaging system that unlike Snapd was not created by a distribution. Flatpak is a decentralized system, meaning you can obtain packages from several repos or what Flatpak calls remotes. Flat Hub is the most popular remote and has the most applications. Unlike Snapd, Flatpak is designed to replace user software, not all software. Flatpak is installed by default on most modern Linux distributions. If that's not the case, you can install Flatpak packages using most distribution package management tools. The third Sandboxed application system on Linux is Appimage. The concept behind Appimage is fairly simple, one file per app. To try out Appimage, all you need to do is download the package, make it executable, and run it as your regular user. It's similar to how dot eac files work in Windows. Appimage Hub is the central repository for Appimage packages and contains most popular applications. Appimage is different in that there's no real installation process. You just run the Appimage. My preference at this point in the Linux timeline is to use operating system packages from the software repositories whenever possible. If an application is not available in a trusted software repository I will use a containerized application from whichever system has it. In extremely rare cases, I will compile software from source code and usually only for development reasons. In this way, I can take advantage of the security and stability of Linux software repositories, the availability of containerized applications, and the flexibility of compiling from source when necessary.