eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The best and the worst attributes of Linux as a desktop operating system involve acquiring and maintaining software applications. For me, the positives outweigh the negatives, making Linux the best desktop operating system option I’ve encountered, and the one I choose at work and at home.
If Linux is to pile up more desktop adherents, the vendors and communities that back the open-source platform need to work together to accentuate those positives and shrink down the negative aspects of getting and managing software on Linux.
The GOOD: Software packages are your friends
All the bits that make up a typical Linux distribution, from the kernel to the little applets on the task bar, are divvied up into software packages, each of which contains metadata about what its bits are supposed to do, where they came from and what other packages they require to operate.
As a result, Linux is modular enough to squeeze into all sorts of vessels, and to integrate code contributions from many different sources without becoming unmanageable. In fact, as long as you stick to software that’s been packaged up for your Linux distribution of choice, there’s no better platform for staying in control of what runs on your system.
In order to keep my Linux desktop up-to-date, I don’t have to spend my time clicking on a succession of different vendors’ system tray-embedded update applets, reiterating to Adobe, Apple, et al, that I still don’t want to install that Yahoo tool bar or take them up on that Quicktime up-sell opportunity.
The BAD: Linux and proprietary software don’t mix well (usually)
The desktop market share of Linux is pretty small compared to that of Macintosh or Windows, which tends to make the platform an unattractive development target for software vendors. Making things worse, Linux’s slender share is divided up between many different Linux distributions, many of which require different packages.
As a result, even those software vendors that do support Linux often end up producing script-based installers that work on multiple Linux distributions, but that leave these systems in a less manageable state by working outside of Linux’s various software packaging frameworks.
When you’re dealing with open-source software, the companies and communities that build Linux distributions are able to grab the source and package it up for easy consumption, thereby tackling the packaging and distribution work on behalf of the upstream developers. This doesn’t work so well with proprietary software, in part because the code is closed, and in part because volunteer packagers prefer to donate their time to free software projects.
There are exceptions, however. When I fire up a fresh Ubuntu install and cruise to YouTube.com, the system offers to download Adobe’s Flash Player, and when the inevitable security issues emerge, my proprietary Flash Player updates occur alongside all my free software updates, and there’s not an unwanted tool bar offer to be seen.
The UGLY: Open-source software gone wild
When the source code is freely licensed and available, it’s much easier for someone to package. However, someone still has to take the time to do the packaging–just because a given Linux distribution could offer packages for an open-source application doesn’t mean that the distribution will offer them.
Significantly complicating matters is the fact that it’s much easier to configure, compile and install an open-source application than it is to package that application. Sure, you have to install some development tools and root out various needed libraries, but it usually isn’t too tough to go from a source code tarball to a running application.
The ugliness accrues as you move forward, and parts of your system are updated without any regard for the dependencies of the roll-your-own open source apps living on your machine. When security updates for your self-compiled apps come down, they won’t get applied unless you keep an eye out for them, fetch the code anew, and repeat the configure, compile, install procedure. Forget about managing this process on multiple machines.
This is what gives me pause about Novell’s SLED series of Linux desktops, and their constrained selection of software packages. Why should we mess with unpackaged apps, or spend time packaging them yourself, when other options are available with much more expansive package catalogs?
THE WAY FORWARD:
1. Everybody Hug
Ubuntu is (and has been for a couple years now) my desktop Linux distribution of choice because Ubuntu offers a very large catalog of packaged and ready to install applications. Ubuntu owes its large application catalog, in large part, to the Debian project, which has been cranking out software packages on a volunteer basis for years now.
I’d love to see Novell and Red Hat figure out a way to work with the Debian project to reuse the packaging work that its members are doing to broaden the range of software packages available for easy installation. It would take some work to translate the Debian packaging efforts to work with Novell and Red Hat’s RPM-based distributions, but Novell already has a project underway capable of building packages for SUSE, Red Hat, and Ubuntu-based distributions.
2. Proprietary Apps are People, Too
No less important than maximizing the work that’s already being done around packaging open-source applications, it’s important that major Linux distributors make it easier for proprietary software vendors to package their wares for Linux.
I know that many in the open-source community have an allergic reaction to proprietary software, but if open platforms such as Linux are to realize their potential, they must host proprietary applications just as well as, and better, than proprietary platforms do.
Again, Novell’s OpenSUSE Build Service seems to offer a decent foundation for moving forward. While the OpenSUSE-hosted version of the service is limited to open-source software, Novell makes the service available for download and self-hosting, so proprietary software vendors could use this code to produce packages for multiple distributions, particularly if Canonical, Red Hat and other Linux vendors began pitching in to help streamline the process.
3. Write Once, Run Anywhere, for Real
Considering the chicken-and-egg issues that desktop Linux faces regarding the relatively small market opportunity it offers to ISVs, I find it surprising that distributors haven’t put more effort into advancing the state of Web application delivery and management on Linux.
I’m a heavy user of Google’s hosted mail service, which I run within a site-specific browser, Mozilla Prism, in order to protect myself from evil-doing scripts that might take advantage of the sorry state of inter-tab isolation in most of today’s Web browsers, and to isolate my mail session from things such as runaway Flash ads adjacent browser tabs.
As far as I’m aware, however, Ubuntu is the only Linux distribution with a ready-to-install package for Prism. What could be more enterprise-appropriate (I’m looking at you, SLED) than providing for isolation between running Web applications? And more than simply packaging Prism, or something like it, why don’t any Linux distributions employ one of their built-in privilege management frameworks, such as SELinux or AppArmor, to offer enhanced Web browser isolation right out of the box?