On Thu, 2004-12-09 at 21:35 -0800, Philip Miller wrote: > Greg Folkert wrote: > > Many reasons people come to Debian... Distributed Binaries is not one of > > them. > > If you think this isn't a reason to use Debian, I, as a long-time user, will > tell you that > you're dead wrong. I use Debian because there exist packages for most every > popular piece > of free software out there, and I will never have to use an untrusted binary > package to > install it conveniently. Even when it comes to installing software that's not > in the > Archive, I can safely install it from source, with the assurance that none of > its files > will be mixed in with any files installed by the package management system > (not the case > with most 3rd-party RPMS).
Should umm, clarify, Distributed Binaries == Binaries Built and shoved into Debian by an External Entity or 3rd Party. I rarely, RARELY compile a package with dpkg-buildpackage. When I do, it is for a local modification to workaround a hardware, security or performance issue before it is patched or fixed in Debian. Typically the only 3rd Party Binaries I use are Games or Business Critical (non-free/commercial) applications as deemed by the PHBs that be. > I am doing some sysadmin work involving RedHat Enterprise Linux 3 systems, > and I will tell > you that they do a terrible job of maintaining a binary distribution. > Standing by > themself, let alone compared to Debian, they do no integration testing of the > packages > they release and distribute. For example, this past summer, after a new > server > installation, we had to build and install a local copy of Perl, because the > version they > distributed was completely incompatible with both mailscanner and amavisd-new > due to > module bugs. This sort of brown-paper-bag error in a release is unthinkable > in Debian, > precisely because of the QA that our exact distributed binaries go through > (and this > particular issue was actually caught in testing, as it should have been). I have done and continue to manage RedHat AS/ES installations. I do these primarily via ssh, one is on another continent, most are in the US, though states away though). I can tell you first hand the terrible fixes I have had to force onto some of those systems that just wouldn't work with Oracle or Tuxedo or Websphere or <insert other "Enterprise Application"> mainly becuase of this lack of QA from RedHat. Regression testing, or integration testing as you call it, is by far the best reason to come to Debian. When I think of Debian and Binary... those are Binaries Built by Buildd-s in the Debian Submission and Acceptance process. Not on lumpy.redhat.com or some other external host that I have zero real knowledge of. And for your Perl Issue, you could have just CPAN updated those Perl Modules. I have had to do that many times. There are certain things I like about RedHat... one is the rpmbuild setup. If one could employ policies in an RPM build that are applied to DEB builds... I'd think that 99.9% of the issues we speak about in RedHat would be solved. So, I guess you misread what I meant. Or I wasn't as clear as I should have been. Either way, you should now understand my position a bit better. -- greg, [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry Onerous congratulations on your conceptual development of obliteration concerning telephones, lobsters and fish!
signature.asc
Description: This is a digitally signed message part
