Whuut?!

Friday, May 15, 2009

Unified 3d-party Packaging for Linux

While this topic has been, and are stilldebated over and over, I think two aspects are fairly often missed in the debate.

While the discussions often boil down to dpkg vs. rpm, I as a systems administrator and Linux users have a few practical problems that is really frustrating.

Problem #1 - Big fat Lie: "Linux gives you Single Point of Software Management and Updates"

This is often touted as one of the many advantages in Linux over both Windows and Proprietary Unices. And very well, in theory if you manage to ONLY stick to the packages provided by your distro, any popular distro does a decent job creating a unified software management system.

The problem comes with the cold hard "real world". In practice, every systems administrator I know is forced to think outside the box now and then, either for proprietary software or free software for some reason not yet packaged, or packaged in an old/broken version. (QBzr in Jaunty *mumble*) As soon as that happen (usually within 5 minutes after install), the whole software management system starts to crack, and there is no longer ONE system in control, but several, and often rouge software outside all control systems.

Problem #2 - Beta-testing is reserved for the "elite"
Again, in theory anyone can allow beta-testers to download their beta-versions/svn-snapshots of their software, and have the user install, test, and give feedback.

In practice, this ability is reserved for the top-5% of users with enough skill and time to download, configure, make and install the software (including all dependencies). The other 95% of users, less time or hacking skills could probably give valuable feedback and wider testing, but since they can't easily install the software, they can't really test or comment. They get the software roughly 6 months later, when the mainstream distros have caught on, and by then the upstream developers is already working on something else. This creates huge latencies in the feedback-release cycles, which enforces the one of the few bad effects of open source, that many programs get written for the 5% elite, and the other 95% user-base is more or less coincidental.

Problem #3 - Gaming on Linux is not for Joe Average (a symptomatic case, not really a problem itself)
This have often been stated "Gaming on Linux sucks". While I mostly disagree with that statement, it holds some merit, but not due to the regular argument that the selection of games for Linux are so limited. While yes, there are more games for "that other platform", the real problem with games for Linux is that they are for a newbie-user really hard to find, install and keep updated.

The first step (once you've found a game you want to try out) is to check if your distro has it. But since none of the big ones come with a really good selection of games, the user is probably required to got to the website of the game, and use the games own, often strange and tedious, process. This almost always requires (or at least encourages) at some point to open the console for some "terminal magic" (you know chmod +x, sudo install to /opt, etc). Then comes the weekly game-balancing-patch, which is discovered when at first when trying to connect to some server (assuming multiplayer), which sometimes requires a new download, and often an even more tedious patch-application-process. (Or even worse, due to auto-download, requires all gaming users to have write-access to the game install-dir, something that the installer certainly did not care about.) This, I believe more then the selection of games itself (especially if you count Wine) makes Linux games just a bit too challenging to even test for many users.

The problem for the game creators is that same as for all software, (except that maybe some games gets more patching with new content, rule-adjustments etc.)
The difference with games compared to much other software is that since they make so big changes, since there are so many of them, since they are often not prioritized software (by say RedHat, Novell or Canonical), and especially since they often require 0-day updates for multiplayer to work, it seems like regular distro-packaging simply can't keep up.

Requirements of a Solution
The above problems are in no way a complete list of software management issues under Linux, far from it, but one of those that hit me most often as a user and administrator at home and at work.

These problems would not be technically difficult to solve, for any particular distro, but for it to be effective, it will require a great deal of communication and agreement between distros.

The problem is not really on standardized package-formats in the usual form, that whole debate is largely over-rated. Noone sane would try to take KDE4 from Fedora and jam it into Ubuntu anyways (and I don't think it should be encouraged), but there is a real need for better handling of 3d-party applications, in all distros. These packages includes proprietary applications, but also open-source applications such as niche-applications, games, and other apps when the user simply wants to try "the bleeding edge".

Such 3d-party package system should:
  1. Be able to safely install, upgrade, revert and remove packages
  2. Support crypto-signatures and trust-networking such that the user can assess the quality and risk of installing a certain package beforehand
  3. Support automatic checking for updates, and inform this in a single subtle manner.
  4. Be linked to the native package-system in such way that dependencies can be resolved, and that the gui can be integrated
  5. Support peer2peer (torrents) for large downloads
  6. Work with LSB for dependency-control
  7. Work on multi-architecture, as well as arch-independent packages.
  8. (Critically important, and ultimately where it's likely to fail) Be well-supported by major distros for the network effect to work positively
  9. Preferably be distro-neutral, to avoid distro-lockin.


Right now, the thing that comes closest to this is probably Ubuntu:s Personal Package Archives, which roughly solves requirements 1,2,3,4,6 and 7. Then, since the 3d-party stuff is more important on the desktop (less of a problem for server admin than average desktop users), the growing popularity of Ubuntu itself may end up solving the last and critical requirement.

So basically, unless everyone sits down and agrees soon, apt/dpkg may likely become the de-facto standard for 3d party software. While this would practically solve the current problems, I personally would be sad if that becomes the case, as such distro-tied de-facto standard could risk some stagnation, and hinder the diversity that makes Linux so great.

2 Comments:

  • Hey man, thank you for your coments on my blog anditosan.blogspot.com. I agree with you completely. thanks and visit it again.

    BTW. I like your blog too.

    By Blogger Unknown, at 11:18 AM  

  • Thanks, as you may have seen, i don't really write here often. Mostly i just write here, when a response somewhere else gets too long.

    In this case, i actually had to re-read the post to remember, and since then i, seen two more things missing in the packaging-systems i'm familiar with; package install isolation, and per-user installs. Perhaps time to write something up again.

    Anyways, thanks! Fun to see someone actually read what i wrote. :)

    By Blogger Rawler, at 2:45 PM  

Post a Comment

<< Home