On Tue, Nov 24, 2009 at 12:17 AM, Michael Torrie <torr...@gmail.com> wrote:
> difference. RPMs do have one advantage over .debs. That is that they > handle multiple architectures fairly cleanly and smoothly. In other > words RPM can deal with the idea that I have two identical packages, one > 32-bit and one 64-bit than can both be installed without causing > conflicts. This a big deal for me, since all my servers are 64-bit and > occasionally I need to deal with a 32-bit binary for whatever reason. > > I'm not going to repeat everything that Arron said regarding Debian's packages or apt, because I feel he said it good enough. I will also agree that we are on the same team, moving FOSS forward. Please remember that when AMD64 came onto the scene, Red Hat and Debian took very different approaches to how they would integrate 64-bit into their systems. Red Hat wanted to get it out their quick (servers would see a bigger benefit from 64-bit kernel and some apps than the desktop, this is the only thing I've seen Red Hat "rush") without changing too much of how they got day to day business done. Debian on the other hand decided to start over with the concept of multiarch which took a lot more time and energy to redesign, but in the end you could compile anything on anything. In the beginning it was difficult to run apps on amd64 Debian, because everything waited to be compiled 64-bit clean. To run 32-bit apps, you had to install the 32-bit libs and then run a 32-bit chroot with your app in it. I do like knowing that everything in a 64-bit Debian install is 64-bit (minus the 32-bit libs you can install for apps outside of Debian's repos). This could be a pro or con for you, for me it's a pro. As far as Ubuntu not giving back to the community. I would say this is false. Many times looking through Debian's PTS, I see bug reports and patches submitted by Ubuntu users. The Ubuntu community also tries to get packages in Debian where it fits Debian's model. This provides new software and package maintainers for Debian packages. And Debian packages generally don't go stale for two reasons. What is in stable is patched by the Debian Security team, second if a packages in testing starts to break because of dependencies being upgraded or what not, it is orphaned and removed before it enters stable. I've worked with RHEL, CENTOS, etc and my biggest grip is there is no structure. An RPM can choose to put things anywhere (/etc, /opt, /usr, /var, etc). Debian has a strict file structure that every package must follow (config in /etc, user modified data in /var/lib/, etc) for me it makes it much easier to manage my servers because I can 'expect' a certain level of uniformity. my $.02 Robert LeBlanc Life Sciences & Undergraduate Education Computer Support Brigham Young University
-------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list
