Re: Caldera installation - something Debian should learn
On Fri, Apr 23, 1999 at 04:58:24PM -0700, R Garth Wood wrote:
> > the fact is, you CAN engineer in robustness and backups etc
> > into databases. that's true. however, you can't put back in the
> > flexibility that you've sacrificed.
>
> One of my other posts spoke to this.
>
> > text files are essentially free-form, and comments can be left in
> > them to provide instructions, commentary, and examples.
>
> ditto.
i've read all of the posts so far in this thread, and didn't see anything
from you (or anyone else) which even remotely addressed these issues.
"proof by assertion" is no proof at all.
> > by contrast, databases are a rigid structure and a menu or GUI
> > config tool is severely limited in that it can only do what someone
> > has time to
>
> install postgres and play with "pgsql"(I think it is). It's not what
> I'd call a GUI. I'm not proposing a GUI for everything.
i use postgresql on a daily basis. it's a great tool. one of the good
things about it (and any other unix-based SQL database) is that it is
quite easy to extract the data from it into plain text format so the
data can be manipulated with standard text processing tools (awk, sed,
perl, etc) for generating reports in plain text, html, TeX, postscript
or whatever.
however, it's not the right tool for the job of a configuration system.
One reason for this is that there is a lot of low level stuff (network
interfaces, IP addresses, hostname, etc etc etc) which has to be set up
at boot-time BEFORE postgresql can be started.
text files work right from the moment the kernel is booted and init
is started. This single fact is of absolutely vital importance - it
means you can recover your system from anything short of a complete
catastrophic disk failure (e.g. a fire).
Another reason for pgsql (or any other db) being inappropriate for this
job is that is a lot more complicated and you need specialised tools to
interact with the database. for applications-level stuff, that is fine.
for systems-level stuff, it sucks badly.
If one of my servers goes down and the config data gets garbled, I
*must* be able to start working to fix it immediately, and not have to
mess about for a few hours to get postgres running again before i can
even begin to fix the configuration. downtime is expensive, much more
expensive than intelligent and experienced sysadmin staff.
with text config files, i can do that with a boot floppy and vi (or even
cat and/or ed in a pinch). with postgres, i can't.
robustness requires that the machine is usable or recoverable even in
the worst-case scenario...not just the best case.
> I'm a strict believer that command prompts are the fastest way to get
> stuff done. But what command prompt is the fastest?
command prompts are useful for running or scripting things. text editors
are useful for editing things. together they provide the most flexible
configuration environment possible...you can do things with them that
the configuration-tool's programmer hasn't even thought of, let alone
catered for.
> > program. In a text config file you can leave a human language
> > comment saying "Do X if you want Y" or "uncomment the next line to
> > do blah".
>
> You can put that in the db as well.
no, you can't.
really.
all you can do is have space for a field or record so that someone can
enable X or Y. You can't leave in a comment explaining what, why, or
how....to do that, you need to write some code to make that option
available to whatever front-end (gui, curses, cmd line, etc) the user
is running, and you need extra code to provide help/documentation, and
extra code to ensure that the user isn't filling the db with garbage.
even worse, this will greatly slow down the evolution of programs. in
order for a new feature to be implemented, you now have to also update
the configuration tools to support the new feature. you have to do this
for each of the configuration tools that are available (GUI, curses,
command line, etc).
that is a lot more work than just implementing the new feature and
leaving a comment in the config file. Writing user interface code is,
generally, a lot more work than writing the "payload" of a program. this
would have a serious impact on the ability of programmers to experiment.
to summarise my arguments against your ideas, i think that some of what
you say has some merit...but you are way too narrowly focussed. You see
only the detail of "making it easier for novices to configure unix".
You fail to see the bigger picture of WHY unix is the way it is. It
isn't like this because nobody has thought of these things before. It
is like this because it works, and it works reliably, and it allows for
incremental or evolutionary improvement....and it has demonstrated these
virtues repeatedly for decades.
You say in another message "I guess. But unix has been text based
for almost 30 years. Isn't it time to change, if just a little?".
The answer to that is no. The time to change is when the benefits
of changing greatly outweigh the disadvantages of changing. Any
configuration tool would have to be exceptionally good to be able
to outweigh the costs of transition and the loss of standard text
processing utilities.
i have seen no evidence whatsoever that it is possible for any
configuration tool to do that. The existing configuration environment
of shell + editor + text manipulation tools is just too good to compete
with. you can improve on them, by building some new tool that works well
with them (e.g. perl is a vast improvement over awk...but still remains
compatible with using awk), but you can't replace them.
> > text files are cheap. they are flexible. they depend on an
> > intelligent human being to handle and resolve error conditions.
>
> What if the human is einstein? He was a pretty smart kid but would he
> use windows NT or unix if he was alive today? A hyperbolic example but
> you get the point.
i fail to see your point. is there one?
craig
--
craig sanders
Reply to: