This'll be my last word on the topic.
OK, stop cheering. :-)
[EMAIL PROTECTED] wrote:
>On Mon, 4 Jan 1999, Dave Sill wrote:
>
>> Question: *Why doesn't* Red Hat ship zmailer, exim, smail, or any
>> other OSS sendmail equivalent?
>
>Because they are not as well tested don't scale and do not offer a
>functional replacement for sendmail. I told you that before, but, you
>chose to ignore it.
If you said that, I missed it. Sorry. I'm a big qmail fan, but even
so, I'm pretty sure it's not the only viable sendmail replacement. I'm
not interested in arguing this point, though.
>> How about if we just let developers who don't want to make their code
>> OSS set their own terms based on their beliefs and desires?
>
>You're dodging the issue. You are claiming that OSS development framework
>is somehow defective (in the previous statement of yours that you
>conveniently left out).
I'm arguing that Dan finds the OSS model inadequate to protect qmail
to his level of comfort. I "conveniently" left it out because I didn't
see any reason to include it.
>Now that I've asked you to explain the defects in
>well-known OSS products, you're suddenly changing the topic to something
>else.
Personally, I'm an OSS fan, and have been for many years--at least 10
years before the term "Open Source Software" was coined. A lot it of
it is very good. I shudder to think how I'd do my job if I woke up one
day and it all was gone. A good bit of it is crap, too, but I'm able
to detect and avoid it pretty easily.
But I've never seen any OSS that I'd put in the same class as
djbware. If Dan feels the need to restrict diddling of djbware, that's
OK with me. I don't care if Red Hat or Debian or OpenBSD switch to
qmail. As long as I can install it wherever I need it, and diddle with
my own copies as I need to, I'm perfectly happy.
>> Just because OSS works for some developers/projects, doesn't mean it's
>> the only valid model.
>
>Well, then, please explain what is so special about Qmail that requires
>something different. The answer is: nothing.
I believe its extraordinary quality and security sensitive nature
justify its restricted distribution.
>You may acknowledge it as
>simply a privilege reserved by the author; but you will not be able to
>claim that there is any good and sound technical reason for it. Any time
>this question is put to you, you keep repeating the same mantra about
>diddling with the code.
Code quality control is a good, sound technical reason.
>Well, diddling with the code doesn't bother those
>who maintain the infrastructure that the Internet runs on.
Maybe it should. Maybe it would if their code was as tight as
qmail's. Just because OSS is good enough to run the Internet doesn't
mean it's appropriate for everything. Next time you have a CAT scan,
ask yourself if you'd like the software running the scanner to be Open
Source, running under Red Hat Linux, installed from some RPM that the
technician found on the net, or tightly controlled, tested, audited
code provided by the manufacturer, running on tested, approved, h/w
and OS.
>> qmail is not a democracy.
>
>Once again, you're changing the topic. Noone said that it has to be a
>democracy. Try arguing the topic, for a change.
My point is that 5,000 people screaming at Dan for relaxed qmail
redistribution rights won't mean squat. Dan has already considered
relaxed licensing, already heard and considered all of your arguments,
and decided against it. Deal with it.
>> >> Oh, right, users installing, say, a broken modified qmail RPM will
>> >> *know* that the packager broke it, not the author. I forgot that.
>> >
>> >Too bad, because they do. You can choose to ignore that fact, but it will
>> >remain a fact nevertheless.
>>
>> Riiight. But even if I agreed, it wouldn't matter.
>
>Well, facts matter to me.
Then you should realize that your "fact" isn't one: it's an assertion.
>> >And since add-ons cannot be redistributed,
>>
>> Wrong.
>
>You cannot redistribute Qmail with add-ons, silly.
You can't distribute modified qmail source or binaries, but you can
distribute virgin qmail + add-ons like rblsmtp and you can distribute
virgin qmail source + source patches for add-ons.
Now who's being silly?
>> Ever heard of rblsmtp?
>
>Which is badly broken,
That's news to me, but I don't use it.
>and places unnecessary load on the server, and
In your opinion.
>does not permit selective RBLing based upon the recipient.
procmail. Modularity. Sure, it's less efficient, in some
ways. "Premature optimization is the root of all evil."
>> Fine. Let's just say that qmail requires tcpserver. So what?
>
>So what is the fact that Qmail is not the ultimate MTA, therefore, if you
>choose to argue that a vendor must bend through hoops in order to
>distribute it, just because it's so great, you will be mistaken.
I'm not a vendor, but if I was, I *would* jump through hoops to
distribute qmail. It's not "ultimate", as if that's possible, but it's
the best there is for the types of applications I have.
>> >Except that qmail-smtpd logging is what most people require.
>>
>> Says who?
>
>Says those who administer mail servers for user bases that are at least
>five digits long.
I must have missed the reference to the peer-reviewed study that
reached this conclusion. What's that URL, again?
>> "Require" or "desire"?
>
>Require.
And this is documented there, too, right?
...not holding my breath...
-Dave
