[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Linux Core Consortium



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, greg@gregfolkert.net
REMEMBER ED CURRY! http://www.iwethey.org/ed_curry

Onerous congratulations on your conceptual development of obliteration
concerning telephones, lobsters and fish!

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: