Re: Caldera installation - something Debian should learn
On Sat, 24 Apr 1999, Craig Sanders wrote:
> > 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.
Maybe it wasn't posted to the list yet.
> "proof by assertion" is no proof at all.
Then I shall invoke my favourite: proof left to the reader.
> > 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.
Great then you agree with me.
> 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.
After init anything can be started. You're right in pointing out
that it would be problematic but not that hard, either.
> 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).
a database could use data correction, if a text file is corrupt
what're you gonna do?
> 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.
I think we could make it not suck that badly(tm). :>
> 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.
Well postgres is a bit of a monster to require all machines to
run. A light version with pointers into a postgres might be a better
idea.
> 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.
I think a command line db editor would be small and straight-forward.
In fact it would resemble a file system.
> robustness requires that the machine is usable or recoverable even in
> the worst-case scenario...not just the best case.
Given a random disk-corruption function
a database with data-correction will do better than a text based
dataset everytime, and with no effort from the user.
> > 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.
I'm not saying we have to do away with text editors either. After all
what the hell are we going to write all these programs with?
No I quite like vi(m). There is a language for just about everything.
To write a program you invariably need a editor and an envoirnment
to run it in. These things are self-evident.
Consider the task of writing a GUI:
You have purpose P. You have a dataset D. Each item of D has dependancies.
Hence to reach P you need to complete D.
Hence a GUI language must only specify the the data set and the purpose.
Clearly in such a language the program would only constitute
a few lines:
P = some_funtion(fistname x, lastname y, addres z);
x = get_from_db(name.first);
y = get_from_db(name.last);
z is not specified but the language knows what an address is and
how to get it. It would ask the user in whatever interface he was
viewing to specify the data.
Yet in C/C++ even tcl/tk this is a O(1k) lines program.
The point? Every language has a purpose. Every db has it's place
as well, text dbs are good for small systems that are "one-offs".
If you want all the benefits I have outlined at length use a db.
> > > 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.
So then you can. Great we agree.
I'll say it again I don't want to GUIfy everything(anything). I don't
believe I've mentioned a GUI in this whole LONG thread.
I believe for scalible systems you need dbs. For small one-off
systems text files may be better.
> 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
What feature?
> 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).
What if you only had to write the UI code once and it could be
rendered in text, X/gtk or openGL? Wouldn't that be cool?
> 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.
I know how you feel. Wait for it. There's a storm coming...
> 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
Thanks.
> only the detail of "making it easier for novices to configure unix".
It will be easier for everybody. Windows made the following mistake:
make everything look like stuff in the real world and computers
will be easy to understand. The proplem is you can't do anything
powerfull with windows because itr's made for idiots. The truth
is if you learn a bit on the front end you probably will win
in the end.
Anecdote( i still can't spell):
I recently went to a travel agent. To find out flight times
they where entering some cyptic stuff into a mac terminal interaface.
She was doing like 5 actions per second. She then went to print
something. It took her about 15 seconds to do that.
The point(ok so it's a parable) with a little bit of education
she was very efficient. When she went to the idiot's interface
her productivity dropped fast.
> 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
I think there's a lot of reasons why it's not used today.
> 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.
There is a need for a better way. See the number of installed NT
boxes. ppl are so desparate they're use NT!!
> 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.
Let's not get crazy here. Gradual. Moderation. That's the way.
> 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.
Well all I ask is an open mind.
> > > 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?
No actually you got me .. no wait, sure there is! Does everyone
have to understand m4 to configure sendmail? I don't think so.
Smile man, it's friday!
+---------------------------------+-------------------------------------+
| R Garth Wood | Making waves... |
| Stormix Technologies Inc. | |
| rgwood@stormix.com | |
Reply to: