* [gentoo-dev] Config Idea
@ 2002-04-22 12:39 Yannick Koehler
2002-04-22 13:52 ` Todd Wright
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Yannick Koehler @ 2002-04-22 12:39 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi fellow Gentoo Developer ;-)
An idea I got this morning, which is certainly not new, but I'd like to know
what are/his the final word on this from your mind.
What about a central config file, that would be able to generate all other
related config... gentoo_config.xml, which when transformed using xslt,
would produce conf.d/net, conf.d/ntp, etc...
I would be interested in working on this. It looks like the way this would
work could be similar as the today ebuild script system, where one would
write a XSLT for each module it port inside gentoo.
For example, I get in, I add an app such as xntp, I write down the xml
stylesheet to convert
<ntp>
<servers>
<server>name</server>
</servers>
</ntp>
Into
NTPDATESERVER=name
Then the ebuild script check if a ${P}.xslt file exists and if so execute it,
otherwise it call a function such as src_config() { }.
The whole system config would then stay in /etc/gentoo.xml.
People would still be able to change their config as normal because the output
files would be present and writable. Others would be able to view their
whole system config through a single file...
I have to admit that I don't have much ideas as to what are all the advantages
/ disadvantage of such system, I just thought it looked cool ;-) Maybe I can
just say that it is an exercice for the mind that I left for you to try out?
- --
Yannick Koehler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8xASLfuKOJNEyL1URAqa2AJ9jyNEZstvicKCzIERcjM5wDI4JQwCfdWph
+xrtQnfxl7Ay19QoEofwR6c=
=PaZx
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [gentoo-dev] Config Idea
2002-04-22 12:39 [gentoo-dev] Config Idea Yannick Koehler
@ 2002-04-22 13:52 ` Todd Wright
2002-04-22 14:20 ` Yannick Koehler
2002-04-22 14:20 ` Alexander Gretencord
2002-04-22 14:58 ` William McArthur
2002-04-22 17:21 ` [gentoo-dev] Config Idea - take 2 Yannick Koehler
2 siblings, 2 replies; 20+ messages in thread
From: Todd Wright @ 2002-04-22 13:52 UTC (permalink / raw
To: gentoo-dev
> What about a central config file, that would be able to
> generate all other
> related config... gentoo_config.xml, which when transformed using xslt,
> would produce conf.d/net, conf.d/ntp, etc...
I havnt seen anything in /etc/conf.d yet that couldnt/shouldnt be in /etc/rc.conf
Either way, this is how it should be. We dont need all this extra (xml) pre processing. We just need a single config file (rc.conf) or a ../conf.d/ directory containing per package config variablle - but not both.
If you want to edit a config setting, what could be simpler than editing the appropriate file, once, and in one place.
-- _--_|\ --------- Todd Wright -- wylie@geekasylum.org --------
/ \
\_.--._* <--- http://www.dreams.darker.net/~wylie/
v Mobile: +61-403-796-001 Ph: +61-2-9521-8677
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Config Idea
2002-04-22 13:52 ` Todd Wright
@ 2002-04-22 14:20 ` Yannick Koehler
2002-04-22 15:11 ` Todd Wright
2002-04-22 14:20 ` Alexander Gretencord
1 sibling, 1 reply; 20+ messages in thread
From: Yannick Koehler @ 2002-04-22 14:20 UTC (permalink / raw
To: gentoo-dev, Todd Wright
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On April 22, 2002 09:52 am, Todd Wright wrote:
> > What about a central config file, that would be able to
> > generate all other
> > related config... gentoo_config.xml, which when transformed using xslt,
> > would produce conf.d/net, conf.d/ntp, etc...
>
> I havnt seen anything in /etc/conf.d yet that couldnt/shouldnt be in
> /etc/rc.conf
>
> Either way, this is how it should be. We dont need all this extra (xml) pre
> processing. We just need a single config file (rc.conf) or a ../conf.d/
> directory containing per package config variablle - but not both.
>
> If you want to edit a config setting, what could be simpler than editing
> the appropriate file, once, and in one place.
Like I said, I have not giving it much thought because I mostly was probing to
see if similar ideas have been discussed and what were their results.
I agree with you that there's not much simpler than editing the appropriate
file once and in a single place. But maybe the issue is about merging 10
files instead of one or about automatic config file merging or about mapping
a user idea to an appropriate specific software config file.
We can't merge a single file instead of many because there's no such single
master config file.
We can't automatically merge config file because there's no way for a computer
at the present time to figure out what each config means other than being
text/token-value or other kind of cfg file.
We could re-write the whole linux system and make use a single config file but
I'm not up to that task.
Xml namespace seems to be great for that kind of stuff where a single file can
contain links to other files or content based on different namespace. Also
many software exist today and will be written to easily edit those type of
file. Project such as WebMin or Linux conf MAY already have started such
system, but they surely have not addresse the merging config issue that
gentoo users gets face with.
The issue is not such a big deal but I believe that solving it would then open
doors to very easy installation software (even easier than today) and also
remove the need to have documents for newbie on how to configure/continually
upgrade their system by writing graphical tools that map config file to UI.
- --
Yannick Koehler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8xBwQfuKOJNEyL1URAg8hAJ9mzNnQLACsktrynTwwpjayTHj6mACeILWX
m1IfaH8rdeqguQGovMEKfK4=
=T5FC
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Config Idea
2002-04-22 13:52 ` Todd Wright
2002-04-22 14:20 ` Yannick Koehler
@ 2002-04-22 14:20 ` Alexander Gretencord
2002-04-22 14:31 ` Yannick Koehler
1 sibling, 1 reply; 20+ messages in thread
From: Alexander Gretencord @ 2002-04-22 14:20 UTC (permalink / raw
To: gentoo-dev
On Monday 22 April 2002 15:52, Todd Wright wrote:
> Either way, this is how it should be. We dont need all this extra (xml) pre
> processing.
ACK
> We just need a single config file (rc.conf) or a ../conf.d/
> directory containing per package config variablle - but not both.
Well I don't like the idea of a single file. It's easier to have a directory
with individual files so you can simply drop your file in there if you need
it. Just like the env.d.
That two different paradigma are just confusing is (one point for) why I don't
like SuSE. They got a sysv init system but it just doesn't matter what you do
to the symlinks, you gotta edit rc.config too.
Alex
--
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
Benjamin Franklin
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Config Idea
2002-04-22 14:20 ` Alexander Gretencord
@ 2002-04-22 14:31 ` Yannick Koehler
0 siblings, 0 replies; 20+ messages in thread
From: Yannick Koehler @ 2002-04-22 14:31 UTC (permalink / raw
To: gentoo-dev, Alexander Gretencord
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On April 22, 2002 10:20 am, Alexander Gretencord wrote:
> On Monday 22 April 2002 15:52, Todd Wright wrote:
> > Either way, this is how it should be. We dont need all this extra (xml)
> > pre processing.
>
> ACK
>
> > We just need a single config file (rc.conf) or a ../conf.d/
> > directory containing per package config variablle - but not both.
>
> Well I don't like the idea of a single file. It's easier to have a
> directory with individual files so you can simply drop your file in there
> if you need it. Just like the env.d.
>
> That two different paradigma are just confusing is (one point for) why I
> don't like SuSE. They got a sysv init system but it just doesn't matter
> what you do to the symlinks, you gotta edit rc.config too.
>
> Alex
Note that xml could still allow you to have multiple file or a single one.
Xml is made such that part of a file can be parse with different rules than
other. There's also XLink that allow you to link xml content inside another
file this allow someone to create many xml file and a master xml file telling
where to look for the content.
This allow a choice about a single or multiple files.
The issue I think you want to refer to is duplication. Having a single or
multiple xml cfg files + backward compatible cfg file could be a cost that
will annoy users. For that I have yet to think about something interesting
but I'll try, maybe the solution would just be to generate the backward
comptaible files in hidden mode or in a hidden folder. That would make only
advance users see them and play with them.
- --
Yannick Koehler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8xB7NfuKOJNEyL1URAiXxAJ4535HrrCAop0GcrR2oTDRVkQCgKQCeK1kp
hSDpp2NahEpHR5dPERtjfmk=
=hHF0
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Config Idea
2002-04-22 12:39 [gentoo-dev] Config Idea Yannick Koehler
2002-04-22 13:52 ` Todd Wright
@ 2002-04-22 14:58 ` William McArthur
2002-04-22 15:26 ` Yannick Koehler
2002-04-22 17:21 ` [gentoo-dev] Config Idea - take 2 Yannick Koehler
2 siblings, 1 reply; 20+ messages in thread
From: William McArthur @ 2002-04-22 14:58 UTC (permalink / raw
To: gentoo-dev
Yannick Koehler wrote:
> What about a central config file, that would be able to generate all other
> related config... gentoo_config.xml, which when transformed using xslt,
> would produce conf.d/net, conf.d/ntp, etc...
So you just want the windows registry?
Sandy McArthur
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [gentoo-dev] Config Idea
2002-04-22 14:20 ` Yannick Koehler
@ 2002-04-22 15:11 ` Todd Wright
2002-04-22 15:26 ` Alexander Gretencord
0 siblings, 1 reply; 20+ messages in thread
From: Todd Wright @ 2002-04-22 15:11 UTC (permalink / raw
To: gentoo-dev
> The issue is not such a big deal but I believe that solving it
> would then open
> doors to very easy installation software (even easier than today)
> and also
> remove the need to have documents for newbie on how to
> configure/continually
> upgrade their system by writing graphical tools that map config
> file to UI.
Unfortunately I saw htis comment after I had replied to the earlier point.
As I eluded to in my previous post, if you want a graphical configuration which is simple for newbies to understand, and doesnt require editing files, go use a microsoft product. This is Linux.
Please dont change the way *nix works.
Im not against improvements, and there may be ways to improve etc-update or other tools, but these tools must work on the existing structure, dont change the structure to suit the tools. I dont use etc-update, I go and edit my config files by hand (usually with Joe). Yes there is a learning curve and I dont expect newbies to understand how to configure a Linux system on their first try, but rather than change how everything works because you are impatient, why not read some documentation and understand all the configuration options you are adjusting. In the long run, you will do better by understanding each little adjustment you are making than by having a graphical GUI set it all up for you in secret, in a total of 30 seconds.
-- _--_|\ --------- Todd Wright -- wylie@geekasylum.org --------
/ \
\_.--._* <--- http://www.dreams.darker.net/~wylie/
v Mobile: +61-403-796-001 Ph: +61-2-9521-8677
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Config Idea
2002-04-22 14:58 ` William McArthur
@ 2002-04-22 15:26 ` Yannick Koehler
2002-04-22 17:16 ` George Shapovalov
0 siblings, 1 reply; 20+ messages in thread
From: Yannick Koehler @ 2002-04-22 15:26 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On April 22, 2002 10:58 am, William McArthur wrote:
> Yannick Koehler wrote:
> > What about a central config file, that would be able to generate all
> > other related config... gentoo_config.xml, which when transformed using
> > xslt, would produce conf.d/net, conf.d/ntp, etc...
>
> So you just want the windows registry?
Hello Sandy,
Not at all, actually as I reply to Todd Wright in private,
"As for the single configuration file, we may not need it. If we evolve to a
configuration file that allow software to understand and manipulate it then
it would solve my issues without breaking yours.
And it would still make the config files small and would encourage
re-use of tools that can manipulate configuration file. If we use xml we
juste gain tools that already exists."
The idea that I had originally started with a single file because in my head,
software needed a location to start reading your configuration. If that
logical location is a directory such as /etc then fine it would be able to
retrieve all configurations and deal with them. The missing piece is what
xml is all about, adding definition to content so that software can be
written that properly understand and handle its content.
This would still allow automatic merging and application to be written that
are not bloat and can allow easy configuration of those files while allowing
advance users to simply go and edit those files. There could even exists a
deamon that monitor /etc and when a file changes reparse it to generate the
proper backward compatible config file so that nothing change for advance
users as well.
It wouldn't even be hard to go back and forth such as the transformation be
applied in reverse and actually generate the xml file so that they stay in
synch even after the backward-compatible related cfg gets modified.
Actually that's where I would start, making a system that takes current cfg
and get them into xml/xslt. Once this gets done then it would be easy to
reverse the process using existing xml tools and editors. A deamon would
need to run to maintain them in sync and that would be it.
- --
Yannick Koehler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8xCuifuKOJNEyL1URAlPHAJ9uBTCrChWhsu0YUy5rKCAqfmcVdACgo0kN
85p+3P63ZaTvgV2McZ9QIGw=
=k8Oi
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Config Idea
2002-04-22 15:11 ` Todd Wright
@ 2002-04-22 15:26 ` Alexander Gretencord
2002-04-22 15:46 ` Yannick Koehler
0 siblings, 1 reply; 20+ messages in thread
From: Alexander Gretencord @ 2002-04-22 15:26 UTC (permalink / raw
To: gentoo-dev
On Monday 22 April 2002 17:11, Todd Wright wrote:
> Please dont change the way *nix works.
ACK
> I dont use etc-update, I go and edit my config files by hand
ACK
> I dont expect newbies to understand how to configure a Linux
> system on their first try, but rather than change how everything works
> because you are impatient, why not read some documentation and understand
> all the configuration options you are adjusting. In the long run, you will
> do better by understanding each little adjustment you are making than by
> having a graphical GUI set it all up for you in secret, in a total of 30
> seconds.
Isn't that why we all chose to use gentoo instead of SuSE or Mandrake ? I know
at least lately many Linux newbies have come to Gentoo but if they want to
take the challange, let them. I've come from RH 6.2 through about 1 day of
Mandrake then Slackware 8 to Gentoo now. You could even use Slackware with
checkinstall or something like that instead of gentoo if it wasn't for the
great ports like system (tho it still needs some work :)) I installed gentoo
because it was _not_ like SuSE. The first sentence in the Gentoo description
says it all: "that's geared towards experienced Linux users."
Alex
--
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
Benjamin Franklin
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Config Idea
2002-04-22 15:26 ` Alexander Gretencord
@ 2002-04-22 15:46 ` Yannick Koehler
2002-04-22 16:33 ` Alexander Gretencord
2002-04-22 16:53 ` Todd Wright
0 siblings, 2 replies; 20+ messages in thread
From: Yannick Koehler @ 2002-04-22 15:46 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On April 22, 2002 11:26 am, Alexander Gretencord wrote:
> Isn't that why we all chose to use gentoo instead of SuSE or Mandrake ? I
> know at least lately many Linux newbies have come to Gentoo but if they
> want to take the challange, let them. I've come from RH 6.2 through about 1
> day of Mandrake then Slackware 8 to Gentoo now. You could even use
> Slackware with checkinstall or something like that instead of gentoo if it
> wasn't for the great ports like system (tho it still needs some work :)) I
> installed gentoo because it was _not_ like SuSE. The first sentence in the
> Gentoo description says it all: "that's geared towards experienced Linux
> users."
That maybe why you and other people switched to Gentoo but that wasn't my
reasons and probably some others are like me also.
I personnaly switched to Gentoo because I can upgrade my system faster and
ensure that I'm running the latest version of the software I run in order to
help testing and get security and other different fix fast.
Another reason for which I switched to Gentoo was to be able to upgrade big
libraries such as glibc without having to wait for a major release of the
distro or manually finding one by one each RPM I needed and then try to force
some to install because there was circular dependencies.
I believe Gentoo should enhance on the path of ease-of-use not just for
developers but also for users.
Why create a system such as portage and install your PC from that distro if
your kick is to learn everything? Then go read Linux from Scratch, you'll
learn all the things that ebuild script do for you and you'll also learn when
x package depend upon y. I've tried that in my past and it proven to take
too much of my time therefore I use Gentoo because it make me go beyond that.
Now the things that slow me down are config upgrade and system configuration.
Those are smaller than learning every packages but still can be enhanced
greatly. And that's why I initiate discussions on this.
Maybe thought that my idea belong on a project on its own and not inside a
specific distribution. Most similar project do exactly what you mention,
adapt to current /etc/ file system but this proven to be bad on evolve system
as then your system configuration tools doesn't update as fast as all the
related packages. That's why I first thought that Gentoo would be the ideal
mix as if the script get edited and the template is inside the script it
would then be piece of cake (nearly) to change the template at the same time
and then provide up-to-date package + config definition file.
- --
Yannick Koehler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8xDBdfuKOJNEyL1URAuyAAKCJ3YqXCtD+yFPCPNVMe+BIIe1grwCfeFo7
ElepG9f6+D97gkwZXOquKds=
=PqHh
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Config Idea
2002-04-22 15:46 ` Yannick Koehler
@ 2002-04-22 16:33 ` Alexander Gretencord
2002-04-23 17:14 ` Damon Conway
2002-04-22 16:53 ` Todd Wright
1 sibling, 1 reply; 20+ messages in thread
From: Alexander Gretencord @ 2002-04-22 16:33 UTC (permalink / raw
To: gentoo-dev
On Monday 22 April 2002 17:46, Yannick Koehler wrote:
> I personnaly switched to Gentoo because I can upgrade my system faster and
> ensure that I'm running the latest version of the software I run in order
> to help testing and get security and other different fix fast.
That's why I made the final step from Slackware to Gentoo. But as I stated,
gentoo _is_ meant for advanced users, that the first thing you get told in
the "About Gentoo" document.
You can try to make configuration easier but don't kick *nix for it as someone
else put it already.
Alex
--
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
Benjamin Franklin
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [gentoo-dev] Config Idea
2002-04-22 15:46 ` Yannick Koehler
2002-04-22 16:33 ` Alexander Gretencord
@ 2002-04-22 16:53 ` Todd Wright
1 sibling, 0 replies; 20+ messages in thread
From: Todd Wright @ 2002-04-22 16:53 UTC (permalink / raw
To: gentoo-dev
> Why create a system such as portage and install your PC from that distro
> if your kick is to learn everything? Then go read Linux from Scratch
Because for those of us who took the time to learn everything first, Gentoo is the quickest and simplest way to keep up to date with the current available software packages. Gentoo does not replace experience, and part of that experience is installing and configuring software. The trouble is that these days everyone wants to be spoon fed. Like I said before, if you want a system that you can just type setup.exe and in 30 mins you have a complete working system, install windows. Linux takes time to configure and customise, and I wouldnt want it any other way.
-- _--_|\ --------- Todd Wright -- wylie@geekasylum.org --------
/ \
\_.--._* <--- http://www.dreams.darker.net/~wylie/
v Mobile: +61-403-796-001 Ph: +61-2-9521-8677
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Config Idea
2002-04-22 15:26 ` Yannick Koehler
@ 2002-04-22 17:16 ` George Shapovalov
2002-04-22 17:44 ` Yannick Koehler
0 siblings, 1 reply; 20+ messages in thread
From: George Shapovalov @ 2002-04-22 17:16 UTC (permalink / raw
To: gentoo-dev
I think this will be a very BAD, BAD thing to do.
Imagine, you want to get a really small gentoo installation, where you do not
want just anything extra...
Imaging paranoid sysadmin concerned with sequrity who wants to trust
absolutewly nothing. He would hate the idea that something stands between him
and his conf files...
Well, you get an idea.
Even Mandrake does not do things this way, and for the reason.
Now if you just want some frendly conf interface, there is a way to correctly
implement this (just as done in Mandrake, Suse and many other distros) -
create an appropriate tool (optional). That tool may even use some personal
database after it parses all config files, but leave these plain-text conf
files *authorative*. If you are really onto it you are welcom to create an
ebuild for linuxconf or even to try to strip Mandrake tools out of their
distro and create an appropriate ebuild...
Another point I want to make here (on the original 1 vs many files): it is far
more easier to update many files that a single big one. After all, when I do
etc-update I accept changes to ~60% files reject ~30% and have to hand edit
the remaining 10% only. Now, with a single file that would be about 100% :).
Also (and more importantly) it is far easier to check an updates (look through
diffs) to plain-text files rather than XML or anything else...
George
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Config Idea - take 2
2002-04-22 12:39 [gentoo-dev] Config Idea Yannick Koehler
2002-04-22 13:52 ` Todd Wright
2002-04-22 14:58 ` William McArthur
@ 2002-04-22 17:21 ` Yannick Koehler
2002-04-22 22:49 ` Terje Kvernes
2 siblings, 1 reply; 20+ messages in thread
From: Yannick Koehler @ 2002-04-22 17:21 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So far what I learned is that the whole system should be optionnal. It must
retain support for existing configuration files for several reasons such as
working with current applications. It must not gives a feeling of
duplication but still provide a comprehensive way for software to deal with
the various configuration.
The idea is evolving a little more. What if the system was not going to
create files, but was going to apply transformation rules from a given folder
when reading the file and then parsing it internally into xml to then use
inside some kind of application like merge or configurator.
So you'll have /etc which remains intact, a software that is optionnaly
installed with a bunch of transformation text file such as xslt which would
provide instruction to the software on how to parse the original file and
transform it into an xml one. Then using xml tools merge software could be
written and xml editor used. The xml then become a software interface and
never interfere with existing etc folder.
What do you think on that one?
- --
Yannick Koehler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8xEaZfuKOJNEyL1URApUIAKCkTrBXoDJC+m2zVMfGfnm+wWOxyACfbrq+
aryxixkijdj5YUixaeTpLq0=
=jJaO
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Config Idea
2002-04-22 17:16 ` George Shapovalov
@ 2002-04-22 17:44 ` Yannick Koehler
2002-04-23 1:22 ` Todd Wright
0 siblings, 1 reply; 20+ messages in thread
From: Yannick Koehler @ 2002-04-22 17:44 UTC (permalink / raw
To: gentoo-dev, George Shapovalov
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On April 22, 2002 01:16 pm, George Shapovalov wrote:
> I think this will be a very BAD, BAD thing to do.
> Imagine, you want to get a really small gentoo installation, where you do
> not want just anything extra...
> Imaging paranoid sysadmin concerned with sequrity who wants to trust
> absolutewly nothing. He would hate the idea that something stands between
> him and his conf files...
> Well, you get an idea.
> Even Mandrake does not do things this way, and for the reason.
For now thought I have to admit that a deamon which would translate the xml to
the old format would be seen as a danger to administrator and therefore
should be totally optionnal. Note thought that etc-update is also such a
tools that could make your config file all disappear if badly written. The
same apply to tools such as diff/merge and even to editors. So I guess that
real paranoid administrator use hexedit or tools that they wrote and have
investigated the byte code to ensure that their compiler didn't had
bugs/hacks. I don't think for paranoid because otherwise I would be myself a
paranoid and I wouldn't even had time to write down emails. So imagining
paranoid sysadmin is like imagining that I'm rich. Make me loose my time.
> Now if you just want some frendly conf interface, there is a way to
> correctly implement this (just as done in Mandrake, Suse and many other
> distros) - create an appropriate tool (optional). That tool may even use
> some personal database after it parses all config files, but leave these
> plain-text conf files *authorative*. If you are really onto it you are
> welcom to create an ebuild for linuxconf or even to try to strip Mandrake
> tools out of their distro and create an appropriate ebuild...
The conf file would have to stay authoritative as support for existing
software need to be maintain. I was in no way going to drop support for
existing application and therefore that argument was never an issue in this
idea. The idea was create equivalent xml files and hide from non-advanced
users the original one. Based on the feedback I'll have to promote the xml
one without touching the old one.
> Another point I want to make here (on the original 1 vs many files): it is
> far more easier to update many files that a single big one. After all, when
> I do etc-update I accept changes to ~60% files reject ~30% and have to hand
> edit the remaining 10% only. Now, with a single file that would be about
> 100% :).
It is actually not easier for everyone. It is easier once you've done it once
or twice so that you know which files you don't play with. But once you know
it then it also become easy to skip part of a single file if the tools that
you use present the different change inside that file in block. This is
exactly what xml can offer.
The simple fact that etc-update tool exists prove that handling many file is
actually harder than a single one. Otherwise that tool wouldn't have been
wrote or wouldn't be used by administrator or normal users.
> Also (and more importantly) it is far easier to check an updates
> (look through diffs) to plain-text files rather than XML or anything
> else...
Again this is a matter of tools, if you use text diff tools to see the diff
between xml files than yes it will be harder. The same is true if you use
XML diff tool to diff two text file it will be harder. Comparing a xml diff
tools with a text diff tool can only be done once we have example and because
at the xml level there's more information about what is what for the software
I can easily bet that an xml diff tools with valid template would be far
easier than text diff. The xml tool will be able to help you out during the
merge while the text diff can only hope that you know what you do.
And if you know everything about all the different config files without going
to your man pages or doing an edit of the file to see the various comments
inside the file then you won't use that configuration management tool.
- --
Yannick Koehler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8xEvxfuKOJNEyL1URAreDAJ912xO0LC9lBA/+m7xs39fUb2T6JgCggWSN
3ykQ23/O6NX937WlbUeU9gs=
=PVzw
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Config Idea - take 2
2002-04-22 17:21 ` [gentoo-dev] Config Idea - take 2 Yannick Koehler
@ 2002-04-22 22:49 ` Terje Kvernes
2002-04-23 13:47 ` Yannick Koehler
0 siblings, 1 reply; 20+ messages in thread
From: Terje Kvernes @ 2002-04-22 22:49 UTC (permalink / raw
To: gentoo-dev
Yannick Koehler <yannick.koehler@colubris.com> writes:
> So far what I learned is that the whole system should be optionnal.
if you're thinking "XML", yes. it should be.
> It must retain support for existing configuration files for several
> reasons such as working with current applications. It must not
> gives a feeling of duplication but still provide a comprehensive way
> for software to deal with the various configuration.
ick. this sounds a lot like marketspeak. honestly, the day someone
starts writing XSLTs for configuration files, I wish them pity. for
one thing, adding a single option in a given config suddenly
requires another DTD. another DTD which is in no way _really_
related to the previous one. maintenance becomes interesting. the
XSLT work also has to change.
second, we'd have the issue of verbosity. writing XML isn't
something you do easily during emerge. imagine wanting to port from
one version of the initscripts to another -- you might just want to
add one single variable. we'll need to require a full XML parser
just to do such a task, instead of adding a line to the end of a
file. unless this gives us a very large benefit, I don't see it
happening at all.
third. most configurationfiles are flat. very flat. with a very
loose order. changing this isn't a good idea in itself, it's not
needed to change either. using XML to store a very flat hierarchy
is usually overkill.
and fourth, and this is very general. KISS. things work very well
today. again, if we're going to change it, there should be some
great promise of good things happening. again, I don't see it. :/
> The idea is evolving a little more. What if the system was not
> going to create files, but was going to apply transformation rules
> from a given folder when reading the file and then parsing it
> internally into xml to then use inside some kind of application like
> merge or configurator.
whoa. this would make emerge optionally depend on a full XML
suite. fair enough, 4Suite mostly works, but why? and if it is
optional, will people use it?
> So you'll have /etc which remains intact, a software that is
> optionnaly installed with a bunch of transformation text file such
> as xslt which would provide instruction to the software on how to
> parse the original file and transform it into an xml one.
honestly, that XSLT-file I want to see before I will give it much
faith. I handcoded XSLT for a long while and I don't see this as a
trivial task. how many developers know their XML and XSLT well
enough to do this (properly)?
> Then using xml tools merge software could be written and xml editor
> used. The xml then become a software interface and never interfere
> with existing etc folder.
you'd have to interfere with /etc, otherwise inconsistencies would
emerge (okay, bad pun :) and all hell would break loose.
> What do you think on that one?
I think it sounds like the debates that happen now and then on using
XML in /proc on linux-kernel. it doesn't _give_ as much as it
demands. by far. if anyone can prove the gain from such a change,
I'd rethink my stance, but so far the idea scares me. it adds a lot
of complexity and solves very few problems, if any. :/
and no, I don't work with XML anymore. I happily got away from it.
two years of trying to make DTDs "fake" inheritance and deal with
version changes now and then got the best of me. if I was going to
rant about XML in general, and not about this specific issue, I'd
say "XML is very often the wrong solution to the wrong problem".
--
Terje
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [gentoo-dev] Config Idea
2002-04-22 17:44 ` Yannick Koehler
@ 2002-04-23 1:22 ` Todd Wright
2002-04-23 14:05 ` Yannick Koehler
0 siblings, 1 reply; 20+ messages in thread
From: Todd Wright @ 2002-04-23 1:22 UTC (permalink / raw
To: gentoo-dev
> > Another point I want to make here (on the original 1 vs many
> files): it is
> > far more easier to update many files that a single big one.
>
> It is actually not easier for everyone. It is easier once you've
> done it once
> or twice so that you know which files you don't play with. But
> once you know
> it then it also become easy to skip part of a single file if the
> tools that
> you use present the different change inside that file in block. This is
> exactly what xml can offer.
This is exactly what I have been talking about - experience. Would you hire a system administrator to configure your system who had NOT done it a few times? While agree that it is admirable that you are trying to cater for the newbies, they MUST learn this stuff. Doing it for them is not helping them learn. If they dont learn it, then they will have major problems the first time something breaks and they need to fix it.
> The simple fact that etc-update tool exists prove that handling
> many file is
> actually harder than a single one. Otherwise that tool wouldn't
> have been
> wrote or wouldn't be used by administrator or normal users.
No. It does not prove that. I may have been on the fence about one vs many earlier, but thinking about it I would much rather the many config files approach. It makes it simple to go directly to the file I want to edit without having to scroll through pages and pages of unrelated stuff. It also makes it impossible to break anything not related to the change Im making.
The etc-update tool does not prove that this is difficult. It proves that it is tedious to mass-update your system after installing a package makes 20 or more changes to /etc (which just happened to me). Presumably you have customised your system, and presumably new versions of packages add new functionality and coresponding new configuration parameters. You need to merge the new with the old, and etc-update makes that simpler by showing you the differences between the two. While I dont normally use etc-update, in this instance I will because it makes my task of merging new configuration with old simpler.
Imagine trying to edit a single file, keeping some older parameters that you have customised and adding new parameters at the same time. You have stated that the configuration would be generated from a single master xml file. You have even talked about such a tool to keep this master file up to date. Does that prove that handling a single file is more dificult?
You are contradicting yourself which proves to me that the idea has not properly formulated in your mind. You are comming up with arguments that do not make sense, simply to support your view, whichever way the wind blows it at the time. These are the tactics of a Troll. (no its not an insult - if you dont know what a Troll is, search a few mailing lists or ask in the newsgroups). I havnt made my mind up if you are serious yet or just Trolling. If you are serious, then when you do some more thinking about it, im sure you too will see its a bad idea.
-- _--_|\ --------- Todd Wright -- wylie@geekasylum.org --------
/ \
\_.--._* <--- http://www.dreams.darker.net/~wylie/
v Mobile: +61-403-796-001 Ph: +61-2-9521-8677
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Config Idea - take 2
2002-04-22 22:49 ` Terje Kvernes
@ 2002-04-23 13:47 ` Yannick Koehler
0 siblings, 0 replies; 20+ messages in thread
From: Yannick Koehler @ 2002-04-23 13:47 UTC (permalink / raw
To: gentoo-dev, Terje Kvernes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On April 22, 2002 06:49 pm, Terje Kvernes wrote:
> ick. this sounds a lot like marketspeak. honestly, the day someone
> starts writing XSLTs for configuration files, I wish them pity. for
> one thing, adding a single option in a given config suddenly
> requires another DTD. another DTD which is in no way _really_
> related to the previous one. maintenance becomes interesting. the
> XSLT work also has to change.
I have not heard about marketspeak, I will proceed with some research to see
how it fit inside my idea, thanks. I'd like more details on the thought that
you mention about a single option inside the config may require a whole new
DTD please so that I can validate that case and see how often it could occurs
and if there's anything existing that allow to go around it.
> second, we'd have the issue of verbosity. writing XML isn't
> something you do easily during emerge. imagine wanting to port from
> one version of the initscripts to another -- you might just want to
> add one single variable. we'll need to require a full XML parser
> just to do such a task, instead of adding a line to the end of a
> file. unless this gives us a very large benefit, I don't see it
> happening at all.
Again, please give me concrete example as I don't understand how adding a
variable will cause a need for a parser as XML is quite easy to use without
such parser.
> third. most configurationfiles are flat. very flat. with a very
> loose order. changing this isn't a good idea in itself, it's not
> needed to change either. using XML to store a very flat hierarchy
> is usually overkill.
You have to understand that I'm not going to replace a flat text file into an
XML file just for the sake of it. Actually in the current state the flat
file will be on the fly converted into an XML logical representation which
could be save as-is but most likely will not.
> and fourth, and this is very general. KISS. things work very well
> today. again, if we're going to change it, there should be some
> great promise of good things happening. again, I don't see it. :/
That may be true for you but not for me. The current state of the
configuration system still take up to 20 min. of my time to ensure config are
merged and their results is ok. That is for sure relative on which package I
uninstall/install and will be different for everyone of you. I actually
don't promise good things yet as I'm still very early and looking at the
details of what this represents and to evaluate if at the end the solution
will solve my current problems.
> whoa. this would make emerge optionally depend on a full XML
> suite. fair enough, 4Suite mostly works, but why? and if it is
> optional, will people use it?
!? Not sure I get your point here. There'll be 1 package which portage will
not depend on but when present portage could use. I believe that this would
be set using a keyword inside the USE variable and I have yet no idea as what
will be inside that package and the size of it. It will be for sure a goal
to keep it small and make it fast as with most software I work on, but the
primary goal will absolutely be to solve my issues such as
merging/unmerging/ease creation of config tools and at some point mix that
with an install tool.
> honestly, that XSLT-file I want to see before I will give it much
> faith. I handcoded XSLT for a long while and I don't see this as a
> trivial task. how many developers know their XML and XSLT well
> enough to do this (properly)?
I am not an XML/XSLT expert myself but I have learned in one day how the basic
system work and got a small example running with a single tutorial. There
seems to be plenty of those on the web and as more and more linux software
use XML, such as Web/Mozilla/KDE/Gnome etc., it makes me believe that there
will be a lot more tools related to those technologies in the very near
future.
XSLT doesn't seems to fit my idea of a general purpose transformation
languages as it seems to require an XML tree at the source to generate an XML
tree at the output. Something I'm thinking about is tranforming the flat
config into a keyword XML tree without processing instruction and then
applying templates on them, then reverse the process. But that's too early
to confirm XSLT will be up to the task.
I also have to make it a big point that the way the system is done it would
attract developer by its ease of use. And that's a point I need to work on,
how I will get that as simple as bash (well, actually that may be easy ;-)).
Maybe the kind of person who will help in that sector won't be ebuild
developers but web developers, which could possibly be a greater number of
people as I believe there's more web developer than there is bash developer
but that's not a fact but a thought.
> you'd have to interfere with /etc, otherwise inconsistencies would
> emerge (okay, bad pun :) and all hell would break loose.
For sure I will have to modify /etc content but again that will only be if you
use the tool. There's no point in making the system transform the /etc into
an XML logical representation to merge new config and then discarding the
results. I could easily make it output to a different folder and let you
switch between them to test. That could be a good way to let people
understand how the system works and to test it by having input, output and
merged and do compare.
> I think it sounds like the debates that happen now and then on using
> XML in /proc on linux-kernel. it doesn't _give_ as much as it
> demands. by far. if anyone can prove the gain from such a change,
> I'd rethink my stance, but so far the idea scares me. it adds a lot
> of complexity and solves very few problems, if any. :/
Yes it does, but sometimes the benefit cannot be understood until the system
is actually in place. Right now I see ease of merge with ease for software
installation and from a point of view of an administrator or a developer
those means nothing as he's doing there steps and they are happy with the
current state. For that to make sense you need to get at a different level
where the user is presented and they set up their system. If you want them
to go use some other distro fine but you can't force them, I'd actually like
that more people use gentoo even if they don't know all about Linux, first
they can learn (yes even with such an idea as I got) and they'll generate a
demand on you guys to continue to keep the pace with creating ebuilds.
> and no, I don't work with XML anymore. I happily got away from it.
> two years of trying to make DTDs "fake" inheritance and deal with
> version changes now and then got the best of me. if I was going to
> rant about XML in general, and not about this specific issue, I'd
> say "XML is very often the wrong solution to the wrong problem".
I can't argue with you as I have no experience (except 1 day) with XML. I'm
based myself on the description/purpose of those languages and from what I
experienced with them. That languages has been made as I understand to allow
software to understand content other than their mime-type. From that point
on software can do mostly anything and that's probably why it has not taking
off yet as it has not been clearly define what the software can do as there's
no limitations.
Some additionnal things that I could add as a secondary goal to the config
system could be to remotely configure it or to configure multiple computer at
the same time while only modifying certain parameters that are really system
specific that may help on the clusterisation etc... If software understand
what attribute are unique per PC and which could be duplicated on all PC then
you make it feasible to have central configuration for all your PC without a
single duplication in your configuration tools (the duplication exists
thought when you press the 'do it' button and that it generate the /etc in
the different PC but that may even dissappear if people get to like XML)
- --
Yannick Koehler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8xWXmfuKOJNEyL1URAuEWAKCPUzIwBrhi3CVHBcJ6PvtGd6X1LgCfQWrX
h9RtW8WDvlPTyWl1cihQi5g=
=satu
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Config Idea
2002-04-23 1:22 ` Todd Wright
@ 2002-04-23 14:05 ` Yannick Koehler
0 siblings, 0 replies; 20+ messages in thread
From: Yannick Koehler @ 2002-04-23 14:05 UTC (permalink / raw
To: gentoo-dev, Todd Wright
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On April 22, 2002 09:22 pm, Todd Wright wrote:
> This is exactly what I have been talking about - experience. Would you
> hire a system administrator to configure your system who had NOT done it a
> few times? While agree that it is admirable that you are trying to cater
> for the newbies, they MUST learn this stuff. Doing it for them is not
> helping them learn. If they dont learn it, then they will have major
> problems the first time something breaks and they need to fix it.
I realize that there's system administrator. But realize that there's not
only system administrator. And while I agree that people need to know more,
I simply don't agree on forcing them, I'd like that they have the
opportunities and Gentoo is a great one but that they could start whenever
the want and when they feel tired they can still go ahead and use that distro
and continue another time. That's the idea now it is not always such a big
deal but I do like that idea, it is about choice.
> > The simple fact that etc-update tool exists prove that handling
> > many file is
> > actually harder than a single one. Otherwise that tool wouldn't
> > have been
> > wrote or wouldn't be used by administrator or normal users.
>
> No. It does not prove that. I may have been on the fence about one vs many
> earlier, but thinking about it I would much rather the many config files
> approach. It makes it simple to go directly to the file I want to edit
> without having to scroll through pages and pages of unrelated stuff. It
> also makes it impossible to break anything not related to the change Im
> making.
>
> The etc-update tool does not prove that this is difficult. It proves that
> it is tedious to mass-update your system after installing a package makes
> 20 or more changes to /etc (which just happened to me). Presumably you have
> customised your system, and presumably new versions of packages add new
> functionality and coresponding new configuration parameters. You need to
> merge the new with the old, and etc-update makes that simpler by showing
> you the differences between the two. While I dont normally use etc-update,
> in this instance I will because it makes my task of merging new
> configuration with old simpler.
I have not customized my system in term of configuration much but it still
require me time to merge those file and normally it shouldn't. It looks kind
of stupid to me that a computer cannot figure out how to merge those simple
config file and require my time to do it. In this way I may have been
incorrect to use the word simple as what I meant from the begining is making
my life simplier which meant to remove the headache of playing around with my
config when I didn't want to change anything related to it but at the same
time get the new stuff in and fixes only.
> Imagine trying to edit a single file, keeping some older parameters that
> you have customised and adding new parameters at the same time. You have
> stated that the configuration would be generated from a single master xml
> file. You have even talked about such a tool to keep this master file up to
> date. Does that prove that handling a single file is more dificult?
You are right, it doesn't prove it. Again I wrongly explained myself and I
apologize. My thinking was that a tools based on a file that can tell more
than being a text file would allow a better merging tool and that would make
it easier to use than an existing diff/merge tool. The single/multi file I
don't talk anymore as it looks obvious that no one want a single file.
Software thought seems to work best on a single representation of files and in
this way I keep the idea of a single logical representation of those multiple
files.
> You are contradicting yourself which proves to me that the idea has not
> properly formulated in your mind. You are comming up with arguments that do
> not make sense, simply to support your view, whichever way the wind blows
> it at the time. These are the tactics of a Troll. (no its not an insult -
> if you dont know what a Troll is, search a few mailing lists or ask in the
> newsgroups). I havnt made my mind up if you are serious yet or just
> Trolling. If you are serious, then when you do some more thinking about it,
> im sure you too will see its a bad idea.
That is true, as I've mentionned before and still mention recentely I am
thinking about the idea and request comments. I am seeking points that I'll
need to work on more than others, some may defines that as priorities in
order to setup a proof of concept.
- --
Yannick Koehler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8xWo5fuKOJNEyL1URAnqGAJwJaop+usVGsd/Y/9g08IwY11NQpgCgkOjk
9KSxDxXJsXDdect37hg8G28=
=NO0x
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Config Idea
2002-04-22 16:33 ` Alexander Gretencord
@ 2002-04-23 17:14 ` Damon Conway
0 siblings, 0 replies; 20+ messages in thread
From: Damon Conway @ 2002-04-23 17:14 UTC (permalink / raw
To: gentoo-dev
On Mon, Apr 22, 2002 at 06:33:15PM +0200, Alexander Gretencord wrote:
> On Monday 22 April 2002 17:46, Yannick Koehler wrote:
> > I personnaly switched to Gentoo because I can upgrade my system faster and
> > ensure that I'm running the latest version of the software I run in order
> > to help testing and get security and other different fix fast.
>
> That's why I made the final step from Slackware to Gentoo. But as I stated,
> gentoo _is_ meant for advanced users, that the first thing you get told in
> the "About Gentoo" document.
Gentoo is a flexible metadistribution. It can be many things to many
people, and I think it will be able to meet the expecations of both the
novice and advanced user.
> You can try to make configuration easier but don't kick *nix for it as
> someone else put it already.
I see no reason why there cannot be a graphical interface to portage, or
for the install. By the same token, I see no reason why the current
method has to be affected if such an interface is written. There really
is no reason to shun users especially if devs are willing to write the
code to support them.
These ideas are not new to Gentoo (or Linux for that matter), and they
will be dealt with in time.
kabau
--
"UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things." --Doug Gwyn
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2002-04-23 17:14 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-04-22 12:39 [gentoo-dev] Config Idea Yannick Koehler
2002-04-22 13:52 ` Todd Wright
2002-04-22 14:20 ` Yannick Koehler
2002-04-22 15:11 ` Todd Wright
2002-04-22 15:26 ` Alexander Gretencord
2002-04-22 15:46 ` Yannick Koehler
2002-04-22 16:33 ` Alexander Gretencord
2002-04-23 17:14 ` Damon Conway
2002-04-22 16:53 ` Todd Wright
2002-04-22 14:20 ` Alexander Gretencord
2002-04-22 14:31 ` Yannick Koehler
2002-04-22 14:58 ` William McArthur
2002-04-22 15:26 ` Yannick Koehler
2002-04-22 17:16 ` George Shapovalov
2002-04-22 17:44 ` Yannick Koehler
2002-04-23 1:22 ` Todd Wright
2002-04-23 14:05 ` Yannick Koehler
2002-04-22 17:21 ` [gentoo-dev] Config Idea - take 2 Yannick Koehler
2002-04-22 22:49 ` Terje Kvernes
2002-04-23 13:47 ` Yannick Koehler
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox