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----- |