Gentoo Archives: gentoo-dev

From: Yannick Koehler <yannick.koehler@××××××××.com>
To: gentoo-dev@g.o, Todd Wright <wylie@××××××××××.org>
Subject: Re: [gentoo-dev] Config Idea
Date: Tue, 23 Apr 2002 09:05:47
Message-Id: 200204231005.46603.yannick.koehler@colubris.com
In Reply to: RE: [gentoo-dev] Config Idea by Todd Wright
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA1
3
4 On April 22, 2002 09:22 pm, Todd Wright wrote:
5 > This is exactly what I have been talking about - experience. Would you
6 > hire a system administrator to configure your system who had NOT done it a
7 > few times? While agree that it is admirable that you are trying to cater
8 > for the newbies, they MUST learn this stuff. Doing it for them is not
9 > helping them learn. If they dont learn it, then they will have major
10 > problems the first time something breaks and they need to fix it.
11
12 I realize that there's system administrator. But realize that there's not
13 only system administrator. And while I agree that people need to know more,
14 I simply don't agree on forcing them, I'd like that they have the
15 opportunities and Gentoo is a great one but that they could start whenever
16 the want and when they feel tired they can still go ahead and use that distro
17 and continue another time. That's the idea now it is not always such a big
18 deal but I do like that idea, it is about choice.
19
20 > > The simple fact that etc-update tool exists prove that handling
21 > > many file is
22 > > actually harder than a single one. Otherwise that tool wouldn't
23 > > have been
24 > > wrote or wouldn't be used by administrator or normal users.
25 >
26 > No. It does not prove that. I may have been on the fence about one vs many
27 > earlier, but thinking about it I would much rather the many config files
28 > approach. It makes it simple to go directly to the file I want to edit
29 > without having to scroll through pages and pages of unrelated stuff. It
30 > also makes it impossible to break anything not related to the change Im
31 > making.
32 >
33 > The etc-update tool does not prove that this is difficult. It proves that
34 > it is tedious to mass-update your system after installing a package makes
35 > 20 or more changes to /etc (which just happened to me). Presumably you have
36 > customised your system, and presumably new versions of packages add new
37 > functionality and coresponding new configuration parameters. You need to
38 > merge the new with the old, and etc-update makes that simpler by showing
39 > you the differences between the two. While I dont normally use etc-update,
40 > in this instance I will because it makes my task of merging new
41 > configuration with old simpler.
42
43 I have not customized my system in term of configuration much but it still
44 require me time to merge those file and normally it shouldn't. It looks kind
45 of stupid to me that a computer cannot figure out how to merge those simple
46 config file and require my time to do it. In this way I may have been
47 incorrect to use the word simple as what I meant from the begining is making
48 my life simplier which meant to remove the headache of playing around with my
49 config when I didn't want to change anything related to it but at the same
50 time get the new stuff in and fixes only.
51
52 > Imagine trying to edit a single file, keeping some older parameters that
53 > you have customised and adding new parameters at the same time. You have
54 > stated that the configuration would be generated from a single master xml
55 > file. You have even talked about such a tool to keep this master file up to
56 > date. Does that prove that handling a single file is more dificult?
57
58 You are right, it doesn't prove it. Again I wrongly explained myself and I
59 apologize. My thinking was that a tools based on a file that can tell more
60 than being a text file would allow a better merging tool and that would make
61 it easier to use than an existing diff/merge tool. The single/multi file I
62 don't talk anymore as it looks obvious that no one want a single file.
63
64 Software thought seems to work best on a single representation of files and in
65 this way I keep the idea of a single logical representation of those multiple
66 files.
67
68 > You are contradicting yourself which proves to me that the idea has not
69 > properly formulated in your mind. You are comming up with arguments that do
70 > not make sense, simply to support your view, whichever way the wind blows
71 > it at the time. These are the tactics of a Troll. (no its not an insult -
72 > if you dont know what a Troll is, search a few mailing lists or ask in the
73 > newsgroups). I havnt made my mind up if you are serious yet or just
74 > Trolling. If you are serious, then when you do some more thinking about it,
75 > im sure you too will see its a bad idea.
76
77 That is true, as I've mentionned before and still mention recentely I am
78 thinking about the idea and request comments. I am seeking points that I'll
79 need to work on more than others, some may defines that as priorities in
80 order to setup a proof of concept.
81
82 - --
83
84 Yannick Koehler
85 -----BEGIN PGP SIGNATURE-----
86 Version: GnuPG v1.0.6 (GNU/Linux)
87 Comment: For info see http://www.gnupg.org
88
89 iD8DBQE8xWo5fuKOJNEyL1URAnqGAJwJaop+usVGsd/Y/9g08IwY11NQpgCgkOjk
90 9KSxDxXJsXDdect37hg8G28=
91 =NO0x
92 -----END PGP SIGNATURE-----