On Sat, Feb 21, 2004 at 08:46:48AM +0100, Andreas Aardal Hanssen wrote:
> On Fri, 20 Feb 2004, Peter Stuge wrote:
> >I've only messed up qmail once, the queue. But since I've read the docs
> >and read the source I'm a guru anyway. :) His code is nice to read too.
>
> I've worked a lot with qmail, did loads of modifications to it to have it
> work with needs of my employer, and have to say that I have something of
> the opposite experience. I messed up qmail quite a lot ;-), but have
> learned to respect it for what it is: the only practically bug-free, most
> reliable and secure MTA out there.
Amen. :)
> But this is what I see when trying to read qmail source:
>
> stralloc nughde = {0};
> if (!stralloc_copys(&nughde,"")) _exit(QLX_NOMEM);
> nughde_get(r);
>
> For those of us who know what "nughde" is, and what "stralloc" is, this is
> fine. But for most others, it's enough to go get nuts. Passing what seems
> to be a copy of a stralloc struct to a void function which takes a (char
> *) doesn't make sense. Does it modify my nughde? Probably. What does it
> do, anyway?
>
> One ends up having to read every single line of nughde_get to understand
> what it does. It's very old-school.
Agreed. Could be that more modern methods are less well-known and hence
more error-prone. Or maybe not. Unfortunately I'm going to have to drop
this quite interesting discussion for lack of time. :(
> >> Good design is crafted after the user.
> >Absolutely. Agreed 100%. However, DJB doesn't make software for users,
> >it's for administrators. And I'd hope that my administrator is able to
> >handle it. :) (Many times he isn't, whoever he is, but then I'll hint
> >him straight. :)
>
> With "user" I do mean "administrator". And I do understand what you're
> saying; the software does what it should when it should if the admin
> does it all right. If only DjB didn't place that big red button
> labeled "Do not push this button!" everywhere. ;-) hehe.
He he. We should have something to keep us on our toes though, otherwise
we'll get lazy=>sloppy.. :)
> >> Ofcourse qmail admins back up their queues with "tar cfz ....", they
> >I use dump. Everybody with ext2/3 should. :p
>
> But this doesn't work when upgrading to a different disk, when using LVM,
> changing file systems, or when there is other data than the queue on the
> same partition, but you only want to recover the queue.
resize2fs (or whatever it's called) should be able to grow a recovered
queue partition, although I admit I don't know anyone who runs qmail with
the queue on a separate partition. But I'll start doing just that on my
next qmail installation. dump has obvious limitations though.
> By all means; I also choose qmail because I know it. But recommending it
> to other experienced admins is hard, because they enjoy making
> modifications, and ask questions about queue recovery and backup.
Fortunately they're free to run lesser quality software. :)
> >> Very many things in our world are very ridiculously badly designed!
> >Yes. However, I think it's ok to compromise user friendliness if it
> >buys you something more valuable.
> >Just my 2 �re. :)
>
> Here's my counter argument ;-). One does not have to come at the cost of
> the other. An infinitely advanced IMAP server should not immediately be
> infinitely impossible to install, configure, maintain and modify.
I guess this could be broken down to a logical level where we'll either
find that 1=1 or 1=0 depending on the definition of the problem.
I agree with your view, but things outside the IMAP server can impose
restrictions on the argument.
Anyway, thanks for your work with Binc. :)
//Peter
