Re: Mail reader
On Wed, Aug 28, 2002 at 09:40:01AM -0600, Gary Hennigan wrote:
> "Michael J. Forster" <mike@sharedlogic.ca> writes:
> > On Tue, Aug 27, 2002 at 02:42:55PM -0600, Gary Hennigan wrote:
> [snip]
> > > You might want to learn a bit about the art of debate or at least read
> > > more carefully. I didn't say *I* used an "all in one tool" because of
> > > the possibility of failure at multiple points. It was simply an
> > > argument in favor of doing so, and a valid one at that, despite your
> > > use of term "FUD".
> >
> > You should learn to write more carefully. Your argument implicitly
> > assumes at most one failure point per utility. Nonsense.
>
> Actually, you yourself are implicitly assuming that an "all in one"
> application has to be N times larger than N smaller applications that
> could replace it. Nonsense.
And now _you_ can take a turn at _reading_ carefully. I made no such
assumption. My "5000 lines of code" example was clearly hypothetical
and intended to eliminate all factors save for modularity and
interfacing -- the issues being discussed.
> Theory and practive don't often coincide, particularly when it comes
> to software. Besides, who says you can't design a modular "all in one"
> application, with well defined interfaces between it's modules?
Again, read: I didn't claim that they always do; I merely paraphrased
the theory and cited some examples.
As for interfacing modules as separate executables versus a monolithic
one, I don't deny your point. However, the point I should have made --
and it was my mistake not to -- is that it's easier to apply the principle
of 'least privilege' when granting access control to separate executables.
Yes, yes, I'm aware of the privsep efforts associated with OpenSSH,
but I'm not convinced that it provides an easier or better approach to
process compartmentalization than separate executables.
> > In practice, we have only to compare all-in-one tools like sendmail and
> > bind to many-small tools like qmail and djbdns. And don't bother to
> > debate me on those examples: I manage all four of them on over 500
> > boxes -- I know which ones yield fewer failure points.
>
> I might just "bother" anyway.
>
> First, sendmail is an OLD code. True, it's gone through rewrites, but
> I wouldn't be surprised if it has some legacy code in it. Also, I've
> read a few CS "theory" papers documenting how software degrades with
> age. Given that, how does the age of sendmail compare to the age of
> qmail and djbdns? Not only were the latter developed more recently,
> using more modern SE principles, they were also written with the
> specific goals of being tight, small and secure, if I'm not
> mistaken. That's not really the case with sendmail.
Sorry, are you debating for or against me? Tight, small and secure?
Did I say loose, huge and insecure? More modern principles? In fact,
qmail and djbdns both reflect the original principles of UNIX design
better than the `older' sendmail and bind. And I find it curious that
you didn't address bind; Vixie and crew rewrote the whole thing, using
`design by contract', etc., you know.
> I'm not saying you're necessarily wrong, just that you're not using
> valid examples, and if you think software design works just like CS
> theory says it does you got some learnin' to do! ;)
They're fine examples. As noted just above, qmail and djbdns may be
newer but their greater reliability and security reflect long-established
design principles.
Oh, and as noted somewhat further above, it's clear that I'm not so
naive as to believe that theory translates directly into practice,
your failed attempt at condescension notwithstanding.
> Anyway, I can see this thread degrading into a holy war (is there a CS
> "theory" on that?) so I hereby concede any future argument.
Not really: I use both Emacs/Gnus and vi/Mutt. But wise of you to
concede nonetheless: you seemed to be running out of places to hide.
---Michael J. Forster, B.Sc., Software Engineer, Shared Logic Inc.
mike @ sharedlogic.ca, www.sharedlogic.ca/mjf
Reply to: