Hi!

Just wondering if there is any ongoing work to adapt some sort of XML-like
standard for configurationfiles in Linux/UNIX/whatever?

It would be really easy to write configuration tools if everybody could
agree with one standard. Now most of the "big" apps for Linux use their own
format like Apache, PHP, sendmail, qmail, X and whatnot.

It would be a life in heaven for a poor administrator... :-)

Mats

On Sat, 03 Jul 2004 23:01:33 +0000, Mats wrote:

> It would be a life in heaven for a poor administrator... :-)

Do you have some problem with plain text and vi?

The day that crap comes into being is the day I will quit using Linux.

It was Sat, 03 Jul 2004 18:04:16 -0500 when Dave Uhring wrote:

> On Sat, 03 Jul 2004 23:01:33 +0000, Mats wrote:
> 
>> It would be a life in heaven for a poor administrator... :-)
> 
> Do you have some problem with plain text and vi?

You are aware that XML is plain text?

Besides: A nice interface would be good. With this, there would be no need
to reinvent a text parser over and over again. Something like gconf (or
registry? *G*) wouldn't be that bad...

> The day that crap comes into being is the day I will quit using Linux.

I don't think so.

Alexander Skwar
-- 
Mit wie vielen Sachen vergeuden wir unsere Zeit und fragen 
uns im nachhinein, wo sie denn geblieben ist...

In comp.os.linux.misc, Mats uttered these immortal words:

> It would be really easy to write configuration tools if everybody could
> agree with one standard.

Do you mean "easier to write GUI tools for home users who
can't be bothered to learn and clueless admins"? That's the Windows way and
has no place in Linuxland. If an admin can't understand and edit config
files they have no place being an admin.

> Now most of the "big" apps for Linux use their 
> own format like Apache, PHP, sendmail, qmail, X and whatnot.
> 
> It would be a life in heaven for a poor administrator... :-)

No it wouldn't. One of my functions is as an admin. Being able to configure
a server with vi via a SSH connection is what separates those who can from
those who can't. I know XML files are plain text but I think it can over
complicates things for daemons that only require "variable=value" pairs.

Generally Linux/Unix admins are of a higher calibre than
Windows admins. GUI config tools generating XML files could well change
that.

-- 
Andy.

"Dave Uhring" <daveuhring@yahoo.com> skrev i meddelandet
news:pan.2004.07.03.23.04.16.453503@yahoo.com...
> On Sat, 03 Jul 2004 23:01:33 +0000, Mats wrote:
>
> > It would be a life in heaven for a poor administrator... :-)
>
> Do you have some problem with plain text and vi?
>
No, although i prefer vim. I have however, as you might suspect, a problem
with configuration files.

Why not make it easier? If you have one standard you don't have to learn
every strange syntax of every single configfile. And while were at it, why
not put them all in the same damn directory so we don't have to look for
them over the whole freakin HD.

> The day that crap comes into being is the day I will quit using Linux.

Well, it doesn't have to be specifically XML-crap, just some sort of bleedin
standard-crap, and even so you could edit it by hand if you want to. You can
even do it with a octal editor (if exists) or nibble by nibble, if that's
what get you goin'. Hell, if youre a real man you alter the binaries
directly.

Mats

Andy Fraser wrote:

>> It would be really easy to write configuration tools if everybody could
>> agree with one standard.
> 
> Do you mean "easier to write GUI tools for home users who
> can't be bothered to learn and clueless admins"? That's the Windows way
> and has no place in Linuxland. If an admin can't understand and edit
> config files they have no place being an admin.

Are you paid by Microsoft to air these opinions?
There is absolutely no reason why Linux should not be as easy to administer
as Windows, and in fact it generally is, in my experience.

I think the OP had a valid point;
it would be better if there were a common standard for config files,
and XML might well assist in that.

-- 
Timothy Murphy  
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland

In comp.os.linux.misc, Timothy Murphy uttered these immortal words:

>> Do you mean "easier to write GUI tools for home users who
>> can't be bothered to learn and clueless admins"? That's the Windows way
>> and has no place in Linuxland. If an admin can't understand and edit
>> config files they have no place being an admin.
> 
> Are you paid by Microsoft to air these opinions?

What kind of bullshit statement is that? How is that a pro-MS statement?

> There is absolutely no reason why Linux should not be as easy to
> administer as Windows, and in fact it generally is, in my experience.
> 
> I think the OP had a valid point;
> it would be better if there were a common standard for config files,
> and XML might well assist in that.

XML-like config files help Apache where options can have options nested
within them but for most XML would be overkill. Most of the config files I
touch regularly are of the "variable=value" or "variable value" type and
that's enough for most of them.

Regardless of format you still have to know what each option does. If you
must have some sort of GUI there's always Webmin (which I use from time to
time myself but make sure I know what it's doing to what config file and
what that means). The Webmin developers don't seem to have had any problem
with different config file formats. Neither did the Mandrake developers
responsible for the Mandrake Control Centre.

-- 
Andy.

"Andy Fraser" <andyfraser31@hotmail.com> skrev i meddelandet
news:vosjr1-901.ln1@news.linuxuser.org.uk...
> In comp.os.linux.misc, Mats uttered these immortal words:
>
> > It would be really easy to write configuration tools if everybody could
> > agree with one standard.
>
> Do you mean "easier to write GUI tools for home users who
> can't be bothered to learn and clueless admins"?

No, no and no!

There are so much worthless-knowing with todays configuration-hell like:
where is the bleeding config file for netatalk, what options do "codepage"
have in this version? All this info could exist in the same configfile. One
file to look in with both options, values and explaning text and if the
programmer of an app does it right he might not need to write a README or
FAQ. The programmer could even use a standard library to read/write
configurations from the file.

> That's the Windows way [snip]

No, thats the "let the computer do the work for you" way.

> has no place in Linuxland. If an admin can't understand and edit config
> files they have no place being an admin.

No and no again! Why must i learn 100 different configuration
syntax/flaws/options when they all do basically the same, setting various
variables to different values? Some configfiles has good comments and even
present some options, some don't. You know you should select a charset for
example, but you don't know the syntax/value. F.ex is it sv_SE or latin1 or
iso8859-1? You have to crossreference various docs and faq's just to find
out a simple thing like that. It's just a waste of time.

> No it wouldn't. One of my functions is as an admin. Being able to
configure
> a server with vi via a SSH connection is what separates those who can from
> those who can't. I know XML files are plain text but I think it can over
> complicates things for daemons that only require "variable=value" pairs.

I know it's important to acces config files from texteditors. I don't wan't
binary configfiles. You can still use SSH or whatever shell and texteditor
you like. You also have the opportunity to make a configeditor with curses,
which should work with most shells.

If this is done correctly, it won't just benefit the users/administrators,
it would benefit the programmers too, to put all info in one place, easy to
browse for the user/admin. Not having to answer a lot of stupid emails with
basic questions and frustated admins and write endless updated FAQ's.

>
> Generally Linux/Unix admins are of a higher calibre than
> Windows admins. GUI config tools generating XML files could well change
> that.

It's not a question of Windoze or XML-files, it's a question of doing what
computers IMHO was invented to do, make life technically easier. If we can't
succeed in that, what's the point of Linux/Windoze/MacOS/BeOS....?

>
> -- 
> Andy.

Mats

Mats wrote:

> It would be really easy to write configuration tools 

.... http://www.webmin.com/
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
printk("you lose buddy boy...\n");
        linux-2.6.6/arch/sparc/kernel/traps.c

After takin a swig o' Arrakan spice grog, Andy Fraser <andyfraser31@hotmail.com> belched out:
> Generally Linux/Unix admins are of a higher calibre than
> Windows admins. GUI config tools generating XML files could well change
> that.

Yeah, the Windows admin types seem to prefer .22 calibre.  My own
preference is 9mm...  :-)

<http://www.ai.mit.edu/~shivers/autoweapons.html>

My brother and I spent an afternoon "plinking" last Christmas Eve; he
put up a "kid-sized" IPSC target that we kept vertical by putting a
tire behind it.  He took out an AR-15 that was refitted with a .22
action and barrel.  We could ping that target in semi-auto mode as
fast as we could pull the trigger, and there was more noise from the
lead bouncing off the target 50 feet away than there was from the
rounds firing 8 inches away.

He then changed over to a .303 action, which was, to say the least, a
whole lot more effective.  With some steel jacketed rounds, he put
several holes through the IPSC target before realising, "Crap!  We're
not supposed to use 'armour-piercing' to make holes in it!"  :-)

There was some spot-welding in his future :-)
-- 
output = ("cbbrowne" "@" "ntlug.org")
http://www3.sympatico.ca/cbbrowne/family.html
"As  long as  each  individual is  facing  the TV  tube alone,  formal
freedom poses no threat to privilege."  --Noam Chomsky

In an attempt to throw the authorities off his trail, Alexander Skwar <from@alexander.skwar.name> transmitted:
> It was Sat, 03 Jul 2004 18:04:16 -0500 when Dave Uhring wrote:
>
>> On Sat, 03 Jul 2004 23:01:33 +0000, Mats wrote:
>> 
>>> It would be a life in heaven for a poor administrator... :-)
>> 
>> Do you have some problem with plain text and vi?
>
> You are aware that XML is plain text?
>
> Besides: A nice interface would be good. With this, there would be no need
> to reinvent a text parser over and over again. Something like gconf (or
> registry? *G*) wouldn't be that bad...

If you want a "registry," then there are three excellent approaches
implementable using free software:

 1.  Use a text format for the "source" of the data, and "compile" it
     into either a DBM database, a Berkeley DB database, or a CDB
     database.   I'd favor CDB, for sheer speed.

     Note that this is how various MTAs allow configuring address
     rewrite rules.  Postfix uses Berkeley DB for such files; qmail
     uses CDB.

 2.  If your needs are /fairly/ simple, e.g. - not much more
     sophisticated than what the Windows registry supports, then
     Berkeley DB does support namespaces such that you can have
     an arbitrary number of hash tables that coexist in the same
     database.

 3.  If you want typed _and_ structured data, then I can't see there
     being any choice preferable to PostgreSQL.

     You can hierarchicalize things by having multiple databases, each
     of which can contain multiple namespaces, each of which can
     contain as many tables with as many table schemas and as many
     tuples as you could imagine wanting.

     I find it appalling how often application developers that are
     building data-driven applications wind up pushing configuration
     out to separate config files that make it _harder_ to figure out
     what's going on when they oculd have put them into database
     tables so that you could do "one stop shopping" for your data.
     But that's another story...

>> The day that crap comes into being is the day I will quit using
>> Linux.

> I don't think so.

Apple is actually the folks most likely to succeed at something
vaguely like this.

They have built XML-based 'configurators' for numerous of the
applications that come with Mac OS-X.  It affects more or less all the
apps that users are likely to see _without_ making use of a CLI...

There are worse ideas, but it's the sort of project that requires that
there be an organization building their own "distribution."
-- 
"cbbrowne","@","acm.org"
http://www.ntlug.org/~cbbrowne/linuxsysconfig.html
MICROS~1: The company that brought new meaning to "Nervous System"

In the last exciting episode, "Mats" <spamenot.mog.pettersson@telia.com> wrote:
> Just wondering if there is any ongoing work to adapt some sort of XML-like
> standard for configurationfiles in Linux/UNIX/whatever?

People periodically visit newsgroups, suggest the idea, volunteering
everyone else's effort to actually implement it, and then, when it is
suggested that they hop to it, and implement XML-based configuration
for a few things such as Linux (e.g. - replacing $SRC_HOME/.config
with $SRC_HOME/.config.xml), Apache, Sendmail, RPM, dpkg, Emacs, vim,
and such, they seem to disappear rather than demonstrating the merits
of their proposals.

> It would be really easy to write configuration tools if everybody
> could agree with one standard. Now most of the "big" apps for Linux
> use their own format like Apache, PHP, sendmail, qmail, X and
> whatnot.

Reality is: No, it _wouldn't_ be really easy to write configuration
tools if they were all using XML.

Unfortunately, between namespaces, Unicode support, and the multitude
of "XML standards," it is actually quite nebulous what you'd actually
use.

Using XML would more than likely make the applications quite a bit
more fragile, because it is an extremely fragile data format.

It would likely make things slower; parsing XML is surprisingly
expensive.  In the big client/server app we run at work, the _MASSIVE_
performance increases that came from migrating from PostgreSQL 7.2 to
7.4 now show that our major performance bottleneck is the cost of
parsing XML messages...

Expensive, verbose, and fragile _isn't_ what you want for
configuration tools.
-- 
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://cbbrowne.com/info/linuxsysconfig.html
http://cbbrowne.com/info/xml.html
Rules of the Evil Overlord #1. "My Legions of Terror will have helmets
with   clear    plexiglass   visors,   not    face-concealing   ones."
<http://www.eviloverlord.com/>

"Andy Fraser" <andyfraser31@hotmail.com> skrev i meddelandet
news:8jvjr1-g61.ln1@news.linuxuser.org.uk...
> In comp.os.linux.misc, Timothy Murphy uttered these immortal words:
>
[snip]
> Regardless of format you still have to know what each option does. If you
> must have some sort of GUI there's always Webmin (which I use from time to
> time myself but make sure I know what it's doing to what config file and
> what that means). The Webmin developers don't seem to have had any problem
> with different config file formats.
[snip]

Do you know how many manhours the developers of Webmin would have saved if
there where a standard for the configurationfiles? It's ok for you to be
satisfied, who maybe don't need the daemons/apps i'm running and isn't
supported (or poorly supported) in Webmin. Those would have worked
automagically (almost all anyway) if there where a standard.

> Neither did the Mandrake developers
> responsible for the Mandrake Control Centre.
>
> -- 
> Andy.

Mats

"Christopher Browne" <cbbrowne@acm.org> skrev i meddelandet
news:2kp2n2F4v74cU3@uni-berlin.de...
> In the last exciting episode, "Mats" <spamenot.mog.pettersson@telia.com>
wrote:
> > Just wondering if there is any ongoing work to adapt some sort of
XML-like
> > standard for configurationfiles in Linux/UNIX/whatever?
>
> People periodically visit newsgroups, suggest the idea, volunteering
> everyone else's effort to actually implement it, and then, when it is
> suggested that they hop to it, and implement XML-based configuration
> for a few things such as Linux (e.g. - replacing $SRC_HOME/.config
> with $SRC_HOME/.config.xml), Apache, Sendmail, RPM, dpkg, Emacs, vim,
> and such, they seem to disappear rather than demonstrating the merits
> of their proposals.

He, i was just *asking* for a status on the subject, not "volunteering
everyone else's effort to actually implement it". But i can't say i hasn't
thought of doing it myself (a sort of configuration library that is).

> > It would be really easy to write configuration tools if everybody
> > could agree with one standard. Now most of the "big" apps for Linux
> > use their own format like Apache, PHP, sendmail, qmail, X and
> > whatnot.
>
> Reality is: No, it _wouldn't_ be really easy to write configuration
> tools if they were all using XML.
>
> Unfortunately, between namespaces, Unicode support, and the multitude
> of "XML standards," it is actually quite nebulous what you'd actually
> use.

It could be a stripped down XML-hybrid (or whatever label you se fit) that
enforces iso8859-1 (for example), and have very strict rules. It really
doesn't matter if it is specifically XML or not. However, most importantly,
it should be a standard apropriate for configuration files (which many times
include "nesting"). You can't fully mean that anything would be worse than
it is now (in the case of writing configuration tools)?

>
> Using XML would more than likely make the applications quite a bit
> more fragile, because it is an extremely fragile data format.
>
> It would likely make things slower; parsing XML is surprisingly
> expensive.  In the big client/server app we run at work, the _MASSIVE_
> performance increases that came from migrating from PostgreSQL 7.2 to
> 7.4 now show that our major performance bottleneck is the cost of
> parsing XML messages...

However, we are talking about configuration files being read only when
application is starting/restarting which is probably just once in the
process's lifetime. Special cases can have their own propriatary format.

>
> Expensive, verbose, and fragile _isn't_ what you want for
> configuration tools.
> -- 
> If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
> http://cbbrowne.com/info/linuxsysconfig.html
> http://cbbrowne.com/info/xml.html
> Rules of the Evil Overlord #1. "My Legions of Terror will have helmets
> with   clear    plexiglass   visors,   not    face-concealing   ones."
> <http://www.eviloverlord.com/>

Mats wrote:

>> Unfortunately, between namespaces, Unicode support, and the multitude
>> of "XML standards," it is actually quite nebulous what you'd actually
>> use.
> 
> It could be a stripped down XML-hybrid 

.... it really doesnt matter, actually.

what you're talking about is a great effort. all applications
that read the config files would all have to be rewritten.

i dont see that happening anytime soon
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
The Ranger isn't gonna like it, Yogi.

In comp.os.linux.misc, Mats uttered these immortal words:

>> Do you mean "easier to write GUI tools for home users who
>> can't be bothered to learn and clueless admins"?
> 
> No, no and no!

So that's not what you mean? Then tell me in as few words as possible what
you really mean (see below).
 
> There are so much worthless-knowing with todays configuration-hell like:
> where is the bleeding config file for netatalk,

They should all be in /etc if they're global or $HOME if it's a user's copy.
If your distro/daemon developer/app developer doesn't conform to that then
they need to be shot TBH.

> what options do "codepage" 
> have in this version? All this info could exist in the same configfile.

Can you explain that. To me it reads as "everything should be in one file
like the Windows registry".

> One file to look in with both options, values and explaning text and if
> the programmer of an app does it right he might not need to write a README
> or FAQ. The programmer could even use a standard library to read/write
> configurations from the file.

If I've read that as you intended that would require developers of different
daemons to talk to each other. If that's the case then nothing would get
done. If I wanted to write a daemon I'd have to wait for info from others
before I could start. Please tell me I read that wrongly.
 
>> That's the Windows way [snip]
> 
> No, thats the "let the computer do the work for you" way.

Actually that's the "let MS do a lot of the thinking for you" way but that's
OT here.
 
I'm not going to reply to any more until you've clarified the points above.

-- 
Andy.

"mjt" <mjtobler@removethis_mail.ru> skrev i meddelandet
news:OaJFc.4024$R36.1858@newsread2.news.pas.earthlink.net...
> Mats wrote:
>
> >> Unfortunately, between namespaces, Unicode support, and the multitude
> >> of "XML standards," it is actually quite nebulous what you'd actually
> >> use.
> >
> > It could be a stripped down XML-hybrid
>
> ... it really doesnt matter, actually.
>
> what you're talking about is a great effort. all applications
> that read the config files would all have to be rewritten.

Ofcourse it would be an effort. All applications is constantly rewritten
anyway though, and if an configurationstandard was to be, tools should be
there to ease the convertion. But still, it would be an effort.

>
> i dont see that happening anytime soon

No, neither do i. It's easiest to walk along the same old path and safest to
stay in the same place. You know what they say: "Standards are good,
everyone should have one."


> .
> -- 
> <<   http://michaeljtobler.homelinux.com/   >>
> The Ranger isn't gonna like it, Yogi.
>

In comp.os.linux.misc, Mats uttered these immortal words:

Just a few more points...

> If this is done correctly, it won't just benefit the users/administrators,

Why "users/administrators"? They are very different in Linuxland. On a home
system used by one person the user is also the admin but they are different
roles. In a company they would be different people of course.

> it would benefit the programmers too,

How exactly?

> to put all info in one place,

Now I'm sure you're after a registry type thing for Linux. Yay or nay?

> easy  
> to browse for the user/admin.

There's that "user/admin" thing again. A user shouldn't ever need to read
files in /etc, only his or her copies for their own customisations to
programs that they're allowed to run for which there's usually a
"configure", "preferences" or "options" dialog just like in Windows (GUI
apps assumed here).

> Not having to answer a lot of stupid emails 
> with basic questions and frustated admins and write endless updated FAQ's.

You'll never, ever eliminate that no matter what you do. ;-)
 
>> Generally Linux/Unix admins are of a higher calibre than
>> Windows admins. GUI config tools generating XML files could well change
>> that.
> 
> It's not a question of Windoze or XML-files, it's a question of doing what
> computers IMHO was invented to do, make life technically easier.

They make things easier when they're configured correctly. That's the admins
job. If the setting is a company then it's down to the company admins to
make sure things are working before the computer hits the users desk so the
user can get on with things. If the setting is your home then you have to
be the admin before you can be the user. I may be going OT here. It's hard
to tell when I'm still not 100% sure what you're getting at.

-- 
Andy.

On Sun, 04 Jul 2004 01:21:53 +0200, Alexander Skwar wrote:

> It was Sat, 03 Jul 2004 18:04:16 -0500 when Dave Uhring wrote:
> 
>> On Sat, 03 Jul 2004 23:01:33 +0000, Mats wrote:
>> 
>>> It would be a life in heaven for a poor administrator... :-)
>> 
>> Do you have some problem with plain text and vi?
> 
> You are aware that XML is plain text?

With a bunch of tags attached.  XML is a needless complication and wholly
contradictory to the Unix philosophy.

> Besides: A nice interface would be good. With this, there would be no need
> to reinvent a text parser over and over again. Something like gconf (or
> registry? *G*) wouldn't be that bad...

The proper interface to system configuration files is vi.  No argument
about emacs; it does not come with the BSDs, Solaris or Tru64.

>> The day that crap comes into being is the day I will quit using Linux.
> 
> I don't think so.

I'm damn sure of it.  There are good alternatives.  My other desktop
machine runs Slackware Linux but this one is a Sun Ultra running Solaris.
There is already too much XML here in my newsreader.

On Sun, 04 Jul 2004 00:05:21 +0000, Mats wrote:

> 
> "Dave Uhring" <daveuhring@yahoo.com> skrev i meddelandet
> news:pan.2004.07.03.23.04.16.453503@yahoo.com...
>> On Sat, 03 Jul 2004 23:01:33 +0000, Mats wrote:
>>
>> > It would be a life in heaven for a poor administrator... :-)
>>
>> Do you have some problem with plain text and vi?
>>
> No, although i prefer vim. I have however, as you might suspect, a problem
> with configuration files.

Experience is necessary.

> Why not make it easier? If you have one standard you don't have to learn
> every strange syntax of every single configfile. And while were at it, why
> not put them all in the same damn directory so we don't have to look for
> them over the whole freakin HD.

There is nothing easier than using vi to edit your configuration files,
particularly if you are doing it remotely.

>> The day that crap comes into being is the day I will quit using Linux.
> 
> Well, it doesn't have to be specifically XML-crap, just some sort of bleedin
> standard-crap, and even so you could edit it by hand if you want to. You can
> even do it with a octal editor (if exists) or nibble by nibble, if that's
> what get you goin'. Hell, if youre a real man you alter the binaries
> directly.

Just what in hell is more standard than ASCII text files?  And this from a
Windoze luser.

X-Newsreader:  Microsoft Outlook Express 6.00.2800.1409

My days of editing binary files ended when I started using Linux.  I have
had my share of editing those binary files using ddt under CP/M and debug 
in MS-DOS.

Andy Fraser wrote:

I tend to agree with Andy and disagree with Mats for reasons
listed below as we go.

> In comp.os.linux.misc, Mats uttered these immortal words:
> 
> Just a few more points...
> 
> 
>>If this is done correctly, it won't just benefit the users/administrators,

"If" is a very small word which has many implications and
many traps and pitfalls.

> 
> 
> Why "users/administrators"? They are very different in Linuxland. On a home
> system used by one person the user is also the admin but they are different
> roles. In a company they would be different people of course.
> 
> 
>>it would benefit the programmers too,
> 
> 
> How exactly?
> 
> 
>>to put all info in one place,
> 
> 
> Now I'm sure you're after a registry type thing for Linux. Yay or nay?

Ahhh... the evil empire's "registry."

"One ring to rule them all, one ring to find them.
One ring to bring them all and in the shadows bind them."

For reasons too numerous to mention, experiences
with the MicroShaft registry IMO have proven beyond
a shadow of a doubt this is *"A BAD IDEA!"*

> 
> 
>>easy  
>>to browse for the user/admin.
> 
> 
> There's that "user/admin" thing again. A user shouldn't ever need to read
> files in /etc, only his or her copies for their own customisations to
> programs that they're allowed to run for which there's usually a
> "configure", "preferences" or "options" dialog just like in Windows (GUI
> apps assumed here).

If a user screws up his/her own version of a particular APP's
config file, they lose use of that APP.  If an admin screws up
the global config file for an APP, *all* users may lose use of
that app.  If an admin screws up a GLOBAL config file for all apps
(or if some ill-designed GUI/CLI app by some newbie screws up the global
config file for all apps), *everyone* is SOL.  No thanks,
I still prefer a config file per app.

I even have reservations about putting all the config files
in /etc, because I would like to be able to uninstall and
eradicate all traces of an app just by doing something
like stepping into the app's directory and removing everything
and then removing the app out of /usr/local/bin or wherever it lives.

Now, I can definitely sympathize with Mat's complaint that
every app seems to have their own idea of how a config
file should be laid out. And there do not seem to be
any strictly-adhered-to naming conventions for the config
files.  That *is* a PITA.  XML (for better of for worse)
is becoming a de-facto standard for this kind of stuff
and people will want to use it as the "path of least resistance."
But, does that mean that *every* app must include an
XML parser?  Just to read the startup parameters?
Even a stripped down parser?  Talk about software bloat!

At the risk of also going far afield from the original
intent of the posting, I could argue that a well-designed
app should not need a complex configuration file.
If it's more than a screenful of parameters in vim or emacs,
they've overcomplicated the problem, overcomplicated
the solution, or both.  Given the fact that there *are*
complex configuration files out there, that argument
is moot in this context, however.

> 
> 
>>Not having to answer a lot of stupid emails 
>>with basic questions and frustated admins and write endless updated FAQ's.
> 
> 
> You'll never, ever eliminate that no matter what you do. ;-)
>  
> 
>>>Generally Linux/Unix admins are of a higher calibre than
>>>Windows admins. GUI config tools generating XML files could well change
>>>that.
>>
>>It's not a question of Windoze or XML-files, it's a question of doing what
>>computers IMHO was invented to do, make life technically easier.
> 
> 
> They make things easier when they're configured correctly. That's the admins
> job. If the setting is a company then it's down to the company admins to
> make sure things are working before the computer hits the users desk so the
> user can get on with things. If the setting is your home then you have to
> be the admin before you can be the user. I may be going OT here. It's hard
> to tell when I'm still not 100% sure what you're getting at.
> 

NPL

-- 
"It is impossible to make anything foolproof
because fools are so ingenious"
  - A. Bloch

Mats wrote:


> 
> 
> No, neither do i. It's easiest to walk along the same old path and safest to
> stay in the same place. You know what they say: "Standards are good,
> everyone should have one."
> 

Or ... "The nice thing about standards is that there
are so many (conflicting ones) to choose from."

-- 
"It is impossible to make anything foolproof
because fools are so ingenious"
  - A. Bloch

----- Original Message ----- 
From: "Andy Fraser" <andyfraser31@hotmail.com>
Newsgroups: comp.os.linux.misc
Sent: Sunday, July 04, 2004 3:45 AM
Subject: Re: Why not XML based configurationfiles?


> In comp.os.linux.misc, Mats uttered these immortal words:
>
> >> Do you mean "easier to write GUI tools for home users who
> >> can't be bothered to learn and clueless admins"?
> >
> > No, no and no!
>
> So that's not what you mean? Then tell me in as few words as possible what
> you really mean (see below).
>
> > There are so much worthless-knowing with todays configuration-hell like:
> > where is the bleeding config file for netatalk,
>
> They should all be in /etc if they're global or $HOME if it's a user's
copy.

In a perfect world, maybe it would be there. But in this world it could be
in /usr/etc, /usr/local/etc, /usr/local/share or whatever the author thought
was best fit.

See, if your distro doesn't contain the apps you wan't or versions of the
apps you wan't, you have to download and install them yourself, most often
from source. Your distro author, the apps author and yorself, have often
different opinions on where things should go. You can however alter this
with a bit of work, but still.

> If your distro/daemon developer/app developer doesn't conform to that then
> they need to be shot TBH.

Man, that would be quite a bunch of dead people. :-)

>
> > what options do "codepage"
> > have in this version? All this info could exist in the same configfile.
>
> Can you explain that. To me it reads as "everything should be in one file
> like the Windows registry".

No, not like that. The windows registry is almost as bad (or worse) than
what we have now, in some cases anyway.

I think like, one app and one configurationfile (ofcourse there are some
special cases). *Not* all configurations in one systemdatabase like the
windows registry.

The configurationfile would contain two parts. One part is a
description/template of the variable/value pairs, and one contain the
actually configured values. The description/template part contains version
number, variable/value pairs (nested/recursive if so required) with a label
and an conected list of all possible values for that variable and type of
the variable and (as icing on the cake) an explanation of the
option/variable and it's values. The value part of the file is the actual
configuration i.o.w the values that is set in the file.

>
> > One file to look in with both options, values and explaning text and if
> > the programmer of an app does it right he might not need to write a
README
> > or FAQ. The programmer could even use a standard library to read/write
> > configurations from the file.
>
> If I've read that as you intended that would require developers of
different
> daemons to talk to each other. If that's the case then nothing would get
> done. If I wanted to write a daemon I'd have to wait for info from others
> before I could start. Please tell me I read that wrongly.

I'm not quite shure what you mean with "talk to each other", but it's *not*
like the windows registry, different apps still has different
configurationfiles (no connection to other apps), only they conform to the
same standard. If you make (*shrugs*) a horrid GUI configuration utility
that can read/edit one of these "standard configurationfiles" it can
automagically read/edit any other configurationfile that conforms to the
same standard. To put it simply, it would be almost like an html form for a
webbrowser, or in Lord Of  The Rings lingo: "One configuration utility to
rule them all". :-P

>
> >> That's the Windows way [snip]
> >
> > No, thats the "let the computer do the work for you" way.
>
> Actually that's the "let MS do a lot of the thinking for you" way but
that's
> OT here.

Don't get MS credit for this. If you do like Webmin and if you are an admin
that constantly have to alter configurationfiles and have more daemons and
servers than two/three to worry about, you should *love* this. If you just
running apache, php and sendmail you probably get by anyway.

>
> I'm not going to reply to any more until you've clarified the points
above.
>
> -- 
> Andy.

Oops! Sorry about the private mail, pressed the wrong button. It was meant
to the group.

Mats

Mats wrote:

>> i dont see that happening anytime soon
> 
> No, neither do i. It's easiest to walk along the same old path and safest to
> stay in the same place. 

.... "if it aint broke, dont fix it"

> You know what they say: "Standards are good, 
> everyone should have one."

nope:  "the computer industry loves standards,
that's why there are so many of them
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
It seems like the less a statesman amounts to, the more he loves the flag.

Dave Uhring wrote:

> Just what in hell is more standard than ASCII text files?

.... nothing. 

i think the OP was bored.

heck, even on the m$ platform, they cant decide what
is "standard" ... m$ keeps changing their game.
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
Kiss a non-smoker; taste the difference.

Dave Uhring wrote:

> With a bunch of tags attached.��XML�is�a�needless�complication�and�wholly
> contradictory to the Unix philosophy.

.... thank you, Dave!!!
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
"Joy is wealth and love is the legal tender of the soul."
-- Robert G. Ingersoll

On Sun, 04 Jul 2004 03:54:07 +0000, mjt wrote:

> i think the OP was bored.

He should rewrite the Linux kernel and all the GNU utilities and other
free daemons and servers to provide his own distro, one which suits the
click and drool needs of Windoze addicts.

It looks like Darwin's hypotheses are starting to be proven in the IT
world :-)

> heck, even on the m$ platform, they cant decide what
> is "standard" ... m$ keeps changing their game.

That is a market driven monopoly, not a technological one.  I trust that
Darwinism will prevail there also.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2004-07-03, Mats <spamenot.mog.pettersson@telia.com> wrote:
>
> It would be a life in heaven for a poor administrator... :-)

Emphasis on "poor"--we'd all be out of work because configuration would
be so easy, even an MCSE could do it!   Then we'd all have to get
lobotomies to get an MCSE so we could get these jobs.  ;-)

One item that hasn't been mentioned yet is the human-readability of
configuration files.  At least for me, XML is not as readable as, say, a
BIND zone file, a Postfix config file, or an xinetd.conf file.  In
theory XML may be easier to parse (people have already mentioned that
practice is not as easy as theory) for a computer, but in this case
humans do need to be able to read these files.

- --keith

- -- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFA55GghVcNCxZ5ID8RAhH4AJsGipjXvxBf4iO5kGpkbPg/YmMszQCfWEE9
5z6G57hZfs1AtwZr+OHO7VQ=
=+05o
-----END PGP SIGNATURE-----

Alexander Skwar <from@alexander.skwar.name> wrote:
> It was Sat, 03 Jul 2004 18:04:16 -0500 when Dave Uhring wrote:
> 
> > On Sat, 03 Jul 2004 23:01:33 +0000, Mats wrote:
> > 
> >> It would be a life in heaven for a poor administrator... :-)
> > 
> > Do you have some problem with plain text and vi?
> 
> You are aware that XML is plain text?

No it isn't - it's marked up plain text. Illegible, I might add.

> Besides: A nice interface would be good. With this, there would be no need
> to reinvent a text parser over and over again. Something like gconf (or

Nobody has any problem "inventing" a text parser. Everybody simply
execs the config file as a shell script and then reads the environment
variables that result.

> registry? *G*) wouldn't be that bad...

Yes it would be hrrible.

> 
> > The day that crap comes into being is the day I will quit using Linux.
> 
> I don't think so.

There are existing libraries for reading conf files if using shell
does not appeal.

Peter

Timothy Murphy <tim@birdsnest.maths.tcd.ie> wrote:
> I think the OP had a valid point;
> it would be better if there were a common standard for config files,

There is a common standard - it's to write

    a = b

in order to set a to be b.

> and XML might well assist in that.

No it wouldn't. (and I speak as a person who has written a higher order
extension of XML).

Peter

Mats <spamenot.mog.pettersson@telia.com> wrote:
> There are so much worthless-knowing with todays configuration-hell like:

There is no "hell".

> where is the bleeding config file for netatalk,

Wherever the package says it is.

> what options do "codepage"

What's a "codepage"? Anyway, whatever the man page says (xml would not
solve this directly, because you wouldn't know the possible values even
of an enumerated type without the type being specified for you, which
means that you need the definition of the xml sublanguage you are using,
which means that not all the config languages you are using are the same
    ...  and anyway, the type would be a string in practice, not an
enumeration).

> have in this version? All this info could exist in the same configfile.

No it wouldn't - it would exist elsewhere, in the xml dtd (or schema),
or out there in the universe somewhere.

> One
> file to look in with both options, values and explaning text and if the

That's what one gets now.

> > That's the Windows way [snip]
> 
> No, thats the "let the computer do the work for you" way.

No it isn't.  XML is obscurantist, because you cannot directly read the
file that results.  There is nothing wrong in writing config files the
way we do now - they're readable.

> No and no again! Why must i learn 100 different configuration

You don't.

> variables to different values? Some configfiles has good comments and even

All of them do.

> present some options, some don't.

Then talk to their authors about them.

> You know you should select a charset for
> example, but you don't know the syntax/value.

Often you can't in XML, because it's not an enumeraton, but merely a
string. There is no help for you there.

> F.ex is it sv_SE or latin1 or

You would not know in XML.

Peter

Alexander Skwar <from@alexander.skwar.name> writes:

> Besides: A nice interface would be good. With this, there would be no need
> to reinvent a text parser over and over again. Something like gconf (or
> registry? *G*) wouldn't be that bad...

On one of the comp.os.linux.* newsgroups (good chance on this one),
there was a longish thread about registry a couple of months ago,
and great many people (including me) didn't like it. It is worth
to hunt it down and read it.

That thread also described why many people (including me) liked
the plain text config files.

Vilmos

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Dave Uhring <daveuhring@yahoo.com> suggested:
> On Sat, 03 Jul 2004 23:01:33 +0000, Mats wrote:

>> It would be a life in heaven for a poor administrator... :-)

Install suse then...

> Do you have some problem with plain text and vi?

> The day that crap comes into being is the day I will quit using Linux.

Full ack! So don't use suse then, they are using XML for quite a
few of there own config files, where it looks to me they'd like to
lock people in there own vendor trap.;(

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA57B0AkPEju3Se5QRAjujAKCzT/QvUH5MdSfz1Bj3lPRofCOFwQCcCEsM
sZDd1DfV/oWZUQRyrTTIxRY=
=uQnV
-----END PGP SIGNATURE-----

It was Sat, 03 Jul 2004 21:11:06 -0500 when Dave Uhring wrote:
> On Sun, 04 Jul 2004 01:21:53 +0200, Alexander Skwar wrote:
 
>> You are aware that XML is plain text?
> 
> With a bunch of tags attached.  XML is a needless complication and wholly
> contradictory to the Unix philosophy.

That's why there should be an interface which allows standardized editing.
No, vi is not an interface.

>> Besides: A nice interface would be good. With this, there would be no need
>> to reinvent a text parser over and over again. Something like gconf (or
>> registry? *G*) wouldn't be that bad...
> 
> The proper interface to system configuration files is vi.

Jup, it's so easy to run vi on a hand of remote machines in a loop. I
forgot.

Alexander Skwar
-- 
prom_printf("Detected PenguinPages, getting out of here.\n");
	2.0.38 /usr/src/linux/arch/sparc/mm/srmmu.c

It was Sun, 04 Jul 2004 07:26:34 +0200 when P.T. Breuer wrote:

> Alexander Skwar <from@alexander.skwar.name> wrote:
>> It was Sat, 03 Jul 2004 18:04:16 -0500 when Dave Uhring wrote:
>> 
>> > On Sat, 03 Jul 2004 23:01:33 +0000, Mats wrote:
>> > 
>> >> It would be a life in heaven for a poor administrator... :-)
>> > 
>> > Do you have some problem with plain text and vi?
>> 
>> You are aware that XML is plain text?
> 
> No it isn't - it's marked up plain text.

But it is plain text.

> Illegible, I might add.

No.

>> registry? *G*) wouldn't be that bad...
> 
> Yes it would be hrrible.

Not at all.

Alexander Skwar
-- 
danke dir du sprichst mir aus der seele ich dachte schohn 
ich waer zu doff fuer diese kominiti aber auch ich bin hier 
schohn seit einpar tagen unterwegs ... 
    "cetdsl" in microsoft.public.de.german.win98.allgemein

It was Sun, 04 Jul 2004 00:40:47 +0100 when Andy Fraser wrote:

> In comp.os.linux.misc, Mats uttered these immortal words:
> 
>> It would be really easy to write configuration tools if everybody could
>> agree with one standard.
> 
> Do you mean "easier to write GUI tools for home users who
> can't be bothered to learn and clueless admins"? That's the Windows way and
> has no place in Linuxland. If an admin can't understand and edit config
> files they have no place being an admin.

That's so full of bullsh*t. What's bad about making it easier? Is it, that
you hate changes? Seems like.


> No it wouldn't. One of my functions is as an admin. Being able to configure
> a server with vi via a SSH connection is what separates those who can from
> those who can't. I know XML files are plain text but I think it can over
> complicates things for daemons that only require "variable=value" pairs.

Well, complicate? What's so hard about

<variable>
	value
</variable>

Alexander Skwar
-- 
/* Binary compatibility is good American knowhow fuckin' up. */
	2.2.16 /usr/src/linux/arch/sparc/kernel/sunos_ioctl.c

"Mats" <spamenot.mog.pettersson@telia.com> writes:

> There are so much worthless-knowing with todays configuration-hell like:
> where is the bleeding config file for netatalk, what options do "codepage"
> have in this version? All this info could exist in the same configfile. One
> file to look in with both options, values and explaning text and if the
> programmer of an app does it right he might not need to write a README or
> FAQ. The programmer could even use a standard library to read/write
> configurations from the file.

Is it so hard to read that !#@$ README and FAQ? Linux is not there
to hold your hand. If you need software which you can use without
actually understanding what it does or how it does it, then use
Windows. They are easy to learn (albeit I question if they are
easy to use on the long run).
> > has no place in Linuxland. If an admin can't understand and edit config
> > files they have no place being an admin.
> 
> No and no again! Why must i learn 100 different configuration
> syntax/flaws/options when they all do basically the same, setting various
> variables to different values?

You still need to learn 100 different config syntax, but now they
would be wrapped in xml. You still need to know the proper keywords.

> Some configfiles has good comments and even
> present some options, some don't. You know you should select a charset for
> example, but you don't know the syntax/value.

And how will xml tell me what is the syntax/value?

> iso8859-1? You have to crossreference various docs and faq's just to find
> out a simple thing like that. It's just a waste of time.

No, it is not a waste of time. Or, what is a waste of time for you,
is valuable time spent for me learning the thing. You know the
phrase don't you? An engineer is a man who spends three hours to
figure out how to do a two hour job in one hour. However, if you
have to do it over and over, that time saving (learning) does
help.

Once I figure out, by crossreferencing for example, wtf iso8859-1 is,
I don't need to look it up later. It is called learning. And if you
want to configure a system without learning, or understanding
what to do, then you shouldn't be in the admin business.

I still don't see how an xml config file standard will save me
from knowing what iso8859-1 is.

> I know it's important to acces config files from texteditors. I don't wan't
> binary configfiles. You can still use SSH or whatever shell and texteditor
> you like. You also have the opportunity to make a configeditor with curses,
> which should work with most shells.

Bad idea, the configeditor with curses. A question. How do you automate
it? Say, an event occurs on the system, and a program needs to modify
a config file. How do you do that with a curses interface?

Also, one of the most beautiful thing in Unix is that I am not tied
to use a specific program to accomplish something (in most cases).

Do you think any admin would like to go down the road that only one
program would be able to modify config files? Do you like the fact
the you need Microsoft Word to edit your Word files (if a conversion
doesn't go perfectly)? Do you want to go down the route where the
configeditor is the only program to search in your config files?
What if you don't want to use their crappy search but would prefer
to use grep? Or sed to replace text? Having a xml based config
file will make life miserable for those who manage more than a
couple of machines. It is ok to configedit the same file on a
couple of boxes. But what if you have tens or hundreds of boxes?
How do you automate that? With the plain text and simple config
files, I can easily automate such things if I need. With an xml
based config file, it is still possible, but it will be much harder
and more error prone. When you want something like an xml based
config file, think about not only the single user who maintains
only his/her box, but an overworked admin who have better things
to do than to fight with xml.

Also, if we use xml based config files, there will be so much
fluff that it will be much harder to figure out settings just
by looking it. Do I really want to waste my time by "unseeing"
all the xml wrappings when all I need is one single value?

> If this is done correctly, it won't just benefit the users/administrators,
> it would benefit the programmers too, to put all info in one place, easy to
> browse for the user/admin. Not having to answer a lot of stupid emails with
> basic questions and frustated admins and write endless updated FAQ's.

It won't benefit the users/admins. It *MIGHT* benefit the ignorant
who is unwilling to invest to learning the ins and outs of the system.

But Linux is not for those people. For those, there are other systems.

And I fully expect a programmer to be able to write a simple text
parser. If he fails at that, then there are other professions
available for him which fit his mental abilities.

I fail to see how an xml config file would prevent a lot of stupid
questions. Any idea?

>> Generally Linux/Unix admins are of a higher calibre than
>> Windows admins. GUI config tools generating XML files could well change
>> that.
> 
> It's not a question of Windoze or XML-files, it's a question of doing what
> computers IMHO was invented to do, make life technically easier. If we can't
> succeed in that, what's the point of Linux/Windoze/MacOS/BeOS....?

It wouldn't make your life technically easier. It would confine
you to the one program, the configeditor, which was designed to
edit config files. This is not the Unix way.

My life is technically easy if *I CAN* decide how I edit the config
files.

Don't take it as a personal insult since I didn't mean it that way.
Take it as a letter from and admin who is wearing many hats, and the
last thing he needs is to be forced to edit config files in a way that
he feels is unnatural.

Look, I have used RedHat since version 2.x or 3.x, don't remember.
And I have never used their config tools except for configuring
printers. Guess what, I just didn't like them. Neither the X
nor the ncurses interfaces. They weren't intuitive (for me), they
were buggy (at least a couple of years ago), and they were a pain
in the ass to use. I always used emacs or vi to configure the
machines. And they are up and running. Also, since I actually know
how the system works (or at least I think), my knowledge is fairly
generic. I could pick up OpenBSD pretty fast since I learned things
the hard way. I learned them. No handholding. Forcing one particular
program to edit config files would have prevented me from a lot
of learning. And it also happened that sometimes I mucked up the
config file, and the program didn't work. Fortunately there was no
config editor there which prevented me from making an error. What
happened? I forced to dig into it, understand it, correct it, and
LEARN HOW I WORKED. In the short run, this is bad, since you screw
up a system/program. But in the long run, it is a blessing since I
actually learned how the system worked.

Vilmos

"Mats" <spamenot.mog.pettersson@telia.com> writes:

> In a perfect world, maybe it would be there. But in this world it could be
> in /usr/etc, /usr/local/etc, /usr/local/share or whatever the author thought
> was best fit.

I totally agree with you in this point. It is really a pain in the
ass when there are multiple config directories, and even worse, when
there are two sets of config files (one ignored) for the same program.
I experienced it with OpenSSH. One config file set was in /etc/ssh,
and another in something like /usr/local/etc/ssh.

>> Can you explain that. To me it reads as "everything should be in one file
>> like the Windows registry".
> 
> No, not like that. The windows registry is almost as bad (or worse) than
> what we have now, in some cases anyway.

Agreed.

> Don't get MS credit for this. If you do like Webmin and if you are an admin
> that constantly have to alter configurationfiles and have more daemons and
> servers than two/three to worry about, you should *love* this. If you just
> running apache, php and sendmail you probably get by anyway.

I refuse to use anything like Webmin. The last thing I want is to
use a web browser to configure my systems. Do I really want to run a
webserver on my servers? Also, I just don't want any extra layer
between the config files and me. What happens if there is a new version
of the program, with a different config file? Then do I have to wait
until webmin comes out with a new module?

Vilmos

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
> It was Sat, 03 Jul 2004 21:11:06 -0500 when Dave Uhring wrote:
>> On Sun, 04 Jul 2004 01:21:53 +0200, Alexander Skwar wrote:
[..]

>> The proper interface to system configuration files is vi.

Yup, the only portable way, there are more *nix systems then a
bunch of Linux distro. Where one or another tries to lock people
in a vendor trap.;(

> Jup, it's so easy to run vi on a hand of remote machines in a loop. I
> forgot.

While I'd use sed/awk/perl/whatever through ssh-agent for
single-sign-on, you can do it easily with vi, just that you are
not knowledgeable enough doesn't mean it wouldn't be possible.

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA58ElAkPEju3Se5QRAsegAJ4oDlSuVmnZ59I9c+B1BVQGV+h/MQCgu7DD
zWaOLCysh9UGL1R3P3w15/E=
=ZBIa
-----END PGP SIGNATURE-----

It was Sun, 04 Jul 2004 08:34:45 +0000 when Michael Heiming wrote:

> single-sign-on, you can do it easily with vi, just that you are
> not knowledgeable enough doesn't mean it wouldn't be possible.

Yeah, right, whatever, screw yourself. You're too stupid to grasp what I
said. That's all, and that's why you're insulting me. Hey, I understand
that. It's gotta be hurting, doesn't it?

Alexander Skwar
-- 
printk("Entering UltraSMPenguin Mode...\n");
	2.2.16 /usr/src/linux/arch/sparc64/kernel/smp.c

On Sat, 03 Jul 2004 23:01:33 +0000, Mats wrote:

> Hi!
> 
> Just wondering if there is any ongoing work to adapt some sort of XML-like
> standard for configurationfiles in Linux/UNIX/whatever?
> 
> It would be really easy to write configuration tools if everybody could
> agree with one standard. Now most of the "big" apps for Linux use their own
> format like Apache, PHP, sendmail, qmail, X and whatnot.
> 
> It would be a life in heaven for a poor administrator... :-)
> 
> Mats

Why ?, what we have at the moment works.

Dave

-- 

Some people use windows, others have a life.

It was Sun, 04 Jul 2004 10:17:40 +0100 when Dave Stanton wrote:

> Why ?, what we have at the moment works.

Yes, it works. Suboptimal.

Alexander Skwar
-- 
5bb(D!(D))D,)D5(D:(D?XP2@@0@@C,!~~SVPZj]XXd@e$2D@0D@F#KHKuK^C[u7aQ
e;HVZ~ye}Y'egx,7^{x|bZJxxympW1noNVbMg2)>L_Q,Fo8<Y#E'56?X?uruA#OXW"
8tH<}Q.YmQ_i8y5'05/)9-OJ4X4%o-PfPsSe3@=Gd5*x<0_\)-/]6y%g;RfE4:4'G!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
> It was Sun, 04 Jul 2004 08:34:45 +0000 when Michael Heiming wrote:

>> single-sign-on, you can do it easily with vi, just that you are
>> not knowledgeable enough doesn't mean it wouldn't be possible.

> Yeah, right, whatever, screw yourself. You're too stupid to grasp what I
> said. That's all, and that's why you're insulting me. Hey, I understand
> that. It's gotta be hurting, doesn't it?

LOL...Nope pan-boy, just corrected your false assumption that vi
couldn't run in a batch, that's all, no insulting intended. 

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA5898AkPEju3Se5QRAtcLAKCBS3toKZGYE9opDiWW7Lbom4u/wgCgypX+
Cexy3px+wymSDKlZ2QXpJXU=
=0JbP
-----END PGP SIGNATURE-----

It was Sun, 04 Jul 2004 09:35:59 +0000 when Michael Heiming wrote:

> LOL...Nope pan-boy, just corrected your false assumption that vi
> couldn't run in a batch, that's all, no insulting intended.

And how did you correct that "false" assumption? You showed that other
tools can be used. You did not use vi. 

Alexander Skwar
-- 
prom_printf("Detected PenguinPages, getting out of here.\n");
	2.0.38 /usr/src/linux/arch/sparc/mm/srmmu.c

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
> It was Sun, 04 Jul 2004 09:35:59 +0000 when Michael Heiming wrote:
[..]

> And how did you correct that "false" assumption? You showed that other
> tools can be used. You did not use vi. 

As a personal preference yes, simply pointed out that vi can work
perfectly in a batch. What's so hard about it.

There are always dozens of ways to do the same thing which is one
of the strongest points of unix. 

BTW
vi(m) was used to write this message...

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA59elAkPEju3Se5QRAjGJAJ0RtZyWmOLNYKfDJHpkt+sO3n3yAwCgiRay
YRUEtlbGgmNjKV0JulQlmKA=
=WHAG
-----END PGP SIGNATURE-----

Mats wrote:
> Hi!
> 
> Just wondering if there is any ongoing work to adapt some sort of
> XML-like standard for configurationfiles in Linux/UNIX/whatever?
> 
> It would be really easy to write configuration tools if everybody could
>  agree with one standard. Now most of the "big" apps for Linux use
> their own format like Apache, PHP, sendmail, qmail, X and whatnot.
> 
> It would be a life in heaven for a poor administrator... :-)
> 
Not for the administrator where things were not working right; in 
particular, if the XML tools were not configured right. One more thing 
that must work before you can get started.

At one time, Red Hat did a bunch of graphical tools that went by the name 
of _linixconfig_ or something like that. Now they were not in XML, but 
they were GUI. The GUI part was nice enough, BUT

1.) Not all things were in there, so you still had to know the names and 
how to use the things that were not done in linuxconfig.

2.) It had bugs that totally damaged a system (especially when configuring 
sendmail), so you had to disable it from doing sendmail.

Red Hat tried for several releases to fix linuxconfig, but the release 
where they removed it from the distribution was the best fix of all.

The big advantage of a text-based system where you edit plain ASCII files 
using vi or emacs is that you can do it with a minimum of software, 
software that has been working for 30 years or more. So when there are 
problems, you can be certain you have screwed up a configuration file that 
you can fix by studying it with a simple editor and fixing it without 
requiring a lot of other software to be installed and working correctly.

If your problem is that XML is not installed or misconfigured, how do you 
install and configure it if it is all in XML?


-- 
   .~.  Jean-David Beyer           Registered Linux User 85642.
   /V\                             Registered Machine   241939.
  /( )\ Shrewsbury, New Jersey     http://counter.li.org
  ^^-^^ 06:00:00 up 1 day, 18:55, 3 users, load average: 4.17, 4.19, 4.42

Alexander Skwar wrote:
> It was Sat, 03 Jul 2004 18:04:16 -0500 when Dave Uhring wrote:
> 
> 
>>On Sat, 03 Jul 2004 23:01:33 +0000, Mats wrote:
>>
>>
>>>It would be a life in heaven for a poor administrator... :-)
>>
>>Do you have some problem with plain text and vi?
> 
> 
> You are aware that XML is plain text?

Plain test a bit like HTML?
> 
> Besides: A nice interface would be good. With this, there would be no need
> to reinvent a text parser over and over again. Something like gconf (or
> registry? *G*) wouldn't be that bad...

You do not need to reinvent a plain text parser (though this may be done).

You can make lexical analyzers and parsers with lex (flex) and yacc 
(bison) pretty fast.
> 
> 
>>The day that crap comes into being is the day I will quit using Linux.
> 
> 
> I don't think so.
> 
> Alexander Skwar


-- 
   .~.  Jean-David Beyer           Registered Linux User 85642.
   /V\                             Registered Machine   241939.
  /( )\ Shrewsbury, New Jersey     http://counter.li.org
  ^^-^^ 06:10:00 up 1 day, 19:05, 3 users, load average: 4.10, 4.16, 4.29

Alexander Skwar <from@alexander.skwar.name> wrote:
> Jup, it's so easy to run vi on a hand of remote machines in a loop. I
> forgot.

It is. One makes a patch out of the before and after versions and applies it
to all.

Peter

Timothy Murphy wrote:
> Andy Fraser wrote:
> 
> 
>>>It would be really easy to write configuration tools if everybody could
>>>agree with one standard.
>>
>>Do you mean "easier to write GUI tools for home users who
>>can't be bothered to learn and clueless admins"? That's the Windows way
>>and has no place in Linuxland. If an admin can't understand and edit
>>config files they have no place being an admin.
> 
> 
> Are you paid by Microsoft to air these opinions?
> There is absolutely no reason why Linux should not be as easy to administer
> as Windows, and in fact it generally is, in my experience.

Windows is only easy to administer it if you do not need to administer it.

As soon as something comes along that actually needs serious work, such as 
a registry collapse, you are screwed. About all you can do is reinstall.
> 
> I think the OP had a valid point;
> it would be better if there were a common standard for config files,
> and XML might well assist in that.
> 


-- 
   .~.  Jean-David Beyer           Registered Linux User 85642.
   /V\                             Registered Machine   241939.
  /( )\ Shrewsbury, New Jersey     http://counter.li.org
  ^^-^^ 06:20:00 up 1 day, 19:15, 3 users, load average: 4.10, 4.13, 4.19

It was Sun, 04 Jul 2004 10:10:46 +0000 when Michael Heiming wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> NotDashEscaped: You need GnuPG to verify this message
> 
> In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
>> It was Sun, 04 Jul 2004 09:35:59 +0000 when Michael Heiming wrote:
> [..]
> 
>> And how did you correct that "false" assumption? You showed that other
>> tools can be used. You did not use vi. 
> 
> As a personal preference yes, simply pointed out that vi can work
> perfectly in a batch. 

How/Where did you point out that vi can work in a batch?

Alexander Skwar
-- 
A: Weil es die Lesbarkeit des Textes verschlechtert.
Q: Warum ist TOFU so schlimm?
A: TOFU
F: Was ist das groesste Aergerniss im Usenet?

Alexander Skwar <from@alexander.skwar.name> wrote:
> It was Sun, 04 Jul 2004 07:26:34 +0200 when P.T. Breuer wrote:
> 
> > Alexander Skwar <from@alexander.skwar.name> wrote:
> >> It was Sat, 03 Jul 2004 18:04:16 -0500 when Dave Uhring wrote:
> >> 
> >> > On Sat, 03 Jul 2004 23:01:33 +0000, Mats wrote:
> >> > 
> >> >> It would be a life in heaven for a poor administrator... :-)
> >> > 
> >> > Do you have some problem with plain text and vi?
> >> 
> >> You are aware that XML is plain text?
> > 
> > No it isn't - it's marked up plain text.
> 
> But it is plain text.

No it isn't. Don't confuse marked up plain text with plain text.

> 
> > Illegible, I might add.
> 
> No.

Oh yes it is. Here, have some:

<questestinterop>
    <item title="Single response" ident="A">
        <presentation label="BasicExample002a">
            <material>
                <mattext>Which is the first working day of the week ?</mattext>
            </material>
            <response_lid ident="MCb_01" rcardinality="Single" rtiming="No">
                <render_choice>
                    <response_label ident="A">
                        <material><mattext>Saturday</mattext></material>
                    </response_label>
                    <response_label ident="B">
                        <material><mattext>Monday</mattext></material>
                    </response_label>
                    <response_label ident="C">
                        <material><mattext>Wednesday</mattext></material>
                    </response_label>
                    <response_label ident="D">
                        <material><mattext>Tuesday</mattext></material>
                    </response_label>
                    <response_label ident="E">
                        <material><mattext>Sunday</mattext></material>
                    </response_label>
                    <response_label ident="F">
                        <material><mattext>Friday</mattext></material>
                    </response_label>
                    <response_label ident="G">
                        <material><mattext>Thursday</mattext></material>
                    </response_label>
                </render_choice>
            </response_lid>
        </presentation>
        <resprocessing>
            <outcomes><decvar/></outcomes>
            <respcondition title="Correct">
                <conditionvar>
                    <varequal respident="MCb_01">B</varequal>
                </conditionvar>
                <setvar action="Set">1</setvar>
                <displayfeedback feedbacktype="Response" linkrefid="Correct"/>
            </respcondition>
        </resprocessing>
        <itemfeedback ident="Correct" view="Candidate">
            <material><mattext>Yes, you are right.</mattext></material>
        </itemfeedback>
    </item>
</questestinterop>


> >> registry? *G*) wouldn't be that bad...
> > 
> > Yes it would be horrible.
> 
> Not at all.

Yes it would, as well as no help at all to you in your quest.

Peter

It was Sun, 04 Jul 2004 06:17:06 -0400 when Jean-David Beyer wrote:
> Alexander Skwar wrote:

>> You are aware that XML is plain text?
> 
> Plain test a bit like HTML?

Yes.

> You can make lexical analyzers and parsers with lex (flex) and yacc 
> (bison) pretty fast.

Okay, fine, I don't care about XML. If a standardized way would be to use
flex/yacc - fine. To me, the relevant part would not be the XML, it would
be to have a common interface and a common configuration "language".

Alexander Skwar
-- 
/*
 * Hash table gook..
 */	2.4.0-test2 /usr/src/linux/fs/buffer.c

It was Sun, 04 Jul 2004 12:30:03 +0200 when P.T. Breuer wrote:

> Oh yes it is. Here, have some:

Nice and easy to read. And how complicated would the "simple" text look
like?

Alexander Skwar
-- 
B�ck dich, Fee. Wunsch ist Wunsch!

It was Sun, 04 Jul 2004 12:24:50 +0200 when P.T. Breuer wrote:

> Alexander Skwar <from@alexander.skwar.name> wrote:
>> Jup, it's so easy to run vi on a hand of remote machines in a loop. I
>> forgot.
> 
> It is. One makes a patch out of the before and after versions and applies it
> to all.

And what does patch/diff have to do with vi? Also, why can't you
patch/diff your xml file?

Alexander Skwar
-- 
Sig zum kaufen oder mieten gesucht.
Angebote an: sig.for.askwar@spamgourmet.com

Mats wrote:
> Hi!
> 
> Just wondering if there is any ongoing work to adapt some sort of
> XML-like standard for configurationfiles in Linux/UNIX/whatever?

I guess a question for which I need the answer for this is:

What is the problem for which this is a proposed solution?
> 
> It would be really easy to write configuration tools if everybody could
>  agree with one standard. Now most of the "big" apps for Linux use
> their own format like Apache, PHP, sendmail, qmail, X and whatnot.

Since I come from a relational database background, I could be tempted
(_not seriously_) to suggest that everything be kept in a relational
database. Now each application could have its own relation for its
configurations. That would solve the name-value pair problem where there
is doubt if an equal sign is needed or not, and whether spaces are
tolerated around the equal signs. But it sure would be overkill for such a
pathetically little problem.

But nothing else. You would still need the names of the relations, the
names of the attributes, etc., similarly to now needing to know the full
pathnames where the ASCII configuration files are.

For stuff that comes with the distribution and apply to all users,
configuration files go into /etc or subdirectories of /etc. For stuff that
you choose to put into /usr/local, they tend to go into /usr/local/etc. I
believe the FSHS even tells where they should go.

And the configuration files are fairly well known by those needing to do
the configurations. Thus, now some are directly in /etc -- such as hosts,
resolv.conf, ... And the more complex ones are in /etc/appname, such as
/etc/mail (for sendmail)... .

You see, for any application with complexity in their configuration files,
the least of the problems is the syntax of the configuration file. For
sendmail's sendmail.cf, there is a 1000 page book on how to write such
things. It is bad enough that most people write a sendmail.mc file and use
m4 to compile it into a sendmail.cf. And a sendmail.mc file is a bit
tricky in that the order of the entries matter to a certain extent, and
there are so many parameters and some of their parameters are much more
complex than name-value pairs; e.g.,

FEATURE(dnsbl, `rbl-plus.mail-abuse.org', `"550 5.7.1 " $&{client_addr} "
Rejected - see http://www.mail-abuse.com/support/enduserinfo.html"')dnl

By the time you figure out how to write one of those, you will have long
since found out where the file is and the syntax of the file.
> 
> It would be a life in heaven for a poor administrator... :-)
> 
It seems to me that your proposal would make the easy parts of system 
managing configuration files a little easier, but make the difficult parts 
much more difficult.

-- 
   .~.  Jean-David Beyer           Registered Linux User 85642.
   /V\                             Registered Machine   241939.
  /( )\ Shrewsbury, New Jersey     http://counter.li.org
  ^^-^^ 06:45:00 up 1 day, 19:40, 3 users, load average: 4.25, 4.20, 4.18

Alexander Skwar <from@alexander.skwar.name> wrote:
> It was Sun, 04 Jul 2004 12:24:50 +0200 when P.T. Breuer wrote:
> 
> > Alexander Skwar <from@alexander.skwar.name> wrote:
> >> Jup, it's so easy to run vi on a hand of remote machines in a loop. I
> >> forgot.
> > 
> > It is. One makes a patch out of the before and after versions and applies it
> > to all.
> 
> And what does patch/diff have to do with vi? Also, why can't you
> patch/diff your xml file?

Because one can't edit it in the first place, being unreadable 'n all.

Peter

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
> It was Sun, 04 Jul 2004 10:10:46 +0000 when Michael Heiming wrote:
>> In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
>>> It was Sun, 04 Jul 2004 09:35:59 +0000 when Michael Heiming wrote:
[..]
>> As a personal preference yes, simply pointed out that vi can work
>> perfectly in a batch. 

> How/Where did you point out that vi can work in a batch?

In my first reply to you, in this thread, sorry if I assumed to
much knowledge about vi(m)/system administration and you didn't
got that point until now. 

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA5+TgAkPEju3Se5QRAorHAKChBBs8VI+duQ3rpyzl7NuEbyEpUwCgnGD2
dQ/Z+Qn6ci2ZqwzJq80FTTA=
=pX2i
-----END PGP SIGNATURE-----

Alexander Skwar <from@alexander.skwar.name> wrote:
> Okay, fine, I don't care about XML. If a standardized way would be to use
> flex/yacc - fine. To me, the relevant part would not be the XML, it would
> be to have a common interface and a common configuration "language".

That makes sense, and the common configuration language is

 A = B

Sometimes with grouping, like

 C {

   A = B
   ...
 }

and sometimes with optional semicolons as separators or terminators,
like:

 C {

   A = B;
   ...
 };

Peter

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Jean-David Beyer <jdbeyer@exit109.com> suggested:
> Mats wrote:
[..]

Hi Jean-David!

> You see, for any application with complexity in their configuration files,
> the least of the problems is the syntax of the configuration file. For
> sendmail's sendmail.cf, there is a 1000 page book on how to write such
> things. It is bad enough that most people write a sendmail.mc file and use

Having read large parts of this O'Reilly book, it's great if you
have m4, one shouldn't touch sendmail.cf since he's hacking a
binary, unless he's really sure he knows what he's doing, but
then he wouldn't ask. Might be a reason why you won't get support
from the usual cms gurus if you insist on hacking sendmail.cf.

While it might be sometimes needed, there are *nix systems that
don't have m4, one shouldn't if m4 is available.

[..]

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA5+gQAkPEju3Se5QRAhPkAJ9HJwiGMzsL32plVFaDD3NB3kwudQCgjxTE
Yr/nw4atVMgZrdKLxoBCLM0=
=KP3q
-----END PGP SIGNATURE-----

It was Sun, 04 Jul 2004 11:07:13 +0000 when Michael Heiming wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> NotDashEscaped: You need GnuPG to verify this message
> 
> In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
>> It was Sun, 04 Jul 2004 10:10:46 +0000 when Michael Heiming wrote:
>>> In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
>>>> It was Sun, 04 Jul 2004 09:35:59 +0000 when Michael Heiming wrote:
> [..]
>>> As a personal preference yes, simply pointed out that vi can work
>>> perfectly in a batch. 
> 
>> How/Where did you point out that vi can work in a batch?
> 
> In my first reply to you, in this thread, 

news:52skr1-ass.ln1@news.heiming.de you mean? Where did you point out that
vi can work in a batch?

Alexander Skwar
-- 
panic("Oh boy, that early out of memory?");
	2.2.16 /usr/src/linux/arch/mips/mm/init.c

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
> It was Sun, 04 Jul 2004 11:07:13 +0000 when Michael Heiming wrote:

>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> NotDashEscaped: You need GnuPG to verify this message
>> 
>> In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
>>> It was Sun, 04 Jul 2004 10:10:46 +0000 when Michael Heiming wrote:
>>>> In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
>>>>> It was Sun, 04 Jul 2004 09:35:59 +0000 when Michael Heiming wrote:
>> [..]
>>>> As a personal preference yes, simply pointed out that vi can work
>>>> perfectly in a batch. 
>> 
>>> How/Where did you point out that vi can work in a batch?
>> 
>> In my first reply to you, in this thread, 

> news:52skr1-ass.ln1@news.heiming.de you mean? Where did you point out that
> vi can work in a batch?

You wrote:

"> Jup, it's so easy to run vi on a hand of remote machines in a loop. I"
"> forgot."

My answer:

"While I'd use sed/awk/perl/whatever through ssh-agent for
single-sign-on, you can do it easily with vi,[..}"

Now that was meant to say that vi can work perfectly in a batch
on remote systems. Don't like to write large amounts of text
about simple tasks, while it seems to be needed sometimes.;(

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA5+rgAkPEju3Se5QRAgTQAJ9G/K+olQc/fULFuzhfLyQ2yi3bVQCgz9tX
7a8M0al7vdup7TbwkOK5skU=
=y7Rm
-----END PGP SIGNATURE-----

It was Sun, 04 Jul 2004 11:32:49 +0000 when Michael Heiming wrote:

> Now that was meant to say that vi can work perfectly in a batch
> on remote systems.

How?

Alexander Skwar
-- 
printk(KERN_WARNING "Multi-volume CD somehow got mounted.\n");
	2.2.16 /usr/src/linux/fs/isofs/inode.c

Mats wrote:

> Just wondering if there is any ongoing work to adapt some sort of
> XML-like standard for configurationfiles in Linux/UNIX/whatever?

I dont think so.

> It would be really easy to write configuration tools if everybody
> could agree with one standard.

What's wrong with Microsoft's INI file format?  Or with plain
<name>=<value> pairs?

> Now most of the "big" apps for Linux use their own format like
> Apache, PHP, sendmail, qmail, X and whatnot.
> 
> It would be a life in heaven for a poor administrator... :-)

Yes.  But XML isn't the answer.  The overhead is _much_ too large for
most purposes.

Jacob
-- 
"I'm going as a barrel of toxic waste!"

Vilmos Soti wrote:
> "Mats" <spamenot.mog.pettersson@telia.com> writes:

[snip]

> Is it so hard to read that !#@$ README and FAQ?  Linux is not there
> to hold your hand. If you need software which you can use without
> actually understanding what it does or how it does it, then use
> Windows.

It's not about learning/understanding the app, it's about to make it 
easyer to administrate several configurationfiles. By the way, the 
"security by obscurity" and the "superiority by unneccesary complexity" 
buzz words in this newsgroup doesn't impress me.

> They are easy to learn (albeit I question if they are
> easy to use on the long run).
> 
>>>has no place in Linuxland. If an admin can't understand and edit config
>>>files they have no place being an admin.
>>
>>No and no again! Why must i learn 100 different configuration
>>syntax/flaws/options when they all do basically the same, setting various
>>variables to different values?
> 
> 
> You still need to learn 100 different config syntax, but now they
> would be wrapped in xml. You still need to know the proper keywords.
> 

No, mabye i need to learn a 100 different apps/standards but it's a 
waste of time learning 100 ways to to edit freaking configfiles.

> 
>>Some configfiles has good comments and even
>>present some options, some don't. You know you should select a charset for
>>example, but you don't know the syntax/value.
> 
> 
> And how will xml tell me what is the syntax/value?

Sort of like a form in html...

Description part, this part you never mess with. It's from the author of 
the app. It just describes the configurations variable/value pairs. It 
can have min/max values also and types so a sanity check can be made 
when importing data to the app.

<variable name="this option" valueform="options">
  <text>
   This variable is an example with 2
   options with values: option1 and option2
   that does... blah blah...
  </text>
  <option type="text" value="option1" label="label1">
  <option type="text" value="option2" label="label2">
</variable>

Config part, the part that contains the current value for the variable. 
This is were you do the edit.

<variable name="this option" value="option1"/>

> 
> 
>>iso8859-1? You have to crossreference various docs and faq's just to find
>>out a simple thing like that. It's just a waste of time.
> 
> 
> No, it is not a waste of time. Or, what is a waste of time for you,
> is valuable time spent for me learning the thing. You know the
> phrase don't you? An engineer is a man who spends three hours to
> figure out how to do a two hour job in one hour. However, if you
> have to do it over and over, that time saving (learning) does
> help.

The waste of time is that in that specific configfile one of the options 
could be set to (among others) iso8859-1, but in another configfile for 
another app it might be latin1 or any other value for basically the same 
thing, so after a while twiddling with both these configfiles you might 
start using the wrong value in the wrong configfile. Besides if you 
write ISO8859-1 and the author of the app has choosen to parse the file 
with case sensitivity, it would break, or you spell it wrong by mistake, 
it will break.

> 
> Once I figure out, by crossreferencing for example, wtf iso8859-1 is,
> I don't need to look it up later. It is called learning. And if you
> want to configure a system without learning, or understanding
> what to do, then you shouldn't be in the admin business.
> 
> I still don't see how an xml config file standard will save me
> from knowing what iso8859-1 is.

Not saving you from knowing what it is, but from wondering what the 
value could be.

> 
>>I know it's important to acces config files from texteditors. I don't wan't
>>binary configfiles. You can still use SSH or whatever shell and texteditor
>>you like. You also have the opportunity to make a configeditor with curses,
>>which should work with most shells.
> 
> 
> Bad idea, the configeditor with curses. A question. How do you automate
> it? Say, an event occurs on the system, and a program needs to modify
> a config file. How do you do that with a curses interface?

Well, since it is an open standard you could use a library if you write 
the program yourself or a commandline configuration tool like: 
configtool /etc/configfile.conf -s "variable" "value" (where -s means 
set). Maybe there would be perl/python modules and whatnot.

> 
> Also, one of the most beautiful thing in Unix is that I am not tied
> to use a specific program to accomplish something (in most cases).

No, but were tied to unneccesary complexity in some cases.

> Do you think any admin would like to go down the road that only one
> program would be able to modify config files? Do you like the fact
> the you need Microsoft Word to edit your Word files (if a conversion
> doesn't go perfectly)? Do you want to go down the route where the
> configeditor is the only program to search in your config files?

I don't know why you think that. It wouldn't be much more complicated to 
edit with vi/emacs/joe than your regular apache.conf. Infact maybe 
vi/emacs could even be scripted to present it so you don't have to se 
all the tags in the configfiles.

> What if you don't want to use their crappy search but would prefer
> to use grep? Or sed to replace text? Having a xml based config
> file will make life miserable for those who manage more than a
> couple of machines.

Well if we break out from pure XML and make this more strict we could 
see to it that all lines with variable pairs start with "<variable 
name="blah"..." and you just grep for that.

> It is ok to configedit the same file on a
> couple of boxes. But what if you have tens or hundreds of boxes?
> How do you automate that? With the plain text and simple config
> files, I can easily automate such things if I need. With an xml
> based config file, it is still possible, but it will be much harder
> and more error prone. When you want something like an xml based
> config file, think about not only the single user who maintains
> only his/her box, but an overworked admin who have better things
> to do than to fight with xml.

Your last sentence "overworked admin" is why i brought this (now growing 
mess) up in the first place. Maybe i was vauge when i said "*one* 
configuration tool to manage all files". Ofcourse you can have how many 
specialised configtools you wan't, especially for purposes like you give 
above. And the thing is, the tool you choose automagically works on all 
configurationfiles for all apps that conforms to this standard. No need 
to manically tweak scripts for each type of configfile like now.

About configuring multiple servers, this would make things like LDAP easier.

> 
> Also, if we use xml based config files, there will be so much
> fluff that it will be much harder to figure out settings just
> by looking it. Do I really want to waste my time by "unseeing"
> all the xml wrappings when all I need is one single value?

I agree that is the *bad* thing about XML and the like, but it need to 
be structed in *some* way. Maybe there are better standards for this 
than XML, but most standards i've seen is looking like XML/HTML/Apache 
config and hybrids there about.

>>If this is done correctly, it won't just benefit the users/administrators,
>>it would benefit the programmers too, to put all info in one place, easy to
>>browse for the user/admin. Not having to answer a lot of stupid emails with
>>basic questions and frustated admins and write endless updated FAQ's.
> 
> 
> It won't benefit the users/admins. It *MIGHT* benefit the ignorant
> who is unwilling to invest to learning the ins and outs of the system.

No, i don't agree and don't accept that. If you set up a mail server you 
got to know at least basic SMTP and DNS/MX stuff. But it's always a 
struggle to find how you enable disable some functions in the maildaemon 
(for example). *This* is what should be easier.

> 
> But Linux is not for those people. For those, there are other systems.
> 
> And I fully expect a programmer to be able to write a simple text
> parser. If he fails at that, then there are other professions
> available for him which fit his mental abilities.

The point is to stop reinvent the wheel over and over again. We have 
evolved enough now to know what features most configfiles have. Take the 
   menuconfig for the linux-kernel for example. It's really good. If you 
not quite shure what the label of the option tells you, you can press 
"help" and you get explainig text directly, instead of rebrowse the 
whole README/INSTALL/Doc or wherever that option was explained.

> I fail to see how an xml config file would prevent a lot of stupid
> questions. Any idea?

As above.

>>>Generally Linux/Unix admins are of a higher calibre than
>>>Windows admins. GUI config tools generating XML files could well change
>>>that.
>>
>>It's not a question of Windoze or XML-files, it's a question of doing what
>>computers IMHO was invented to do, make life technically easier. If we can't
>>succeed in that, what's the point of Linux/Windoze/MacOS/BeOS....?
> 
> 
> It wouldn't make your life technically easier. It would confine
> you to the one program, the configeditor, which was designed to
> edit config files. This is not the Unix way.

No, i don't mean "one tool" like that, i mean the same tool can manage 
many different configfiles. You can ofcourse have how many configtools 
you want for special purposes. You can even make your own.

> 
> My life is technically easy if *I CAN* decide how I edit the config
> files.
> 
> Don't take it as a personal insult since I didn't mean it that way.
> Take it as a letter from and admin who is wearing many hats, and the
> last thing he needs is to be forced to edit config files in a way that
> he feels is unnatural.
> 
> Look, I have used RedHat since version 2.x or 3.x, don't remember.
> And I have never used their config tools except for configuring
> printers. Guess what, I just didn't like them. Neither the X
> nor the ncurses interfaces. They weren't intuitive (for me), they
> were buggy (at least a couple of years ago), and they were a pain
> in the ass to use.

.... and they don't always work as they should. That is partly because of 
the same problem i'm trying to explain here. Most of todays 
multi-configurationtools are *hacks* as there is no humanly possible way 
to keep track of all the various syntaxes of the configurationfiles out 
there. Although Webmin does a good job.

> I always used emacs or vi to configure the
> machines. And they are up and running. Also, since I actually know
> how the system works (or at least I think), my knowledge is fairly
> generic. I could pick up OpenBSD pretty fast since I learned things
> the hard way. I learned them. No handholding. Forcing one particular
> program to edit config files would have prevented me from a lot
> of learning. And it also happened that sometimes I mucked up the
> config file, and the program didn't work. Fortunately there was no
> config editor there which prevented me from making an error. What
> happened? I forced to dig into it, understand it, correct it, and
> LEARN HOW I WORKED. In the short run, this is bad, since you screw
> up a system/program. But in the long run, it is a blessing since I
> actually learned how the system worked.

You say above that you learned from making an error in the configfile, 
but what did you learn? You just learned the syntax of that configfile 
for that particular program. If you move over to another app (say qmail 
instead of sendmail) you have no use of that info because qmail's 
configfile, though doing more or less the same things, has a whole other 
syntax. What you learnt is now worthless. There are more important 
things to learn and keep track of then syntax's for configfiles.

> 
> Vilmos

Mats

Michael Heiming wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> NotDashEscaped: You need GnuPG to verify this message
> 
> In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
> 
>>It was Sat, 03 Jul 2004 21:11:06 -0500 when Dave Uhring wrote:
>>
>>>On Sun, 04 Jul 2004 01:21:53 +0200, Alexander Skwar wrote:
> 
> [..]
> 
> 
>>>The proper interface to system configuration files is vi.
> 
> 
> Yup, the only portable way, there are more *nix systems then a
> bunch of Linux distro. Where one or another tries to lock people
> in a vendor trap.;(

Why isn't XML portable? You must really hate apache's configfiles if you 
don't like tags.

> 
> 
>>Jup, it's so easy to run vi on a hand of remote machines in a loop. I
>>forgot.
> 
> 
> While I'd use sed/awk/perl/whatever through ssh-agent for
> single-sign-on, you can do it easily with vi, just that you are
> not knowledgeable enough doesn't mean it wouldn't be possible.
> 

Yeah, why make it easy and use one app when you have sed/awk/perl/ssh 
just collecting dust in the corner? That's also more impressive and 
gains higher eLit3 status.

Mats

P.T. Breuer wrote:
> Alexander Skwar <from@alexander.skwar.name> wrote:
> 
>>Okay, fine, I don't care about XML. If a standardized way would be to use
>>flex/yacc - fine. To me, the relevant part would not be the XML, it would
>>be to have a common interface and a common configuration "language".
> 
> 
> That makes sense, and the common configuration language is
> 
>  A = B
> 
> Sometimes with grouping, like
> 
>  C {
> 
>    A = B
>    ...
>  }
> 
> and sometimes with optional semicolons as separators or terminators,
> like:
> 
>  C {
> 
>    A = B;
>    ...
>  };

Yeah! A bit more strict (especially whith the semicolon thingies), an 
data description part and were set.

> 
> Peter

Mats

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
> It was Sun, 04 Jul 2004 11:32:49 +0000 when Michael Heiming wrote:

>> Now that was meant to say that vi can work perfectly in a batch
>> on remote systems.

> How?

What about RTFM? From 'man vi(m)':

  -s {scriptin}
        The  script file {scriptin} is read.  The characters in the
        file are interpreted as if you had typed them.   The  same
        can be done with the command ":source!{scriptin}".  If the
        end of the file is reached before the editor exits, further
        characters are read from the keyboard.

Running in addition in "ex" mode might be more convenient, even
if this is more a personal preference as you can do it once in
interactive mode and record what you did, for further usage. The
vim docs should have full info available.

Good luck

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA5/llAkPEju3Se5QRApVfAJoDGhTQm6HSwifAmYTTLuzSgdeN7QCgsHKj
JFIZ1OEWm1fCs/Hi7U66QWY=
=oapA
-----END PGP SIGNATURE-----

It was Sun, 04 Jul 2004 12:34:46 +0000 when Michael Heiming wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> NotDashEscaped: You need GnuPG to verify this message
> 
> In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
>> It was Sun, 04 Jul 2004 11:32:49 +0000 when Michael Heiming wrote:
> 
>>> Now that was meant to say that vi can work perfectly in a batch
>>> on remote systems.
> 
>> How?
> 
> What about RTFM? From 'man vi(m)':
> 
>   -s {scriptin}

You gotta be kidding me? So it's not enough to learn all the different
configuration syntaxes, you also expect people to learn the "vi
programming language"? And you really think that this isn't hard?

Alexander Skwar
-- 
Wusstest Du schon, das "slrn" das Gerauesch ist, das Hamster macht,
wenn er einen Frottee Agent auswuergt? 
  [Joachim Kromm in tot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Mats <spamenot.mog.pettersson@telia.com> suggested:
> Michael Heiming wrote:
>> In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
>>>It was Sat, 03 Jul 2004 21:11:06 -0500 when Dave Uhring wrote:
>>>>On Sun, 04 Jul 2004 01:21:53 +0200, Alexander Skwar wrote:
[..]
>>>>The proper interface to system configuration files is vi.
>> 
>> Yup, the only portable way, there are more *nix systems then a
>> bunch of Linux distro. Where one or another tries to lock people
>> in a vendor trap.;(

> Why isn't XML portable? You must really hate apache's configfiles if you 
> don't like tags.

Apache's config isn't that bad and not XML. You won't be able to reuse Ie.
suse config files made in XML on another distro, it won't work
out, but an apache config file will be easily reusable on any
*nix you happen to be able to compile apache.

>>>Jup, it's so easy to run vi on a hand of remote machines in a loop. I
>>>forgot.
>> 
>> While I'd use sed/awk/perl/whatever through ssh-agent for
>> single-sign-on, you can do it easily with vi, just that you are
>> not knowledgeable enough doesn't mean it wouldn't be possible.

> Yeah, why make it easy and use one app when you have sed/awk/perl/ssh 
> just collecting dust in the corner? That's also more impressive and 
> gains higher eLit3 status.

You haven't understood much if anything about the unix way of
doing things, we don't need bloatware that pretends to do
anything with a single app, that doesn't work at all. 

No thx, the way of doing basic things hasn't changed much in >30 
years, one reason might be that it works perfectly and is pretty
easy/portable once you are used to it. This might take some time,
but none ever said it would be that easy, in exchange you get the
massive power of the shell that is still and will always be
unmatched by any GUI tool. If you don't get that, simply use
another OS.

-- 
Michael Heiming - RHCE (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA5/z2AkPEju3Se5QRAid9AKCe2vYm4o44GeI5bJ0IzbyqnyrWiACgq/cj
pBemoypaQQbu9JKNOwSl+RA=
=/ej+
-----END PGP SIGNATURE-----

Jean-David Beyer wrote:
> Mats wrote:
> 
>> Hi!
>>
>> Just wondering if there is any ongoing work to adapt some sort of
>> XML-like standard for configurationfiles in Linux/UNIX/whatever?
>>
>> It would be really easy to write configuration tools if everybody could
>>  agree with one standard. Now most of the "big" apps for Linux use
>> their own format like Apache, PHP, sendmail, qmail, X and whatnot.
>>
>> It would be a life in heaven for a poor administrator... :-)
>>
> Not for the administrator where things were not working right; in 
> particular, if the XML tools were not configured right. One more thing 
> that must work before you can get started.
> 
> At one time, Red Hat did a bunch of graphical tools that went by the 
> name of _linixconfig_ or something like that. Now they were not in XML, 
> but they were GUI. The GUI part was nice enough, BUT
> 
> 1.) Not all things were in there, so you still had to know the names and 
> how to use the things that were not done in linuxconfig.
> 
> 2.) It had bugs that totally damaged a system (especially when 
> configuring sendmail), so you had to disable it from doing sendmail.
> 
> Red Hat tried for several releases to fix linuxconfig, but the release 
> where they removed it from the distribution was the best fix of all.

Part of thoose problems probably was due to the different standards of 
various config files. As said in an earlier post those 
multi-configurationtools are mostly hacks. They probably break when 
another version of the same app comes along. Or the configtool has to be 
updated everytime a app is updated.

The point of my view of configurationfiles is that the possible choises 
in the configurationfile chips in the same file, in the description part 
of the file. So when the app is updated the options in the 
configurationutility is automagically updated.

> 
> The big advantage of a text-based system where you edit plain ASCII 
> files using vi or emacs is that you can do it with a minimum of 
> software, software that has been working for 30 years or more. So when 
> there are problems, you can be certain you have screwed up a 
> configuration file that you can fix by studying it with a simple editor 
> and fixing it without requiring a lot of other software to be installed 
> and working correctly.

You can still configure manually with vi or whatever even if it's XML or 
the like. XML is just sort of a structured textfile.

> If your problem is that XML is not installed or misconfigured, how do 
> you install and configure it if it is all in XML?

The XML or configuration parser is just a library, either by itself or 
compiled in in whatever the configuration editor. It doesn't need a 
configurationfile.

> 
> 

Mats

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
> It was Sun, 04 Jul 2004 12:34:46 +0000 when Michael Heiming wrote:
>> In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
>>> It was Sun, 04 Jul 2004 11:32:49 +0000 when Michael Heiming wrote:
[..]
>> What about RTFM? From 'man vi(m)':
>> 
>>   -s {scriptin}

> You gotta be kidding me? So it's not enough to learn all the different
> configuration syntaxes, you also expect people to learn the "vi
> programming language"? And you really think that this isn't hard?

Don't care if anyone thinks that would be easy or hard, nor do I
expect people to learn anything, if they like, yep we can point
out some hints, which is what this ng is about. If not, they
might like to stop moaning, look for some advocacy ng or/and use
another OS, which suits there needs better. But then Linux is a
clone of a POSIX compatible UNIX system, that's what it's all
about. Many people including me don't see any point in changing
that.;)

-- 
Michael Heiming - RHCE (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA5/93AkPEju3Se5QRAn5LAKC5LAYOS4PsiQQo5gaz59T90hIjQACguanz
FwUWJvy8YEd3FI8O8JeLLw8=
=O4vt
-----END PGP SIGNATURE-----

mjt <mjtobler@removethis_mail.ru> wrote in message news:<i9LFc.4984$oD3.4022@newsread1.news.pas.earthlink.net>...
> Mats wrote:
> 
> >> i dont see that happening anytime soon
> > 
> > No, neither do i. It's easiest to walk along the same old path and safest to
> > stay in the same place. 
> 
> ... "if it aint broke, dont fix it"
> 
> > You know what they say: "Standards are good, 
> > everyone should have one."
> 
> nope:  "the computer industry loves standards,
> that's why there are so many of them
> .


The one enduring standard is that standards don't endure.
Regards...Dan.

On Sun, 04 Jul 2004 07:23:34 +0000, Michael Heiming wrote:

> Full ack! So don't use suse then, they are using XML for quite a
> few of there own config files, where it looks to me they'd like to
> lock people in there own vendor trap.;(

The last time I installed SuSE was their v7.2 IIRC.  I put all the CDs and
dead tree stuff back into the box and sold it to a Windows user who wanted
to learn Linux, then reinstalled Slackware.

The are perfectly welcome to try to lock in their customers since there
are other Linux distro vendors who do not attempt that.

Jean-David Beyer wrote:
> Mats wrote:
> 
>> Hi!
>>
>> Just wondering if there is any ongoing work to adapt some sort of
>> XML-like standard for configurationfiles in Linux/UNIX/whatever?
> 
> 
> I guess a question for which I need the answer for this is:
> 
> What is the problem for which this is a proposed solution?
> 
>>
>> It would be really easy to write configuration tools if everybody could
>>  agree with one standard. Now most of the "big" apps for Linux use
>> their own format like Apache, PHP, sendmail, qmail, X and whatnot.
> 
> 
> Since I come from a relational database background, I could be tempted
> (_not seriously_) to suggest that everything be kept in a relational
> database. Now each application could have its own relation for its
> configurations. That would solve the name-value pair problem where there
> is doubt if an equal sign is needed or not, and whether spaces are
> tolerated around the equal signs. But it sure would be overkill for such a
> pathetically little problem.

Yeah, and it couldn't be configured by hand.

> But nothing else. You would still need the names of the relations, the
> names of the attributes, etc., similarly to now needing to know the full
> pathnames where the ASCII configuration files are.

The names of attributes and such would be in the description part of the 
configfile. But yes, as long as the configfiles isn't gathered in one 
directory you have to specify the path.

> For stuff that comes with the distribution and apply to all users,
> configuration files go into /etc or subdirectories of /etc. For stuff that
> you choose to put into /usr/local, they tend to go into /usr/local/etc. I
> believe the FSHS even tells where they should go.
> 
> And the configuration files are fairly well known by those needing to do
> the configurations. Thus, now some are directly in /etc -- such as hosts,
> resolv.conf, ... And the more complex ones are in /etc/appname, such as
> /etc/mail (for sendmail)... .

I spend some time configuring, although often when i've been away a 
while or use some other distro i tend to forget where it is when i have 
to go back for it. Some times the location pointed to by the man-page is 
wrong, depending on distro or if the app is compiled by hand and not 
part of the distro.

> 
> You see, for any application with complexity in their configuration files,
> the least of the problems is the syntax of the configuration file. For
> sendmail's sendmail.cf, there is a 1000 page book on how to write such
> things. It is bad enough that most people write a sendmail.mc file and use
> m4 to compile it into a sendmail.cf. And a sendmail.mc file is a bit
> tricky in that the order of the entries matter to a certain extent, and
> there are so many parameters and some of their parameters are much more
> complex than name-value pairs; e.g.,
> 
> FEATURE(dnsbl, `rbl-plus.mail-abuse.org', `"550 5.7.1 " $&{client_addr} "
> Rejected - see http://www.mail-abuse.com/support/enduserinfo.html"')dnl
> 
> By the time you figure out how to write one of those, you will have long
> since found out where the file is and the syntax of the file.

Ouch! Sendmails config... You're trying to get me nightmares!

>> It would be a life in heaven for a poor administrator... :-)
>>
> It seems to me that your proposal would make the easy parts of system 
> managing configuration files a little easier, but make the difficult 
> parts much more difficult.
> 

Well, maybe you're right. I'll just go back to my configfiles and 
continue cursing.

Mats

Michael Heiming wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> NotDashEscaped: You need GnuPG to verify this message
> 
> In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
> 
>>It was Sun, 04 Jul 2004 12:34:46 +0000 when Michael Heiming wrote:
>>
>>>In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
>>>
>>>>It was Sun, 04 Jul 2004 11:32:49 +0000 when Michael Heiming wrote:
> 
> [..]
> 
>>>What about RTFM? From 'man vi(m)':
>>>
>>>  -s {scriptin}
> 
> 
>>You gotta be kidding me? So it's not enough to learn all the different
>>configuration syntaxes, you also expect people to learn the "vi
>>programming language"? And you really think that this isn't hard?
> 
> 
> Don't care if anyone thinks that would be easy or hard, nor do I
> expect people to learn anything, if they like, yep we can point
> out some hints, which is what this ng is about. If not, they
> might like to stop moaning, look for some advocacy ng or/and use
> another OS, which suits there needs better. But then Linux is a
> clone of a POSIX compatible UNIX system, that's what it's all
> about. Many people including me don't see any point in changing
> that.;)
> 

Oh, i thought Linux was just a kernel. Maybe it's been kidnapped by UNIX? :)

Mats

On Sun, 04 Jul 2004 13:34:26 +0200, Alexander Skwar wrote:
> It was Sun, 04 Jul 2004 11:32:49 +0000 when Michael Heiming wrote:
> 
>> Now that was meant to say that vi can work perfectly in a batch
>> on remote systems.
> 
> How?

Many ways ... , here is one:

ssh somebox "vi /etc/some.conf <<END
:%s/somehting=blah/something=blahblah/g
:wq
END"

-- 
-Menno.

Mats <spamenot.mog.pettersson@telia.com> wrote:
> P.T. Breuer wrote:
> > That makes sense, and the common configuration language is
> > 
> >  A = B
> > 
> > Sometimes with grouping, like
> > 
> >  C {
> > 
> >    A = B
> >    ...
> >  }
> > 
> > and sometimes with optional semicolons as separators or terminators,
> > like:
> > 
> >  C {
> > 
> >    A = B;
> >    ...
> >  };
> 
> Yeah! A bit more strict (especially whith the semicolon thingies), an 
> data description part and were set.

There's no need to be strict - the above is unambiguous as a grammar
(as far as it goes) with or without optional semicolons.

If it were ambiguous you could agree to resolve ambiguities
automatically by any of several disambiguating rules - longest initial
match, for example. But it's usually better to be forgiving about
syntax. Optional semicolons are OK. They would allow you to write

    A = B; C = D

instead of

    A = B
    C = D

Peter

P.T. Breuer wrote:
> Mats <spamenot.mog.pettersson@telia.com> wrote:
> 
>>P.T. Breuer wrote:
>>
>>>That makes sense, and the common configuration language is
>>>
>>> A = B
>>>
>>>Sometimes with grouping, like
>>>
>>> C {
>>>
>>>   A = B
>>>   ...
>>> }
>>>
>>>and sometimes with optional semicolons as separators or terminators,
>>>like:
>>>
>>> C {
>>>
>>>   A = B;
>>>   ...
>>> };
>>
>>Yeah! A bit more strict (especially whith the semicolon thingies), an 
>>data description part and were set.
> 
> 
> There's no need to be strict - the above is unambiguous as a grammar
> (as far as it goes) with or without optional semicolons.
> 
> If it were ambiguous you could agree to resolve ambiguities
> automatically by any of several disambiguating rules - longest initial
> match, for example. But it's usually better to be forgiving about
> syntax. Optional semicolons are OK. They would allow you to write
> 
>     A = B; C = D
> 
> instead of
> 
>     A = B
>     C = D
> 
> Peter

....and speaking of bloat (as a former poster), add several lines of code 
in the parser to handle two scenarios instead of one. I like it strict. 
If not complied to standards, output error and refuse to read. The more 
loose specs, the higher ods are for bugs, security-flwas and increased 
developing time.

Mats

Mats <spamenot.mog.pettersson@telia.com> wrote:
> ...and speaking of bloat (as a former poster), add several lines of code 
> in the parser to handle two scenarios instead of one. I like it strict. 

Parsers do not need code "added". The simple specification is exactly

  config = stanza*

  stanza = NAME '{' stanza* '}' [ ';' ]
         | NAME '=' VALUE       [ ';' ]

This is ambiguous at the token level in the sense that the VALUE token
might have the same form as a sequence of NAMEs too, thus

  "foo = bar gum = bay"

might be interpreted as foo = "bar gum = bay" or as the two stanzas
"foo = bar" and "gum = bay". You would want to disambiguate this by
using explicit quotes or inserting semicolons. 

> If not complied to standards, output error and refuse to read. The more 

Please stop making up nonsense.

Peter

On Sat, 03 Jul 2004 23:01:33 GMT, "Mats"
<spamenot.mog.pettersson@telia.com> wrote:

>Hi!
>
>Just wondering if there is any ongoing work to adapt some sort of XML-like
>standard for configurationfiles in Linux/UNIX/whatever?
>
>It would be really easy to write configuration tools if everybody could
>agree with one standard. Now most of the "big" apps for Linux use their own
>format like Apache, PHP, sendmail, qmail, X and whatnot.
>
>It would be a life in heaven for a poor administrator... :-)
>
>Mats
>

Blech!  The first step toward the windows registry. A few days ago I
got involved with an app that uses XML for it's config file.  What's
wrong with being able to edit a text config file with whatever editor
you prefer? 

Mike-
--
If you're not confused, you're not trying hard enough.
--
Please note - Due to the intense volume of spam, we have installed 
site-wide spam filters at catherders.com.  If email from you bounces,
try non-HTML, non-encoded, non-attachments,




----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Mats <spamenot.mog.pettersson@telia.com> suggested:
> Michael Heiming wrote:
>> In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
>>>It was Sun, 04 Jul 2004 12:34:46 +0000 when Michael Heiming wrote:
>>>>In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
>>>>>It was Sun, 04 Jul 2004 11:32:49 +0000 when Michael Heiming wrote:
[..]
>> Don't care if anyone thinks that would be easy or hard, nor do I
>> expect people to learn anything, if they like, yep we can point
>> out some hints, which is what this ng is about. If not, they
>> might like to stop moaning, look for some advocacy ng or/and use
>> another OS, which suits there needs better. But then Linux is a
>> clone of a POSIX compatible UNIX system, that's what it's all
>> about. Many people including me don't see any point in changing
>> that.;)
>> 

> Oh, i thought Linux was just a kernel. Maybe it's been kidnapped by UNIX? :)

Now that was funny...

What is Linux?
Linux is a clone of the operating system Unix, written from
scratch by Linus Torvalds with assistance from a loosely-knit
team of hackers across the Net. It aims towards POSIX and Single
UNIX Specification compliance.

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA6CrCAkPEju3Se5QRAvfNAKCF4HkhSPVkmDu5O7lmRM9rVOtoSACgiqKI
bNIn8+c3Jilv4RVG6AvxUcE=
=9cdJ
-----END PGP SIGNATURE-----

Keith Keller wrote:

>> It would be a life in heaven for a poor administrator... :-)
> 
> Emphasis on "poor"--we'd all be out of work because configuration would
> be so easy, even an MCSE could do it!�

.... excellent point, indeed !
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
Civilization is fun!  Anyway, it keeps me busy!!

It was Sun, 04 Jul 2004 11:54:07 -0400 when Michael W. Cocke wrote:

> Blech!  The first step toward the windows registry.

That wouldn't be so bad.

> A few days ago I
> got involved with an app that uses XML for it's config file.  What's
> wrong with being able to edit a text config file with whatever editor
> you prefer? 

Nothing. That's why XML is nice - you're able to use whatever editor you
prefer, in case you need to edit it manually.

Alexander Skwar
-- 
Sig zum kaufen oder mieten gesucht.
Angebote an: sig.for.askwar@spamgourmet.com

Alexander Skwar wrote:

> Well, complicate? What's so hard about
> 
> <variable>
> ��������value
> </variable>

.... it's too verbose, IMO
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
It is like saying that for the cause of peace, God and the Devil will
have a high-level meeting. - Rev. Carl McIntire, on Nixon's China trip

It was Sun, 04 Jul 2004 16:22:17 +0000 when mjt wrote:

> Alexander Skwar wrote:
> 
>> Well, complicate? What's so hard about
>> 
>> <variable>
>> ��������value
>> </variable>
> 
> ... it's too verbose, IMO

*LOL*

Okay, how about this then:

	<variable value="whatnot"/>

Still too verbose?

OTOH: I don't think that a configuration file can be *too* verbose. Quite
the opposite is IMO true: Most of the times, they are not verbose enough.

Alexander Skwar
-- 
Die meisten Einfuhren der USA kommen aus dem Ausland. George.W.Bush

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
> It was Sun, 04 Jul 2004 11:54:07 -0400 when Michael W. Cocke wrote:

>> Blech!  The first step toward the windows registry.

> That wouldn't be so bad.


                     Troll O Meter

  0    1    2    3    4    5    6    7    8    9    10
  ___________________________________________________
  |    |    |    |    |    |    |    |    |    |    |
  ---------------------------------------------------
      ^
      |

Sorry, try a little harder next time.  Thanks for playing!

Thx for supporting.

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA6DR0AkPEju3Se5QRAgzPAJ4kQKvVhgB/6ELoCm+0zTfLezpD/gCgrdiR
7MPxmlS7MF6iTDpAMJjKTnw=
=YhwU
-----END PGP SIGNATURE-----

Mats wrote:

> No, mabye i need to learn a 100 different apps/standards but it's a 
> waste of time learning 100 ways to to edit freaking configfiles.

.... you're missing one thing, however.

a couple of points that are missing, i believe, concerning
the "have to learn 100 different config files" argument are:

* if you're a Linux hobbyist, and you're experimenting
  with different distros, then yes, you're expected to
  know how different distros are "configured" and which
  files (or tools) are required to configure that distro(s).

* if you're a sysadmin working for a company, and you're
  a smart IT department, you're gonna choose a specific
  Linux distro and learn its configuration environment.

the "learn 100 different config files" argument is
immediately invalidated
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
Agnes' Law: Almost everything in life is easier to get into than out of.

It was Sun, 04 Jul 2004 16:46:45 +0000 when Michael Heiming wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> NotDashEscaped: You need GnuPG to verify this message
> 
> In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
>> It was Sun, 04 Jul 2004 11:54:07 -0400 when Michael W. Cocke wrote:
> 
>>> Blech!  The first step toward the windows registry.
> 
>> That wouldn't be so bad.
> 
> 
>                      Troll O Meter

Whatever. I honestly don't think that a registry thing would be bad. Have
a look at GConf, it's also a registry type of configuration thing. Sure,
it's not as hard to use and I agree that this is bad.

Alexander Skwar
-- 
panic("Foooooooood fight!");
	2.2.16 /usr/src/linux/drivers/scsi/aha1542.c

Dave Uhring wrote:

>> i think the OP was bored.
> 
> He should rewrite the Linux kernel and all the GNU utilities and other
> free daemons and servers to provide his own distro, one which suits the
> click and drool needs of Windoze addicts.

.... you beat me to that suggestion :)

> It looks like Darwin's hypotheses are starting to be proven in the IT
> world :-)

.... "starting to"??

>> heck, even on the m$ platform, they cant decide what
>> is "standard" ... m$ keeps changing their game.
> 
> That is a market driven monopoly, not a technological one.��I�trust�that
> Darwinism will prevail there also.

.... exactly. i've always considered their "languages" as
products, rather than as programming languages. (you'll
hear me saying that around the office, too :)
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
Sailing is fun, but scrubbing the decks is aardvark. - Heard on Noahs' ark

Alexander Skwar wrote:
> It was Sun, 04 Jul 2004 12:34:46 +0000 when Michael Heiming wrote:
>>What about RTFM? From 'man vi(m)':
>>
>>  -s {scriptin}
> 
> 
> You gotta be kidding me? So it's not enough to learn all the different
> configuration syntaxes, you also expect people to learn the "vi
> programming language"? And you really think that this isn't hard?

Oh, my, god.

Who was it that wanted to make people learn the XML language?  XML is 
just as hard as any programming language.

NR


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 100,000 Newsgroups - 19 Different Servers! =-----

Alexander Skwar <from@alexander.skwar.name> wrote:
> It was Sun, 04 Jul 2004 16:22:17 +0000 when mjt wrote:
> 
> > Alexander Skwar wrote:
> > 
> >> Well, complicate? What's so hard about
> >> 
> >> <variable>
> >> ????????value
> >> </variable>
> > 
> > ... it's too verbose, IMO
> 
> *LOL*
> 
> Okay, how about this then:
> 
>         <variable value="whatnot"/>
> 
> Still too verbose?

Yep. Which variable was that?  Didn't you mean

          <variable name="foo" value="whatnot"/>

and why don't you just write

     foo=whatnot

Or was it that the name field, if missing, takes the value "foo" by
default? And what values of "whatnot" are allowed?

I don't see that this is any "easier", and it looks a lot worse!


> OTOH: I don't think that a configuration file can be *too* verbose. Quite

It can be too incomprehensible. Short equals comprehensible.

> the opposite is IMO true: Most of the times, they are not verbose enough.

Peter

Alexander Skwar wrote:

>> Blech!��The�first�step�toward�the�windows�registry.
> 
> That wouldn't be so bad.

.... my troll-o-meter is twitching
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
Who does not trust enough will not be trusted.  - Lao Tsu

On Sun, 04 Jul 2004 18:41:09 +0200, Alexander Skwar staggered into the
Black Sun and said:
> It was Sun, 04 Jul 2004 16:22:17 +0000 when mjt wrote:
>> Alexander Skwar wrote:
>>> Well, complicate? What's so hard about
>>> <variable>
>>>    value
>>> </variable>
>> ... it's too verbose, IMO

AOL.  Especially when whatever DTD you're using for the XML file has a
lot of levels/layers to it, and the tag names are long.

> 	<variable value="whatnot"/>

Better.

> OTOH: I don't think that a configuration file can be *too* verbose.
> Quite the opposite is IMO true: Most of the times, they are not
> verbose enough.

The verbosity in the first XML example serves no purpose to a human
who's trying to parse the document.  The redundancy makes it easier for
a *computer* to parse it, that's all.  What many config files need is
something like the way it's done in the default Postfix and Samba config
files:

# foo describes the frobnick option and can be set to bar or baz.  Most
# users will want to set it to bar, unless they're running more than 50
# instances of the server.
foo = bar

....these comments are extremely useful, and I'm really surprised that
none of the people who're for XML config files have said anything about
putting basic option guides within <!-- ... --> tags or creating a
Config_Option_Description tag (which is *still* more verbose than the #
convention) or something.

Feh.  Give me a simple plaintext file with keyword=value pairs and
helpful comments in it any day.

-- 
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin /    mail: TRAP + SPAN don't belong
http://www.brainbench.com     /                Hire me! 
-----------------------------/ http://crow202.dyndns.org/~mhgraham/resume

Alexander Skwar wrote:

>> ... it's too verbose, IMO
> 
> LOL
> Okay, how about this then:
> ��������<variable value="whatnot"/>
> 
> Still too verbose?

.... yep.  why do you have to say "value"?
why do you have to have the < /> notation?
why do you have to quote the value?

let's take an easy one; how would this look
with your XML notation?

ShowLeftHideButton=false
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
"If affirmative action means what I just described,
what I'm for, then I'm for it." - George W. Bush

On Sun, 04 Jul 2004 18:22:04 +0200, Alexander Skwar
<from@alexander.skwar.name> wrote:

>It was Sun, 04 Jul 2004 11:54:07 -0400 when Michael W. Cocke wrote:
>
>> Blech!  The first step toward the windows registry.
>
>That wouldn't be so bad.
>
>> A few days ago I
>> got involved with an app that uses XML for it's config file.  What's
>> wrong with being able to edit a text config file with whatever editor
>> you prefer? 
>
>Nothing. That's why XML is nice - you're able to use whatever editor you
>prefer, in case you need to edit it manually.
>
>Alexander Skwar

No - first you have to figure out the obscure variation on XML that
the programmer used.  XML = eXtensible Markup Language.  It's
extensible.  Not standardized. As in "Is that a keyword or a value?"

Screw that idea.

Mike-
--
If you're not confused, you're not trying hard enough.
--
Please note - Due to the intense volume of spam, we have installed 
site-wide spam filters at catherders.com.  If email from you bounces,
try non-HTML, non-encoded, non-attachments,




----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

On Sun, 04 Jul 2004 18:57:07 +0200, Alexander Skwar
<from@alexander.skwar.name> wrote:

>It was Sun, 04 Jul 2004 16:46:45 +0000 when Michael Heiming wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> NotDashEscaped: You need GnuPG to verify this message
>> 
>> In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
>>> It was Sun, 04 Jul 2004 11:54:07 -0400 when Michael W. Cocke wrote:
>> 
>>>> Blech!  The first step toward the windows registry.
>> 
>>> That wouldn't be so bad.
>> 
>> 
>>                      Troll O Meter
>
>Whatever. I honestly don't think that a registry thing would be bad. Have
>a look at GConf, it's also a registry type of configuration thing. Sure,
>it's not as hard to use and I agree that this is bad.
>
>Alexander Skwar

Never had to fix a real windows crash, eh?  Now I think we can all see
where you're coming from with this half-assed idea.  Not just a linux
newbie but a _computer_ newbie...  Stop by again in a few years when
you understand what you're suggesting - we'll all have a good laugh.

Mike-

--
If you're not confused, you're not trying hard enough.
--
Please note - Due to the intense volume of spam, we have installed 
site-wide spam filters at catherders.com.  If email from you bounces,
try non-HTML, non-encoded, non-attachments,




----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

On Sun, 04 Jul 2004 16:59:57 +0000, mjt wrote:

> Dave Uhring wrote:

>> It looks like Darwin's hypotheses are starting to be proven in the IT
>> world :-)
> 
> ... "starting to"??

Since NT4 is no longer supported by MSFT many organizations will be
switching to Linux instead of WinServer 2003.  Their existing admins can
damn well learn how to work with what's in Linux rather than whining that
it's not like Windoze.

The ISP I do some work for tried for a month to get W2k3 installed on a
server; after about a week the OS ate itself and would not even boot.  He
moved the HDDs to my Slackware server and abandoned Windows for a server
OS.

Dave Uhring wrote:

>>> It looks like Darwin's hypotheses are starting to be proven in the IT
>>> world :-)
>> 
>> ... "starting to"??
> 
> Since NT4 is no longer supported by MSFT many organizations will be
> switching to Linux instead of WinServer 2003.��Their�existing�admins�can
> damn well learn how to work with what's in Linux rather than whining that
> it's not like Windoze.

.... well said. there's an old expression we had in the
military: "your previous duty station is always better
than where you're stationed now"

> The ISP I do some work for tried for a month to get W2k3 installed on a
> server; after about a week the OS ate itself and would not even boot.��He
> moved the HDDs to my Slackware server and abandoned Windows for a server
> OS.

reminds me of a funny story that many of you regulars
have read from me before: a friend of mine installed
winnt on a clean box and put it in a closet at work,
turned the switch on, logged in, and closed the door.

occasionally, he would open the door to check on the
system. in less than 30 days, winnt had BSD'd. this
box was NOT on a network and wasnt running any apps
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
Flon's Law: There is not now, and never will be, a language
in which it is the least bit difficult to write bad programs.

On Sun, 04 Jul 2004 18:32:27 +0000, mjt wrote:

> Dave Uhring wrote:

>> Since NT4 is no longer supported by MSFT many organizations will be
>> switching to Linux instead of WinServer 2003.��Their�existing�admins�can
>> damn well learn how to work with what's in Linux rather than whining that
>> it's not like Windoze.
> 
> ... well said. there's an old expression we had in the
> military: "your previous duty station is always better
> than where you're stationed now"

They can stop their whining, learn Linux administration while getting
plenty of help from here and other sources or learn how to ask "Would you
like to supersize that?"

> reminds me of a funny story that many of you regulars
> have read from me before: a friend of mine installed
> winnt on a clean box and put it in a closet at work,
> turned the switch on, logged in, and closed the door.
> 
> occasionally, he would open the door to check on the
> system. in less than 30 days, winnt had BSD'd. this
> box was NOT on a network and wasnt running any apps
> .

The guy I knew who claimed to put his NT4 box in a closet like that was
running a web server, IIS I suppose, and claimed it had been up for more
than a year.  He didn't give me the URL for that server so I couldn't
check it but either he was lying or MSFT really had a good point about
device drivers making their so-called OS unstable.

It was Sun, 04 Jul 2004 14:08:43 -0400 when Michael W. Cocke wrote:

> On Sun, 04 Jul 2004 18:57:07 +0200, Alexander Skwar
> <from@alexander.skwar.name> wrote:
> 
>>It was Sun, 04 Jul 2004 16:46:45 +0000 when Michael Heiming wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>> NotDashEscaped: You need GnuPG to verify this message
>>> 
>>> In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
>>>> It was Sun, 04 Jul 2004 11:54:07 -0400 when Michael W. Cocke wrote:
>>> 
>>>>> Blech!  The first step toward the windows registry.
>>> 
>>>> That wouldn't be so bad.
>>> 
>>> 
>>>                      Troll O Meter
>>
>>Whatever. I honestly don't think that a registry thing would be bad. Have
>>a look at GConf, it's also a registry type of configuration thing. Sure,
>>it's not as hard to use and I agree that this is bad.
>>
>>Alexander Skwar
> 
> Never had to fix a real windows crash, eh?

Yes, I had. Why?

>  Now I think we can all see
> where you're coming from with this half-assed idea.  

Okay, where am I coming from?

> Not just a linux
> newbie but a _computer_ newbie...  

*LOL* Yeah, right. Whatever. You're SO clueless.

> Stop by again in a few years when
> you understand what you're suggesting - we'll all have a good laugh.

I do understand what I'm suggesting. It's not my fault if you're too
stubborn to understand it.

Alexander Skwar
-- 
printk("What? oldfid != cii->c_fid. Call 911.\n");
        2.4.3 linux/fs/coda/cnode.c

It was Sun, 04 Jul 2004 17:57:22 +0000 when mjt wrote:

> Alexander Skwar wrote:
> 
>>> ... it's too verbose, IMO
>> 
>> LOL
>> Okay, how about this then:
>> ��������<variable value="whatnot"/>
>> 
>> Still too verbose?
> 
> ... yep.  why do you have to say "value"?

Because YOU wanted that.

> why do you have to have the < /> notation?

To find the end of the variable.

> why do you have to quote the value?

To tell the "system" what the value is. Not necessary in the "long"
notation.

> let's take an easy one; how would this look
> with your XML notation?
> 
> ShowLeftHideButton=false

You know the answer.

Alexander Skwar
-- 
panic("IRQ, you lose...");
	2.2.16 /usr/src/linux/arch/mips/sgi/kernel/indy_int.c

It was Sun, 04 Jul 2004 19:37:29 +0200 when P.T. Breuer wrote:

> It can be too incomprehensible. Short equals comprehensible.

Nope. Wrong.

Alexander Skwar
-- 
Working with Unix is like wrestling a worthy opponent.
Working with windows is like attacking a small whining 
child who is carrying a .38. 

Centuries ago, Nostradamus foresaw when Alexander Skwar <from@alexander.skwar.name> would write:
> It was Sun, 04 Jul 2004 12:24:50 +0200 when P.T. Breuer wrote:
>
>> Alexander Skwar <from@alexander.skwar.name> wrote:
>>> Jup, it's so easy to run vi on a hand of remote machines in a loop. I
>>> forgot.
>> 
>> It is. One makes a patch out of the before and after versions and applies it
>> to all.
>
> And what does patch/diff have to do with vi? Also, why can't you
> patch/diff your xml file?

diff output happens to be ex commands, which means you can pass them
at vi and hope they'll work...
-- 
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://cbbrowne.com/info/spiritual.html
"... While programs written for Sun machines won't run unmodified on
Intel-based computers, Sun said the two packages will be completely
compatible and that software companies can convert a program from one
system to the other through a fairly straightforward and automated
process known as ``recompiling.''" -- San Jose Mercury News

Alexander Skwar <from@alexander.skwar.name> wrote:
> It was Sun, 04 Jul 2004 19:37:29 +0200 when P.T. Breuer wrote:
> 
> > It can be too incomprehensible. Short equals comprehensible.
> 
> Nope. Wrong.

Yep. Right.

Peter

Alexander Skwar wrote:

>> ShowLeftHideButton=false
> 
> You know the answer.

.... i would like to see it, as others would, in black-n-white
how much better the above would be represented in XML
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
Imagination is more important than knowledge.  - Albert Einstein

Alexander Skwar wrote:

> It was Sun, 04 Jul 2004 17:57:22 +0000 when mjt wrote:
> 
>> Alexander Skwar wrote:
>> 
>>>> ... it's too verbose, IMO
>>> 
>>> LOL
>>> Okay, how about this then:
>>> ��������<variable value="whatnot"/>
>>> 
>>> Still too verbose?
>> 
>> ... yep.  why do you have to say "value"?
> 
> Because YOU wanted that.

nope, i want this:
ShowLeftHideButton=false

terse, yet succinct

> 
>> why do you have to have the < /> notation?
> 
> To find the end of the variable.

actually, i think that's incorrect. it's the
end of the DEFINITION and VALUE. my notation
(well, standard *Nix notation) makes it easy: EOL

>> why do you have to quote the value?
> 
> To tell the "system" what the value is. Not necessary in the "long"
> notation.

.... ah, now you've got TWO ways to represent it.
seems a bit of indecision there

..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
The number of UNIX installations has grown to 10, with more expected.
        -- The Unix Programmer's Manual, 2nd Edition, June 1972

P.T. Breuer wrote:

>> > It can be too incomprehensible. Short equals comprehensible.
>> 
>> Nope. Wrong.
> 
> Yep. Right.

..... what's right is what we have to do today.

and what we have to do today is NOT xml-ified config files
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
There is nothing wrong with writing ... as long as it
is done in private and you wash your hands afterward.

mjt wrote:

> ... i would like to see it, as others would, in black-n-white
> how much better the above would be represented in XML

I don't think the suggestion is that XML would be "better" in that sense,
but rather that it would be better if there were a common format
for config files, and XML seems a reasonable candidate for that.

If you want to see two very different config formats
compare texmf.cnf with xorg.conf, or either with sendmail.cf .

If config files were in a common format,
it would be possible to use a standard "wizard"
with standard options and help.



-- 
Timothy Murphy  
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland

<posted &     ***NOT***      mailed>


.... please dont set "Mail-Copies-To" in USENET"
most people will NOT do it - it's only a nuisance


Timothy Murphy wrote:
>> ... i would like to see it, as others would, in black-n-white
>> how much better the above would be represented in XML
> 
> I don't think the suggestion is that XML would be "better" in that sense,
> but rather that it would be better if there were a common format
> for config files, and XML seems a reasonable candidate for that.

.... i agree about the point of standardization.

with that said, back to the OP:

"if you arent a part of the solution, then you're a part of the problem"

..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
You'd better smile when they watch you, smile like you're in control.
                -- Smile, "Was (Not Was)"

Dances With Crows wrote:
> On Sun, 04 Jul 2004 18:41:09 +0200, Alexander Skwar staggered into the
> Black Sun and said:
> 
>>It was Sun, 04 Jul 2004 16:22:17 +0000 when mjt wrote:
>>
>>>Alexander Skwar wrote:
>>>
[snip]
> 
> The verbosity in the first XML example serves no purpose to a human
> who's trying to parse the document.  The redundancy makes it easier for
> a *computer* to parse it, that's all.

The point is to make it easier for a computer to parse, since that makes 
it easier to do a configurationutility/editor that can manage several 
different configfiles that complies to the same standard.

> What many config files need is
> something like the way it's done in the default Postfix and Samba config
> files:
> 
> # foo describes the frobnick option and can be set to bar or baz.  Most
> # users will want to set it to bar, unless they're running more than 50
> # instances of the server.
> foo = bar
> 
> ...these comments are extremely useful, and I'm really surprised that
> none of the people who're for XML config files have said anything about
> putting basic option guides within <!-- ... --> tags or creating a
> Config_Option_Description tag (which is *still* more verbose than the #
> convention) or something.

I did describe "option guides" in a post earlier, although i called them 
"<help>", also i described how to put in various options for variables, 
so there would be no question of what options should be used for a 
specific variable or it's syntax. That's what got me to start this 
thread in the first place. I was crossreferencing 3 doc-files and 3 
configurationfiles to come up with a simple option that just as well 
could be commented in the configfile in the first place.

I also made a reference to the Linux-kernels menuconfig utility that 
somewhat functions the way i think would be helpful.

Actually, i don't care if it would be XML or any other *standard*. I 
just put XML in the subject line because it's a known standard and it 
involves data-descriptions, which is the point of all this. For all i 
care it could look like structs in C, there's where they going to end up 
anyway.

> Feh.  Give me a simple plaintext file with keyword=value pairs and
> helpful comments in it any day.

Mats

It was Sun, 04 Jul 2004 20:30:15 +0000 when mjt wrote:

> <posted &     ***NOT***      mailed>
> 
> 
> ... please dont set "Mail-Copies-To" in USENET"
> most people will NOT do it - it's only a nuisance
> 
> 
> Timothy Murphy wrote:
>>> ... i would like to see it, as others would, in black-n-white
>>> how much better the above would be represented in XML
>> 
>> I don't think the suggestion is that XML would be "better" in that sense,
>> but rather that it would be better if there were a common format
>> for config files, and XML seems a reasonable candidate for that.
> 
> ... i agree about the point of standardization.

And that's what I wrote some other place in this thread. I couldn't care
less about the usage of XML. The important aspect would be to have a
standardized way/format. However, I think that the storage would best be
done in a XML format, as it is reasonable easy to read and use.

Alexander Skwar
-- 
panic("floppy: Port bolixed.");
	2.2.16 /usr/src/linux/include/asm-sparc/floppy.h

It was Sun, 04 Jul 2004 21:39:03 +0200 when P.T. Breuer wrote:

> Alexander Skwar <from@alexander.skwar.name> wrote:
>> It was Sun, 04 Jul 2004 19:37:29 +0200 when P.T. Breuer wrote:
>> 
>> > It can be too incomprehensible. Short equals comprehensible.
>> 
>> Nope. Wrong.
> 
> Yep. Right.

No, short is not comprehensible. Short/Long doesn't have ANYTHING at all
to do with how good/easy something can be understood.

So: "Short equals comprehensible" is wrong.

Alexander Skwar
-- 
/* vsprintf.c -- Lars Wirzenius & Linus Torvalds. */
 *
 * Wirzenius wrote this portably, Torvalds fucked it up :-)
 */	2.2.16 /usr/src/linux/lib/vsprintf.c

It was Sun, 04 Jul 2004 20:03:23 +0000 when mjt wrote:

> P.T. Breuer wrote:
> 
>>> > It can be too incomprehensible. Short equals comprehensible.
>>> 
>>> Nope. Wrong.
>> 
>> Yep. Right.
> 
> .... what's right is what we have to do today.

Ah, now I see. Your so-called "argument" is: We always did it that way.

Well. That's not an argument.

Alexander Skwar
-- 
Sind Sch�fchens Locken schwarz und braun, 
dann lehnt es am Elektrozaun. 
Und wenn es mit den �uglein rollt, 
dann will es sagen: "Zuviel Volt!"

Jacob Sparre Andersen <sparre@nbi.dk> wrote in message news:<pl7jtkkn4n.fsf@sparre.crs4.it>...
> > 
> > It would be a life in heaven for a poor administrator... :-)
> 
> Yes.  But XML isn't the answer.  The overhead is _much_ too large for
> most purposes.
> 
> Jacob
Perhaps the answer is to use a good administrator, rather than a poor one.
Regards... Dan.

On Sun, 04 Jul 2004 20:30:15 +0000, mjt wrote:

> ... i agree about the point of standardization.

I fail to see how that could be accomplished since responsibility for the
kernel resides with one person, BIND with another, Apache with still
another, ad infinitum.

Do you think there should be *one* Microsfot-like entity which specifies
some "standard"?  Those fsckwits cannot even standardize their own
so-called OSs.

Alexander Skwar <from@alexander.skwar.name> wrote:
> It was Sun, 04 Jul 2004 21:39:03 +0200 when P.T. Breuer wrote:
> 
> > Alexander Skwar <from@alexander.skwar.name> wrote:
> >> It was Sun, 04 Jul 2004 19:37:29 +0200 when P.T. Breuer wrote:
> >> 
> >> > It can be too incomprehensible. Short equals comprehensible.
> >> 
> >> Nope. Wrong.
> > 
> > Yep. Right.
> 
> No, short is not comprehensible. Short/Long doesn't have ANYTHING at all
> to do with how good/easy something can be understood.
> 
> So: "Short equals comprehensible" is wrong.

No it isn't.


Look - information is the abstraction of meaning from data. Data is
big. Information is small. More = meaningless.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
> It was Sun, 04 Jul 2004 21:39:03 +0200 when P.T. Breuer wrote:

>> Alexander Skwar <from@alexander.skwar.name> wrote:
>>> It was Sun, 04 Jul 2004 19:37:29 +0200 when P.T. Breuer wrote:
>>> 
>>> > It can be too incomprehensible. Short equals comprehensible.
>>> 
>>> Nope. Wrong.
>> 
>> Yep. Right.

> No, short is not comprehensible. Short/Long doesn't have ANYTHING at all
> to do with how good/easy something can be understood.

The XML crap posted in this thread was hardly readable at all,
there is no point of using it for configuring *nix. Wonder if you
have actually worked as *nix admin?

> So: "Short equals comprehensible" is wrong.

No it isn't, won't like to wade through your large and long
lined XML config files through a slow/crappy serial connection on
a system perhaps hundreds miles away from you.

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA6HbMAkPEju3Se5QRAg3CAKC7+vL1gPKxeii2kooRi7laqJ+3dACgwChu
Bi525s2TJMf/QlslLmXYACc=
=5OlD
-----END PGP SIGNATURE-----

Mats wrote:
> Jean-David Beyer wrote:
> 
>> Mats wrote:
>>
>>> Hi!
>>>
>>> Just wondering if there is any ongoing work to adapt some sort of
>>> XML-like standard for configurationfiles in Linux/UNIX/whatever?
>>>
>>> It would be really easy to write configuration tools if everybody could
>>>  agree with one standard. Now most of the "big" apps for Linux use
>>> their own format like Apache, PHP, sendmail, qmail, X and whatnot.
>>>
>>> It would be a life in heaven for a poor administrator... :-)
>>>
>> Not for the administrator where things were not working right; in 
>> particular, if the XML tools were not configured right. One more thing 
>> that must work before you can get started.
>>
>> At one time, Red Hat did a bunch of graphical tools that went by the 
>> name of _linixconfig_ or something like that. Now they were not in 
>> XML, but they were GUI. The GUI part was nice enough, BUT
>>
>> 1.) Not all things were in there, so you still had to know the names 
>> and how to use the things that were not done in linuxconfig.
>>
>> 2.) It had bugs that totally damaged a system (especially when 
>> configuring sendmail), so you had to disable it from doing sendmail.
>>
>> Red Hat tried for several releases to fix linuxconfig, but the release 
>> where they removed it from the distribution was the best fix of all.
> 
> 
> Part of thoose problems probably was due to the different standards of 
> various config files. As said in an earlier post those 
> multi-configurationtools are mostly hacks. They probably break when 
> another version of the same app comes along. Or the configtool has to be 
> updated everytime a app is updated.
> 
> The point of my view of configurationfiles is that the possible choises 
> in the configurationfile chips in the same file, in the description part 
> of the file. So when the app is updated the options in the 
> configurationutility is automagically updated.
> 
I just wonder what language one would pick for the language suitable for 
configuring /etc/mail/sendmail.cf on the one hand and /etc/hosts on the 
other. If the language has the power to manage sendmail, the person 
wishing to do /etc/hosts would be overwhelmed.

Sounds like Tom Steel's UNCOL all over again.

-- 
   .~.  Jean-David Beyer           Registered Linux User 85642.
   /V\                             Registered Machine   241939.
  /( )\ Shrewsbury, New Jersey     http://counter.li.org
  ^^-^^ 17:35:00 up 2 days, 6:30, 3 users, load average: 4.33, 4.13, 4.09

Mats <spamenot.mog.pettersson@telia.com> wrote:
> The point is to make it easier for a computer to parse, since that makes 

No that isn't the point. I don't care how difficult it is for a
computer to parse (and the computer doesn't either).

> it easier to do a configurationutility/editor that can manage several 

No it doesn't. Parse = parse. Where do you get the weird idea that
computers have any more or less "difficulty" doing one thing or
another? You can't mean that - what you must mean is that humans have
difficulty writing the parser. Uh uh - no they don't. Writing parsers
is peasy, and you only have to do it once, and you can use it on all
your config files that are written that way.

How many different formats of config file are there? Five? And 90% of
them are just "foo = bar". 

> different configfiles that complies to the same standard.

And I don't want to use a special editor - I want to do it myself!


> > # foo describes the frobnick option and can be set to bar or baz.  Most
> > # users will want to set it to bar, unless they're running more than 50
> > # instances of the server.
> > foo = bar
> > 
> > ...these comments are extremely useful, and I'm really surprised that
> > none of the people who're for XML config files have said anything about
> > putting basic option guides within <!-- ... --> tags or creating a
> > Config_Option_Description tag (which is *still* more verbose than the #
> > convention) or something.

You can put them inside the variable tags as PCDATA

  <variable name="foo" value="42">
      foo describes the frobnick option and can be set to bar or baz.  Most
      users will want to set it to bar, unless they're running more than 50
      instances of the server.
  </variable>

What is mising here is the horrible XML context that will be necessary.
Shudder.


> I did describe "option guides" in a post earlier, although i called them 
> "<help>", also i described how to put in various options for variables, 

Ooohhhh - you want 

  <variable name="foo" value="42">
      <help>
      foo describes the frobnick option and can be set to bar or baz.  Most
      users will want to set it to bar, unless they're running more than 50
      instances of the server.
      </help>
  </variable>

Or would you prefer ...

<stanza name="foostuff" version="1.1" author="A.N.Other">
  <variable name="foo" value="42"/>
  <help name="foo">
      foo describes the frobnick option and can be set to bar or baz.  Most
      users will want to set it to bar, unless they're running more than 50
      instances of the server.
  </help>
</stanza>


!!


> so there would be no question of what options should be used for a 
> specific variable or it's syntax.

There would be plenty of scope. Suppose the type is "String"? (limited
to 256 chars, maybe). Uh, sorry, I meant:

    <type name="String" restrictions="shorter than 256"/>


> Actually, i don't care if it would be XML or any other *standard*. I 

Then choose 5 particular standards and implement parsers for them.
Trivial.


Peter

The world rejoiced as Alexander Skwar <from@alexander.skwar.name> wrote:
> It was Sun, 04 Jul 2004 19:37:29 +0200 when P.T. Breuer wrote:
>
>> It can be too incomprehensible. Short equals comprehensible.
>
> Nope. Wrong.

Well, then I guess that the last few hundred years of developments in
mathematical notation were just plain "Wrong."

And the creation of new languages intended to allow algorithms to be
expressed in more compact ways than the "bad, old" verbose method of
assembly language must have been just plain "Wrong."

Or perhaps it wasn't they that were wrong...
-- 
(format nil "~S@~S" "cbbrowne" "acm.org")
http://cbbrowne.com/info/lsf.html
You can lead a horse to water, but if you can get him to swim on his
back, you've got something.

A long time ago, in a galaxy far, far away, Alexander Skwar <from@alexander.skwar.name> wrote:
> It was Sun, 04 Jul 2004 20:03:23 +0000 when mjt wrote:
>
>> P.T. Breuer wrote:
>> 
>>>> > It can be too incomprehensible. Short equals comprehensible.
>>>> 
>>>> Nope. Wrong.
>>> 
>>> Yep. Right.
>> 
>> .... what's right is what we have to do today.
>
> Ah, now I see. Your so-called "argument" is: We always did it that way.
>
> Well. That's not an argument.

Well, it happens to function, and you have not indicated any
particular merit provided by the change in notation that you are
suggesting.

What we know is that the systems function as they are.

Responsibility for proof of the merits of your proposed "new way"
rests on _you_.
-- 
output = ("cbbrowne" "@" "cbbrowne.com")
http://www.ntlug.org/~cbbrowne/nonrdbms.html
"Using Outlook Express  is the  moral equivalent  of putting on  spike
heels, fishnets, and a bustier, walking down to the corner of Virus St
and Trojan Ave, and shouting 'Hello, Sailor!'."  -- John W. Kennedy:

Alexander Skwar wrote:
> However, I think that the storage would best be
> done in a XML format, as it is reasonable easy to read and use.

That's personal opinion.  I'll bet, too, that in the opinions of the 
various software developers, the method they're currently using is "easy 
to read and use".  IOW, what's best to you isn't necessarily what's best 
in the mind of the people who wrote whatever programs you're tyring to 
configure.  And furthermore, what's best for BIND isn't necessarily 
what's best for Apache (for example).

Mats wrote:
> 
> I did describe "option guides" in a post earlier, although i called them 
> "<help>", also i described how to put in various options for variables, 
> so there would be no question of what options should be used for a 
> specific variable or it's syntax. That's what got me to start this 
> thread in the first place. I was crossreferencing 3 doc-files and 3 
> configurationfiles to come up with a simple option that just as well 
> could be commented in the configfile in the first place.

So why not just ask developers to better comment their sample config 
files?  AFAICT, all that is needed is one good sample config with 
comments explaining the various options.  No XML, no fancy parser, 
nothing beyond better documentation of the existing config files.

It was Sun, 04 Jul 2004 21:29:49 +0000 when Michael Heiming wrote:

> The XML crap posted in this thread was hardly readable at all,

No, it wasn't. It was complex. But have a look at hardly readable "plain"
text configuration files like the ones sendmail uses.

> there is no point of using it for configuring *nix. Wonder if you
> have actually worked as *nix admin?

These things are COMPLETELY unrelated.

>> So: "Short equals comprehensible" is wrong.
> 
> No it isn't, won't like to wade through your large and long
> lined XML config files through a slow/crappy serial connection on
> a system perhaps hundreds miles away from you.

What does that have to do with "comprehensible"? That's a completely
different problem. You do have the same with nicely verbose plain-text
config files like the ones from postfix or samba.

Alexander Skwar
-- 
We're Germans and we use Unix. That's a combination of two 
demographic groups known to have no sense of humour whatsoever.
  -- Hanno M�ller <sockpuppet@hanno.de> in de.comp.os.unix.programming 

On Mon, 05 Jul 2004 00:20:26 +0200, Alexander Skwar wrote:

> It was Sun, 04 Jul 2004 21:29:49 +0000 when Michael Heiming wrote:
> 
>> The XML crap posted in this thread was hardly readable at all,
> 
> No, it wasn't. It was complex. But have a look at hardly readable "plain"
> text configuration files like the ones sendmail uses.

/etc/mail/sendmail.cf is not the file which was configured initially, it
was sendmail.mc, a perfectly readable ASCII text file.  One wonders just
what your experience really is.

>> there is no point of using it for configuring *nix. Wonder if you
>> have actually worked as *nix admin?
> 
> These things are COMPLETELY unrelated.

Not at all.  You come off as some MCSE who wants to change everything in
Unix/POSIX to suit your limited experience.

As I mentioned previously, write your own kernel, substitutes for the GNU
utilities and other daemons and applications or STFU or just FOAD.

Do you want to supersize that?

On Sun, 04 Jul 2004 21:27:36 +0200, Alexander Skwar wrote:

> It was Sun, 04 Jul 2004 19:37:29 +0200 when P.T. Breuer wrote:
> 
>> It can be too incomprehensible. Short equals comprehensible.
> 
> Nope. Wrong.

OK, which of these is the more comprehensible:

The XML file I found:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE map SYSTEM 'http://java.sun.com/dtd/preferences.dtd'>

<map MAP_XML_VERSION="1.0">
 <entry key="RunGuiStart" value="false" />
 <entry key="AllowOtherHosts" value="true" />
 <entry key="httpsProxyAddr" value="127.0.0.1" />
 <entry key="httpsProxyPort" value="8081" />
 <entry key="proxyAddr" value="127.0.0.1" />
 <entry key="proxyPort" value="8080" />
 <entry key="useHttpsProxy" value="false" />
 <entry key="useProxy" value="false" />
</map>

Or the equivalent as plain text:

RunGuiStart=false
AllowOtherHosts=true
httpsProxyAddr=127.0.0.1
httpsProxyPort=8081
proxyAddr=127.0.0.1
proxyPort=8080
useHttpsProxy=false
useProxy=false

The 2nd. Also, which is easier to edit? Clearly the 2nd, I'm less likely
to make a mistake (such as missing an " or a space).

Too short can be incomprehensible:

1=0
2=1
3=127.0.0.1
4=8081
5=127.0.0.1
6=8080
7=0
8=0

But the same can be done with XML, of course.

-- 
Matt

Swap .invalid for .net to reply.


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 100,000 Newsgroups - 19 Different Servers! =-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
> It was Sun, 04 Jul 2004 21:29:49 +0000 when Michael Heiming wrote:

>> The XML crap posted in this thread was hardly readable at all,

> No, it wasn't. It was complex. But have a look at hardly readable "plain"
> text configuration files like the ones sendmail uses.

Like those:

define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl
define(`ALIAS_FILE', `/etc/aliases')dnl
define(`STATUS_FILE', `/etc/mail/statistics')dnl

Now that's pretty easy readable/understandable. If you mean
sendmail.cf, you should never touch it, if you have m4 and are
not 100% sure you know what you are doing. 

>> there is no point of using it for configuring *nix. Wonder if you
>> have actually worked as *nix admin?

> These things are COMPLETELY unrelated.

Like your lack of knowledge how Linux works seems to
be unrelated to the poor quality of your answers?

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA6IgnAkPEju3Se5QRAjlaAJ45E4Nv61E1YrgQTpDKksA4Jx8xIQCdHgpy
FwMc7PKCUEg0ZYrbLTNeCJY=
=nP8m
-----END PGP SIGNATURE-----

P.T. Breuer wrote:
> Mats <spamenot.mog.pettersson@telia.com> wrote:
> 
>>The point is to make it easier for a computer to parse, since that makes 
> 
> No that isn't the point. I don't care how difficult it is for a
> computer to parse (and the computer doesn't either).

Well, writing an algorithm that do regular expressions is more 
complicated than one just splitting variable=value pairs (for example), 
you also have the problem with tags that span over multiple lines, that 
i think is allowed in XML. That's why i want to have it more strict. If 
one f***k up with parsing you might get buffer overruns and whatever (at 
least if you do a utility in C).

> 
>>it easier to do a configurationutility/editor that can manage several 
> 
> 
> No it doesn't. Parse = parse. Where do you get the weird idea that
> computers have any more or less "difficulty" doing one thing or
> another? You can't mean that - what you must mean is that humans have
> difficulty writing the parser. Uh uh - no they don't. Writing parsers
> is peasy, and you only have to do it once, and you can use it on all
> your config files that are written that way.
> 
> How many different formats of config file are there? Five? And 90% of
> them are just "foo = bar".

If it's so easy, how come only Webmin does a descent job with it?

> 
>>different configfiles that complies to the same standard.
> 
> 
> And I don't want to use a special editor - I want to do it myself!

You still can.

[snip]

>>I did describe "option guides" in a post earlier, although i called them 
>>"<help>", also i described how to put in various options for variables, 
> 
> 
> Ooohhhh - you want 
> 
>   <variable name="foo" value="42">
>       <help>
>       foo describes the frobnick option and can be set to bar or baz.  Most
>       users will want to set it to bar, unless they're running more than 50
>       instances of the server.
>       </help>
>   </variable>
> 
> Or would you prefer ...
> 
> <stanza name="foostuff" version="1.1" author="A.N.Other">
>   <variable name="foo" value="42"/>
>   <help name="foo">
>       foo describes the frobnick option and can be set to bar or baz.  Most
>       users will want to set it to bar, unless they're running more than 50
>       instances of the server.
>   </help>
> </stanza>

Yes! The last one above is sort of what i wan't. but you should also ad 
the options in tags, so there is no doubt what values the variable can 
have, like (in the descriptor part):

<descriptor>
<variable name="Color" vartype="options">
  <help>You can only use Green and Red Color</help>
  <option value="Green">
  <option value="Red">
</variable>
</descriptor>

or if XML is not to be, maybe something like:

<descriptor>
  define_options Color:"Green","Red";
  define_help Color:"You can only use Green and Red Color";
</descriptor>

Now you know exactly what values is allowed to go in that variable and 
how they are spelled. In the actual data part, you have:

<configuration>
<variable name="Color" value="Red"/>
</configuration>

or

<configuration>
  Color="Red"
</configuration>

This is the part of the file you change if you edit it, f.ex you can 
manually alter the value of "Red" to "Green". If you're not shure if 
Yellow is an option, you look at the descriptor part. If it isn't there 
it's not allowed.

Ofcourse the keywords "variable" and "value" could be "var" and "val" 
instead to reduce bloat.

> 
>>so there would be no question of what options should be used for a 
>>specific variable or it's syntax.
> 
> 
> There would be plenty of scope. Suppose the type is "String"? (limited
> to 256 chars, maybe). Uh, sorry, I meant:
> 
>     <type name="String" restrictions="shorter than 256"/>
> 
> 
>>Actually, i don't care if it would be XML or any other *standard*. I 
> 
> 
> Then choose 5 particular standards and implement parsers for them.
> Trivial.

Yes, maybe. But the point is not just the parser. It's also to make 
shure that the options is properly explained for each variable, so you 
don't have to crossreference multiple files just to find out what other 
options is available.

Most of the times you know what option and value you wan't, it's just 
that you don't know (unless the configfile is very well commented) what 
options the programmer had in mind. By using version number you also 
make shure that the configfile matches the apps version and so doesn't 
use any depreciated options, and thanks to the descriptor field you're 
shure what options the variable can have, if they are static.

> 
> 
> Peter

Mats

On Sun, 04 Jul 2004 00:05:21 +0000, Mats wrote:

> Why not make it easier? If you have one standard you don't have to learn
> every strange syntax of every single configfile.
>
Yeah, great idea.  It can be wrapped up in a proprietary binary format
which for security reasons wouldn't be documented, although a crummy
GUI-only tool could be provided to edit it.

Ah wait, this all sounds depressingly familiar.  M$ remind us every day
this is a truly stupid idea.

I don't understand: just what is it about ASCII that you find so difficult?


B.
-- 
Opera is when a guy gets stabbed in the back and instead of
bleeding, sings. -Ed Gardner

On Sun, 04 Jul 2004 21:24:49 +0200, Alexander Skwar wrote:

[snips]
> 
> I do understand what I'm suggesting. It's not my fault if you're too
> stubborn to understand it.
>
Ok, so there you are with the usual smoking wreckage left after a Windows
crash and you can't even get the GUI-based registry editor up & running to
fix what caused the crash.

Now what?


B.
-- 
Never play strip tarot.

Christopher Browne wrote:

Not really a followup to Chistopher's latest comment,
but general remarks about this whole thread -


My thoughts regarding this whole discussion regarding
config file formats (esp. wrt. Linux) -

1 - There is no "big brother" in the Linux world which mandates any
particular format of config file.  Apps are written by different
developers and development oranizations.

2 - Trying to impose a standard externally will not work unless
there is *market pressure* or standardized OS "support" (and we've
all seen what happens with the Windoze registry).  So far, the only
arguments I've seen for a standard format have been for the
sake of convenience of the administrators.  In most corporate
hierarchies, administrators are considered lower than Whaleshit
so there is not likely to be any market pressure from corporate
higher-ups to help them out.  When given a choice of buying
product ABC which may be hard to configure and product
XYZ which my be easier to configure but costs twice as much,
which one do you think corporate higher-ups will choose?
I can just hear the conversation:
     Administrator:  "But boss, it's hard to adminster!"
     Boss:  "Stop whining and go do the job I hired you to do!"

3 - If, by some chance, a whole bunch of software vendors
got together and thought it might be a good idea to standardize
the config files, what would happen?  My cloudy crystal ball
says that someone would suggest forming a "standards
committee" with representation from the major software
vendors for that platform.  This committee would meet every
once in a while, or exchange Emails every once in a while and
might come up with a standard (which nobody really likes but
are resigned to) in maybe 2 years at the earliest, after they
had debated how many angels might dance on the head
of a pin.  And (gasp), they might reinvent the registry.
(In case you didn't notice, standards bodies are political,
not technical.  You are not likely to get a good technical
solution out of one.  You are likely to get the solution favored
by the corporation with the most "clout.")

4 - Even if such a standard were published, what would be the
*monetary incentive* for the software developers to change
what they already have (and which works) to comply with this new
standard? (This is a rehash of point 2 to a large extent).

5 - How often do the config files change once you've got them
right the first time?  The *format* of the file is less important
than understanding what the parameters mean and this is
different for every application.  Should we standardize the
nomenclature in the config files? (I can see yet another
standards body for that!  GACK.)  No formatting scheme
is going to help you when one of the parameters you must
set is named "YX24AB", thus

YX24AB=5
is no less cryptic than
<parameter: name="YX24AB", value="5"/>

Nevermind that the other competing APP (at double the price)
lists this as <parameter: name="TabStops", value="5"/>

(A ridiculous example, I'll admit, but I've seen as bad or worse
in some config files.)

So, if you had to change the config 6 months from
now, you would still have to Read The Fine Manual (RTFM)
anyway to see what that parameter meant.

Bottom Line:  This spit comes with the territory. If
you can make a financial case for changing the way
it is, you may stand a chance.  If you can't, I would
rather bet $5.00 on the snowball in hell.

- NPL

P.S. - Think about this.  If you *can* make a financial
case for it, and let's say you now have two (2) admnistrators
supporting X users.  Will your company now need only one (1) ?
Could the one they fire be you?




-- 
"It is impossible to make anything foolproof
because fools are so ingenious"
  - A. Bloch

Dave Uhring wrote:

>> ... i agree about the point of standardization.
> 
> I fail to see how that could be accomplished since responsibility for the
> kernel resides with one person, BIND with another, Apache with still
> another, ad infinitum.

i said i agreed with the point of standardization,
not that it's gonna happen. and i would be dead
against using XML

> Do you think there should be one Microsfot-like entity which specifies
> some "standard"?��Those�fsckwits�cannot�even�standardize�their�own
> so-called OSs.

....nope, i never said that.  if you do go to, say, OMG or
ISO or ANSI, it'll be ten years before we see a standard.

-- 
<<   http://michaeljtobler.homelinux.com/   >>
Once the toothpaste is out of the tube, it's hard to get it back in.
                -- H.R. Haldeman

On Mon, 05 Jul 2004 00:29:47 +0000, mjt wrote:

> Dave Uhring wrote:

>> I fail to see how that could be accomplished since responsibility for the
>> kernel resides with one person, BIND with another, Apache with still
>> another, ad infinitum.
> 
> i said i agreed with the point of standardization,
> not that it's gonna happen. and i would be dead
> against using XML

The silly attempt to standardize all configurations would require the
rewrite of everything.  Do you really think that is a good idea?  That
XML crap is not going to happen with Linux, the BSDs or real UNIX.

> ...nope, i never said that.  if you do go to, say, OMG or
> ISO or ANSI, it'll be ten years before we see a standard.

As long as software is free there ain't going to be such a thing.  Any
alternative to freedom is unacceptable and those would-be Linux admins
with MCSEs can either learn how to use vi and the man pages or go to work
flipping burgers.  Piss on them who want to change everything.

In comp.os.linux.misc, Mats uttered these immortal words:

>> > There are so much worthless-knowing with todays configuration-hell
>> > like: where is the bleeding config file for netatalk,
>>
>> They should all be in /etc if they're global or $HOME if it's a user's
> copy.
> 
> In a perfect world, maybe it would be there. But in this world it could be
> in /usr/etc, /usr/local/etc, /usr/local/share or whatever the author
> thought was best fit.

AFAIC /usr/local/etc is a valid place for software compiled by you which I
forgot to mention. If config files are installed elsewhere,
like /usr/share, they should by symlinked back to /etc. This is what Debian
do. This is what happens for phpMyAdmin where the config file belongs in
DocumentRoot (because it's a PHP file which the web app depends on) but may
need to be edited. That's another example I forgot about but as I said it
should be symlinked back to /etc as Debian do.
 
> See, if your distro doesn't contain the apps you wan't or versions of the
> apps you wan't, you have to download and install them yourself,

IMHO the correct way to do that is to create your own package which can
possibly be fed back into the distro you use after all Linux is a community
effort. You can then control where the config files go.

> most often 
> from source. Your distro author, the apps author and yorself, have often
> different opinions on where things should go. You can however alter this
> with a bit of work, but still.

That's what Debian do. For some reason the only config file (out of the
packages I use) that isn't in /etc or symlinked to /etc is GRUB's menu.lst.
I only noticed that because Mondo complained.
 
>> If your distro/daemon developer/app developer doesn't conform to that
>> then they need to be shot TBH.
> 
> Man, that would be quite a bunch of dead people. :-)

You'll find most developers *do* conform to the standards unlike Windows
developers and INI files. Now /that/ was a real nightmare.

>> > what options do "codepage"
>> > have in this version? All this info could exist in the same configfile.
>>
>> Can you explain that. To me it reads as "everything should be in one file
>> like the Windows registry".
> 
> No, not like that. The windows registry is almost as bad (or worse) than
> what we have now, in some cases anyway.

Amen.
 
> I think like, one app and one configurationfile (ofcourse there are some
> special cases).

That's how it is now.

> *Not* all configurations in one systemdatabase like the 
> windows registry.

Good. I hoped you hadn't completely taken leave of your senses.
 
> The configurationfile would contain two parts. One part is a
> description/template of the variable/value pairs, and one contain the
> actually configured values. The description/template part contains version
> number, variable/value pairs (nested/recursive if so required) with a
> label and an conected list of all possible values for that variable and
> type of the variable and (as icing on the cake) an explanation of the
> option/variable and it's values. The value part of the file is the actual
> configuration i.o.w the values that is set in the file.

That's how the Leafnode and Squid config files are laid out on my systems.
That would be a nightmare for something like Apache though with all of it's
options, most of which aren't used in a lot of cases. What's wrong with
having to read the docs in /usr/share/doc or on-line? That's where
documentation should be.

>> If I've read that as you intended that would require developers of
> different
>> daemons to talk to each other. If that's the case then nothing would get
>> done. If I wanted to write a daemon I'd have to wait for info from others
>> before I could start. Please tell me I read that wrongly.
> 
> I'm not quite shure what you mean with "talk to each other", but it's
> *not* like the windows registry, different apps still has different
> configurationfiles (no connection to other apps), only they conform to the
> same standard. If you make (*shrugs*) a horrid GUI configuration utility
> that can read/edit one of these "standard configurationfiles" it can
> automagically read/edit any other configurationfile that conforms to the
> same standard. To put it simply, it would be almost like an html form for
> a
> webbrowser, or in Lord Of  The Rings lingo: "One configuration utility to
> rule them all". :-P

<shrugs> I still don't see what's so hard about using vi and editing
"parameter=value" pairs with a book or website open but then it's getting
late, it's been a long day and I can't be arsed to argue anymore. I've had
my say. You're free to disagree but in this case you're wrong. ;-)

>> >> That's the Windows way [snip]
>> >
>> > No, thats the "let the computer do the work for you" way.
>>
>> Actually that's the "let MS do a lot of the thinking for you" way but
> that's
>> OT here.
> 
> Don't get MS credit for this. If you do like Webmin and if you are an
> admin that constantly have to alter configurationfiles and have more
> daemons and servers than two/three to worry about, you should *love* this.
> If you just running apache, php and sendmail you probably get by anyway.

I run Apache (and PHP. Quite complicated multi-domain setups too), Postfix
(and amavis-ng, procmail, spamassassin), INN, Leafnode, Squid, Bind, NFS,
Samba (yes, there are still Windows clients about), apt-proxy (now I'm
stretching the point :-p) and Exim (internal purposes only) and several
firewall installs with iptables. I find it very easy as do my colleagues.

I do use Webmin from time to time but, as I said, I make sure I know what
it's doing when it changes something. Webmin can be a good learning tool or
an easy tool to update config files when you know what it's doing. You must
know what it's doing though for the times when it's not available.

> Oops! Sorry about the private mail, pressed the wrong button. It was meant
> to the group.

I did wonder.

-- 
Andy.

Brian wrote:

> I don't understand: just what is it about ASCII that you find so difficult?

values 32 through 126.

NR


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 100,000 Newsgroups - 19 Different Servers! =-----

Brian wrote:

> Ok, so there you are with the usual smoking wreckage left after a Windows
> crash and you can't even get the GUI-based registry editor up & running to
> fix what caused the crash.
> 
> Now what?

.... install Linux
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
Romeo wasn't bilked in a day.
- Walt Kelly, "Ten Ever-Lovin' Blue-Eyed Years With Pogo"

Alexander Skwar wrote:

> I think that the storage would best be
> done in a XML format

.... that's opinion, of course
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
Steinbach's Guideline for Systems Programming:
        Never test for an error condition you don't know how to handle.

Alexander Skwar wrote:

>> .... what's right is what we have to do today.
> 
> Ah, now I see. Your so-called "argument" is: We always did it that way.
> 
> Well. That's not an argument.

.... no, that's not my argument - you've missed my
opinion in all my posts:

"if you expect all the various applications (the authors
 of course) to change the config style to meet a suggested
 standard, it isnt gonna happen."

first of all, there ISNT any sort of working standard
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
Over the years, I've developed my sense of deja vu so acutely that now
I can remember things that *have* happened before ...

Nick Landsberg wrote:

> My thoughts regarding this whole discussion regarding
> config file formats (esp. wrt. Linux) -
> 
> 1 - There is no "big brother" 

.... even in a world of big brother, such as m$, they
cant get their "standards" to last more than a couple
of years or so. that's one reason i quit using their
toolsets and libraries
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
Punning is the worst vice, and there's no vice versa.

Alexander Skwar <from@alexander.skwar.name> wrote:
> It was Sun, 04 Jul 2004 21:29:49 +0000 when Michael Heiming wrote:
> 
> > The XML crap posted in this thread was hardly readable at all,
> 
> No, it wasn't. It was complex. But have a look at hardly readable "plain"
> text configuration files like the ones sendmail uses.

?? Sendmail's sendmail.cf files are immensely well commented. I have
always (for at least ten years) edited them directly (and I have never
read or referred to the book, though I have it). Maybe you mean the .mc
files, which I DO find incomprehensible and undocumented ....

> What does that have to do with "comprehensible"? That's a completely
> different problem. You do have the same with nicely verbose plain-text
> config files like the ones from postfix or samba.

??

Peter

Mats <spamenot.mog.pettersson@telia.com> wrote:
> P.T. Breuer wrote:
> > Mats <spamenot.mog.pettersson@telia.com> wrote:
> > 
> >>The point is to make it easier for a computer to parse, since that makes 
> > 
> > No that isn't the point. I don't care how difficult it is for a
> > computer to parse (and the computer doesn't either).
> 
> Well, writing an algorithm that do regular expressions is more 

I don't understand what you mean. What have finite state machines (aka
"regular expressions") got to do with it? They are usually used to
define lexical tokenisers. Presumably you would always use the same
tokeniser no matter what your grammar or parser was.

> complicated than one just splitting variable=value pairs (for example), 

I don't understand what you mean.

> you also have the problem with tags that span over multiple lines, that 

There's no problem with that ... what's the difficulty supposed to be?

> i think is allowed in XML. That's why i want to have it more strict. If 
> one f***k up with parsing you might get buffer overruns and whatever (at 
> least if you do a utility in C).

I think from the amazingly ig'rant stuff above that you don't have any
knowledge of parsing or parsers. Well, I do. I am the author of a
compiler compiler, used worldwide for about 15 years (preccx). No
"buffer" is involved. Parsers are easy to generate by anyone who has
any training in computer science.

> >>it easier to do a configurationutility/editor that can manage several 
> > 
> > No it doesn't. Parse = parse. Where do you get the weird idea that
> > computers have any more or less "difficulty" doing one thing or
> > another? You can't mean that - what you must mean is that humans have
> > difficulty writing the parser. Uh uh - no they don't. Writing parsers
> > is peasy, and you only have to do it once, and you can use it on all
> > your config files that are written that way.
> > 
> > How many different formats of config file are there? Five? And 90% of
> > them are just "foo = bar".
> 
> If it's so easy, how come only Webmin does a descent job with it?

When did you stop beating your wife. What's "webmin"? Isn't that some
useless gui config utility for lusers? Why not just edit the files in
question yourself? 

As to why "only webmin", I don't know even why one should use it! But 
whatever parsing it does is the trivial part of its programming.

> > And I don't want to use a special editor - I want to do it myself!
> 
> You still can.

NO I can't - XML is unreadable for humans.

> > Ooohhhh - you want 
> > 
> >   <variable name="foo" value="42">
> >       <help>
> >       foo describes the frobnick option and can be set to bar or baz.  Most
> >       users will want to set it to bar, unless they're running more than 50
> >       instances of the server.
> >       </help>
> >   </variable>
> > 
> > Or would you prefer ...
> > 
> > <stanza name="foostuff" version="1.1" author="A.N.Other">
> >   <variable name="foo" value="42"/>
> >   <help name="foo">
> >       foo describes the frobnick option and can be set to bar or baz.  Most
> >       users will want to set it to bar, unless they're running more than 50
> >       instances of the server.
> >   </help>
> > </stanza>
> 
> Yes! The last one above is sort of what i wan't. but you should also ad 
> the options in tags, so there is no doubt what values the variable can 
> have, like (in the descriptor part):

You also want a unique identifier for each help text, as well as its
label. Maybe versioned. ANd then let's not forget the locale
designator.

> <descriptor>
> <variable name="Color" vartype="options">
>   <help>You can only use Green and Red Color</help>
>   <option value="Green">
>   <option value="Red">
> </variable>
> </descriptor>

You forgot the lang="C" bits! And you are messed up already because
what you wanted was to restrict the type of "variable"  to an enumerated
list, defined in the xml schema. 


> 
> or if XML is not to be, maybe something like:
> 
> <descriptor>
>   define_options Color:"Green","Red";
>   define_help Color:"You can only use Green and Red Color";
> </descriptor>
> 
> Now you know exactly what values is allowed to go in that variable and 
> how they are spelled. In the actual data part, you have:

If you use XML, you want to learn about enumerated types! The above
seems to  be part of a description section of the config file.

> <configuration>
> <variable name="Color" value="Red"/>
> </configuration>

Incomprehensible.

> <configuration>
>   Color="Red"
> </configuration>

Eh? Oh, non-xml.


> This is the part of the file you change if you edit it, f.ex you can 

Now you have description help and config in different parts!


> > Then choose 5 particular standards and implement parsers for them.
> > Trivial.
> 
> Yes, maybe. But the point is not just the parser. It's also to make 
> shure that the options is properly explained for each variable, so you 

The type would just be "string", and nobody would bother documenting
which string. Using XML does not enforce it.

Peter

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Skwar wrote:
> It was Sun, 04 Jul 2004 16:22:17 +0000 when mjt wrote:
>
>
>>Alexander Skwar wrote:
>>
>>
>>>Well, complicate? What's so hard about
>>>
>>><variable>
>>>        value
>>></variable>
>>
>>... it's too verbose, IMO
>
>
> *LOL*
>
> Okay, how about this then:
>
> 	<variable value="whatnot"/>
>
> Still too verbose?

Too verbose, /and/ too fragile.


- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA6MBIagVFX4UWr64RAs+TAKCrOKN24uwbHjmpWGiUSvukFQUb+wCeIlOI
k6rH/FzN9ZKqREkq8+aGOzQ=
=zqoh
-----END PGP SIGNATURE-----

The world rejoiced as Nick Landsberg <SPAMhukolauTRAP@SPAMworldnetTRAP.att.net> wrote:
> Christopher Browne wrote:
>
> Not really a followup to Chistopher's latest comment,
> but general remarks about this whole thread -
>
>
> My thoughts regarding this whole discussion regarding
> config file formats (esp. wrt. Linux) -
>
> 1 - There is no "big brother" in the Linux world which mandates any
> particular format of config file.  Apps are written by different
> developers and development oranizations.

Agreed.

I would go further and suggest that, in this context, "Linux" is
merely the name of an operating system kernel, whose configuration
file is typically found in /usr/src/linux/.config

NONE of the other stuff is "Linux software:"

 - Apache even runs on Windows;

 - MTAs are generally quite portable across Unix flavours, if not
   Windows;

 - GNOME and KDE are _NOT_ specific to Linux, but run across numerous
   flavours of Unix;

 - Even the "Linux packaging tools," rpm and dpkg, are NOT "for Linux"
   because they are getting observed increasingly often on platforms
   that are conspicuously NOT LINUX.  For instance, AIX version 5
   uses rpm to install additional software.

Many applications that are commonly run on Linux are developed by
people whose first priority goes to _Other Platforms_; some would-be
"Linux solution" means nothing to them when they don't necessarily
even support Linux.

> 2 - Trying to impose a standard externally will not work unless
> there is *market pressure* or standardized OS "support" (and we've
> all seen what happens with the Windoze registry).  So far, the only
> arguments I've seen for a standard format have been for the
> sake of convenience of the administrators.  In most corporate
> hierarchies, administrators are considered lower than Whaleshit
> so there is not likely to be any market pressure from corporate
> higher-ups to help them out.  When given a choice of buying
> product ABC which may be hard to configure and product
> XYZ which my be easier to configure but costs twice as much,
> which one do you think corporate higher-ups will choose?
> I can just hear the conversation:
>      Administrator:  "But boss, it's hard to adminster!"
>      Boss:  "Stop whining and go do the job I hired you to do!"

The other possibility is to pooh-pooh the "commercial administrators"
part, and to say:

 "But we need this stuff so that Granny can run Linux on her
  computer."

This is, of course, an even less useful idea, because "ignorant
end-users" are, if anything _less_ able to assert legitimate design
requirements than the upper level managers that get their modicum of
cluelessness from reading InfoWeek.

> 3 - If, by some chance, a whole bunch of software vendors got
> together and thought it might be a good idea to standardize the
> config files, what would happen?  My cloudy crystal ball says that
> someone would suggest forming a "standards committee" with
> representation from the major software vendors for that platform.
> This committee would meet every once in a while, or exchange Emails
> every once in a while and might come up with a standard (which
> nobody really likes but are resigned to) in maybe 2 years at the
> earliest, after they had debated how many angels might dance on the
> head of a pin.  And (gasp), they might reinvent the registry.  (In
> case you didn't notice, standards bodies are political, not
> technical.  You are not likely to get a good technical solution out
> of one.  You are likely to get the solution favored by the
> corporation with the most "clout.")

This is largely what happened with LSB.  LSB defined a set of
requirements for building a system on which one could install
LSB-compliant applications.

But nobody much cares, because it's a pretty worthless
lowest-common-denominator.  A distribution maker can't win big
contracts by building something that's generic; they "win big" when
they provide a system that is a lot _more_ functional than the LCD.

> 4 - Even if such a standard were published, what would be the
> *monetary incentive* for the software developers to change what they
> already have (and which works) to comply with this new standard? 
> (This is a rehash of point 2 to a large extent).

Here, I disagree.  The point isn't that of *monetary incentive*.

It is of convincing developers that it is such a good idea that they
should throw away what works now, require that everyone reimplement
all their configuration schemes, and replace it with the New Thing.

If the replacement "New Thing" is really conspicuously better than the
Old Thing, money isn't necessarily required as incentive.

What really *is* required is incentive for the massive amount of work
both at the project level, as well as on the part of every user of the
system that gets forced to put effort into the upgrade.

If it's trivial to write a tool to rewrite config files, then the
effort might not be too immense.  

But for someone with (say) a particularly complicated MTA
configuration, there may not be enough staff around to do the upgrade,
and multiply that by thousands of users, and you get a big hue and cry
that says: "Don't you dare to ******** touch the configuration
scheme!"

The problem is that cost of the "upgrade" isn't a burden on the
developers, but rather the existing user base.

> 5 - How often do the config files change once you've got them right
> the first time?  The *format* of the file is less important than
> understanding what the parameters mean and this is different for
> every application.  Should we standardize the nomenclature in the
> config files? (I can see yet another standards body for that!
> GACK.)  No formatting scheme is going to help you when one of the
> parameters you must set is named "YX24AB", thus

I haven't yet properly grokked what Apache config files _really_ mean,
as far as semantics are concerned, so that's always somewhat magic to
me.

When the problems are semantic, changing the grammar a bit isn't
terribly helpful.

> Bottom Line: This spit comes with the territory. If you can make a
> financial case for changing the way it is, you may stand a chance.
> If you can't, I would rather bet $5.00 on the snowball in hell.

Remember that the costs are distributed...  There are costs at the
"software project" level, but also at the _users'_ level.  Those that
have considerable infrastructure devoted to the current approach would
be seriously disrupted [e.g. - incur SUBSTANTIAL costs] if changes
were made.

> P.S. - Think about this.  If you *can* make a financial case for it,
> and let's say you now have two (2) admnistrators supporting X users.
> Will your company now need only one (1) ?  Could the one they fire
> be you?

This is what caused me amusement in the last round of "Microsoft
savings" commercials.  The only way I can see the upgrades saving
companies millions of dollars is if it allows them to lay off a whole
bunch of administrators, thereby throwing a bunch of MCSE's onto the
unemployment lines.
-- 
select 'cbbrowne' || '@' || 'ntlug.org';
http://cbbrowne.com/info/emacs.html
Rules of the  Evil Overlord #94. "When arresting  prisoners, my guards
will  not allow  them to  stop and  grab a  useless trinket  of purely
sentimental value." <http://www.eviloverlord.com/>

It was Mon, 05 Jul 2004 00:26:20 +0100 when Brian wrote:

> Ok, so there you are with the usual smoking wreckage left after a Windows
> crash and you can't even get the GUI-based registry editor up & running to
> fix what caused the crash.
> 
> Now what?

What, "now what"?  You're trying to tell, that a binary configuration file
is a bad idea? And maybe, that it's also a bad idea, to have (basically)
just one very huge file (instead of many small ones)?

Agreed. That's bad.

But what are you trying to tell? Who said that everything has to be as
badly implemented as the Windows registry?

Alexander Skwar
-- 
printk("CPU[%d]: Sending penguins to jail...",smp_processor_id());
        2.4.8 arch/sparc64/kernel/smp.c

It was Sun, 04 Jul 2004 22:43:20 -0400 when Lew Pitcher wrote:
> Alexander Skwar wrote:
>> It was Sun, 04 Jul 2004 16:22:17 +0000 when mjt wrote:
>>>Alexander Skwar wrote:

>> 	<variable value="whatnot"/>
>>
>> Still too verbose?
> 
> Too verbose,

So what?

> /and/ too fragile.

How so?

Alexander Skwar
-- 
die_if_kernel("Kernel gets FloatingPenguinUnit disabled trap", regs);
	2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c

It was Mon, 05 Jul 2004 01:28:13 +0000 when mjt wrote:

> Alexander Skwar wrote:
> 
>> I think that the storage would best be
>> done in a XML format
> 
> ... that's opinion, of course

What else to use? A MySQL database?

Alexander Skwar
-- 
downtime (noun.) The period during which a system is error-free and immune from user 

It was Sun, 04 Jul 2004 18:19:54 -0400 when John-Paul Stewart wrote:

> That's personal opinion.  I'll bet, too, that in the opinions of the 
> various software developers, the method they're currently using is "easy 
> to read and use".

Sure, and they're wrong. Have a look at the registry. It's *VERY* easy to
use and read, if the Windows API is used.

Alexander Skwar
-- 
panic("bad_user_access_length executed (not cool, dude)");
        2.0.38 /usr/src/linux/kernel/panic.c

It was Sun, 04 Jul 2004 23:36:49 +0100 when Matt wrote:

> OK, which of these is the more comprehensible:
> 
> The XML file I found:
> 
[...]
> 
> Or the equivalent as plain text:
> 
[...]
> 
> The 2nd.

No. Both are comprehensible.

> Also, which is easier to edit? 

The first.

> Too short can be incomprehensible:

Now, really? Tell that Christopher and all those other ignorants.

> But the same can be done with XML, of course.

Yes.

Alexander Skwar
-- 
panic("Tell me what a watchpoint trap is, and I'll then 
deal with such a beast...");
	2.2.16 /usr/src/linux/arch/arch/sparc/kernel/traps.c

It was Mon, 05 Jul 2004 04:11:11 +0200 when P.T. Breuer wrote:
> Alexander Skwar <from@alexander.skwar.name> wrote:

[ large files take a lot of bandwidth ]

>> What does that have to do with "comprehensible"? That's a completely
>> different problem. You do have the same with nicely verbose plain-text
>> config files like the ones from postfix or samba.
> 
> ??

See, I was as baffled as you.

Alexander Skwar
-- 
5bb(D!(D))D,)D5(D:(D?XP2@@0@@C,!~~SVPZj]XXd@e$2D@0D@F#KHKuK^C[u7aQ
e;HVZ~ye}Y'egx,7^{x|bZJxxympW1noNVbMg2)>L_Q,Fo8<Y#E'56?X?uruA#OXW"
8tH<}Q.YmQ_i8y5'05/)9-OJ4X4%o-PfPsSe3@=Gd5*x<0_\)-/]6y%g;RfE4:4'G!

It was Mon, 05 Jul 2004 01:28:29 +0000 when mjt wrote:

> 
> "if you expect all the various applications (the authors
>  of course) to change the config style to meet a suggested
>  standard, it isnt gonna happen."

I agree with that. However I disagree that this is a good opinion. I'm
just saying that it would be better if there were a standardized way. Yes,
this might mean "registry". However, if properly implemented (maybe, one
file for each "key"? of course plain text files with XML markup?), what's
so bad?

I know what's so bad: People like Michael would have to adopt to new
situations. That's got to be hurting if you lost all the flexibility (I'm
not talking about computer files here).

> first of all, there ISNT any sort of working standard

Yes, that's the problem. To the greatest part, I can agree with Nick in
news:Ka1Gc.60293$OB3.26657@bgtnsc05-news.ops.worldnet.att.net 

Alexander Skwar
-- 
/* After several hours of tedious analysis, the following hash
 * function won.  Do not mess with it... -DaveM
 */	2.2.16 /usr/src/linux/fs/buffer.c

It was Mon, 05 Jul 2004 00:18:34 +0100 when Brian wrote:

> Yeah, great idea.  It can be wrapped up in a proprietary binary format

Nobody said that.

> I don't understand: just what is it about ASCII that you find so difficult?

Same to you. XML is ASCII (or maybe UTF-8; but ASCII isn't good enough
anyway, if you wish to store non-ASCII chars like ����... And no, I
don't like the idea of qp encoding values in a file).

Alexander Skwar
-- 
Windows error message #4711:
"Intellimouse (optical) detected penguin patterns on mousepad. 
TCPA violation, reactivation required, 3 days grace period"

It was Sun, 04 Jul 2004 18:23:28 -0700 when Noah Roberts wrote:

> Brian wrote:
> 
>> I don't understand: just what is it about ASCII that you find so difficult?
> 
> values 32 through 126.

Where's the � in 32..126?

Alexander Skwar
-- 
Jegliche "Sicherheitsma�nahme", die von einem kompromittierten Rechner 
�berhaupt ausgeht, ist ungef�hr so, als w�rde man einer Leiche einen 
Helm aufsetzen. (Erhard Schwenk in dcsf)

Alexander Skwar <from@alexander.skwar.name> writes:

> this might mean "registry". However, if properly implemented (maybe, one
> file for each "key"? of course plain text files with XML markup?), what's
> so bad?

Actually, qmail is pretty much one file per key. Of course, it doesn't
have xml or anything comparable stuff in it. You can easily configure
it with grep, sed, and cat. Fortunately, it doesn't have any extra
fluff like xml wrappings. It follows the kiss school. Keep it small
and simple. It is that simple.

> I know what's so bad: People like Michael would have to adopt to new
> situations. That's got to be hurting if you lost all the flexibility (I'm
> not talking about computer files here).

Yes, that hurts. Having all that flexibility makes my job easier.
I can do it the way I find convenient, and not the way somebody
else finds it convenient.

Vilmos

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Skwar wrote:

> It was Sun, 04 Jul 2004 22:43:20 -0400 when Lew Pitcher wrote:
>
>>Alexander Skwar wrote:
>>
>>>It was Sun, 04 Jul 2004 16:22:17 +0000 when mjt wrote:
>>>
>>>>Alexander Skwar wrote:
>
>
>>>	<variable value="whatnot"/>
>>>
>>>Still too verbose?
>>
>>Too verbose,
>
>
> So what?
>
>
>>/and/ too fragile.
>
>
> How so?

<?xml version="1.O" encoding="US-ASCII" standalone="yes">
<my_control_document>
<variab1e value="whatnot"/>
<variable2 value="something">
<variab1e3 va1ue="whatnot'/>
</mycontroldocument>


See the errors? They are trivial enough that a human eye will miss some of them,
but a computer program won't. And, of course, the computer program will complain
that
a) this is badly formed XML, and cannot be read, and (perhaps)
b) that mycontroldocument is not defined and
   variable is not defined, and
   variable2 is not defined, and
   variable3 is not defined

Now, fix it.

- --
Lew Pitcher
IT Consultant, Enterprise Application Architecture,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFA6US/agVFX4UWr64RAstuAJ9vqpiKsYflj7UTVewAkYoMgRC/KACcCCTd
t6oI17aKEVHojoJ1vxvbqZ0=
=DBdV
-----END PGP SIGNATURE-----

In the last exciting episode, Lew Pitcher <Lew.Pitcher@td.com> wrote:
> Alexander Skwar wrote:
>
>> It was Sun, 04 Jul 2004 22:43:20 -0400 when Lew Pitcher wrote:
>>
>>>Alexander Skwar wrote:
>>>
>>>>It was Sun, 04 Jul 2004 16:22:17 +0000 when mjt wrote:
>>>>
>>>>>Alexander Skwar wrote:
>>
>>
>>>>	<variable value="whatnot"/>
>>>>
>>>>Still too verbose?
>>>
>>>Too verbose,
>>
>>
>> So what?
>>
>>
>>>/and/ too fragile.
>>
>>
>> How so?
>
> <?xml version="1.O" encoding="US-ASCII" standalone="yes">
> <my_control_document>
> <variab1e value="whatnot"/>
> <variable2 value="something">
> <variab1e3 va1ue="whatnot'/>
> </mycontroldocument>
>
>
> See the errors? They are trivial enough that a human eye will miss some of them,
> but a computer program won't. And, of course, the computer program will complain
> that
> a) this is badly formed XML, and cannot be read, and (perhaps)
> b) that mycontroldocument is not defined and
>    variable is not defined, and
>    variable2 is not defined, and
>    variable3 is not defined
>
> Now, fix it.

The essential problem is that any number of trivial changes transform
a valid XML document into something that is not a valid XML document.

XML is so fragile that any of the (I count 5) errors that you
introduced essentially _destroy_ the ability of the system to
recognize the information in the document.

In effect, XML is just as fragile, in the face of _any_ sort of
corruption problem, as is the Windows Registry.  In both cases, if
something comes in and destroys either:
 a) A few characters of the data, or
 b) A block of data,
the whole set of data is irretrievably destroyed.

By the way, Dave Raggett's "tidy" tool tells me that what you meant to
write was the following.  Was that right?  :-)

<?xml version="1.o" encoding="us-ascii" standalone="yes"?>
<my_control_document>
<variab1e value="whatnot" />
<variable2 value="something">
<variab1e3 va1ue="whatnot'/&gt; &lt;/mycontroldocument&gt;">
</variab1e3>
</variable2>
</my_control_document>

-- 
output = reverse("moc.enworbbc" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/linuxxian.html
"Linux:  the  operating  system  with  a CLUE...   Command  Line  User
Environment".  (seen in a posting in comp.software.testing)

Am Mon, 05 Jul 2004 08:08:33 -0400 schrieb Lew Pitcher:

> Alexander Skwar wrote:
> 
>> It was Sun, 04 Jul 2004 22:43:20 -0400 when Lew Pitcher wrote:
>>
>>>Alexander Skwar wrote:
>>>
>>>>It was Sun, 04 Jul 2004 16:22:17 +0000 when mjt wrote:
>>>>
>>>>>Alexander Skwar wrote:
>>
>>
>>>>	<variable value="whatnot"/>
>>>>
>>>>Still too verbose?
>>>
>>>Too verbose,
>>
>>
>> So what?
>>
>>
>>>/and/ too fragile.
>>
>>
>> How so?
> 
> <?xml version="1.O" encoding="US-ASCII" standalone="yes">
> <my_control_document>
> <variab1e value="whatnot"/>
> <variable2 value="something">
> <variab1e3 va1ue="whatnot'/>
> </mycontroldocument>
> 
> 
> See the errors? 

Well, some. Missing /, O instead of 0, ' instead of ", my_con.. instead
of mycon.... "variab1e" is no XML related error, though.

> They are trivial enough that a human eye will miss some of them,
> but a computer program won't. 

Well, yes. It's possible that these errors occur. But it's just as likely
that a user writes "var:val" instead of "var=val", or 
	var="some val'
instead of
	var="some val"
.. Besides, in the easier comprehensible, ie. longer, form of
	<variable1>
		val
	</variable1>
you at once skip the errors you had at variable2 and var3. 

Alexander Skwar
-- 
"Dass wir keine Sklavenarbeit mehr haben zeigt doch, dass der
Marktwirtschaft �berhaupt kein Raum zu ihrer Entfaltung gelassen
wird."				      -- Frank Paulsen in d.a.t.u

Am 5 Jul 2004 12:53:57 GMT schrieb Christopher Browne:

> The essential problem is that any number of trivial changes transform
> a valid XML document into something that is not a valid XML document.

Yes. And I actually like that. It (possibly) makes it easier to
spot/notice errors.

> XML is so fragile that any of the (I count 5) errors that you
> introduced essentially _destroy_ the ability of the system to
> recognize the information in the document.

Yes.

Alexander Skwar
-- 
panic("Tell me what a watchpoint trap is, and I'll then 
deal with such a beast...");
	2.2.16 /usr/src/linux/arch/arch/sparc/kernel/traps.c

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher Browne wrote:

> In the last exciting episode, Lew Pitcher <Lew.Pitcher@td.com> wrote:
>
>>Alexander Skwar wrote:
>>
>>
>>>It was Sun, 04 Jul 2004 22:43:20 -0400 when Lew Pitcher wrote:
>>>
>>>
>>>>Alexander Skwar wrote:
>>>>
>>>>
>>>>>It was Sun, 04 Jul 2004 16:22:17 +0000 when mjt wrote:
>>>>>
>>>>>
>>>>>>Alexander Skwar wrote:
>>>
>>>
>>>>>	<variable value="whatnot"/>
>>>>>
>>>>>Still too verbose?
>>>>
>>>>Too verbose,
>>>
>>>
>>>So what?
>>>
>>>
>>>
>>>>/and/ too fragile.
>>>
>>>
>>>How so?
>>
>><?xml version="1.O" encoding="US-ASCII" standalone="yes">
>><my_control_document>
>><variab1e value="whatnot"/>
>><variable2 value="something">
>><variab1e3 va1ue="whatnot'/>
>></mycontroldocument>
>>
>>
>>See the errors? They are trivial enough that a human eye will miss some of them,
>>but a computer program won't. And, of course, the computer program will complain
>>that
>>a) this is badly formed XML, and cannot be read, and (perhaps)
>>b) that mycontroldocument is not defined and
>>   variable is not defined, and
>>   variable2 is not defined, and
>>   variable3 is not defined
>>
>>Now, fix it.
>
>
> The essential problem is that any number of trivial changes transform
> a valid XML document into something that is not a valid XML document.

Exactly. It violates the KISS principle, and makes configuration difficult to
maintain without complex tools. As far as I'm concerned, /any/ Linux
configuration error should not involve complex data structures, and should be
fixable with no more than /bin/echo or /bin/cp

> XML is so fragile that any of the (I count 5) errors that you

I didn't count the errors

> introduced essentially _destroy_ the ability of the system to
> recognize the information in the document.
>
> In effect, XML is just as fragile, in the face of _any_ sort of
> corruption problem, as is the Windows Registry.  In both cases, if
> something comes in and destroys either:
>  a) A few characters of the data, or
>  b) A block of data,
> the whole set of data is irretrievably destroyed.
>
> By the way, Dave Raggett's "tidy" tool tells me that what you meant to
> write was the following.  Was that right?  :-)

No ;-)  (see the value in using a complex tool to correct simple errors?)

> <?xml version="1.o" encoding="us-ascii" standalone="yes"?>
Still wrong. The xml version must be "1.0" (that's DIGIT ONE, PERIOD, DIGIT
ZERO). The tidy tool makes it "1.o" (that's DIGIT ONE, PERIOD, LOWER CASE LETTER O)

> <my_control_document>
Should be
  <mycontroldocument>

> <variab1e value="whatnot" />
Should be
  <variable value="whatnot" />
with "variable" spelled with an "L", not a "1" (DIGIT ONE)

> <variable2 value="something">
Should be
  <variable2 value="something" />

> <variab1e3 va1ue="whatnot'/&gt; &lt;/mycontroldocument&gt;">
Should be
  <variable3 value="whocares" />
(Trick error: misspelled "variable3", misspelled "value", incorrect "value" value)

> </variab1e3>
No. Using Alexander Skwar's "empty" XML entity scheme, no terminating tag is
necessary

> </variable2>
No. Using Alexander Skwar's "empty" XML entity scheme, no terminating tag is
necessary

> </my_control_document>
No. The document /should have/ been a <mycontroldocument> entity, so the
terminating tag should be </mycontroldocument>


So, the poor sysadm (or the user who thinks that they are a sysadm) depends on
complex tools to maintain an XML config file, and if those tools cannot
anticipate the structure of the file, they cannot correct the errors. I'd much
rather depend on simple files with simple tools and an intellegent sysadm/user
than complex files with complex tools and an ignorant user.

It sounds like you feel the same ;-)

- --
Lew Pitcher
IT Consultant, Enterprise Application Architecture,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFA6VQ3agVFX4UWr64RAjLSAJ4h3VMMiAFK+NqafJ9d3uufOpKBkACglT6f
quSmWtA7WG8GCByja5rCASk=
=O49k
-----END PGP SIGNATURE-----

Am Mon, 05 Jul 2004 09:14:34 -0400 schrieb Lew Pitcher:
> Christopher Browne wrote:
>> In the last exciting episode, Lew Pitcher <Lew.Pitcher@td.com> wrote:
>>>Alexander Skwar wrote:
>>>>It was Sun, 04 Jul 2004 22:43:20 -0400 when Lew Pitcher wrote:
>>>>>Alexander Skwar wrote:
>>>>>>It was Sun, 04 Jul 2004 16:22:17 +0000 when mjt wrote:
>>>>>>>Alexander Skwar wrote:

>>><?xml version="1.O" encoding="US-ASCII" standalone="yes">
>>><my_control_document>
>>><variab1e value="whatnot"/>
>>><variable2 value="something">
>>><variab1e3 va1ue="whatnot'/>
>>></mycontroldocument>

>> The essential problem is that any number of trivial changes transform
>> a valid XML document into something that is not a valid XML document.
> 
> Exactly. 

Well, no. Since the system forces you to have a parseable cfg file, it's
less likely that errors slip in.

>> <?xml version="1.o" encoding="us-ascii" standalone="yes"?>
> Still wrong. The xml version must be "1.0" (that's DIGIT ONE, PERIOD, DIGIT
> ZERO). The tidy tool makes it "1.o" (that's DIGIT ONE, PERIOD, LOWER CASE LETTER O)

Yep.

>> <my_control_document>
> Should be
>   <mycontroldocument>

Well, my_con. is as good as mycon.

> 
>> <variab1e value="whatnot" />
> Should be
>   <variable value="whatnot" />
> with "variable" spelled with an "L", not a "1" (DIGIT ONE)

No XML error. Can happen as easily in plain-text cfg files.

>> <variable2 value="something">
> Should be
>   <variable2 value="something" />

Yep.

> 
>> <variab1e3 va1ue="whatnot'/&gt; &lt;/mycontroldocument&gt;">
> Should be
>   <variable3 value="whocares" />
> (Trick error: misspelled "variable3", 

Again: Not an XML error. Besides: Maybe variable2 was misspelled, since
var1 and var3 are spelled variab1e and variab1e3.

> misspelled "value", 

Oh, missed that one ;)

> incorrect "value" value)

No. Incorrectly terminated line. Valid value (at least 

>> </variab1e3>
> No. Using Alexander Skwar's "empty" XML entity scheme, no terminating tag is
> necessary

Yep. However, tidy was correct, since var2 didn't have a terminating tag
and since tags have to be closed someplace, it closed all the still open
tags before the end of the document.

>> </my_control_document>
> No. The document /should have/ been a <mycontroldocument> entity, so the
> terminating tag should be </mycontroldocument>

Well, close to impossible to tell without documentation. It could have
been a my_con. entity.

Alexander Skwar
-- 
Oxymoron: Microsoft Works

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Skwar wrote:

> Am Mon, 05 Jul 2004 09:14:34 -0400 schrieb Lew Pitcher:
>
>>Christopher Browne wrote:
>>
>>>In the last exciting episode, Lew Pitcher <Lew.Pitcher@td.com> wrote:
>>>
>>>>Alexander Skwar wrote:
>>>>
>>>>>It was Sun, 04 Jul 2004 22:43:20 -0400 when Lew Pitcher wrote:
>>>>>
>>>>>>Alexander Skwar wrote:
>>>>>>
>>>>>>>It was Sun, 04 Jul 2004 16:22:17 +0000 when mjt wrote:
>>>>>>>
>>>>>>>>Alexander Skwar wrote:
>
>
>>>><?xml version="1.O" encoding="US-ASCII" standalone="yes">
>>>><my_control_document>
>>>><variab1e value="whatnot"/>
>>>><variable2 value="something">
>>>><variab1e3 va1ue="whatnot'/>
>>>></mycontroldocument>
>
>
>>>The essential problem is that any number of trivial changes transform
>>>a valid XML document into something that is not a valid XML document.
>>
>>Exactly.
>
>
> Well, no. Since the system forces you to have a parseable cfg file, it's
> less likely that errors slip in.

Well, no. Since these are text files, they suffer from the frailties of both
'text' and 'files'. That is to say, they can be hand edited (and thus
invalidated), and they can be corrupted (by disk failure, rogue program, etc.).
In any case, errors /must/ be diagnosible and correctable from the commandline,
using simple tools.

It is apparent that you've never had to recover a crashed system before.

>
>>><?xml version="1.o" encoding="us-ascii" standalone="yes"?>
>>
>>Still wrong. The xml version must be "1.0" (that's DIGIT ONE, PERIOD, DIGIT
>>ZERO). The tidy tool makes it "1.o" (that's DIGIT ONE, PERIOD, LOWER CASE
LETTER O)
>
>
> Yep.
>
>
>>><my_control_document>
>>
>>Should be
>>  <mycontroldocument>
>
>
> Well, my_con. is as good as mycon.

Nope. They are two /different/ entities. So, an app looking for
mycontroldocument will /not/ be satisfied with my_control_document.

>
>>><variab1e value="whatnot" />
>>
>>Should be
>>  <variable value="whatnot" />
>>with "variable" spelled with an "L", not a "1" (DIGIT ONE)
>
>
> No XML error. Can happen as easily in plain-text cfg files.

True, but with XML, it's not as easily diagnosed or corrected.

>
>>><variable2 value="something">
>>
>>Should be
>>  <variable2 value="something" />
>
>
> Yep.
>
>
>>><variab1e3 va1ue="whatnot'/&gt; &lt;/mycontroldocument&gt;">
>>
>>Should be
>>  <variable3 value="whocares" />
>>(Trick error: misspelled "variable3",
>
>
> Again: Not an XML error. Besides: Maybe variable2 was misspelled, since
> var1 and var3 are spelled variab1e and variab1e3.

In XML, spelling counts. Especially with the XML 'overhead' components.

>
>>misspelled "value",
>
>
> Oh, missed that one ;)

But the app didn't, and crashed because of it. Since you missed it, you can't
fix it, can you?

>
>>incorrect "value" value)
>
>
> No.

No. The intended XML entity was
  <variable3 value="whocares" />
not
 <variable3 value="whatnot" />

> Incorrectly terminated line. Valid value (at least

Yes, but only because of the previous XML syntax error with improper quoting.

>>></variab1e3>
>>
>>No. Using Alexander Skwar's "empty" XML entity scheme, no terminating tag is
>>necessary
>
>
> Yep. However, tidy was correct, since var2 didn't have a terminating tag
> and since tags have to be closed someplace, it closed all the still open
> tags before the end of the document.

Doesn't matter. We're not talking about what 'tidy' did to clean up the XML,
we're talking about some app that needed the (valid) XML to be something else. I
don't care that 'tidy' took invalid XML and made it into valid XML, the XML is
/still/ incorrect, it's just 'valid' now.

>
>>></my_control_document>
>>
>>No. The document /should have/ been a <mycontroldocument> entity, so the
>>terminating tag should be </mycontroldocument>
>
>
> Well, close to impossible to tell without documentation. It could have
> been a my_con. entity.

Yes. But that's a significant part of the point. Simple config files are simple
to describe, and simple to fix. Complex config files are not simple to describe
or simple to fix, and most complex config file structures come with absolutely
/no/ documentation (probably because it's too complex a structure to properly
describe). Simple config files often do have documentation, because their
structure /is/ simple to document.

Now, if the app is broken because the config file is garbage, how do /you/ fix
the config file? If init(1) depended on an XML file, and it gets trashed, how do
/you/ fix the init XML file? How do you fix X when X won't start because it's
XML config file is trashed? How do you start that nice complex GUI XML editor
without X? When hand typing that 2000 line XML document into it's config file
(using nothing more than 'cat'), can you be /sure/ that you haven't made an
error like one of those in my example? How easy will it be for you to detect the
error and correct it?

There's a reason for KISS.


> Alexander Skwar


- --
Lew Pitcher
IT Consultant, Enterprise Application Architecture,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFA6WlPagVFX4UWr64RAssWAKDYCyxH56Spjik1gsl/l2smE7tMjwCfQ+tZ
5m1OQRG/CgRAviutZq2xSAI=
=AHll
-----END PGP SIGNATURE-----

On 2004-07-05, Alexander Skwar wrote:
> Am Mon, 05 Jul 2004 08:08:33 -0400 schrieb Lew Pitcher:
>> 
>> <?xml version="1.O" encoding="US-ASCII" standalone="yes">
>> <my_control_document>
>> <variab1e value="whatnot"/>
>> <variable2 value="something">
>> <variab1e3 va1ue="whatnot'/>
>> </mycontroldocument>
>> 
>> 
>> See the errors? 
>
> Well, some. Missing /, O instead of 0, ' instead of ", my_con.. instead
> of mycon.... "variab1e" is no XML related error, though.
>
>> They are trivial enough that a human eye will miss some of them,
>> but a computer program won't. 
>
> Well, yes. It's possible that these errors occur. But it's just as likely
> that a user writes "var:val" instead of "var=val", or 
> 	var="some val'
> instead of
> 	var="some val"

    Unlikely in most instances.

    Most of the configuration files in a Linux installation have the
    best documentation available anywhere.

-- 
    Chris F.A. Johnson                  http://cfaj.freeshell.org/shell
    ===================================================================
    My code (if any) in this post is copyright 2004, Chris F.A. Johnson
    and may be copied under the terms of the GNU General Public License

Alexander Skwar wrote:
> It was Sun, 04 Jul 2004 18:19:54 -0400 when John-Paul Stewart wrote:
> 
> 
>>That's personal opinion.  I'll bet, too, that in the opinions of the 
>>various software developers, the method they're currently using is "easy 
>>to read and use".
> 
> 
> Sure, and they're wrong. 

By definition of "opinion", there is no such thing as "right" and "wrong".

For you to say it is "wrong" for application developers to use config 
file formats that *you* don't like is incredibly arrogant on your part.

If this thread has taught you nothing else, it should at least show you 
that there are *tons* of people who find the current config files just 
fine.  They are not wrong because you say so, and you are not wrong 
because they say so.  It is simply a matter of personal preference where 
yours and theirs differ.

So, don't be surprised when developers don't change everything to suit 
your personal preference.

Lew Pitcher <Lew.Pitcher@td.com> writes:

> I'd much rather depend on simple files with simple tools and
> an intellegent sysadm/user than complex files with complex
> tools and an ignorant user.

This perfectly much sums up how I feel about having xml config files.

Also, I live by the following four guidelines, and "Lew's law" :-)
will be the perfect fifth one.

Make everything as simple as possible, but not simpler. -- Albert Einstein

Simplicity is prerequisite for reliability. -- Edsger W. Dijkstra

Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away -- Antoine de
Saint-Exupery

There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies. -- C.A.R Hoare

Vilmos

[I hate replying twice to the same post, but this point escaped me the 
first time.]

Alexander Skwar wrote:
> Have a look at the registry. It's *VERY* easy to
> use and read, if the Windows API is used.

Using the Windows API to edit the registry *requires* the use of a 
dedicated registry editing tool.  A mere text editor will not suffice as 
it doesn't use the Windows Registry API.  How, then, do you edit the 
registry *without* that specialized tool?  Answer:  you don't.  That's 
the problem with the scheme.

In the event of a catastrophic system failure you don't know ahead of 
time what tools will still be functioning and what won't.  Thus you need 
to be able to recover from that failure using any one of a number of 
general purpose tools, not some dedicated software that may not be 
available.

It was Mon, 05 Jul 2004 15:00:08 +0000 when Chris F.A. Johnson wrote:

>> Well, yes. It's possible that these errors occur. But it's just as likely
>> that a user writes "var:val" instead of "var=val", or 
>> 	var="some val'
>> instead of
>> 	var="some val"
> 
>     Unlikely in most instances.

Agreed. However, it's also unlinkely to mess up the var3 error he had.

Alexander Skwar
-- 
Zugegeben mein Computer ist etwas alt, aber 
ich mag das warme Gl�hen der R�hren...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vilmos Soti wrote:

> Lew Pitcher <Lew.Pitcher@td.com> writes:
>
>
>>I'd much rather depend on simple files with simple tools and
>>an intellegent sysadm/user than complex files with complex
>>tools and an ignorant user.
>
>
> This perfectly much sums up how I feel about having xml config files.
>
> Also, I live by the following four guidelines, and "Lew's law" :-)
> will be the perfect fifth one.

Why, thank you <grin>

My computer career spans over 27 years, on both mainframe and microcomputer, and
I've learned that lesson the hard way. It's no fun trying to remote repair a
system at 2:00AM, and the simpler everything is, the easier a sleepy programmer
can fix it. :-)

> Make everything as simple as possible, but not simpler. -- Albert Einstein
>
> Simplicity is prerequisite for reliability. -- Edsger W. Dijkstra
>
> Perfection is reached, not when there is no longer anything to add,
> but when there is no longer anything to take away -- Antoine de
> Saint-Exupery
>
> There are two ways of constructing a software design. One way is to
> make it so simple that there are obviously no deficiencies. And the
> other way is to make it so complicated that there are no obvious
> deficiencies. -- C.A.R Hoare
>
> Vilmos

Words to live by, in the computer world at least.


- --
Lew Pitcher
IT Consultant, Enterprise Application Architecture,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFA6XZnagVFX4UWr64RAhTkAJ96WzbxypSVbspdWKWGDngpDHPGSACgv5lS
t/xyXmVUTbXlvpvtzniDvvg=
=Od7Q
-----END PGP SIGNATURE-----

It was Mon, 05 Jul 2004 10:44:34 -0400 when Lew Pitcher wrote:
> Alexander Skwar wrote:
>> Am Mon, 05 Jul 2004 09:14:34 -0400 schrieb Lew Pitcher:
>>>Christopher Browne wrote:
>>>>In the last exciting episode, Lew Pitcher <Lew.Pitcher@td.com> wrote:
>>>>>Alexander Skwar wrote:
>>>>>>It was Sun, 04 Jul 2004 22:43:20 -0400 when Lew Pitcher wrote:
>>>>>>>Alexander Skwar wrote:
>>>>>>>>It was Sun, 04 Jul 2004 16:22:17 +0000 when mjt wrote:
>>>>>>>>>Alexander Skwar wrote:

>>>>><?xml version="1.O" encoding="US-ASCII" standalone="yes">
>>>>><my_control_document>
>>>>><variab1e value="whatnot"/>
>>>>><variable2 value="something">
>>>>><variab1e3 va1ue="whatnot'/>
>>>>></mycontroldocument>
>>
>>
>>>>The essential problem is that any number of trivial changes transform
>>>>a valid XML document into something that is not a valid XML document.
>>>
>>>Exactly.
>>
>>
>> Well, no. Since the system forces you to have a parseable cfg file, it's
>> less likely that errors slip in.
> 
> Well, no. Since these are text files, they suffer from the frailties of both
> 'text' and 'files'. That is to say, they can be hand edited (and thus
> invalidated), and they can be corrupted (by disk failure, rogue program, etc.).
> In any case, errors /must/ be diagnosible and correctable from the commandline,
> using simple tools.

Yes, that's what's nice about XML.

> It is apparent that you've never had to recover a crashed system before.

How's that apparent? The opposite is true.

>>>><?xml version="1.o" encoding="us-ascii" standalone="yes"?>
>>>
>>>Still wrong. The xml version must be "1.0" (that's DIGIT ONE, PERIOD, DIGIT
>>>ZERO). The tidy tool makes it "1.o" (that's DIGIT ONE, PERIOD, LOWER CASE
> LETTER O)
>>
>>
>> Yep.
>>
>>
>>>><my_control_document>
>>>
>>>Should be
>>>  <mycontroldocument>
>>
>>
>> Well, my_con. is as good as mycon.
> 
> Nope. They are two /different/ entities. 

Of course. I meant, that any answer would have been wrong. Either the
my_con at the beginning is wrong, or the mycon at the end is wrong.

>>>><variab1e value="whatnot" />
>>>
>>>Should be
>>>  <variable value="whatnot" />
>>>with "variable" spelled with an "L", not a "1" (DIGIT ONE)
>>
>>
>> No XML error. Can happen as easily in plain-text cfg files.
> 
> True, but with XML, it's not as easily diagnosed or corrected.

Wrong. A missspelling like this is as hard to diagnose in XML as it is in
plain text. Actually, with the long form (<var> .. </var>), it's easier.

>>>><variab1e3 va1ue="whatnot'/&gt; &lt;/mycontroldocument&gt;">
>>>
>>>Should be
>>>  <variable3 value="whocares" />
>>>(Trick error: misspelled "variable3",
>>
>>
>> Again: Not an XML error. Besides: Maybe variable2 was misspelled, since
>> var1 and var3 are spelled variab1e and variab1e3.
> 
> In XML, spelling counts. 

Well, but that doesn't have *anything* to do with XML. If the
configuration var is missspelled, it is wrong. In both systems.

> But the app didn't, and crashed because of it. Since you missed it, you can't
> fix it, can you?

Well, I can't fix that I don't know, that's true. I suppose that I would
have looked closer in reality. Dunno.

>>>incorrect "value" value)
>>
>> No.
> 
> No. The intended XML entity was
>   <variable3 value="whocares" />
> not
>   <variable3 value="whatnot"  />

Uh? Where's the difference?

> Doesn't matter. We're not talking about what 'tidy' did to clean up the XML,
> we're talking about some app that needed the (valid) XML to be something else. I
> don't care that 'tidy' took invalid XML and made it into valid XML, the XML is
> /still/ incorrect, it's just 'valid' now.

Well, if you specify wrong values, then it's your problem. Not related to
XML.

>>>></my_control_document>
>>>
>>>No. The document /should have/ been a <mycontroldocument> entity, so the
>>>terminating tag should be </mycontroldocument>
>>
>>
>> Well, close to impossible to tell without documentation. It could have
>> been a my_con. entity.
> 
> Yes. But that's a significant part of the point. Simple config files are simple
> to describe, and simple to fix. Complex config files are not simple to describe
> or simple to fix, and most complex config file structures come with absolutely
> /no/ documentation (probably because it's too complex a structure to properly
> describe). Simple config files often do have documentation, because their
> structure /is/ simple to document.
> 
> Now, if the app is broken because the config file is garbage, how do /you/ fix
> the config file? If init(1) depended on an XML file, and it gets trashed, how do
> /you/ fix the init XML file? 

Well, we already have this. Suppose your grub menu.lst is broken, how do
you fix this? Yep, you hit "e". Same if it were a XML file. Now, how do
you recover if inittab is broken? You do init=/bin/sh and start your
configuration tool (vi). How would you recover if inittab were a XML file?
start your manual configuration tool (vi) or the XML-cfgtool.

> How do you fix X when X won't start because it's
> XML config file is trashed? 

Unrelated to XML.

> How do you start that nice complex GUI XML editor
> without X? 

Nobody ever said that the ONLY way should be through a GUI. I honestly
agree that it would be bad. I'd think about something like

cfgtool --modify /some/key/value new_value

> When hand typing that 2000 line XML document into it's config file

Hand typing? What are you talking about? 

> (using nothing more than 'cat'), can you be /sure/ that you haven't made an
> error like one of those in my example? 

No, I cannot. However, in complex cfg files, you never can. Even w/o XML.

Alexander Skwar
-- 
/* James M doesn't say fuck enough. */
        2.4.3 linux/net/core/netfilter.c

It was Sun, 04 Jul 2004 22:26:51 -0700 when Vilmos Soti wrote:

> Alexander Skwar <from@alexander.skwar.name> writes:
> 
>> this might mean "registry". However, if properly implemented (maybe, one
>> file for each "key"? of course plain text files with XML markup?), what's
>> so bad?
> 
> Actually, qmail is pretty much one file per key. 

Yep.

> Of course, it doesn't
> have xml or anything comparable stuff in it. 

Of course not. 

> You can easily configure
> it with grep, sed, and cat. 

XML still allows you to do just that.

> Fortunately, 

Why?

> Yes, that hurts. Having all that flexibility makes my job easier.
> I can do it the way I find convenient, and not the way somebody
> else finds it convenient.

So I've got to do it the way you find it convenient? That's not flexible.

Alexander Skwar
-- 
*Catholism*: If shit happend I deserve it. *Voodoo*: Shit will hapen to
you. *Ateism*: Shit happens, but I don't care anyway. *Judaism*: Why does
shit always happen to us? *Mormonism*: If shit happens we still got enough
women to clean it up. *Moslemism*: If shit happens take a hostage.

Alexander Skwar wrote:

> Sure, and they're wrong. Have a look at the registry. It's VERY easy to
> use and read, if the Windows API is used.

..... and if it becomes corrupt, you're SOL. i know,
i've helped a friend try to recover - he ended up
having to reinstall the OS and all his software. the
m$ tech document that addressed the error message
identified the procedure for recovery: reinstall.
i wish i could remember the exact error message.

you'll never get my vote on a "registry" style of
configuration, simply because it's a screwed up
method of configuring a system.
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
For every problem there is one solution which
is simple, neat, and wrong. - H. L. Mencken

It was Mon, 05 Jul 2004 16:49:26 +0000 when mjt wrote:

> Alexander Skwar wrote:
> 
>> Sure, and they're wrong. Have a look at the registry. It's VERY easy to
>> use and read, if the Windows API is used.
> 
> .... and if it becomes corrupt, you're SOL.

Yes, I dislike the way it's implemented. IMO, it would be better to have
one file per key. That way, it's easy to extend (just add a new file or
directory) and dataloss isn't as extreme (if just one file "goes away",
that file is gone instead of the whole registry).

> you'll never get my vote on a "registry" style of
> configuration, simply because it's a screwed up
> method of configuring a system.

Well, no, it's not. The way it's implemented in Windows is tremendously
bad - as usual. I like the GConf way better.

Alexander Skwar
-- 
panic("sun_82072_fd_inb: How did I get here?");
        2.2.16 /usr/src/linux/include/asm-sparc/floppy.h

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In simple terms, XML contains a lot of confusing (to the eye) overhead that is
superfluous to the requirements of passing parameters to a program. This
overhead makes it difficult to detect errors by eye, thus making it difficult to
/correct/ errors.

Additionally, XML imposes a structure that, when broken, invalidates the entire
file. This means that the simplest error can not only cause a point problem, but
can cause a "catastrophic" failure of the application.

For instance, given the hypothetical application that requires three keyed
strings, with keys of "hostname", "IPAddress", and "domainname", we can have
either

  hostname=thishost
  domainname=thisdomain
  IPAddress=10.10.10.10

or we can have

  <?xml version="1.0" encoding="us-ascii" standalone="yes">
  <configuration>
  <hostname value="thishost"/>
  <domainname value="thisdomain"/>
  <IPAddress value="10.10.10.10"/>
  </configuration>

However, if something invalidates the hostname line, such that

  hostname~thishost
  domainname=thisdomain
  IPAddress=10.10.10.10

or

  <?xml version="1.0" encoding="us-ascii" standalone="yes">
  <configuration>
  <hostname value="thishost">
  <domainname value="thisdomain"/>
  <IPAddress value="10.10.10.10"/>
  </configuration>

then problems start. With the plain text file, the damage is localized to the
hostname key/value pair, and the application can continue using the other two
parameters.

However, with the XML file, the damage is systemic, and the application can
neither use, nor even /access/ *any* of the parameters.

That's what I meant by saying that XML is "fragile".


- --
Lew Pitcher
IT Consultant, Enterprise Application Architecture,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFA6Yx4agVFX4UWr64RAoxtAKDHyv1yolRDGayUxQMc+eZxOZyJqQCgkpJl
BcMuclYAE93N1ifldCHcIEo=
=Q/4k
-----END PGP SIGNATURE-----

It was Mon, 05 Jul 2004 11:38:41 -0400 when John-Paul Stewart wrote:

> [I hate replying twice to the same post, but this point escaped me the 
> first time.]
> 
> Alexander Skwar wrote:
>> Have a look at the registry. It's *VERY* easy to
>> use and read, if the Windows API is used.
> 
> Using the Windows API to edit the registry *requires* the use of a 
> dedicated registry editing tool.  

Yes, that's bad. A properly implemented registry shouldn't have that
problem. Hence XML.

> it doesn't use the Windows Registry API.  How, then, do you edit the 
> registry *without* that specialized tool?  Answer:  you don't.  That's 
> the problem with the scheme.

No, that's the problem with the implementation in Windows.

> time what tools will still be functioning and what won't.  Thus you need 
> to be able to recover from that failure using any one of a number of 
> general purpose tools, not some dedicated software that may not be 
> available.

Well, if the system were fully XML-registry, would it be so hard to
conceive, that there'd be a /sbin/cfg-tool?

Once more: The Windows implementation is bad. Extremely bad. I'm much more
thinking about GConf.

Alexander Skwar
-- 
Jegliche "Sicherheitsma�nahme", die von einem kompromittierten Rechner 
�berhaupt ausgeht, ist ungef�hr so, als w�rde man einer Leiche einen 
Helm aufsetzen. (Erhard Schwenk in dcsf)

It was Mon, 05 Jul 2004 11:05:52 -0400 when John-Paul Stewart wrote:

> Alexander Skwar wrote:
>> It was Sun, 04 Jul 2004 18:19:54 -0400 when John-Paul Stewart wrote:
>> 
>> 
>>>That's personal opinion.  I'll bet, too, that in the opinions of the 
>>>various software developers, the method they're currently using is "easy 
>>>to read and use".
>> 
>> 
>> Sure, and they're wrong. 
> 
> By definition of "opinion", there is no such thing as "right" and "wrong".

Yes.

> For you to say it is "wrong" for application developers to use config 
> file formats that *you* don't like is incredibly arrogant on your part.

No more arrogant thant the Anti fraction is.

> If this thread has taught you nothing else, it should at least show you 
> that there are *tons* of people who find the current config files just 
> fine.  

Yep, for no reason - besides "It's always been that way".

> So, don't be surprised when developers don't change everything to suit 
> your personal preference.

I am not. I don't see this turning to the good side any time soon. For
this, there would need to be pressure. And who'd exert this pressure and
why should an *independant* developer be interested in that pressure?

Alexander Skwar
-- 
die_if_kernel("Penguin instruction from Penguin mode??!?!", regs);
	2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c

Quoth Vilmos Soti <vilmos@vilmos.org>:
> Lew Pitcher <Lew.Pitcher@td.com> writes:
>
>> I'd much rather depend on simple files with simple tools and
>> an intellegent sysadm/user than complex files with complex
>> tools and an ignorant user.
>
> This perfectly much sums up how I feel about having xml config files.
>
> Also, I live by the following four guidelines, and "Lew's law" :-)
> will be the perfect fifth one.
>
> Make everything as simple as possible, but not simpler. -- Albert Einstein
>
> Simplicity is prerequisite for reliability. -- Edsger W. Dijkstra
>
> Perfection is reached, not when there is no longer anything to add,
> but when there is no longer anything to take away -- Antoine de
> Saint-Exupery
>
> There are two ways of constructing a software design. One way is to
> make it so simple that there are obviously no deficiencies. And the
> other way is to make it so complicated that there are no obvious
> deficiencies. -- C.A.R Hoare

XML sure seems to fit into the "so complicated that there are no
_obvious_ deficiencies" category.

Another problem worth mentioning is that "repairing" a broken XML
configuration is likely to be *WAY* more complicated than repairing
more pedestrian data formats.

I'll head back to the example:

<?xml version="1.O" encoding="US-ASCII" standalone="yes">
<my_control_document>
<variab1e value="whatnot"/>
<variable2 value="something">
<variab1e3 va1ue="whatnot'/>
</mycontroldocument>

We run this through "tidy's" best guesses of how to fix it, and get:

<?xml version="1.o" encoding="us-ascii" standalone="yes"?>
<my_control_document>
<variab1e value="whatnot" />
<variable2 value="something">
<variab1e3 va1ue="whatnot'/&gt; &lt;/mycontroldocument&gt;">
</variab1e3>
</variable2>
</my_control_document>

It's fairly evident to the human eye that this made things
substantially worse.  To be fair, that's NOT a failing of "tidy;" it
had some real garbage to deal with, and no realistic guidance.

Some other "fixer" might make different assumptions, and be forced
into a different set of errors.

But to those that like the idea, the fact that it is too complicated
to allow the deficiencies to be blatantly obvious nicely obscures
them...
-- 
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','cbbrowne.com').
http://www3.sympatico.ca/cbbrowne/xml.html
:FATAL ERROR -- ERROR IN USER

It was Mon, 05 Jul 2004 13:14:34 -0400 when Lew Pitcher wrote:

> In simple terms, XML contains a lot of confusing (to the eye) overhead that is
> superfluous to the requirements of passing parameters to a program. This
> overhead makes it difficult to detect errors by eye, thus making it difficult to
> /correct/ errors.

Well, I suppose it depends on how used you are to seeing/reading XML data.

> Additionally, XML imposes a structure that, when broken, invalidates the entire
> file.

Yes. As I said, I think that this is good, because it right away allows to
see that there IS an error.

> can cause a "catastrophic" failure of the application.

Yes.

> For instance, given the hypothetical application that requires three
> keyed strings, with keys of "hostname", "IPAddress", and "domainname",
> we can have either
> 
>   hostname=thishost
>   domainname=thisdomain
>   IPAddress=10.10.10.10
> 
> or we can have
> 
>   <?xml version="1.0" encoding="us-ascii" standalone="yes">
>   <configuration>
>   <hostname value="thishost"/>
>   <domainname value="thisdomain"/>
>   <IPAddress value="10.10.10.10"/>
>   </configuration>
> 
> However, if something invalidates the hostname line, such that
> 
>   hostname~thishost

lets take
    hostname~thishost

>   domainname=thisdomain
>   IPAddress=10.10.10.10
> 
> or
> 
>   <?xml version="1.0" encoding="us-ascii" standalone="yes">
>   <configuration>
>   <hostname value="thishost">
>   <domainname value="thisdomain"/>
>   <IPAddress value="10.10.10.10"/>
>   </configuration>
> 
> then problems start. 

Yes, you are right. In the plain text file, the error is just *MUCH* later
spotted as the application might run anyway. In the XML case, it just
cannot work, as the XML cannot be parsed.

Alexander Skwar
-- 
Mit wie vielen Sachen vergeuden wir unsere Zeit und fragen 
uns im nachhinein, wo sie denn geblieben ist...

Alexander Skwar <from@alexander.skwar.name> writes:

>> Actually, qmail is pretty much one file per key. 

....

>> You can easily configure
>> it with grep, sed, and cat. 
> 
> XML still allows you to do just that.

No, you are dead wrong. I used the qualifier "easily" (OK, I didn't
emphasize it) with a reason. Qmail uses one config option per line
where multiline is used (rcpthost, for example). On the other hand,
xml would use multiple lines for these things. Massage that with
sed/cat/grep. Maybe awk helps, but that definitely wouldn't qualify
as "easy".

>> Yes, that hurts. Having all that flexibility makes my job easier.
>> I can do it the way I find convenient, and not the way somebody
>> else finds it convenient.
> 
> So I've got to do it the way you find it convenient? That's not flexible.

This is not worthy to comment.

Vilmos

Alexander Skwar wrote:
> It was Mon, 05 Jul 2004 11:05:52 -0400 when John-Paul Stewart wrote:
> 
> 
>>Alexander Skwar wrote:
>>
>>>It was Sun, 04 Jul 2004 18:19:54 -0400 when John-Paul Stewart wrote:
>>>
>>>
>>>
>>>>That's personal opinion.  I'll bet, too, that in the opinions of the 
>>>>various software developers, the method they're currently using is "easy 
>>>>to read and use".
>>>
>>>
>>>Sure, and they're wrong. 
>>
>>By definition of "opinion", there is no such thing as "right" and "wrong".
> 
> Yes.

So your previous post was nonsense.

>>For you to say it is "wrong" for application developers to use config 
>>file formats that *you* don't like is incredibly arrogant on your part.
> 
> 
> No more arrogant thant the Anti fraction is.

It is quite a lot more arrogant.  You're telling *all* developers that 
they should do things your way.  Conversely, the individual developers 
are saying "this is what I think is best for this *one* application".
No developer has tried to force their preferred config file format on 
anybody else, which is precisely what you're doing.  It's a case of you 
trying to tell others what to do vs. everybody else doing what they 
personally see as best.

>>If this thread has taught you nothing else, it should at least show you 
>>that there are *tons* of people who find the current config files just 
>>fine.  
> 
> Yep, for no reason - besides "It's always been that way".

It's not for no reason.  Lots of people find the non-XML config files 
much easier to read than one with all the extraneous XML markup.  I 
understand that you disagree with this, but you're in the minority on 
that one, AFAICT from this thread.  Nearly everybody in this thread who 
has argued against your proposal finds the XML *less* readable than 
simple "name = value" lines.  That's why they're arguing against XML. 
Not for no reason; not because "it's always been that way"; but because 
the majority of people in this thread find the non-XML files easier to read.

As I mentioned elsewhere in this thread, I still don't see what your XML 
proposal brings to the table that couldn't be achieved with 
well-documented files of the format:

# foo can have the values a, b, or c.
foo = a

With sufficiently descriptive names instead of "foo", "a", "b", and "c", 
you have a clear explanation of what the variables are, what values they 
can have, and what each one does.  AIUI, your proposal is to include all 
of that information within the XML config files.  I don't see what the 
XML buys (other than an added layer of complexity) that you cannot 
obtain with good comments in the sample config.

Alexander Skwar wrote:
> 
> So I've got to do it the way you find it convenient? That's not flexible.

It's no less flexible than your assertion that we all do things the way 
*you* find convenient.

Alexander Skwar wrote:
> It was Mon, 05 Jul 2004 11:38:41 -0400 when John-Paul Stewart wrote:
>>
>>time what tools will still be functioning and what won't.  Thus you need 
>>to be able to recover from that failure using any one of a number of 
>>general purpose tools, not some dedicated software that may not be 
>>available.
> 
> 
> Well, if the system were fully XML-registry, would it be so hard to
> conceive, that there'd be a /sbin/cfg-tool?

It's not so hard to imagine that there'd be such a tool.  But there's no 
  way to be sure that /sbin/cfg-tool will still be working after the 
system crash.  The same can be said for vi, emacs, nano, or any other 
editor.  That's why I said that you need to be able to recover "using 
any *one of a number* of general purpose tools" (emphasis added).  It 
doesn't matter that you have GUI and command line configuration tools if 
*both* cease to function.  That's why people like the system that's in 
place now:  they can use *any* editor available or do some fancy 
trickery with cat and/or dd to edit files in a real pinch.  They don't 
need /sbin/cfg-tool or any other application; they can use whatever 
happens to be working.  Sure people may prefer to use emacs, but I'm 
sure everyone here would be able to get by with vi if that's all that 
was available.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Vilmos Soti <vilmos@vilmos.org> suggested:
> Alexander Skwar <from@alexander.skwar.name> writes:

[..]

>>> Yes, that hurts. Having all that flexibility makes my job easier.
>>> I can do it the way I find convenient, and not the way somebody
>>> else finds it convenient.
>> 
>> So I've got to do it the way you find it convenient? That's not flexible.

> This is not worthy to comment.

Yep, but then from the lengthy thread the person you responded
just looks like a simple wintroll, insisting on his ideas of some
broken XML registry, while simply not understanding how *nix
works. Perhaps I should simply kill-file him?
;)

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA6ZqkAkPEju3Se5QRAjAUAKDK28PbXHpOmmai3ctjW6yU96GmFgCgqK+K
9ovVLZIlOUsT+hudZTIjPgg=
=y9lI
-----END PGP SIGNATURE-----

This afternoon, Alexander Skwar wrote:
> Well, no, it's not. The way it's implemented in Windows is tremendously
> bad - as usual. I like the GConf way better.

I may be wrong as I don't know the details of the GConf design, but
AFAIK it is still a single point of failure, right? That's the main
reason why KDE has never had something like this IIRC.

Anyways, I've just found an interesting project on SF:
http://registry.sf.net.

         Roberto.

-- 
\---- roberto selbach teixeira --- rst@iname.com
 \------------------- http://techtux.com/rst.php
  \---------------------------- Curitiba, Brasil

It was Mon, 05 Jul 2004 18:15:01 +0000 when Michael Heiming wrote:

> Yep, but then from the lengthy thread the person you responded
> just looks like a simple wintroll,

Do your homework, boy.

> insisting on his ideas of some
> broken XML registry, while simply not understanding how *nix
> works. 

Oh, it's supposed to be inflexible because of the "reason" that it's
always been done that way?

I don't think so. But if you say so, it's got to be right - RIGHT?

Alexander Skwar
-- 
printk("Cool stuff's happening!\n")
        2.4.3 linux/fs/jffs/intrep.c

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Alexander Skwar <from@alexander.skwar.name> suggested:
> It was Mon, 05 Jul 2004 18:15:01 +0000 when Michael Heiming wrote:

>> Yep, but then from the lengthy thread the person you responded
>> just looks like a simple wintroll,

> Do your homework, boy.

LOL...

Thx and welcome to my kill-file.
;)

-- 
Michael Heiming - RHCE (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA6aJOAkPEju3Se5QRAvbHAJ0a0Xu0WjzS6hqbDomPBY98vX6rQACgrUVD
mgrK0xDWCcqUB5z7jq5jrbc=
=0l6V
-----END PGP SIGNATURE-----

It was Mon, 05 Jul 2004 15:31:34 -0300 when Roberto Selbach Teixeira
wrote:

> This afternoon, Alexander Skwar wrote:
>> Well, no, it's not. The way it's implemented in Windows is tremendously
>> bad - as usual. I like the GConf way better.
> 
> I may be wrong as I don't know the details of the GConf design, but
> AFAIK it is still a single point of failure, right?

What do you mean by single point of failure? With GConf, you've got a
directory structure /etc/gconf:

[alexander@server ~/.pan]$ ls -al /etc/gconf
insgesamt 24
drwxr-xr-x   7 root root   87 Jun 15 08:19 ./
drwx--x--x  88 root adm  8192 Jul  5 18:17 ../
drwxr-xr-x   2 root root   17 Apr  9 10:48 1/
drwxr-xr-x   2 root root   17 Jun 18 23:34 2/
drwxr-xr-x   6 root root   58 Jun 19 00:04 gconf.xml.defaults/
drwxr-xr-x   2 root root    6 Jun 15 08:19 gconf.xml.mandatory/
drwxr-xr-x   2 root root 8192 Jun 19 00:04 schemas/

Underneath that direcoty you've got the default values for the different
apps. Those files are XML and are thus editable by hand (vi). However,
that's not the way it's supposed to be done. You'd rather use "gconftool-2":

[alexander@server /etc/gconf/gconf.xml.defaults/desktop/gnome/sound]$ gconftool-2 --get /desktop/gnome/sound/enable_esd
true

> Anyways, I've just found an interesting project on SF:
> http://registry.sf.net.

Heh ;) There's GOT to be something about the word "registry" here - at
first visit, my Firefox crashed right away *G*

Yep, looks indeed interesting as it seems to go further than GConf.

Alexander Skwar
-- 
Sind Sch�fchens Locken schwarz und braun, 
dann lehnt es am Elektrozaun. 
Und wenn es mit den �uglein rollt, 
dann will es sagen: "Zuviel Volt!"

It was Mon, 05 Jul 2004 14:12:01 -0400 when John-Paul Stewart wrote:

> Alexander Skwar wrote:
>> It was Mon, 05 Jul 2004 11:38:41 -0400 when John-Paul Stewart wrote:
>>>
>>>time what tools will still be functioning and what won't.  Thus you need 
>>>to be able to recover from that failure using any one of a number of 
>>>general purpose tools, not some dedicated software that may not be 
>>>available.
>> 
>> 
>> Well, if the system were fully XML-registry, would it be so hard to
>> conceive, that there'd be a /sbin/cfg-tool?
> 
> It's not so hard to imagine that there'd be such a tool.  But there's no 
>   way to be sure that /sbin/cfg-tool will still be working after the 
> system crash.

Of course not.

>  The same can be said for vi, emacs, nano, or any other 
> editor.

Yep.

>  That's why I said that you need to be able to recover "using 
> any *one of a number* of general purpose tools" (emphasis added).

Ah, yes, I agree. The more, the better. Although it's "starting" to get
boring: With a plain text based configuration file format, which would not
have to be XML, you'd still be able to use vi and such.

>  It 
> doesn't matter that you have GUI and command line configuration tools if 
> *both* cease to function. 

Agreed.

> That's why people like the system that's in 
> place now:  they can use *any* editor available or do some fancy 
> trickery with cat and/or dd to edit files in a real pinch.

Yes, I never disagreed that a text based cfg format would have to be a
must.


> happens to be working.  Sure people may prefer to use emacs, but I'm 

Really? ;)

> sure everyone here would be able to get by with vi if that's all that 
> was available.

You're saying this in such a way, as if vi were bad. Well, I've got to
disagree again. :)

Alexander Skwar
-- 
Wusstest Du schon, das "slrn" das Gerauesch ist, das Hamster macht,
wenn er einen Frottee Agent auswuergt? 
  [Joachim Kromm in tot]

It was Mon, 05 Jul 2004 18:47:43 +0000 when Michael Heiming wrote:

> LOL...

Idiots tend to laugh all the time. Don't they, Michael?

Alexander Skwar
-- 
Mit wie vielen Sachen vergeuden wir unsere Zeit und fragen 
uns im nachhinein, wo sie denn geblieben ist...

On Mon, 05 Jul 2004 14:12:01 -0400, John-Paul Stewart wrote:

> Sure people may prefer to use emacs, but I'm 
> sure everyone here would be able to get by with vi if that's all that 
> was available.

Sometimes not even vi is available.  I once rebuilt /etc/fstab on a Tru64
system using only cat.

I'm sure this winidiot could do that if that file were some XML bullshit.

On Mon, 05 Jul 2004 21:10:27 +0200, Alexander Skwar wrote:

> It was Mon, 05 Jul 2004 18:47:43 +0000 when Michael Heiming wrote:
> 
>> LOL...
> 
> Idiots tend to laugh all the time. Don't they, Michael?

You really are a moron, aren't you?  Michael has already plonked you as I
now have also.

On Mon, 05 Jul 2004 19:45:06 +0200, Alexander Skwar staggered into the
Black Sun and said:
> It was Mon, 05 Jul 2004 13:14:34 -0400 when Lew Pitcher wrote:
>> Additionally, XML imposes a structure that, when broken, invalidates
>> the entire file.
> Yes. As I said, I think that this is good, because it right away
> allows to see that there IS an error.

Just think about what this would cause in the real world:

(enter car, insert key into ignition, turn key)
ERROR: left front turn signal bulb burned out.  Disabling engine.

....there needs to be a distinction between minor problems and major
ones.  Since the XML standard says that an XML file with even one
slightly malformed tag is unparseable, robustness suffers and all errors
are treated as major.  It's insanely easy to screw up an XML file in
this way if you edit it by hand in vim--I've done that many times, and
only found my errors with the aid of the "xmlparse" utility.

> Yes, you are right. In the plain text file, the error is just *MUCH*
> later spotted as the application might run anyway. In the XML case, it
> just cannot work, as the XML cannot be parsed.

The idea "complete failure is better than something that works
partially" is correct for a small minority of applications--mostly
server apps and the kernel.  For desktop apps and 99% of the things that
Joe User wants to run, it's the wrong approach.

-- 
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin /    mail: TRAP + SPAN don't belong
http://www.brainbench.com     /                Hire me! 
-----------------------------/ http://crow202.dyndns.org/~mhgraham/resume

Michael Heiming wrote:

> Yep, but then from the lengthy thread the person you responded
> just looks like a simple wintroll, insisting on his ideas of some
> broken XML registry, while simply not understanding how *nix
> works.

Isn't this what GConf is?

NR


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 100,000 Newsgroups - 19 Different Servers! =-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Noah Roberts wrote:

