[Beowulf] A press release

[Gregory Warnes]

On 7/2/08 1:06AM , "Mark Hahn" <hahn at mcmaster.ca> wrote:

>> > I¹ve never had any major problems.  Most linux vendors supply both RPM¹s >>
and
>> > .tar.gz installers, and I generally have better luck with the latter, even
>> > on RPM based systems anyway.
> 
> interesting - I wonder why.  the main difference would be that the rpm
> format encodes dependencies...
> 
The basic problem is that when folks build the .tar.gz files, they usually
do a good job of explaining the dependencies and how to resolve them, while
the equivalent RPM installer simply lists the dependencies with no hints
about what packages are needed and where to get them.
> 
> 
>>> >> the couple debian people I know tend to have more ideological motives
>>> >> (which I do NOT impugn, except that I am personally more swayed by
>>> >> practical, concrete reasons.)
>>> >>
>> > My Œconversion¹ to use of Debian had little to do with ideological motives,
>> > and a lot more to do with minimizing the amount of time I had to take away
>> > from my research to support the Linux clusters I was maintaining at the
>> > time.
> 
> again interesting, thanks.  what sorts of things in rpm-based distros
> consumed your time?
> 
Well, a key component was obtaining, installing, and keeping open-source
software components of the system up to date.    Most other tasks were
pretty equivalent, although things are organized somewhat differently
between linux variants.

In addition to automatically resolving dependencies for new packages, it
keeps track of the dependencies of existing packages.  This if one asks for
package X that depends on library Y version N, but library Y version M<N is
needed by installed package Z, the package manager will notify you that it
will need to upgrade package Z as well.

Debian packages also  do a very nice job of providing configurable-grained
control on how software configuration files are upgraded.  At one extreme,
you can configure the the system to simply apply all changes, overwriting
any user-applied configuration settings, to applying changes that don¹t
conflict with user supplied changes, to prompting the administrator before
making any changes, to making no changes at all.

A consequence of all of this is that it is remarkably easy to keep a
debian-based system fully up to date with the latest versions of even
fast-moving packages.
> 
>> > Side note, one very nice thing about debian is the ability to upgrade a
>> > system in-place from one O/S  release to another via
>> >
>> >    apt-get dist-upgrade
>> >
>> > Much nicer than reinstalling the O/S as seems to be (used to be?) the norm
>> > with RPM-based systems
> 
> I've done major version upgrades using rpm, admittedly in the pre-fedora
> days.  it _is_ a nice capability - I'm a little surprised desktop-oriented
> distros don't emphasize it...
> 
On fundimental difference in philospohy explains both the fundimental
differences between RPM and debian packages, and the reason for the lack of
emphasis of in-place upgrades of desktop distros: vendor income.  It is not
in Red Hat¹s financial interest to make it easy to upgrade a system in-place
by an automated tool.  They make money by selling new O/S versions.
Consequently, Red Hat explicitly designed the RPM format to discourage
in-place upgrades. 

The debian community, on the other hand, was and is run fundimentally by
system administrators, whose best interest centers around minimizing the
amount of time necessary to keep systems up to date.  Consequently, debian¹s
package system was designed explicitly to make installation and updating of
packages as painless as possible for the admin.

Of course, other pressures have forced deviations from these fundimental
viewpoints, but the patterns are still clearly visible.

-Greg

-- 
Gregory R. Warnes, Ph.D
Program Director
Center for Computational Arts, Sciences, and Engineering
University of Rochester

Tel: 585-273-2794
Fax: 585-276-2097
Email: gregory.warnes at rochester.edu


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20080702/ba67c773/attachment.html>