Re: Caldera installation - something Debian should learn
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.
> need to be reimplemented in some way for any useful configuration method,
> and that's a waste of effort (not to mention clinically proven never to be
> as good as a few simple tools, forming a basis with which any kind of change
> can be made quickly and efficiently).
"clinically"? Where?
> > "spirit"? Well if you have some sort of religous attachment to text files
> > then I can't convince you.
>
> it's not religious... if someone can share their experiences with a
> consistently better method (and if you find a happy nt registry user i will
> be very surprised) and provide examples as to where the unix way (and it is
> the traditional unix way) fails but a binary database succeeds, i could be
> convinced.
Hmm that's a tough one. I'm not old enough to answer that. Just because
I cannot give an example doesn't mean it's not the case, though.
> > I think we should make the distinction here between *data* and a config
> > file. sendmail.cf is a language with variables in it(the data).
>
> yes... the data is going to be the same no matter what language it's
> expressed in. i at least have not even considered storing different data,
> because you haven't suggested it. what we need to consider is what the best
> way to store this particular flavor of data (configuration for various
> programs) is. now, correct me if i'm wrong, but the most vital necessity for
> configuration data is, well, configurability. if it's hard to change the
> configuration data, it's suboptimally stored.
Yes I agree totally. I don't propose to do away with configuration
languages, just where they store their _DATA_. Is there a better
way to store sendmail.cf, maybe but this one works. The data,
however, should not be stored in the file.
> > 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.
> > I would never say that windows * registries are the optimal solution.
> > They are the right idea, though, just a bad implementation.
>
> but i don't like windows registries exactly because they are binary
> databases that are nigh impossible to edit. in fact, when i want to edit my
Like I said a bed implementation.
> > 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.
>
> you can't ensure that nobody will copy the api without closing it. (why
> would you want to? the idea is to make it so nobody *has* to duplicate work,
> not that nobody *can*. that's just fascism.)
I'm not proposing a closed API nor would I ever. I totally agree with
you(on this point).
> > > > 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.
> > All good databases the same mechanism and better performance.
>
> more duplication of effort...
Ok. now you hve to clarify. I forgot what I was talking about.
> > Sure different databases, different permissions.
>
> which is, in fact, non-trivial to do. especially with dumping them to text
> files with the apppropriate owners and permissions. it would probably
Like I said, dumping is not recommended.
> require a setuid database program, which means more nontrivial security
I don't think so.
> issues just because it's setuid.
>
> > To sum up:
> > Databases offer:
> > better speed
> > smaller size.
> > 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
size - ditto
other - stuff already mentioned:
checksums
backups
not mentioned:
networking
high-availibility
I'm sure others can add a lot more as well.
> > 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.
> > 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.
> > they are not NT
>
> this honestly doesn't bother me. in those cases where nt is easier to use i
> wish debian were more nt-like (however, i'll note that i've found none yet,
> with the caveat that i'm not much of an nt user).
It does bother some, though.
+---------------------------------+-------------------------------------+
| R Garth Wood | Making waves... |
| Stormix Technologies Inc. | |
| rgwood@stormix.com | |
Reply to: