Re: Caldera installation - something Debian should learn
> Note: I have been corrected. The above solution could have an arbitrary
> back end.
yeah, but i feel this debate is still useful.
> > > > 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
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).
> "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.
> 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.
> 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.
> 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
windows registry i export it to a text file from the registry editor, switch
to linux, edit the text file, and then re-import the text file. after
installing wine, i may even just do a wine regedit and skip the extra boot
involved.
> 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.)
> > > 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.
> All good databases the same mechanism and better performance.
more duplication of effort...
> 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
require a setuid database program, which means more nontrivial security
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?
> 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.
> 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.
> 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).
> Also note the difference bt _data_(uid=0) and a program(sendmail.cf).
see above.
Reply to: