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

[Bill Gunshannon]

In article <5dk6eb-cdd1.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 <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.
> 
> I was talking about the early 80s.

I didn't see any attempt at binary configs in the early 80's.  That seems
to be today's mantra.

> 
>> "Initialisation performance"?  by the time you get to the point where that
>> really matters it's all binary anyway.  :-)  
>>
>> KISS?  What is simpler than human readable?
> 
> Firstly, having all your parsing done by common routines.  In a
> development culture where everyone parses their own text files you get a
> multitude of parsers.  It's reinventing the wheel and no doubt the same
> mistakes are made time and again.

Unless someone wrote a core parser set and turned it loose.  You know,
that Open Source Model everyone is always talking about.  Worked fine
for things like curses, for terminal handling.  Don't find many people
reinventing that today like we did in the late 70's. (I worked for an
Army Captain who wrote a complete curses like interface in Univac-1100
Assembler for terminals like the Infoton family of terminals!)

> 
> Secondly, by enforcing a workflow where your text config files have to
> go through a syntax checker first you are guaranteed that the application
> will come up.

Yes, but given that there are usually a very limited number of possible
entries how hard is it really to validate input?  Unless the input can
be any string and then how do you validate it in any format?  :-)

> 
>> 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.
> 
> I won't disagree with that.
> 
>>
>>> 
>>> 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.
> 
> Like I said this was the early '80s but let's not forget the lessons we
> learned then.
> 
>>> 
>>> 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.
> 
> Too much RMS propaganda?

If you think I have anything but contempt for RMS you haven't been reading
my posts.

> 
> Not job security when you distributed all those config parsing utilities
> with the applications, and provided proper documentation to go with it.
> 
> Now if I look at your arguments from the "software is free therefore we
> have to drum up excuses for software support charges" angle, 

Where did I say that?  I have made a really good living as a Unix admin
and most of it has been admining free distributions of Unix.  At least
the last 25 years.

>                                                               then yes,
> by all means head for text files handled by a million different parsers,
> most of which are inadequately documented so you need to dig into the
> source to find that hidden corner case.
> 
> Gotta keep the money coming in from those support contracts ya know...

And having binary configs that no one can tell the contents of doesn't?
I have looked at the configs for some of the AP's we have bought that are
.bin files.  Even the text data like SSID and the AP's Name are somehow
encoded into a binary format.  Why exactly is that a good idea?  They
are text strings.  What is accomplished by erncoding them other than
obscurity.

And if you want the ultimate example, try working with Cisco sometime.
There are things that need to be done that can not be done using their
GUI config tool.  Oh, and once you make those manual changes, you can
never go back to the GUI because it will happily remove them for you.

 
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>