In this wide world of Linux, there are primarily just two package management systems which reign: RPM and Deb. Most binary distributions use one or the other and there has long been tension between the two. So which system performs better?
Package management is one of the selling points of Linux distributions. Nothing else comes close. While many argue that it’s much easier to install programs on other operating systems such as Windows and OS X, nothing could be further from the truth. At least, when it comes to officially supported packages.
Within other operating systems if you want to install a program, you first have to find something that’s suitable. This would normally entail a search on the Internet or talking to friends. It might even require visiting a software store and parting with some hard earned cash! Next, insert the physical media (if required), install the software by running through the installer clicking “Next” several times, download updates and if all goes to plan, be on your way.
In Linux however, everything is integrated and simple to use. Most of the software you’ll ever want to install is not only search-able from a single window on your desktop, it’s also installable with a single click. Not only that, but for the extra charge of absolutely nothing all future upgrades are taken care of for you, along with the rest of the system.
The problem is that generally it’s a very distribution specific thing, because, well that’s what distributions do. Each system is built with their own version of various system libraries and even though binaries may work across several distributions, they are just as often incompatible. While users can download and install packages themselves, the system is best controlled by a package manager which keeps track of everything. Installing packages manually might by-pass the manager, making the system inconsistent. Therefore, most packages are managed through a repository; a database of available applications. If an application the user wants is not available in an official repository, there are hundreds of extras available on-line. If a user can find an appropriate binary for their system, package managers can install it along with any required dependencies automatically – so long as they are available in the repository.
But why are package managers so important? Well, due to the fact that most of the software available in Linux distributions is free and open source, they are built upon that heritage. Part of this is a belief in “not re-inventing the wheel”. Most open source projects will take advantage of other code in the form of a library, which enables extra functionality for next to no effort. While software for Windows and OS X often includes all the libraries they need within the program itself, Linux makes the libraries available to the entire system so that any program which needs it, can do so without having to duplicate them. This means that a particular piece of software may not run if it doesn’t have the required libraries! Arising out of the need to install, track and manage all these dependencies, package management systems were born.
Packages in Linux generally fall into two main categories. Either source code, where they are compiled from scratch and installed directly onto the system, or pre-compiled binaries. Binary packages are then usually one of three types: RPM (RPM Package Manager) from Red Hat, Deb (Debian packages), or plain old tar balls. When looking at these files at a low level, there is not much difference. Technically an RPM and a Deb are very similar, they both contain the binary application itself and meta-data which a package manager will use. Also, installing a package rarely takes up lots of resources, it’s mostly just extracting an archive onto a file system and marking it as “Installed” in a local database. It’s generally the database queries, look ups and calculation of dependencies which introduce differences in performance.
Still, if you’re a Linux user content with what your distro has to offer you then you might not care how well your package manager performs. Even if you are, graphical interfaces these days are very similar and so switching between distros does not pose much of a learning curve. With all the changes that package management has been through, you might think there would be a single package management system. One that was so powerful that it just had to be used by everyone. Well there isn’t yet, although some are in the works such as PackageKit. As previously mentioned, most distributions are based on one of those binary formats, which then add a package management layer on top. Naturally Red Hat’s Fedora uses RPM, while Debian and variants such as Ubuntu use Debs. It would be a cold day indeed to see one adopt the other!
Citing improved package management performance as one of the new features, we recently took a look at what the new Fedora 11 Leonidas release had to offer over the previous version. Now the time has come to compare Red Hat’s package manager to one of the most popular, that of Debian. So, how do they compare?
Firstly, some words on our two opponents as they are not created equal. Fedora 11 was recently released and includes a newer kernel and version of GCC than Ubuntu does. Even though the two are very different, there are many core similarities. Both provide basic package management tasks such as searching, installing and removing applications. While the sizes of the local package databases will not be the same, it is the differing implementations of the manager itself which will impact the most. For the tests conducted, they have been made to be as fair as possible. For the package installation test, a native version of a binary for each distro was used which required no dependencies. The 14MB files were within 100Kb size of each other, so this should reflect the handling of the file rather differences between the files themselves. Other tests are not so even keeled. For example, when updating the package database, Ubuntu has to handle many more repositories then Fedora (and yet it still manages to come out on top).
The test system used included an AMD Athlon64 CPU with 1GB of memory. Both operating systems were 32 bit only and included the respective default GNOME environments. Each test was run ten times and the results logged. After every single test, the computer was re-booted so that cached memory could not interfere with the result. The average of these results was then taken to provide the values represented below. Let’s take a look.
Time based results of package management tests
Ubuntu was faster in every single test, with considerable improvement over installing and removing packages.
CPU usage results of package management tests
Once again we can see that Ubuntu used less CPU when performing most of these tests compared to Fedora, with the exception of two.
Comparison of speed performance factor
Ubuntu effectively trounced Fedora in every single test from the smallest factor of two, to over fifteen times.
Comparison of CPU usage factor
Here we can see that Ubuntu was also more CPU efficient than Fedora, except for two areas by a small margin.
Package management under Linux is an art which is taken for granted by many. In light of these results it is important to note that most users won’t care about how fast or slow transactions are, but rather let the package manager do what it needs to in the background. After all, most have come from a system where none existed at all! Still, for terminal junkies and those who work with packages on a day to day basis, dealing with a slow and weary package manager can be torture.
There’s no doubt that for staunch supporters of either camp it will continue to be a fiercely contested issue. Either way, when you look at the numbers Yum is completely trounced by Debian’s aging package management system. Fedora 11 might have introduced a few new improvements to RPM, but perhaps it needs a complete overhaul if it’s to ever compete.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62