Re: Caldera installation - something Debian should learn
On Fri, 23 Apr 1999, Jonathan P Tomer wrote:
> > 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.
>
> i assume that anything you propose and/or write would be free software, yes?
> if it's free, there is no way to prevent other parsers for the same
> format being written; it's a fact of life that sometimes people want to redo
> an old algorithm. so this "problem" (which is actually a good thing) is not
> related to using an easier-to-write-and-parse format.
I would hope they would contribute back into the project. If it was
ideed faster, we'd use it.
> > 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).
>
> if i can't tell exactly what it's doing, it's too obscure for me. further,
> libc is pretty solid because it's both old and used by every c program
> running under unix. no bug could survive long in such an environment. by
> contrast, the first time a new binary format is introduced, the reference
> implementation is guaranteed to be pretty buggy, unless you've designed some
I think you're missing the point.
> new self-debugging programming language, in which case i'd rather see you
> release that first. ;)
Wait for it(it's my own project not related to this at all)!
> > 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.
>
> how does one common api preclude using a good format? if your text file
It doesn't. I didn't say that.
> parsing api is good, nobody will ever write another one to do the same task.
> if it's a good api for a text file format, not only will it be easy to
> parse, but i can edit my config files with sed, which means you don't have
> to write an equivalent for your database. now that's saving effort.
I disagree.
> > 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
>
> why can you store a checksum on a binary database but not a text file? and
> even better for checking whether something has changed than a checksum is to
> check the modification time -- another case of "already been done in an
> easier way".
You can store checksums for individual logical pieces of data. Not only
the whole thing.
> > situation where a text file is better in speed or space than a db.
>
> true, but speed and space just aren't an issue (as you mention in a later
> post to this list) for config files.
OK. I need to be more precise. Relative space and relative speed.
> > What about differential backups?
>
> umm... you got me... what about them? (please clarify how this is relevant
> in the context of this thread, i don't see what you're getting at.)
It relates to the checksum discussion. See above and think about it
some more.
> > Who said you cannot dump the database to a text file?
>
> well this would be nice, but it's still wasted effort to parse the database,
> and you introduce problems of synchronization and security (who gets to edit
This is oviously not the recommended use of the db. Databases handle
syncs for you. Question: how do you handle syncronization?
> the httpd configuration? the sendmail configuration? how do you make sure
> the web admin doesn't get to fubar the password database?)
You can put permissions on databases.
+---------------------------------+-------------------------------------+
| R Garth Wood | Making waves... |
| Stormix Technologies Inc. | |
| rgwood@stormix.com | |
Reply to: