[Info-vax] Changing SMTP server presented hostname in UCX

[Bill Gunshannon]

In article <bpn3eb-n3s1.ln1 at news.chingola.ch>,
	Paul Sture <nospam at sture.ch> writes:
> On 2014-09-09, Bill Gunshannon <bill at server3.cs.scranton.edu> wrote:
>> In article <lumsjt$if5$1 at dont-email.me>,
>> 	Stephen Hoffman <seaohveh at hoffmanlabs.invalid> writes:
>>>
>>> IMO, hand-edited configuration text files aren't the way forward for 
>>> system and network configurations, either.
>>  
>> I have heard this (and seen it done) from many corners but I certainly
>> don't agree.  Sometimes you just want to change something simple and
>> having to redo the whole mess just seems like a lot of wasted time.
>> And, when things go wrong and a human has to fix it it is a lot easier
>> if they can actually see and understand what they are dealing with and
>> not the way some config program is interpreting it.  I would love to
>> know just what the supposed advantage of binary configs over human
>> readable ones is.  Unless it is an attempt at obscuring data to protect
>> ones job.  Sometime abstraction is a good idea, but not always.
> 
> Memory, initialisation performance and Keep It Simple, Stupid.

Memory is hardly a problem today.  I doubt that most config files occipy
that much more space as human readable text than as binary values.

"Initialisation performance"?  by the time you get to the point where that
really matters it's all binary anyway.  :-)  And There are many other places
where efficiency can be improved in most programs but no one seems to care
about system efficiency any more.

KISS?  What is simpler than human readable?


> 
> Many moons ago we used the approach of intermediate binary files because
> we didn't want the overheads (memory, runtime) of a text parser in
> application startup.  Separate utilities to turn text files into binary
> files meant that the syntax checking was done in those, not by the runtime
> app.  Think of bytecode compilers for data structures alone, no code.

To my way of thinking we are long past the point where there is any gain
from "compiing" config files and back when memory and machine performance
were both premium and expensive we didn't do it.

> 
> From the app's point of view, at startup the sizes of the various bits and
> pieces represented by these binary files was worked out at compiler time
> so it was a simply matter of allocating the various memory structures and
> reading binary data straight into them.  This was a definite win on
> application startup times.
> 
> Remember that this was an era where there was a clear separation of duties
> between operators and development staff.  The idea of precompiling config
> files suited this environment well.
> 

Still not convinced, unless, as I said, the real reason is job security.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>