> Michael Heiming wrote:
>
>> Yep, but then from the lengthy thread the person you responded
>> just looks like a simple wintroll, insisting on his ideas of some
>> broken XML registry, while simply not understanding how *nix
>> works.
>
>
> Isn't this what GConf is?

Yep.

So, I hope you don't depend on Gconf for mission-critical applications.


- --
Lew Pitcher
IT Consultant, Enterprise Application Architecture,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFA6a8vagVFX4UWr64RAupsAJ44HpAppv+yEmlYL7BEQCBhUD5VpwCgr95p
09TYBIHOD0GAoxamxzoN+Zw=
=Ok1q
-----END PGP SIGNATURE-----

Alexander Skwar wrote:
> It was Mon, 05 Jul 2004 14:12:01 -0400 when John-Paul Stewart wrote:
> 
>>Sure people may prefer to use emacs, but I'm 
>>sure everyone here would be able to get by with vi if that's all that 
>>was available.
> 
> 
> You're saying this in such a way, as if vi were bad. 

Not at all.  (I'm a vim user myself.)  It's just an example of using 
whatever is at hand in an emergency.  You cannot count on having *anything*.

Dave Uhring wrote:
> On Mon, 05 Jul 2004 14:12:01 -0400, John-Paul Stewart wrote:
> 
> 
>>Sure people may prefer to use emacs, but I'm 
>>sure everyone here would be able to get by with vi if that's all that 
>>was available.
> 
> 
> Sometimes not even vi is available.  I once rebuilt /etc/fstab on a Tru64
> system using only cat.

Sure that can be done and is a good thing about current setups.  But 
somehow I think the point we're trying to make is going right over the 
head of its intended audience....  (Those who don't get it will never 
understand until they have to do it themselves.)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Noah Roberts <nroberts@dontemailme.invalid> suggested:
> Michael Heiming wrote:

>> Yep, but then from the lengthy thread the person you responded
>> just looks like a simple wintroll, insisting on his ideas of some
>> broken XML registry, while simply not understanding how *nix
>> works.

> Isn't this what GConf is?

Perhaps? Never heard about it.

[ http://www.gnome.org/projects/gconf/ ]
"GConf is a system for storing application preferences. It is
intended for user preferences; not configuration of something
like Apache, or arbitrary data storage."

Well, that says it all.

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA6bDzAkPEju3Se5QRAgvcAJ9kXIfVXxjiv0EQ+BvdTvVkkprL4ACg12Sy
/LIiNdAjO0TsEue0eTBLz3Y=
=Npuc
-----END PGP SIGNATURE-----

Dave Uhring wrote:
> On Mon, 05 Jul 2004 00:29:47 +0000, mjt wrote:
> 
> 
>>Dave Uhring wrote:
> 
> 
>>>I fail to see how that could be accomplished since responsibility for the
>>>kernel resides with one person, BIND with another, Apache with still
>>>another, ad infinitum.
>>
>>i said i agreed with the point of standardization,
>>not that it's gonna happen. and i would be dead
>>against using XML
> 
> 
> The silly attempt to standardize all configurations would require the
> rewrite of everything.  Do you really think that is a good idea?  That
> XML crap is not going to happen with Linux, the BSDs or real UNIX.
> 
> 
>>...nope, i never said that.  if you do go to, say, OMG or
>>ISO or ANSI, it'll be ten years before we see a standard.
> 
> 
> As long as software is free there ain't going to be such a thing.  Any
> alternative to freedom is unacceptable and those would-be Linux admins
> with MCSEs can either learn how to use vi and the man pages or go to work
> flipping burgers.  Piss on them who want to change everything.
> 

Freedom?

When Linus altered the system so you could burn CDs without having to 
use the stupid SCSI emulation layer, some people even got p***ed at him. 
Maybe that's the thing with the UNIX community?

Mats

It was Mon, 05 Jul 2004 19:20:26 +0000 when Dances With Crows wrote:

> On Mon, 05 Jul 2004 19:45:06 +0200, Alexander Skwar staggered into the
> Black Sun and said:
>> It was Mon, 05 Jul 2004 13:14:34 -0400 when Lew Pitcher wrote:
>>> Additionally, XML imposes a structure that, when broken, invalidates
>>> the entire file.
>> Yes. As I said, I think that this is good, because it right away
>> allows to see that there IS an error.
> 
> Just think about what this would cause in the real world:
> 
> (enter car, insert key into ignition, turn key)
> ERROR: left front turn signal bulb burned out.  Disabling engine.

Great! No more danger because of hard to see cars. 

> ...there needs to be a distinction between minor problems and major
> ones.

Yes. Minor: Wrong values (ie. a bool value, where only a number is allowed).
Major: Broken syntax.

> are treated as major.  It's insanely easy to screw up an XML file in
> this way if you edit it by hand in vim--

You're right, it is.

> The idea "complete failure is better than something that works
> partially" is correct for a small minority of applications--mostly
> server apps and the kernel.

Those are the apps I care about, mostly. Since those are the apps I have
to take care off.

>  For desktop apps and 99% of the things that
> Joe User wants to run, it's the wrong approach.

Well, I suppose you're saying that, because it cannot be expected that Joe
User is able to read/understand/write XML? You're right, no sense in
arguing that.

However, does Joe User use vi? Or XEmacs for that matter? I don't think
so. Joe User should NOT edit configuration files. He should be guided, so
that he doesn't kill himself. However, there ABSOLUTELY has to be a way
that Joe can kill himself!

Alexander Skwar
-- 
Jegliche "Sicherheitsma�nahme", die von einem kompromittierten Rechner 
�berhaupt ausgeht, ist ungef�hr so, als w�rde man einer Leiche einen 
Helm aufsetzen. (Erhard Schwenk in dcsf)

It was Mon, 05 Jul 2004 14:17:39 -0500 when Dave Uhring wrote:

> On Mon, 05 Jul 2004 21:10:27 +0200, Alexander Skwar wrote:
> 
>> It was Mon, 05 Jul 2004 18:47:43 +0000 when Michael Heiming wrote:
>> 
>>> LOL...
>> 
>> Idiots tend to laugh all the time. Don't they, Michael?
> 
> You really are a moron, aren't you?

No, I'm not. I just reacted in the way you dumbasses like to treat each
other. It's not my way, but hey! If you like the name calling - fine.
Besides: It was NOT me who started that. But well, you're too arrogant to
understand that, I'm oh-so sorry for you.

Alexander Skwar
-- 
# Okay, what on Earth is this one supposed to be used for?
        2.4.0 linux/drivers/char/cp437.uni

It was Mon, 05 Jul 2004 20:01:20 +0000 when Mats wrote:

> Freedom?
> 
> When Linus altered the system so you could burn CDs without having to 
> use the stupid SCSI emulation layer, some people even got p***ed at him. 
> Maybe that's the thing with the UNIX community?

No, it's not. It's just the thing with the "old" school elite guys like
Michael and Dave. They are afraid of changes, because they know that they
are unable to understand new things.

Hey, it's not their fault - it's the fault of the changes, because the
nature of a change is, that it's different from "what always has been done".

Now, to "prove" their point, they are name calling. That's right away
disqualifying for them.

Alexander Skwar
-- 
A: Weil es die Lesbarkeit des Textes verschlechtert.
Q: Warum ist TOFU so schlimm?
A: TOFU
F: Was ist das groesste Aergerniss im Usenet?

On Mon, 05 Jul 2004 20:01:20 +0000, Mats wrote:

> Freedom?
> 
> When Linus altered the system so you could burn CDs without having to 
> use the stupid SCSI emulation layer, some people even got p***ed at him. 
> Maybe that's the thing with the UNIX community?

Doh!  It is *his* kernel and he put it under the GPL (freedom, if you
will) in order to get it developed and kept free.

I don't know who those "some people" are but, like you, perhaps they don't
understand how things are.  If you want XML config files, just write your
own OS, utilities, daemons and servers.  Otherwise just get bent.

Dave Uhring wrote:
> On Mon, 05 Jul 2004 14:12:01 -0400, John-Paul Stewart wrote:
> 
> 
>>Sure people may prefer to use emacs, but I'm 
>>sure everyone here would be able to get by with vi if that's all that 
>>was available.
> 
> 
> Sometimes not even vi is available.  I once rebuilt /etc/fstab on a Tru64
> system using only cat.

Try with ed.

NR


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 100,000 Newsgroups - 19 Different Servers! =-----

Dave Uhring wrote:
> On Mon, 05 Jul 2004 14:12:01 -0400, John-Paul Stewart wrote:
> 
> 
>>Sure people may prefer to use emacs, but I'm 
>>sure everyone here would be able to get by with vi if that's all that 
>>was available.
> 
> 
> Sometimes not even vi is available.  I once rebuilt /etc/fstab on a Tru64
> system using only cat.

I don't quite understand. Could you enlighten me? If your system get's 
corrupt, what says that even cat/sed/grep is available?

> 
> I'm sure this winidiot could do that if that file were some XML bullshit.
> 

Mats

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Skwar wrote:
> It was Mon, 05 Jul 2004 13:14:34 -0400 when Lew Pitcher wrote:
>
>
>>In simple terms, XML contains a lot of confusing (to the eye) overhead that is
>>superfluous to the requirements of passing parameters to a program. This
>>overhead makes it difficult to detect errors by eye, thus making it difficult to
>>/correct/ errors.
>
>
> Well, I suppose it depends on how used you are to seeing/reading XML data.

I've worked with XML for about five years now; I'd say that I'm used to seeing
and reading XML data.

>
>>Additionally, XML imposes a structure that, when broken, invalidates the entire
>>file.
>
>
> Yes. As I said, I think that this is good, because it right away allows to
> see that there IS an error.

Much like cardiac arrest is good because it right away allows the doctor to
see that there /are/ blood clots.

And, like cardiac arrest, by the time the failure is detected, it's usually
too late to fix it. The secret to maintainability is to catch and correct the
problems /before/ they become a critical failure. Failing that, you must build
enough resiliancy into your app so that it can ignore or self-correct such errors.

The problem is, with a highly structured data store like XML, even small
inconsistancies are critical errors. There's no resiliancy, no redundancy, and
no way to continue with such errors. What /could/ have been fixed with a
simple option given to the running app now /must/ be fixed with an XML editor,
because the app /refuses/ to start.

Stepping away from the automated side, the tools are only as good as the
person using them. Why stick all that redundant clutter into a config file? It
is stuff that can be ignored (as far as determining the config data is
concerned), and should be ignored (as far as resiliancy is concerned). And if
you are just going to ignore the XML formatting, why include it in the first
place?

A simple data structure is easier to parse, either by eye, /or/ in an
automated fashion. There's no need to complicate the matter with XML. Or is it
just that you /like/ XML, and are looking for a problem to solve with it?

>
>>can cause a "catastrophic" failure of the application.
>
>
> Yes.
>
>
>>For instance, given the hypothetical application that requires three
>>keyed strings, with keys of "hostname", "IPAddress", and "domainname",
>>we can have either
>>
>>  hostname=thishost
>>  domainname=thisdomain
>>  IPAddress=10.10.10.10
>>
>>or we can have
>>
>>  <?xml version="1.0" encoding="us-ascii" standalone="yes">
>>  <configuration>
>>  <hostname value="thishost"/>
>>  <domainname value="thisdomain"/>
>>  <IPAddress value="10.10.10.10"/>
>>  </configuration>
>>
>>However, if something invalidates the hostname line, such that
>>
>>  hostname~thishost
>
>
> lets take
>     hostname~thishost
>
>
>>  domainname=thisdomain
>>  IPAddress=10.10.10.10
>>
>>or
>>
>>  <?xml version="1.0" encoding="us-ascii" standalone="yes">
>>  <configuration>
>>  <hostname value="thishost">
>>  <domainname value="thisdomain"/>
>>  <IPAddress value="10.10.10.10"/>
>>  </configuration>
>>
>>then problems start.
>
>
> Yes, you are right. In the plain text file, the error is just *MUCH* later
> spotted as the application might run anyway. In the XML case, it just
> cannot work, as the XML cannot be parsed.

With a plain text file, the app can /recover/ the error on it's own. With XML,
the app is dead; no recovery possible, no continuation of processing in a
crippled fashion, just "It's dead, Jim" dead.

So the benefit of XML is that errors kill the app completely?
And that's a /good/ thing?

> Alexander Skwar


- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA6dWlagVFX4UWr64RAmcEAJ9AakeOOH4I0/eGgdadLIx+kgztPACfakBz
mHc/S/oUNXDpYQggSYJLJXQ=
=0f7N
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Skwar wrote:
> It was Mon, 05 Jul 2004 11:05:52 -0400 when John-Paul Stewart wrote:
[snip]
>>If this thread has taught you nothing else, it should at least show you
>>that there are *tons* of people who find the current config files just
>>fine.
>
>
> Yep, for no reason - besides "It's always been that way".

Nope. Mostly for the reason that "It works, and it's robust enough to keep on
working even under difficult conditions."

- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA6dX0agVFX4UWr64RAutEAKDUIBn3Cw8iLa2MY4w7VvzV7SRWtwCaApS3
VFxxWAPe4dy94sttu+cvysU=
=KfEL
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Skwar wrote:
> It was Mon, 05 Jul 2004 11:38:41 -0400 when John-Paul Stewart wrote:
>
>
>>[I hate replying twice to the same post, but this point escaped me the
>>first time.]
>>
>>Alexander Skwar wrote:
>>
>>>Have a look at the registry. It's *VERY* easy to
>>>use and read, if the Windows API is used.
>>
>>Using the Windows API to edit the registry *requires* the use of a
>>dedicated registry editing tool.
>
>
> Yes, that's bad. A properly implemented registry shouldn't have that
> problem. Hence XML.

Let me introduce you to another CS term: "single point of failure".


[snip]
> Well, if the system were fully XML-registry, would it be so hard to
> conceive, that there'd be a /sbin/cfg-tool?
>
> Once more: The Windows implementation is bad. Extremely bad. I'm much more
> thinking about GConf.

Let me repeat that term: "single point of failure".

- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA6dZUagVFX4UWr64RApWbAKC5uaLDEwT+ZPFdmyEdMG+Q0B99CgCbBbkU
GB5KAptCzJaYEV21dFRqsCQ=
=z+1r
-----END PGP SIGNATURE-----

Mats wrote:
> Dave Uhring wrote:
> 
>> On Mon, 05 Jul 2004 14:12:01 -0400, John-Paul Stewart wrote:
>>
>>
>>> Sure people may prefer to use emacs, but I'm sure everyone here would 
>>> be able to get by with vi if that's all that was available.
>>
>>
>>
>> Sometimes not even vi is available.  I once rebuilt /etc/fstab on a Tru64
>> system using only cat.
> 
> 
> I don't quite understand. Could you enlighten me? If your system get's 
> corrupt, what says that even cat/sed/grep is available?

Nothing says that those will be available.  That's just what happened to 
be available by (more-or-less) random chance.  The fact that it was 
available then is no guarantee that it will be available on another 
catasrophic failure.  Maybe next time some other utility will have to do.

On Mon, 05 Jul 2004 22:08:29 +0000, Mats wrote:

> 
> I don't quite understand. Could you enlighten me? If your system get's 
> corrupt, what says that even cat/sed/grep is available?

That is the problem with you trolls.  You *don't* get it.

Learn something about Linux/BSD/UNIX administration before you come up
with such trash as you propounded.

Brian wrote:
> On Sun, 04 Jul 2004 21:24:49 +0200, Alexander Skwar wrote:
> 
> [snips]
> 
>>I do understand what I'm suggesting. It's not my fault if you're too
>>stubborn to understand it.
>>
> 
> Ok, so there you are with the usual smoking wreckage left after a Windows
> crash and you can't even get the GUI-based registry editor up & running to
> fix what caused the crash.
> 
> Now what?

Windows? Then youre in the wrong newsgroup, because i'm not discussing 
either windows or it's infamous registry, although some seems to bring 
them up all the time and kick them around for a while.

Some even seems to think that XML is proprietary and a binary format. 
Everyone seems to agree that it's all evil anyway (both XML, Windows and 
the config-tool suggestion).

I have pointed out that it wouldn't neccesary have to be pure XML, but a 
  liter version, or basically anything that could be a reasonable 
standard for this thing, but then everybody gets back to talk about 
Windows and it's registry again. Also they talk about crash scenarios 
where everything gets corrupted and unusable except sed/grep/cat.

If your wreckage scenario would happen on Linux? You could use a 
command-line based configuration-editor or your usual tools 
sed/grep/cat/vi/emacs or whatever they are.

> 
> 
> B.

Mats

On Mon, 05 Jul 2004 17:38:51 -0500, Dave Uhring staggered into the Black
Sun and said:
> On Mon, 05 Jul 2004 22:08:29 +0000, Mats wrote:
>> I don't quite understand. Could you enlighten me? If your system
>> get's corrupt, what says that even cat/sed/grep is available?
> That is the problem with you trolls.  You *don't* get it.

If cat/sed/grep aren't working, then it's highly probable that libc
and/or ld.so are broken.  In that case, you've either got to run sash,
boot from a rescue CD, or try something like
891kot$7uj@weyl.math.psu.edu (put that into the Message-ID field of
http://groups.google.com/advanced_group_search , hit Search.)  This is
*possible*, but it's extremely unlikely.

-- 
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin /    mail: TRAP + SPAN don't belong
http://www.brainbench.com     /                Hire me! 
-----------------------------/ http://crow202.dyndns.org/~mhgraham/resume

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Dave Uhring <daveuhring@yahoo.com> suggested:
> On Mon, 05 Jul 2004 14:12:01 -0400, John-Paul Stewart wrote:

>> Sure people may prefer to use emacs, but I'm 
>> sure everyone here would be able to get by with vi if that's all that 
>> was available.

> Sometimes not even vi is available.  I once rebuilt /etc/fstab on a Tru64
> system using only cat.

Now that sucks, can remember 'ed' being the only thing available
to me once on Tru64.;(

> I'm sure this winidiot could do that if that file were some XML bullshit.

Looks like he used an open proxy, perhaps there's only one troll
using another pupa to support his strange claims...

Host: h226n2fls35o862.telia.com.
Origin: Sweden
RBL:
   [1]?? Multi DNSBL Lookup 217.211.71.226
   http://openrbl.org/ip/217/211/71/226.htm
   Lookup 217.211.71.226 (h226n2fls35o862.telia.com) in 20+10 Zones
    AS: [2]217.208.0.0/13 [3]AS3301 [4]SE TeliaNet Sweden Goteborg/Goteborg Och Bohus
    Net [5]217/8 [6]EU-ZZ-217 ? Amsterdam, North Holland
    Results: Positive=5, Negative=25 (2004-07-05 20:09:04 UTC)
     * [7]@DYNAMIC/dialup: 217.211.71/24: 553 SORBS DUL
     * [8]@SPAM/spamsource:   217.211.71/24:   553  PROXY telia.com  SWN  217.211.71.193 2003-07
     * [9]DSBL/dsbl.org: 553 DSBL Insecure host; DSBL Unconfirmed [10][Remove]
     * [11]NJABL/njabl.org: 553 NJABL open proxy -- 1073662803 [12][Remove]
     * [13]SORBS/sorbs.net: 217.211.71/24: 553 SORBS DUL [14][Remove]
     * Negative 25: @COUNTRY @ISP AHBL AUDNSBL BLARS BOGONS BOPM CBL DRBL
       FIVETEN INTERSIL JIPPGMA LNSG NOMORE ORDB PSBL RFC_IPWH SBL SPAMBAG
       SPAMCOP SPAMRBL SPAMSITE SPEWS UCEPROT WPBL
   _________________________________________________________________

    Hints for 217.211.71.226: ([15]external, use BACK or ALT-LEFT when done)

     * Track "h226n2fls35o862.telia.com" at [[16]Whois & Abuse|[17]SpamCop*]
     * Search "217.211.71.226" at [[18]Google|[19]SpamCop*|[20]SenderBase]

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA6eOkAkPEju3Se5QRAkimAKDFacoy11OR1Yka9c7YqVBWP9ifSQCeJi70
hGlBChLUpC7Wfp3oWTY+bEk=
=G1ad
-----END PGP SIGNATURE-----

On Mon, 05 Jul 2004 23:19:28 +0000, Dances With Crows wrote:

> If cat/sed/grep aren't working, then it's highly probable that libc
> and/or ld.so are broken.  In that case, you've either got to run sash,
> boot from a rescue CD, or try something like
> 891kot$7uj@weyl.math.psu.edu (put that into the Message-ID field of
> http://groups.google.com/advanced_group_search , hit Search.)  This is
> *possible*, but it's extremely unlikely.

Most systems make it possible to boot from CD and provide in the miniroot
the bare minimum of utilities required to do such repairs.  In the Tru64
instance cat was available and vi was not - and I detest ed.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2004-07-05, Mats <spamenot.mog.pettersson@telia.com> wrote:

> I have pointed out that it wouldn't neccesary have to be pure XML, but a 
>   liter version, or basically anything that could be a reasonable 
> standard for this thing

If you don't have pure XML, you don't have a standard at all.  All
XML says is that tags must be arranged a certain way--it doesn't
even say what those tags are.  So you're basically suggesting a
markup language a la HTML before XHTML, which was an absolute nightmare
for browser coders because people would abuse HTML to get it to do
what they wanted for their app, without regard to someone else's.
Without the structure enforcement of XML, you'll certainly see similar
abuses in these hypothetical ''lite XML'' configuration files, and
we'd be no better off than we are now.

> If your wreckage scenario would happen on Linux? You could use a 
> command-line based configuration-editor or your usual tools 
> sed/grep/cat/vi/emacs or whatever they are.

As many have stated, XML is more difficult to read, as well as
to write, using a standard text editor.  When your supervisor is
breathing your neck, asking why your daemon isn't running, the
last thing you want is to have to parse XML in your head.

What does XML really gain, anyway?  If you're using a tool to
help you configure a piece of software, you don't need to know the
syntax anyway, and since the software itself parses the file, the
tool should be able to do it just as easily.  So why not cater to
those who for whatever reason wish to use a text editor?

- --keith

- -- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFA6etMhVcNCxZ5ID8RAj4lAJ47Xa5+m+nZA8O+oehxs44AiciQYwCdEwE6
5nvAuUMDkuIiBpw8Td98c10=
=jRPI
-----END PGP SIGNATURE-----

On Mon, 05 Jul 2004 23:26:29 +0000, Michael Heiming wrote:

> Now that sucks, can remember 'ed' being the only thing available
> to me once on Tru64.;(

To tell the shameful truth, I never did learn how to use ed :-)

But mv and cat were available and adequate to the job.  The miniroot on
the Solaris CD is ~290MB in size and does have vi available.  I think most
Linux distros also have vi in their miniroots but Tru64 didn't.

> Looks like he used an open proxy, perhaps there's only one troll
> using another pupa to support his strange claims...

I can't see that other wintroll now.  I killfiled him right after you did
but I put only a 30 day limit on the kill.

Mats writes:
> I have pointed out that it wouldn't neccesary have to be pure XML, but a
> liter version...

Yes.  Much lighter.  Such as:

# comment
variable1=value1
variable2=value2
# comment
....
....
....
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, Wisconsin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mats wrote:
[snip]
> I have pointed out that it wouldn't neccesary have to be pure XML, but a
>  liter version,

Ain't no such thing. To be called "XML", it's /got/ to conform to the XML
standard, and that makes it a heavyweight.


> or basically anything that could be a reasonable
> standard for this thing,

Got one already...

  # comment
  variable=value
  variable=value # comment


> but then everybody gets back to talk about
> Windows and it's registry again.

No. Everyone just goes back to plain text configuration files.
OTOH, if you want to talk about 'synergies' and 'common formats' and 'combined
data', then /you/ go back to talking about the registry again.

> Also they talk about crash scenarios
> where everything gets corrupted and unusable except sed/grep/cat.

Been there, done that. If you can't fix it, then it stays broken, and what
good is a broken app?

> If your wreckage scenario would happen on Linux? You could use a
> command-line based configuration-editor or your usual tools
> sed/grep/cat/vi/emacs or whatever they are.

Only if the config files are text files.

Sensable design dictates seperation of unrelated config info, so that a
failure in one app's config does not affect other apps. This, of course, rules
out a 'registry'.

And, config files should be as simple as possible, in order to simplify both
the programming of the app, and the hand recovery when the config file gets
corrupted. This rules out complex formats like XML.

>>
>>
>> B.
>
>
> Mats


- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA6gWBagVFX4UWr64RAhjrAKChx/04bzM3UAHliYQ/sOMbCNWNkwCg8FXC
0YaGGX3M4ZyCKR5dd7yuwvI=
=E87M
-----END PGP SIGNATURE-----

> > Ok, so there you are with the usual smoking wreckage left after a Windows
> > crash and you can't even get the GUI-based registry editor up & running to
> > fix what caused the crash.
> > 
> > Now what?
> 
> What, "now what"?  You're trying to tell, that a binary configuration file
> is a bad idea? And maybe, that it's also a bad idea, to have (basically)
> just one very huge file (instead of many small ones)?
> 
> Agreed. That's bad.
> 
> But what are you trying to tell? Who said that everything has to be as
> badly implemented as the Windows registry?
> 
> Alexander Skwar
I disagree!!!  The windows registry is good implementation of an
exceptionally bad idea.

The idea: A fragile, poorly documentated, proprietary, concentrated
element which as a single point of failure can cause a computer to
become completely unusable.

The implentation: If it were badly implemented, almost no Windows
computers
would be operational.

Regards...Dan.

On Mon, 05 Jul 2004 19:18:34 -0700, Dan Skinner wrote:

> I disagree!!!  The windows registry is good implementation of an
> exceptionally bad idea.

Apparently not.

> The idea: A fragile, poorly documentated, proprietary, concentrated
> element which as a single point of failure can cause a computer to
> become completely unusable.
> 
> The implentation: If it were badly implemented, almost no Windows
> computers
> would be operational.

I just attempted to remove SP2-RC1 from my WinXP installation.  The
Windoze system on that machine is no longer operational, not that I much
care except that sometimes I need to use it for "Help Desk".

Stick your registry where the sun doesn't shine.

Dan Skinner wrote:

>>>Ok, so there you are with the usual smoking wreckage left after a Windows
>>>crash and you can't even get the GUI-based registry editor up & running to
>>>fix what caused the crash.
>>>
>>>Now what?
>>
>>What, "now what"?  You're trying to tell, that a binary configuration file
>>is a bad idea? And maybe, that it's also a bad idea, to have (basically)
>>just one very huge file (instead of many small ones)?
>>
>>Agreed. That's bad.
>>
>>But what are you trying to tell? Who said that everything has to be as
>>badly implemented as the Windows registry?
>>
>>Alexander Skwar
> 
> I disagree!!!  The windows registry is good implementation of an
> exceptionally bad idea.
> 
> The idea: A fragile, poorly documentated, proprietary, concentrated
> element which as a single point of failure can cause a computer to
> become completely unusable.
> 
> The implentation: If it were badly implemented, almost no Windows
> computers
> would be operational.

Just to add to the sarcasm, Dan....

So what's your point? :)

(Note: I come from an environment where the customer
demands less than 5 minutes a year application
down-time from a fully duplexed system. A single
node requirement is a max of 8 hours a year down
time.)

> 
> Regards...Dan.


-- 
"It is impossible to make anything foolproof
because fools are so ingenious"
  - A. Bloch

Lew Pitcher <lpitcher@sympatico.ca> �u�erte:

> Let me introduce you to another CS term: "single point of failure".

Dismissed: Unrelated to the problem.

> Let me repeat that term: "single point of failure".

Yeah, go on. And when you're done, you might tell what the heck this has
to do with a registry approach.

Alexander Skwar
-- 
/*
 * For moronic filesystems that do not allow holes in file.
 * We may have to extend the file.
 */	2.4.0-test2 /usr/src/linux/fs/buffer.c

Dave Uhring <daveuhring@yahoo.com> �u�erte:

> 
> That is the problem with you trolls.

You're talking to yourself, boy? Because that applies so fine to you:

>  You *don't* get it.

> Learn something about Linux/BSD/UNIX administration before you come up
> with such trash as you propounded.

What trash?

Alexander Skwar
-- 
panic("Oh boy, that early out of memory?");
	2.2.16 /usr/src/linux/arch/mips/mm/init.c

On Mon, 05 Jul 2004 01:27:58 +0000, mjt wrote:

> Brian wrote:
> 
>> Ok, so there you are with the usual smoking wreckage left after a Windows
>> crash and you can't even get the GUI-based registry editor up & running to
>> fix what caused the crash.
>> 
>> Now what?
> 
> ... install Linux
>

Hehe  ;)
Of course!

B.
-- 
I route, therefore you are.

On Mon, 05 Jul 2004 06:38:14 +0200, Alexander Skwar wrote:

> It was Mon, 05 Jul 2004 00:26:20 +0100 when Brian wrote:
> 
>> Ok, so there you are with the usual smoking wreckage left after a Windows
>> crash and you can't even get the GUI-based registry editor up & running to
>> fix what caused the crash.
>> 
>> Now what?
> 
> What, "now what"?  You're trying to tell, that a binary configuration file
> is a bad idea? And maybe, that it's also a bad idea, to have (basically)
> just one very huge file (instead of many small ones)?
> 
> Agreed. That's bad.
> 
> But what are you trying to tell? Who said that everything has to be as
> badly implemented as the Windows registry?
> 
Not me - I'm just trying to keep to the KISS principle.

If plain, undecorated 'token=value' ASCII files adequately express what's
required for an application's configuration, additional "flowery" syntax
to define the same thing is just another potential source of errors and a
layer of redundant complexity.

So where once I could fix a config file by attacking tokens & values
directly with a plain ASCII editor, I would now need something more which
would be capable of parsing this additional syntax before I could be in a
position to change anything.  And if the additional syntax is too broken
to be correctly parsed, then I have another (and bigger) problem because
I'm prevented from correcting something by the correction tool itself.
So now I have to build a better tool too, just to do what plain
undecorated ASCII already does?

Kind-of like: I need a fully running GUI provided by the OS to run the
tool to fix the busted entry in the config file which prevents the OS from
running fully...  (spins on spot)

Yes, I could still attack an XML file with a plain ASCII editor but now I
have the additional overhead of parsing the XML structures - and even if
they're all valid it's still visual "clutter" which eyeballs don't need.
That's been illustrated very well by other posters' XML examples.

B.
-- 
Your mouse has moved.
Windows needs to be restarted for the changes to take effect.

On Mon, 05 Jul 2004 06:58:22 +0200, Alexander Skwar wrote:

> It was Mon, 05 Jul 2004 00:18:34 +0100 when Brian wrote:
> 
>> Yeah, great idea.  It can be wrapped up in a proprietary binary format
> 
> Nobody said that.
>
I didn't say they had.  Just taking the idea of wrapping up all configs in
one standard to a logical extreme.

>> I don't understand: just what is it about ASCII that you find so
>> difficult?
> 
> Same to you. XML is ASCII (or maybe UTF-8; but ASCII isn't good enough
> anyway, if you wish to store non-ASCII chars like ����... And no, I
> don't like the idea of qp encoding values in a file).
> 
I meant plain, undecorated 'token=value' ASCII and its usage in config
files.


B.
-- 
Microsoft: The company that made email dangerous.

On Mon, 05 Jul 2004 22:47:24 +0000, Mats wrote:

> Brian wrote:
>> On Sun, 04 Jul 2004 21:24:49 +0200, Alexander Skwar wrote:
>> 
>> [snips]
>> 
>>>I do understand what I'm suggesting. It's not my fault if you're too
>>>stubborn to understand it.
>>>
>> 
>> Ok, so there you are with the usual smoking wreckage left after a Windows
>> crash and you can't even get the GUI-based registry editor up & running to
>> fix what caused the crash.
>> 
>> Now what?
> 
> Windows? Then youre in the wrong newsgroup, because i'm not discussing 
> either windows or it's infamous registry, although some seems to bring 
> them up all the time and kick them around for a while.
> 
No, this is the right group.  I mention that other OS as a fer-instance of
what happens when specialised tools become the norm where simpler ideas
could/should have been used instead.

> If your wreckage scenario would happen on Linux? You could use a 
> command-line based configuration-editor or your usual tools 
> sed/grep/cat/vi/emacs or whatever they are.
>
Yes, exactly.  And without needing to mentally parse XML statements.


B.
-- 
It is not possible to ski through a revolving door.