Re: Caldera installation - something Debian should learn
On 23 Apr 1999, Chris Waters wrote:
> > To sum up:
> > Databases offer:
> > better speed
>
> Not enough to notice unless you have *huge* amounts of data. Config
This is the only situation where you would care.
> file are unlikely to benefit from the ability to sort and search
> quickly -- which is the biggest advantage db's offer here -- configs
> are usually read in their entirety.
bind and apache and sendmail could benefit from differential
loading. These are linux's bread and butter.
> > smaller size.
>
> Mostly because you can't easily store comments with a given db entry.
> One advantage of text files is that you *can* have all sorts of handy,
> useful comments stored in the config file. Even comments on
> particular settings chosen by local admins.
This is a good point. I'm a big fan of adding a comment, date and
uid for every change in a config file. This would be easy in a
db.
> Also, while the data *itself* may be slightly smaller, the code to
> parse it becomes much larger. And, frequently, much less portable.
Maybe and maybe. With special care the code needed to parse the bin
could be smaller than it's txt counter-part, although in general
I agree it would take some effort.
> > other inhereted database properties
>
> Such as? So far, I'm not seeing *any* advantages that are worth
> anything.
I disagree. Please see my other posts.
> > text files have:
> > the "advantage" that they can be edited easily
> > consider: what if you're logging in remotely and they
> > only have telnet or it's a slow connection?
> > ppl are used to them
> > this I think is the strongest point. Retraining
> > is a major concern.
> > they are not NT
>
> Also, text files are *readable*, don't rely on specialized tools, and
> offer far greater flexibility. It's not just a matter of editing
> them, text files can be *parsed* by perl (or other langauge) scripts
> that can make intelligent decisions based on their contents. Yes, you
> can write a perl db api, but that doesn't help the poor sucker who's
> using sh or Python or C or Eiffel or CLOS or Scheme or Forth or
> Snobol. All of those languages *can* and do parse text out of the
> box.
This is a major concern of mine and a reason why we didn't go with COAS.
Our distribution doesn't force you to use the db. When you come around,
though, it's there. (Not that COAS does)
> Also, text files are *simple*, and don't require powerful db engines
Simple things are good for simple jobs(well except mathematics).
Linux is not simple anymore. It needs a more powerful way of doing things.
> to be installed. For people who want to make minimal installations
> for embedded systems or such (c.f. the Linux Router Project), this is
> a very big issue.
I don't think I would store that small an amount of data in a database.
I would be just silly. In our distribution we deal with legacy apps
(ones that need /etc/*) with bridges. These take the info in the
db and write it to the correct file.
> Also text files are inherently platform indepedent. Many db's are
> not, and the ones that are are larger and slower than the ones that
> aren't.
OK. Well the db backend we have chosen is light, portable and
works well with queries but not with frequent updates,
(ten geek points to who can guess the db!).
> A text file can easily be copied to a second machine, and quickly
mirroring
> edited if need be. A text file can often be recreated with no more
> tools than *cat* available, when the system has major corruption. A
roll back the data or use data correction.
> db will make the system far less flexible, far less stable, and far
> less maintainable.
less flexible in some ways but more in others
more stable, not less
less maintainable in some ways but more in others
+---------------------------------+-------------------------------------+
| R Garth Wood | Making waves... |
| Stormix Technologies Inc. | |
| rgwood@stormix.com | |
Reply to: