Re: tlug: Re: djb [was: ibm.net with LINUX (Red Hat)]

[Karl-Max Wagner <karlmax@example.com>]

> Granted.  But you need to trust the author(s).

In a way, yes. However, you do that all the time. Or do you check
your entire Linux distribution when you install a new one.

> Sure.  But Russ may support it because it's easy to use.  All I know
> about Russ (besides the legendary Crynwyr packet drivers) is how

He actually did a lot more, which, however, is not so well
known.

> And at the time I encountered qmail, I had nothing to go on except Jim 
> Tittsler's statement that he thought qmail could be configured to

This actually is easy.

> prevent spam relaying, and Bernstein's glowing review of his own
> program, and disparagement of protocols other than QMTP.  That feature 

Well, if he isn't proud of his work, how could he convince
others ?

> was not well-documented, and Bernstein's evident disdain for sendmail

It is. Look at his website.

> left me with worries that it would not be a "drop in" replacement for
> smail.  I was in a hurry, as you'll see....

It can be configured to be compliant with legacy style
standards. He just discourages doing so.

> The spammers took about three weeks to stop trying to relay through my 
> box.

> And that's one reason why people don't make radical changes even
> though they know their legacy system isn't up to snuff---the legacy
> system works and they don't want to chance downtime because the new
> wonderful stuff tickles a bug in existing software.

To come back to qmail: It has already quite a few users - among
them Red Hat - so that glaring deficiencies should already be
ironed out.

> Yup.  There are still a few 7-bit mail gateways out there.  They ought
> to be replaced.  Millions of Windows machines use Shit-JIS.  _They_
> ought to be replaced.  Your point is...?

Correct. Nuke them.

> It's not unqualifiedly better unless it's backward compatible, too.
> But that's impossible, because (most of what I've seen I agree with
> him _in theory_) he _is_ right, after all. :-)

It is possible. You can run it according to the old standards or
the new ones. See above.

> Um, I'm lost.  Either it's fuzzy and works with common practice, or
> it's reliable and secure.  You don't get both.

So Windows works with common practice and Linux, being reliable
and secure, is for the bucket ? Sorry, can't follow you
there....

> Good enough is good enough.  Stifling technical progress is dangerous
> only to employment of technicians.  :-)

Yes. In the last century the boss of the USPTO thought so, too
and wanted to abolish the USPTO. Well, they sent him into
retirement on the spot......

Seriously, stifling technical progress nowadays means killing
your economy and that is bad for everyone.

> Seriously, who do you think is sticking to legacy technology for the
> sake of the technology?  I'd love to have a 400MHz Alpha or an SGI on

Many people that are simply to lazy to learn something new.
Unfortunately all too common.

> my desk, but I'm stuck with legacy technology.  I guess that makes me
> dangerous.

Ask DEC or SGI. They'll tell you :-)

> Or take spam.  PDAtropos told me that it was impossible to implement a
> spam filter for a system like AOHell's.  They could write one, they

You call that a SYSTEM ?????? I call that a MESS !!!!!

> just didn't dare install it without thorough testing.  And it wasn't
> just AOHell that was forwarding spam, earthlink still does as far as I
> can tell.  AOHell came around, but not for at least 12 months after
> that plaintive cry from their Postmaster.  (And by that time he was

Hmmmm......Actually, with AOL I think they should throw out all
their stuff and build a new one from the ground up. Cheaper and
cleaner.

> Or take Cobol.  Ed Yourdon claimed that as of the early 90s more lines 
> of code were being written in Cobol than in any other language

That shows only one thing: Most IT management is truly
incompetent. Actually, COBOL was already old hat at the end of
the seventies. It would have been already high time by then to
switch to something more up to date like C. A concerted effort
by then would have been a lot cheaper than today.

Rule: if you start feeling that things are on the change and
that you might to have to switch from an old solution to a new
one, do it as soon as possible. The need won't go away. Just
switching becomes more expensive every day. An often overlooked
fact.

> family.  Few of them were new programs, of course.  But they were
> lines of code.  Cobol!  Just like that purple dinosaur, it won't go
> away.

Like old soldiers, it eventually will fade away. And cost those
who finally have to get rid of it dearly.

> And so did the guys who wrote smail, and the guy who wrote exim.
> And the guys who created TrueType and NetBIOS and Windows NT.

Sure. And in their time those were often good solutions. Just
that those times are over.

> The problems with RFCs 821 and 822 are well-known.  But for heaven's
> sake we can't even make the move to ISO-Eurodate (whatever the number
> is, you know what I'm referring to), let alone ditch the CRLF
> convention.  It's not inability to see the problem that delays change.

The best thing IMHO is just to not care and provide an
implementation of new, better ideas and let it go its way. Be
sure: with more qmail use those issues will become discussed a
lot more.

Assuming that many people don't see the problems isn't such a
mistake, BTW. Many simply use things provided to them without
caring a lot how or why they work. Each of us does that with a
lot of stuff. That's simply life. So, if you see a problem, cry
out LOUDLY ! This will make a lot of people pensive and actually
is a good way of getting things into motion.

                               Karl-Max Wagner
                               karlmax@example.com
--------------------------------------------------------------
Next Nomikai: 18 September, 19:30 Tengu TokyoEkiMae 03-3275-3691
Next Meeting: 10 October, Tokyo Station Yaesu central gate 12:30
--------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp