Linked by Kroc Camen on Sun 9th May 2010 12:34 UTC
Talk, Rumors, X Versus Y "Dear Ubuntu, for the last couple years life has been good. Every time I've shown you to a friend or family member, they've compared you to what they're familiar with--Windows XP or Vista, mostly--and by comparison you've looked brilliant. Yeah, your ugly brown color scheme was a bit off-putting at first, but once people saw how secure, simple, and reliable you were, the response was almost universally positive. But recently, things have changed ..."
Thread beginning with comment 423423
To view parent comment, click here.
To read all comments associated with this story, please click here.
darknexus
Member since:
2008-07-15

Simple. RPM took too long to mature and iron out its dependency problems. Now a days there are more deb packages than there are RPMs. For a long time RPM had no equivalent to apt-get. Then someone ported apt-get to RPM, but it was slow and unofficial. Then Red Hat came out with yum, which was even slower for a very long time. Only recently has Yum's speed gotten anywhere close to that of apt. While I always found it much easier to build RPM packages than to build debs, deb provided a better experience for end-users until recently when RPM caught up after years of lagging behind.
Besides, one packaging format isn't going to help. Ever tried installing Suse RPM packages on Fedora? How about installing straight Debian debs on Ubuntu? Eventually, when you cross-mix and match distribution packages even in the same format you run into trouble. If you're advocating standardizing on one distribution, I fully agree with you. It's a pipe dream however. The LSB refuses to evolve, and even supposed LSB compatibility doesn't solve everything. Linux distributions are so different from one another in many respects that they might as well be different oses altogether.

Reply Parent Score: 4

Rahul Member since:
2005-07-06

More misconceptions. RPM is a package manager equivalent to the level of dpkg. Red Hat has for a very very long time included up2date. There are others such as urpmi, zypper and so on.

Yum was originally developed by Seth Vidal who was a sys admin is Duke university and it was a modification of the yellow dog updater (hence yum = yellowdog updater modified). Fedora included it a while later along with up2date and for several releases, both were included.

Fedora later dropped up2date and went exclusively with yum. Red Hat hired Seth Vidal and yum has continued to gain more features and performance.

RPM still has several features that are ahead of others including multi-arch support, automatic debug info package generation, file dependencies, delta RPM support and so on. Let's stick to the facts

Reply Parent Score: 3

unoengborg Member since:
2005-07-06

Today packaging system is not about end users, they have PackageKit and graphical installers. Its all about developers and support.

Software installation is becoming an integrated part of many the desktop environment. E.g. we want to be able to have a standard gnome/KDE/... software installer that work the same way on all distros just like the Gnome/KDE menu works the same on all distros.

It is also not only specialized software install programs that need to install software. As an example printer management software would benefit from being able to automatically download and install printer drivers when we connect a new unknown printer. Other example would be a media player that may need to download and install new codecs, a word processor that need to download and install fonts or dictionaries.

Application developers should not need to do special hacks for each linux distro, to achieve this, and indeed, they don't need to. They can use PackageKit.

So, if application developers develop in a way that is package file format agnostic, and users install packages in a way that is package format agnostic why should developers need to learn how to package their software in at least two ways? It really doesn't make any sense.

It doesn't matter if there are more Debian packages out there. my guess is that Debian people would be smart enough to create some kind of auto translate tool that could generate RPM spec files from corresponding debian package info. By replacing debs with rpms old school, pre packageKit people could still use their apt-get, and Red Hat people can continue to use yum or up2date. Replacing rpms with debs would be a much harder way to get one format.

PackageKit is a kludge to make package installation integrated and manageable in modern Linux desktop environments. The problem is that by demanding that packageKit should be able to handle a large variety of package formats it becomes more complex, and the more complex it is the less flexible to future change it becomes.

Reply Parent Score: 2

lemur2 Member since:
2007-02-17

As an example printer management software would benefit from being able to automatically download and install printer drivers when we connect a new unknown printer.


The printer drivers are already installed for Ubuntu. For the most part, all you have to do is plug in the printer, and 20 seconds later it will be ready to print.

There are only about a dozen printer drivers for Linux, AFAIK. Myriad different models of printers are handled by different configuration files that delineate the differences in models for one or other of the dozen drivers. This configuartion file is typically a "PPD" file, a plain text file describing the underlying printer driver language and the unique properties of a given model.

http://en.wikipedia.org/wiki/PostScript_Printer_Description

It isn't hard to fit a dozen or so software drivers and many hundreds of plain-text PPD files on a Linux distribution LiveCD install disk.

Reply Parent Score: 2