Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Once upon a time, Linux enthusiasts were forced to compile the software they needed. It was the only option available. While the act of compiling software was itself not so bad, the need to chase down dependencies was a deal breaker for many Linux newcomers.
These days however, package management for most Linux distributions has made any sort of software compiling something most people can safely avoid.
As I was pondering these changes to the Linux world, this got me wondering: do most Linux users really prefer one kind of package management over the other? In this article, I hope to shed some light on this once and for all.
I’ll also consider the overall availability of software titles for various Linux distributions and how this affects adoption by anyone looking to try out a given distribution.
RPMs and Debian packages
While there are other software package types out there, the two most commonly used are the RPM and Deb (Debian package). Each option offers various Linux distributions a variety of great FoSS applications from both repositories and direct download links. Each option has its own merits, but the biggest difference I’ve found to the end user is with software availability.
On the one hand, I’ve found a lot of enterprise software favoring RPM availability over that of the Debian package. At the same time, I’ve found that the majority of new software being introduced to the masses, is far more likely to see the Debian packaging than RPM. Mind you that this gap is closing, however it’s still very much an issue that affects end-users based on my own experiences.
Where things get interesting is when you start to look at distributions such as PCLinuxOS (based on RPM using Mandriva) that rely on RPM packages, yet use Synaptic for the installation of any desired software. This is fascinating since Synaptic was designed for apt-get and Debian based distributions. One might even think of this as a blurring of how we install software on the Linux desktop.
Alternative software installation methods
Despite that most distributions come with their own methods for installing software, there have been attempts in the past to get you to use alternative methods. The most famous among them would have to be Linspire’s famed Click-n-Run (CNR) software installer. As the company began to drown, they tried some crazy things to stay afloat. Among them was the idea of allowing non-Linspire-based Linux distributions to install software using their CNR installer.
At its core, the idea might have been more successful had there been less duplication with the existing software repositories already provided by most Linux distributions. Even worse was the issue of software being outdated in CNR. While the installer was worthwhile to those using early Linspire releases, in its later days it was pretty sad to watch.
The next alternative method for installing software was known simply as klik. Unlike CNR, klik handled software installation in a completely different way.
In the interest of accuracy, klik didn’t actually install software in the traditional sense. Instead, your desired software installation was readily available after completing an application selection. In the end, you would end up with “application images” (much like disk images) made up of software “recipes” based on your application selections.
The obvious advantages to using these klik packages is that when it was time to drop an application, all one had to do was drag it to the trash. Much like one would see on OS X. The downside to this type of software management is that you could only run around 7 to 8 klik applications at once. Considering how unlikely it is most people would be running more than 8 applications at once, klik could have been a smashing success.
After a bit of a transition period, the klik project died a peaceful death and other like-minded projects were left to take its place. One of the most commonly known is called Zero Install, followed up by the klik-based Portable Linux Apps project. Both of these projects still work, each offers the same benefits as you would have found with klik. The only difference is that Zero Install is completely cross-platform while Portable Linux Apps is for Linux only systems.
Self-contained apps come with a price
Since the beginning one of the biggest issues I found with klik and similar software solutions was their lack of reliable updates. It’s understandable, since you would need something in place to ensure that all of the software is being checked on a regular basis.
Still, most Linux users expect to have their applications kept up to date. This is why they rely on the package management options that come with their distribution!
I can’t stress enough just how fantastic ideas like Portable Linux Apps could be if there was an update ability to it. If this was in place, we’d see software installation as a cross-distribution standard that everyone could get behind!
No more running as root or touching the operating system like software installed through your existing package manager. The benefits are there, but these exciting ideas come at a price since you are completely reliant on a third-party for software updates. Worse, you’ll need to visit the websites and download these updates manually. Speaking for myself, this isn’t where I want to spend my time.
Software repositories
It should be mentioned that Debian and RPM packages don’t self-update by themselves. So they share that in common with the alternatives listed above. However, if I install software with a Debian package, then later add a software repository offering Debian packages, that application will have the opportunity to be updated easily when I update the rest of my Linux distribution. This is why we see greater adoption with Debian and RPM packages than with any of the alternatives. They play well with updates.
Other distributions do have their own alternatives to Debian and RPM packages that work on a similar principle. In the end, the idea is that the ability to update the software should always be a viable option. This, not system resource concerns, is what I see holding back options like Portable Linux Apps from greater adoption.
If there was a way to enjoy the benefits of a Portable Linux Apps repository yet continue the distribution-agnostic benefits already offered, I could see standalone applications doing really well.
Let the users decide
Over the years there has been one constant that I’ve observed: Linux users will use what they want. And if what they want doesn’t exist, they’ll create it themselves. The greater takeaway here is that the Linux desktop is about choice. Therefore, the idea that one option is absolutely correct is simply absurd.
I know people personally who roll their own vanilla distributions and compile each and every one of the applications they want. Clearly, this is not the way I’d want to handle software management, but it works for those people.
Instead, I prefer anything using Debian packaging on my desktop. For me, it comes down to available software titles and the fact that, while imperfect, the package management that my favorite distribution provides works pretty darned well.
