<HTML>
<HEAD>
<TITLE>Re: [Beowulf] A press release</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
<BR>
<BR>
On 7/2/08 1:06AM , "Mark Hahn" <<a href="hahn@mcmaster.ca">hahn@mcmaster.ca</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>> I’ve never had any major problems.  Most linux vendors supply both RPM’s and<BR>
> .tar.gz installers, and I generally have better luck with the latter, even<BR>
> on RPM based systems anyway.<BR>
<BR>
interesting - I wonder why.  the main difference would be that the rpm<BR>
format encodes dependencies...<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>The basic problem is that when folks build the .tar.gz files, they usually do a good job of <I>explaining</I> 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.   <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
<BR>
>> the couple debian people I know tend to have more ideological motives<BR>
>> (which I do NOT impugn, except that I am personally more swayed by<BR>
>> practical, concrete reasons.)<BR>
>><BR>
> My ‘conversion’ to use of Debian had little to do with ideological motives,<BR>
> and a lot more to do with minimizing the amount of time I had to take away<BR>
> from my research to support the Linux clusters I was maintaining at the<BR>
> time.<BR>
<BR>
again interesting, thanks.  what sorts of things in rpm-based distros<BR>
consumed your time?<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>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.<BR>
<BR>
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.     <BR>
<BR>
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.<BR>
<BR>
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. <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
> Side note, one very nice thing about debian is the ability to upgrade a<BR>
> system in-place from one O/S  release to another via<BR>
><BR>
>    apt-get dist-upgrade<BR>
><BR>
> Much nicer than reinstalling the O/S as seems to be (used to be?) the norm<BR>
> with RPM-based systems<BR>
<BR>
I've done major version upgrades using rpm, admittedly in the pre-fedora<BR>
days.  it _is_ a nice capability - I'm a little surprised desktop-oriented<BR>
distros don't emphasize it...<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>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. <BR>
<BR>
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. <BR>
<BR>
Of course, other pressures have forced deviations from these fundimental viewpoints, but the patterns are still clearly visible.<BR>
<BR>
-Greg<BR>
<BR>
-- <BR>
Gregory R. Warnes, Ph.D<BR>
Program Director<BR>
Center for Computational Arts, Sciences, and Engineering<BR>
University of Rochester<BR>
<BR>
Tel: 585-273-2794<BR>
Fax: 585-276-2097<BR>
Email: <a href="gregory.warnes@rochester.edu">gregory.warnes@rochester.edu</a><BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>