Re: Caldera installation - something Debian should learn
On Sat, 24 Apr 1999, Remco Blaakmeer wrote:
> > > 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?
Ya you wouldn't have to do that if the database is designed correctly.
> > 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.
Like I said if the schema is correct they should be ok.
> > 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.
I think our backups are in the GBs every night. That's with the
traditional tools. There is the problem that what if you have
to restore and the restore spans multiple cds(whatever). In
this case getting a image of said host is not easy but with some
decent software you should be happy.
> 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.
Hmm you think so? Why?
> You can make checksums of text files, and store them in a text file.
> What's the point?
you can store checksums on any piece of data or logic piece.
That's why.
> > backups
>
> See above. Text files can be backed up, too.
Are you sure? No just kidding! Differential backups your friend.
> > 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.
Most dbs can do this with a simple change.
> > high-availibility
>
> Text files are always available. Database servers can crash. What's your
> point?
Nono. I mean as a network service. You could have many servers
acting as one to serve data.
> > > > 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
But you must restart the service.
> 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.
Hence the qualier "only". If you didn't have telnet you'd be screwed.
> > > > 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?
you have the databases' own language(ie sql).
> 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?
checksum.
+---------------------------------+-------------------------------------+
| R Garth Wood | Making waves... |
| Stormix Technologies Inc. | |
| rgwood@stormix.com | |
Reply to: