Re: Caldera installation - something Debian should learn
On Fri, 23 Apr 1999, R Garth Wood wrote:
> On Fri, 23 Apr 1999, Jonathan P Tomer wrote:
>
> > > > > > Things (tm) because *text files can be edited however one wants*. forci
> > > So can a database.
> >
> > you can't edit a binary database with vi. you can't edit a binary database
> > with sed. you can't search a binary database with grep. all these things
>
> Well my sql's a bit more rusty than I'd like so I can't give example
> off the top of my head but you can do all that with it.
I use sql almost every day and I haven't yet seen regular expressions in
it. Also, sed is one of the most powerful search-and-replace tools I have
ever seen (I have never taken a good look at perl). Would you re-implement
that in the database?
> > > With a database you can change the data with SQL or what have you.
> >
> > sql has nothing on sed, and not even an analog to any of the other editing
> > tools available for text files.
>
> Hmm. I think you will find the correct db schema will eliminate the
> need for sed-like tools.
With text files, you don't have to think what your users might need to
use. They'll use whatever they need to do what they want to do.
> > > > > What about differential backups?
> > > > Yes, what's about them?
> > > It should be ovious.
> >
> > clearly it's not, or we wouldn't have asked. if you have a point please
> > clarify it.
>
> Sure by popular demand:
> you can tell if data has changed or not(In constant time).
> therefore you only have to backup of changed data. that's good.
Storage space on backup media is not really much of an issue, if that's
what you mean. My /etc occupies 2843 kB disk space in total. There are
1193 files in it, the largest of them being 90 kB large. If you can detect
if individual files have changed (and you can, in several ways), you only
need to make a backup of files that have changed. You could make
differential backups using time stamps to check if files have changed
since the latest backup, and using a few very simple and age-old unix
tools to back them up onto a 3.5" floppy disk or whatever media you use
for backups.
If you need to _partially_ restore a config file from a backup (because
you screwed up while editing it), you can restore it into a different
location and run all sorts of diffs on the two versions, using standard
unix utilities.
> > > To sum up:
> > > Databases offer:
> > > better speed
This is, like others have said, not much of an issue.
> > > smaller size.
See above. Not important. Configuration data isn't exactly large.
> > > other inhereted database properties
> >
> > i'm not much of a database expert. could you expound these further?
>
> speed - I think you'll argree with me there
Not important. For sendmail speed is important, but that's the only
example I know of. And the syntax of sendmail.cf has been optimised for
parsing speed, so any db will probably score worse anyway.
> size - ditto
See above. Not important.
> other - stuff already mentioned:
> checksums
You can make checksums of text files, and store them in a text file.
What's the point?
> backups
See above. Text files can be backed up, too.
> not mentioned:
> networking
Do you mean centralised configuration stored on a single machine? This can
very easily be done when configuration is stored in text files. Just use
some push mirroring program to send a changed file to every other computer
in your network.
> high-availibility
Text files are always available. Database servers can crash. What's your
point?
> > > 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?
> >
> > ??? what problem is this? it's still easy to type "sed" or run vi.
>
> With a database either it was committed or not. With vi over a modem
> it's painful. Also with on;y telnet you have to think about security.
With vi, you have either written the file to disk or you haven't. It's
just the same. If you think vi over a modem is a pain, it might just be
that you don't know vi well enough. And ssh is a very good alternative for
telnet.
> > > ppl are used to them
> > > this I think is the strongest point. Retraining
> > > is a major concern.
> >
> > it's not only used to... every conceivable utility for the manipulation of
> > the format already exists. if there isn't it can be simulated with perl. all
> > of these would have to be redone with a binary database.
>
> This is one of the major points, though. You don't need grep, sed,
> etc.
Why do you think so?
Now, consider something else. Suppose dpkg is upgrading a certain program.
I have edited its configuration file before, but the default configuration
file that comes with the program has also changed. Maybe it now has a
different format than before, or the author has decided to use different
default values, or there is another reason for it. Dpkg then asks me about
this, so that I can investigate the issue (using normal tools like 'diff')
and tell dpkg what to do. How would you do that if the configuration data
was stored in a db?
Remco
--
rd1936: 4:15am up 11 days, 4:12, 9 users, load average: 1.08, 1.06, 1.01
Reply to: