Re: Caldera installation - something Debian should learn
On Sat, 24 Apr 1999 firstname.lastname@example.org wrote:
> > Note: I have been corrected. The above solution could have an arbitrary
> > back end.
> So, we're keeping the text file based configuration? Than I don't have to
> care further. :-)
This is just a discussion. I just became official today. Woh-ho!
> > > > > no no no! keeping data in a text file may be an old notion, but is not
> > > > > antiquated and *definitely* does not need to be eliminated. quite the
> > > > > contrary, in fact. text files for configuration information are Very Go
> > od
> > > > > Things (tm) because *text files can be edited however one wants*. forci
> > ng
> > So can a database.
> Right, but not with that wide spread collection of tools.
Right but you don't need those tools with a db.
> > > Right. This is the Unix spirit. Use a small orthogonal set of simple tools
> > "spirit"? Well if you have some sort of religous attachment to text files
> > then I can't convince you.
> Please exchange 'spirit' by 'idea behind of', in contrary to 'Eierlegende-
> wollmilchsaeue' (is there a translation for this term? best I can think of
> is 'one-tool-does-it-all') like Netscape and StarOffice.
This is another advantage. If all the information was avail though one
API you wouldn't need all in wonders(well you might need DCOM or
CORBA as well).
> I'm just (very) suspicious, because I made the experience, that the tools
> provided by (most) Unices are better fitted to handle server configuration
> than the NT registry editor. E.g. remote administration or administrating
> a whole bunch of similiar servers (like a web-server farm). On a single
> host it may not matter so much and joe average might like a point and click
> interface better.
> IMHO text based configuration files are an inherent part of Unix. An OS
> without them might prove better (easier to administer) or worse, but it
> wouldn't be Unix anymore. I'm serious about that. Would there still be a
I guess. But unix has been text based for almost 30 years. Isn't it time
to change, if just a little?
> need for sed, grep, awk or vi? Does it even need a shell? Some like to get
> rid of those, since they don't need them anyway and never learned to use
> them (or the other way round?). For the new OS one might wish kde/gnome
> based tools. I'll bet many will stay for a nother decade with traditional
I certainly hope not. No mouse-GUI can match the speed of a good
command line. I think the most optimal would be a keyboard-GUI with
a good 3D accelerator.
> Well, I guess I have an attachment to Unix, but I wouldn't call it religious.
> You must understand me, compared to CP/M (you remember?), DOS, Windoze XX
> and even VMS, it's so lovely. (Now don't call it amorously ;-)
> > With a database you can change the data with SQL or what have you.
> Again, not with the tools I'm used to and have proven to be handy.
This is one of the strongest points for txt-based stuff. I think
a slow migration is the best.
> > > have to use the given tools. Either the problem is solvalble with them or
> > > you're doomed.
> > I would never say that windows * registries are the optimal solution.
> > They are the right idea, though, just a bad implementation.
> Is there a 'good' implementation?
> Another defency of NT registry: If I have to reinstall NT (happend in the
> past, will happen in future) I have to reinstall most applications even
> although they are stored on a seperate (and integre) media, because not
> only system configuration, but also application and even user data is stored
I think they're suffering from marketing pressure there. Can you justify
"it works better" instead of "feature X" on your marketing literature?
> > > > What about differential backups?
> > > Yes, what's about them?
> > It should be ovious.
> Sorry, _that_ wasn't a rhetorical question. I don't see the difference
> between text and binary files in respect to back-up.
You can see what data has changed and on;y backup that data, not all
of it. I know you say diff but diff varies on the bytes in a file
a checksum is already computed usually.
> > All good databases the same mechanism and better performance.
> Right, but can I see the diffs?
You can search for data changed after a certain date/time.
> > I believe cvs does binary files now as well.
> CVS can handle binary files to some degree, but can't give you the (then
> meaningless anyway) diffs.
Hey I didn't say it did it well.
> > To sum up:
> > Databases offer:
> > better speed
> Is there a need to improve time efficience for reading config. files? I
> do not really care, if the servers take 1 or 2 minutes to boot-up. I care,
> if the sendmaild takes 1 or 2 hours to get the mailing list out, but not
> if it takes 5 or 0.03 seconds to parse the configuration file.
Like I said earlier it's relative speed.
> > smaller size.
> for configuration files? Your kidding. In an other mail you estimate the
> total size to be less then 10MB - so what?
> > other inhereted database properties
> I'm not too familiar with DBs. What other properties could help system
> > 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?
> Yes, happens all the time. I can deal with that. Sometimes, I wished to
> have a line-oriented ssh. Why the parantheses? Can you imagine the fact
> to easily edit config files a disadvantage?
You can do the same with dbs.
> > ppl are used to them
> > this I think is the strongest point. Retraining
> > is a major concern.
> Right, Unix is out for about 30 years (as am I ;) And importance of the
> fact, that it is still there and is quite well documented shouldn't be
Yes that's a concern as well. Well see what happens.
> > they are not NT
> I regret to have used the word 'spirit' above. Sorry to mention M$ product
> all the time, but I haven't dealed with any other binary config system
> so far.
Some ppl hate MS a lot, though. I know I do whenever I put a cd
> > Also note the difference bt _data_(uid=0) and a program(sendmail.cf).
> ??? I guess I understood your wish to seperate between configuration
> variables ('keys' in the NT registry, right?) and the data assigned to
> them in a configuration file/registry, but what is meant by uid=0? Should
> the data be accessed by root (setuid process) only?
Nope it was just an example of a key you might store.
| R Garth Wood | Making waves... |
| Stormix Technologies Inc. | |
| email@example.com | |