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

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

>>>>> "Rex" == Rex Walters <rex@example.com> writes:

    Rex> I really wish [djb's] code was more easily parsed by humans (more
    Rex> comments for one) but I can't fault him for it.  To summarize
    Rex> a recent thread on the qmail list: his code is *auditable*,
    Rex> not necessarily transparent.

Ah, now that's a nice word.  Very precise, and captures the discussion 
in a nutshell.  Made my day ;-)

    Rex> Unfortunately, I don't know from smail queues.  Arguably, The
    Rex> "best" method to convert to qmail is to install it on a new
    Rex> machine, update MX records to point to it, and leave your old
    Rex> system up until the queue drains.  Doesn't sound like you
    Rex> have that option.  Sorry.

Oh, Lord, do I wish I owned my DNS!!!!  Individual servers wouldn't go
down half as often because they'd be Linux-based, and there'd be more
than *one* of them for an 800-machine class-C net.  And I'd have an MX 
record ;-)

Not having an MX record has never caused me any trouble I have
noticed.  Sigh.

Actually, I could probably do something like that, that would involve
changing the Internet identities of the individual machines, and use
NFS to make sure that there's only one file system so I don't actually
have to move any files; maybe I will when I get around to looking at
qmail again.  There are other dodges I can think of.

      Linus posted: "It's a new world -- get over it".  Dan posted: "It
      always worked that way, lots of things expect it -- damned if I'll
      be the one to make the changes" (someone else did post patches).

I see.  When Dan's code's dependence on stale idioms is in question,
other people should make the changes.  That's arrogance, at least
taken out of context in this way.

      In my world, a hard crash is rare enough that I can except the
      risk.

Sure.  My point was not that I was worried about qmail's queues (I
think you understood that but it's not entirely clear), I was worried
that pilot error---mine---would trash the (by then, fairly large)
smail queue.  Using a patched smail, of course, vastly reduces that
risk.

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