Fedora Linux Support Community & Resources Center
Prev Previous Post   Next Post Next
  #12  
Old 5th May 2012, 03:50 AM
stevea Offline
Registered User
 
Join Date: Apr 2006
Location: Ohio, USA
Posts: 8,553
linuxfirefox
Re: Setup a Mail server

Quote:
Originally Posted by jpollard View Post
You evidently have not done much application generation
Did it for a living sweet-cheeks. Try revising autoconf file for cross compiles sometime if you want to see what is wrong with this approach.

Quote:
autoconf does exactly that - it is a preprocessor that generates C header files (frequently, not always) for compilation. No difference. Oh, and it uses m4 as well.

But if you want complexity... try modifying a medium sized autoconf file... the macros expanded can be a real mess.
A/ NO it is not "exactly that", your failure to read accurately is legend. I said you have to tweak a bale of C - but that's different than tweaking a massive autoconf file.
B/ I am fully aware autoconf - much earlier there were packages configured to use snobol (yes really). Both are bad approaches by design.
C/ You are making MY case - these sorts of config approaches are brain-dead - too complex and arcane.

No - I DON'T want to modify your hypothetical "medium sized autoconf file" - I've done it 50 times in the past and it's a nightmare. One always expect you are breaking the pkg on some other architecture. The complexity and lack of consistency is the problem - it requires a very different framework if you want to build the same package on an ancient BSD to Solaris to a recent Linux. But to be fair, your example (autoconf) addresses a very different problem then the one on this thread. We are talking about configuring app(sendmail) features NOT configuring the app-build for the environment - two very different things - but thanks for the red-herring fallacy and digression.

Maybe you lost your way in this discussion - my point is that all these "too complex for mortals" approaches to app config are stupid. So your off-topic examples of autoconf are not relevant.



Quote:
Haskell may be clearer, but it is much less portable, and less available. You would do better to use python.
WOW - could you be be any dumber ? I can no longer make excuses for inability to read. I never literally suggested Haskell. I said the a language/macro approach is dumb (like M4) . That IF you had a gun to my head I would choose a "a functional language like haskell" where the declarative non-procedural description has good properties.. Note "like haskell" does NOT mean "Haskell" literally.

Since you seem ignorant on the topic - and have clearly missed my point let me expand. Including ANY common language (M4, C, Snobol) into the app (not environment) config is stupid and wrongheaded. These aren't designed for the purpose and have a lot of obvious flaws when used for this sort of application. Lisp, Haskell, APL and 'make' are functional languages - and I DO NOT suggest any of these be used directly. I DO SUGGEST that IF simple declaration of constants is insufficient (rare and unlikely)- then some functional-language approach be applied. That is it should have a syntax to define rule - not a way to write procedures.

Quote:
But note - your configuration tool is now treating python as a macro preprocessor....
No - I clearly said "None of the above" to macros and other languages, yet you constantly try to insert my ideas into your ill-conceived viewpoint.

Quote:
And it doesn't matter if that configuration tool is GUI based or not. And it gets more complicated on each round, because now you also have to maintain your application configuration tool in addition to maintaining the application.
And you believe that's been a real show-stopper for the Linux kernel and buildtools and crosstools-ng and .... ? LOL, No -the GUI is no cure-all but it can help manage complexity. It does NOT have to be a support-sink.


Quote:
The only advantage m4 really has is that it is nonspecific. It is a small program that doesn't require the application developer to maintain.
And the main disadvantage is that the language syntax and the config design stink like a dirty hippie from the same era
Code:
# strip group: syntax (not inside angle brackets!) and trailing semicolon
R$*                     $: $1 <@>                       mark addresses
R$* < $* > $* <@>       $: $1 < $2 > $3                 unmark <addr>
R@ $* <@>               $: @ $1                         unmark @host:...
R$* [ IPv6 : $+ ] <@>   $: $1 [ IPv6 : $2 ]             unmark IPv6 addr
R$* :: $* <@>           $: $1 :: $2                     unmark node::addr
R:include: $* <@>       $: :include: $1                 unmark :include:...
R$* : $* [ $* ]         $: $1 : $2 [ $3 ] <@>           remark if leading colon
R$* : $* <@>            $: $2                           strip colon if marked
R$* <@>                 $: $1                           unmark
R$* ;                      $1                           strip trailing semi
R$* < $+ :; > $*        $@ $2 :; <@>                    catch <list:;>
R$* < $* ; >               $1 < $2 >                    bogus bracketed semi
utter cr*p, but then .....
Code:
# handle virtual users
R$+                     $: <!> $1               Mark for lookup
R<!> $+ < @ $={VirtHost} . >    $: < $(virtuser $1 @ $2 $@ $1 $: @ $) > $1 < @ $2 . >
R<!> $+ < @ $=w . >     $: < $(virtuser $1 @ $2 $@ $1 $: @ $) > $1 < @ $2 . >
R<@> $+ + $+ < @ $* . >
                        $: < $(virtuser $1 + + @ $3 $@ $1 $@ $2 $@ +$2 $: @ $) > $1 + $2 < @ $3 . >
R<@> $+ + $* < @ $* . >
                        $: < $(virtuser $1 + * @ $3 $@ $1 $@ $2 $@ +$2 $: @ $) > $1 + $2 < @ $3 . >
R<@> $+ + $* < @ $* . >
                        $: < $(virtuser $1 @ $3 $@ $1 $@ $2 $@ +$2 $: @ $) > $1 + $2 < @ $3 . >
R<@> $+ + $+ < @ $+ . > $: < $(virtuser + + @ $3 $@ $1 $@ $2 $@ +$2 $: @ $) > $1 + $2 < @ $3 . >
R<@> $+ + $* < @ $+ . > $: < $(virtuser + * @ $3 $@ $1 $@ $2 $@ +$2 $: @ $) > $1 + $2 < @ $3 . >
R<@> $+ + $* < @ $+ . > $: < $(virtuser @ $3 $@ $1 $@ $2 $@ +$2 $: ! $) > $1 + $2 < @ $3 . >
R<@> $+ < @ $+ . >      $: < $(virtuser @ $2 $@ $1 $: @ $) > $1 < @ $2 . >
R<@> $+                 $: $1
R<!> $+                 $: $1
R< error : $-.$-.$- : $+ > $*   $#error $@ $1.$2.$3 $: $4
R< error : $- $+ > $*   $#error $@ $(dequote $1 $) $: $2
R< $+ > $+ < @ $+ >     $: $>Recurse $1
Anyone sane should recognize the above as a strong reason to avoid using M4 - ever.


Quote:
The sendmail m4 macros encapsulate the rules for features. Most of them are of the "uncomment if you want the feature" variety, with a few "set the value if you want". One of the reasons for the macros is that optional features can affect other features so that they can be implemented properly.
Then we agree that the design is not disjoint, has side-effects - therefore bad. Lack of side-effects is why Haskell-like declarations are a good idea IF they are even needed for an MTA config(unlikely).
__________________
None are more hopelessly enslaved than those who falsely believe they are free.
Johann Wolfgang von Goethe

Last edited by stevea; 5th May 2012 at 03:54 AM.
Reply With Quote
 

Tags
mail, server, setup

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
How to setup mail server kyungmin002 Servers & Networking 2 10th August 2007 11:53 AM
Mail server - setup virtual mail boxes satimis Linux Chat 0 10th February 2007 04:00 PM
Web and/or Mail Server setup process when using a Windows Server 2003 for DNS and IP FarmBoy Servers & Networking 0 14th December 2006 05:48 PM
how to setup pop mail clietns for local mail server? shams Servers & Networking 7 19th July 2006 09:05 AM
Setup a Mail Server? pureFlamez Servers & Networking 12 28th October 2004 03:10 PM


Current GMT-time: 15:43 (Wednesday, 23-04-2014)

TopSubscribe to XML RSS for all Threads in all ForumsFedoraForumDotOrg Archive
logo

All trademarks, and forum posts in this site are property of their respective owner(s).
FedoraForum.org is privately owned and is not directly sponsored by the Fedora Project or Red Hat, Inc.

Privacy Policy | Term of Use | Posting Guidelines | Archive | Contact Us | Founding Members

Powered by vBulletin® Copyright ©2000 - 2012, vBulletin Solutions, Inc.

FedoraForum is Powered by RedHat