Re: Caldera installation - something Debian should learn
In message <[🔎] Pine.LNX.4.10.9904221734490.3373-100000@peace.netnation.com>, R Gar
th Wood writes:
> On Thu, 22 Apr 1999, Jonathan P Tomer wrote:
>
> > > I have read it. Keeping data in a text file that needs to be parsed
> > > is an antiquated notion that needs to be eliminated. The information
> > > contructs are correct, however.
> >
> > no no no! keeping data in a text file may be an old notion, but is not
> > antiquated and *definitely* does not need to be eliminated. quite the
> > contrary, in fact. text files for configuration information are Very Good
> > Things (tm) because *text files can be edited however one wants*. forcing
Right. This is the Unix spirit. Use a small orthogonal set of simple tools
together to solve a given Problem. With text files I can grep through them
or change them with sed on the fly. With binary config files, like on NT, I
have to use the given tools. Either the problem is solvalble with them or
you're doomed.
I think a reason why so many admins don't like AIX is because of the binary
config files there.
>
> In fact I believe that's their most glaring weakness. Enevitably popular
> software has more and more parsers that read and write it's config files.
> Note that they are DIFFERENT parsers(not equivalent ones). For any
> dataset there should only be one way to access the data(one API for
> example). This ensures that work is not duplicated. THIS is a good thing.
How many freeware/shareware/commercial registry editors exist for NT ?
>
> > the sysadmin to depend on a possibly buggy, definitely obscure admintool is
>
> I have never mentioned an obsure admintool. If there was only one API
> it certianly would not be buggy(libc for example is pretty solid).
>
> > always a bad thing. parsing a text file, otoh, is comparatively easy to do,
>
> Counter example: sendmail.cf
I guess it's easier to parse, then to create ;-)
>
> If parsing this is easy to do please write one in the next few hours
> and post it. :>
>
> > especially since it has been done already numerous times for just about any
> > kind of structure.
>
> You see that's the problem. It would not have to be done numerous times
> if there was one common API. Who many ppl on this list have wrote a
> perl script to edit httpd.conf somehow. Wasted effort.
>
> > binary databases, by contrast, have only one virtue: they are slightly
> > faster to look at. this does not even begin to compare with the advantage o
> f
>
> Slightly faster? No way. I store a checksum on a n MB file. You have
> to parse the whole thing to see if it's changed. If fact there is no
> situation where a text file is better in speed or space than a db.
That's what he wrote, isn't it? But speed isn't a issue. Most configuration
files are only read at boot time and even my old i386/20MHz boots in less
than 2 minutes, don't ask about the K6II/400MHz or even the computer most
of us will run two years from now.
>
> What about differential backups?
Yes, what's about them?
BTW: text files fit much easier in a version control system like CVS.
>
> > being able to edit the file. you can have some speed savings by building an
>
> Who said you cannot dump the database to a text file?
Text files. The web-admin should be able to edit the config file(s) for the
httpd, but not necessarily for the MTA. With many files you can exploit
Unix file permissions for access control, with a central DB you have to
invent some alternative scheme. And the past shows, that it's non-trivial
to get security right.
>
> > index of the database to be used by the administration tool, but it's not
> > really worth the effort imho.
>
> Yes that would be silly.
>
Guenther
PS: Look at SuSE's yast/rc.config for a warning.
Reply to: