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

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Karl-Max" == Karl-Max Wagner <karlmax@example.com> writes:

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

    Karl-Max> It is. Look at his website.

I did; at that time it was not well-documented.  It said these are the 
kinds of things you need to do to do X, unfortunately X wasn't good
enough for me.

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

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

By not providing a recipe.  This is not easy stuff; without a tried
recipe to check my needs against I'd be risking hosing my own users.

    >> 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.

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

(a) RedHat is famous for glaring deficiencies.  (b) I don't see any
qmail questions on this list; qmail is _never_ the question here
(although it is always Karl-Max's answer! ;-)

    >> 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...?

    Karl-Max> Correct. Nuke them.

With what?  Antitrust against Microsoft?  A tax on Windows?  Real
megatons?  How do you plan to implement such a nuking on boxes that
are other people's property?

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

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

That's not what I wrote, Karl-Max.  Read what I wrote.

    >> 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

    Karl-Max> Many people that are simply to lazy to learn something
    Karl-Max> new.  Unfortunately all too common.

One man's laziness is another's priority-setting.  Budget constraints, 
both time and money, are also unfortunatley all too common.  Are you
going to shepherd all those legacy systems into the next century, and
straighten our the Y2K problem at the same time, without losing a bit
of data?

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

    Karl-Max> 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

    Karl-Max> You call that a SYSTEM ?????? I call that a MESS !!!!!

So?  It's a MESS, but it's still a system, and it works for as many
people as Linux does (about 20 million in both cases, IIRC).

    >> 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

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

Yes, it would be cheaper and cleaner.  Cheaper, because AOL would be
out of business and probably in court---a non-existent business has no 
costs.  Cleaner?  Of course!  That MESS would be gone.

    >> 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

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

C?  Guffaw!  I gather you have never done any IT (more precisely, IT
management) yourself.  (I haven't either, really, but I have studied
it.)  For interfacing to the legacy applications for which COBOL is
used, technically it's a dead heat between C and COBOL.  The C
programs individually might be more somewhat more maintainable (but
see the Obfuscated C series), but the COBOL programs use a "common
business- oriented" idiom enforced by the language making a suite of
programs more coherent.  The common idiom could be enforced in C++ at
not too much cost to individual programmers, but in C enforcing common
idiom requires the discipline of Xt programming.  Very very hard work.

For replacing the legacy applications, yikes!  It's probably easiest
to compile the COBOL to machine code, then use a "to C" disassembler.
Remember, COBOL was sold as "self-documenting" and many programmers
took the hype as gospel truth (somewhat for self-serving reasons, I'm
sure).  :-P

The overhead required to switch to C nailed that idea to the barn
door, dead.

    Karl-Max> Rule: if you start feeling that things are on the change
    Karl-Max> and that you might to have to switch from an old
    Karl-Max> solution to a new one, do it as soon as possible. The

"Possible" == "funds, management, skilled professionals are available
to do the work".  Where do they come from?

    Karl-Max> need won't go away. Just switching becomes more
    Karl-Max> expensive every day. An often overlooked fact.

Arrogance incarnate.  It is rarely overlooked.

Well, let's be fair.  What you meant to say is that "the fact that
`switching becomes more expensive the longer it is delayed' is rarely
assigned sufficient priority by management," right?

    >> 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.

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

They're already being discussed.  Read RFC 1123 and the various
historical MIME docs and you'll see it's been discussed for quite a
while.  QMTP is a registered protocol; I'm actually rather surprised
to see that it's not an RFC (at least not up to 4/29/1997).

And "just letting [a new, better idea] go its way is dangerous; good
ideas need to be promoted or they won't be adopted, due to laziness ==
budget constraints.

    Karl-Max> Assuming that many people don't see the problems isn't
    Karl-Max> such a mistake, BTW. Many simply use things provided to
    Karl-Max> them without caring a lot how or why they work.

The people who matter are out there writing RFCs and compiling Linux
distributions.  They are not using things provided them without caring
how or why they work.  They do their homework; to imply otherwise, and 
you are doing so, is unfair.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences        Tel/fax: +1 (298) 53-5091
--------------------------------------------------------------
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