[EMAIL PROTECTED] wrote:
>On Wed, 30 Dec 1998, Dave Sill wrote:
>>
>> OK, so why hasn't Red Hat switched to one of the other
>> better-than-sendmail MTA's such as exim?
>
>I don't know anything about exim, so I can't say.
Let me try again. Licensing alone could conceivably explain why Red
Hat doesn't ship qmail. But it does't explain why they don't ship
exim, smail, zmailer, or any other OSS sendmail equivalent.
>> Put yourself in Dan's place. His name is associated with qmail, he has
>> to support it, and his reputation is on the line if Red Hat or anyone
>> else distributes a modified version that's broken.
>
>This is absurd. Would Eric Allman's reputation be "on the line" if Red
>Hat broke their sendmail package?
Trick question, right? Should I answer "No. Eric already trashed his
own reputation with sendmail" or "Yes. Whatever little reputation he's
regained by the recent sendmail bug drought would vanish"?
>Would James Brister's reputation be "on the line", if Red Hat broke
>their INN RPM?
Absolutely, and ISC's as well. Imagine a high-profile hacking incident
due to misconfiguration in Red Hat's INN RPM or some minor source
tweak-perhaps a botched emergency bug fix. The mainstream press would,
of course, reveal no technical details like which OS or server
software was involved, so only the victim's reputation would be harmed
by them. The typical, lame technical press would report that a
UNIX-based news server was compromised--tarnishing the victim, UNIX,
and Netnews. Saavy technical press would mention Red Hat and INN,
possibly ISC, and might quote Brister on the topic. Regardless of what
he says, Red Hat (deservedly) and Brister and ISC (less deservedly)
would be implicated.
>Have you seen what actually goes into the inn 1.7.2 RPM?
No. I don't run INN under Red Hat.
>If an RPM breaks, two kinds of people will notice: the stupid people, and
>the smart people. The stupid people will complain to Red Hat, because as
>far as they can see, this is Red Hat software. The smart people will know
>better, they'll get the source RPM, rip it apart, and tell Red Hat what
>they broke.
There are two kinds of people in the world: those who think everyone
falls into one of two groups, and those who don't. I'm in the latter
category.
Complaining to Red Hat when one of their RPM's breaks is not
stupid. Not everyone has the time or inclination to fix every problem
they encounter. That doesn't make them stupid.
>The notion that any individual author would get the flack for a broken
>distribution is rather silly.
Silly things happen all the time.
>Who told djb that he'll have to support third party changes? Nobody told
>him that.
Of course not. But victims of these third party changes will surely go
to him or his lists for help. And these victims will also be unaware
of the changes their vendor made, so the help they get might be
wrong. There will be unnecessary confusion in the support community,
and this confusion will reflect poorly on Dan and his products to
casual observers who don't realize that the confusion is due to third
party diddling.
>Does this mean that James Brister is responsible for supporting all of
>the stuff that Red Hat puts into inn-1.7.2 RPM?
Nobody's holding a gun to head and making him answer them, but, yes,
Brister has to deal with whatever gunk is in the RPM because he's
going to get questions about it. Dan seeks not to burden himself with
whatever frivilous changes the vendor wants to make to qmail.
>> vendor's trademark provided the vendor agrees to support their version
>> and not mention Dan or qmail anywhere, except perhaps in copyright
>> notices?
>
>That's exactly what IBM did with Apache, BTW. Everyone's happy.
Wonder if Dan would go for it.
>> >... There's absolutely no reason for Red Hat to switch to Qmail, so
>> >let's just stop beating a dead horse.
>>
>> That's not true. There *are* good reasons to switch to qmail. They're
>
>Good reasons in general, and on an individual basis. There are no good
>reasons for Red Hat to switch to Qmail in their distribution. At least,
>not any more.
Huh? How about improved performance, efficiency, security, and
functionality? Or did those evaporate because Dan won't let Red Hat
diddle the code?
-Dave
