Re: Caldera installation - something Debian should learn
On Fri, Apr 23, 1999 at 08:46:01PM -0700, R Garth Wood wrote:
> On Sat, 24 Apr 1999, Craig Sanders wrote:
> > "proof by assertion" is no proof at all.
> Then I shall invoke my favourite: proof left to the reader.
if you wish to convince people, then the onus is on YOU to provide proof
in support of your statements. it's not up to your readers to do your
homework for you.
if you make a claim, it's up to you to back it up with evidence and/or
logical argument.
> > 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.
no i do not! i categorically and emphatically do not agree with you.
as i said, postgres is great for applications-level stuff but it sucks
at the systems-level.
> > 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.
you seem to have missed the point, so i'll make it again:
text files work when the system is in a semi-configured or even
misconfigured state. high-level and complex applications like postgresql
require at least a minimally configured and working environment before
they'll even start.
> > 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?
edit it with vi (or ed or sed or cat or ......) of course.
> 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.
more evidence that you haven't thought deeply enough about the problem.
how does a system connect to a remote postgres server when it depends
on that remote db for configuration information to set up the network
interfaces so it can connect? it doesn't. so your grand scheme for
unifying all config information into a database has a number of
exceptions to the rule.
> > 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.
why re-invent the wheel? we already have a hierarchical file system, and
we already have tools capable of editing, generating or manipulating
text files.
> > 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.
proof by assertion is no proof at all.
i'd place much greater trust in text files checked into RCS or a CVS
repository than i would in any database server. plain text is less
susceptible to corruption problems, and is more easily fixed.
> If you want all the benefits I have outlined at length use a db.
i don't think you have outlined any benefits for using a db for
configuration files rather than text files. you've made some general
assertions about databases being better, without providing specific
details about how they are better and without showing how those benefits
are in any way relevant to configuration files.
databases are very useful tools, but it is a big mistake to think that
every problem can be solved with them.
> > > > 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.
> >
> > [...my explanation of why not deleted...]
>
> So then you can. Great we agree.
are you stupid or something? or just being an annoying smart-arse?
what is it about the phrase "No, you can't" that could possibly be
interpreted as agreement?
it does you and your arguments no good at all to attempt to "win" by
putting words in other people's mouths, especially when those words are
in direct contradiction to that person's own statements. i doubt if any
of us on this list are naive enough to be taken in by such immature
tactics.
> > 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?
how the fuck would i know? A new feature. *any* new feature. You know,
one that hasn't been done before. Something new. as in something novel
or unique or original. an improvement.
> > 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?
it may be "cool", but that doesn't necessarily mean it's a Good Thing.
that depends on what the price for such "coolness" is.
utility is more important than "coolness".
> > 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.
no. Windows makes the mistake of assuming that extremely complex things
*CAN* be simplified to the point where any moron can configure it just
by pointing and clicking.
some things are inherently complex. some things absolutely require
knowledge, experience, insight, and intelligence...in short, a clue.
This fact isn't a problem to be solved, it's merely a truth about the
world which has to be accepted - no software can ever be a substitute
for having a clue.
> > 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.
why is there "a need for a better way" when the unix way has
demonstrated it's superiority for decades?
> See the number of installed NT boxes. ppl are so desparate they're use
> NT!!
then go and use NT if you want that way of doing things.
> No actually you got me .. no wait, sure there is! Does everyone
> have to understand m4 to configure sendmail? I don't think so.
yes. who else is there to understand it? if someone wants to configure
something then they SHOULD understand whatever the hell it is they are
doing.
> Smile man, it's friday!
you're wrong again. it's saturday here. 2:30PM to be precise.
ironically, you're wrong on this point in the same way you are wrong on
all your other points: you assume that your situation is a universal
truth, that your situation is exactly the same as everyone else's
situation.
unix's strength is that you can adapt it to meet your needs, rather than
you having to adapt to meet it's limitations.
craig
--
craig sanders
Reply to: