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

[Rex Walters <rex@example.com>]

On Thu, Aug 13, 1998 at 08:06:05PM +0900, Stephen J. Turnbull wrote:
> 
> You do if you've got crackers or email pirates in your machine and
> that's all you've got to go on to choose the software to crush them
> with.  But that was exactly my point. 

Not a bad point.  There *are* times when all you can do is take
someone's word for it (and everybody in their right mind is selective in
their interpretation of "someone").

>                                                  As you say, you have
> to read the code.  And using non-standard idioms and subsystems makes
> the code unreadable if you haven't got the time to learn the language.

"Unreadable" is a little extreme.  It really isn't that hard to grok
code that doesn't use gets() for instance.  ;-) 

I really wish his code was more easily parsed by humans (more comments
for one) but I can't fault him for it.  To summarize a recent thread on
the qmail list: his code is *auditable*, not necessarily transparent.
In another life I'd really relish the time to sit down for a few weeks
and really immerse myself in qmail source, but you know how it is....

> and I still don't see how QMTP can be both more forgiving and
> contribute to greater reliability of the overall system (ie, the
> internet).

Actually, I think the motivation for QMTP specifically was speed and
efficiency, but I understand your point.  TANSTAAFL.

> I would have taken _your_ opinion at the time (if it came with an
> opinion that I had better than 4:1 odds that I could recover my smail
> queues and not lose any mail).

I'm honored.  

Given decent hardware, redundancy at the disk block level
(mirroring or parity raid, battery-backed cache if using write-back)
quality cabling, memory, and boards, and a robust filesystem
(journalling or guaranteed transactional metadata updates[1]) I have more
confidence in qmails queue structure than any other filesystem based
queuing implementation I've come across.

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

Cheers,
-- 
Rex

P.S.  The "Ordered MetaData Updates" flamefest on the qmail list a while
      back was an interesting counterpoint to this thread.  
      
      In a nutshell, qmail depends on filesystem metadata being synced
      to disk correctly with common idiomatic (unix) programming.  Alas,
      ext2fs operates under "new" idioms that require an explicit sync()
      on directories that UFS wouldn't.  
      
      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).

      Reality is that cheap clone hardware is more likely to lose or
      corrupt mail, but the undeniable fact is that (unpatched) qmail's
      queue is slightly more robust on UFS (*BSD) or a journalled
      filesystem than on ext2fs (linux).

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

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