Re: Let's write a system admin friendly mail server packaging system
Thomas Goirand <thomas@goirand.fr> wrote:
> Mario 'BitKoenig' Holbe wrote:
>> So far this is independent of third packages which is IMHO fine and
>> desirable. So far, this could be solved by a postfix-conf.d-snippet
>> shipped with the amavis package.
> Quite not. You also need to configure the incoming and outgoing ports of
> amavis the correct way.
Which of course will also be done by the amavis package itself. Still,
no dependency on third packages so far.
>> * postfix ships to amavis
>> * amavis ships back to postfix
>> * postfix ships to dkimproxy
>> * dkimproxy ships back to postfix
> No, it's not any cleaner, and it's slower. As I wrote previously, we
Cleaner from a dependency-perspective. Why isn't it?
This way you are able to configure the whole integration within one
package (i.e. amavis ships the amavis-postfix integration, dkimproxy
ships the dkimproxy-postfix integration, etc. pp), you can just avoid
any complex chaining-magic.
And slower? What are we talking about? Whole two percent?
> Are you trying to say that we shall ship a not performing configuration
> by default, because big ISP are capable of reconfiguring? If you are,
I'm trying to say that I would prefer a straight, clean dependency-
minimizing approach over one that does and/or requires complex magic.
And I'm aware that clean approaches are usually somewhat less performant
than optimized setups, which, in turn, tend to be more complex.
And I think that a clean and simple approach would help more users than
one that tries to squeeze the last cpu cycles out of your system for the
price of being hard to understand.
Don't get me wrong: I totally agree with you that what we have now is
neither the one nor the other.
And yes, I think that somebody who tries to optimize a system for
highest performance will write his own configurations anyways.
Hey, if you really like to squeeze cpu cycles the first thing you do is
to build architecture-specific binaries. Writing some optimized config-
files doesn't matter then anymore.
> I think we shall try to release the best distribution as we can, with
> correct, performing values by default, and even, if possible, have a
> default configuration that you never even need to edit, because it's
> just right by default. We should at least have this goal in mind,
"those goals" - you named three: correctness, performance and useful
defaults. Choose two of them :)
There are way more btw. - not only for users but also for maintainers,
etc.
> Maybe I'm being too idealistic here. What's your opinion?
I don't think it's bad to be idealistic. We just have different ideals
probably :) Well, most likely we just weigh conflicting goals different.
regards
Mario
--
Um mit einem Mann gluecklich zu werden, muss man ihn sehr gut
verstehen und ihn ein bisschen lieben.
Um mit einer Frau gluecklich zu werden, muss man sie sehr lieben
und darf erst gar nicht versuchen, sie zu verstehen.
Reply to: