On Thursday 16 October 2008, you wrote: > A lot of what you're saying is right, and is great advice to the > community. But in the time it took you to write that 5000+ word > email you probably could have written the patch and submitted it.
1) I'm a writer by avocation. Honestly, it's much easier for me to write a 5,000 word email than a 500 word one. I'll refer you to Churchill's quotation about how long it would take him to write a long speech vs. a short one. > "You must be the change you wish to see in the world." > -- Mahatma Gandhi Actually, that's a good part of what I'm doing. > If you'd "love to see something happen," why don't you just write the > patch? It would take you 15 minutes, it would probably be accepted > (or at least a variant would be), and then the problem would be fixed > and you wouldn't have anything to complain about! Because it's about much more than the patch itself. Go back and read the thread, starting with a post or two before the topic changed to see what I mean. Hal > Cheers, > > Eric > > Hal Vaughan wrote: > > On Wednesday 15 October 2008, you wrote: > >> Hal Vaughan wrote: > >>> Both of your comments involve disagreements over differences of > >>> opinion -- but I can see where you're coming from and I think the > >>> point about rewording the warnings in menu.lst would go a long > >>> way toward addressing the issue that led me to file the bug > >>> report. > >>> > >>> If filing the bug report had led to that kind of discussion, I > >>> would have felt much better about it than I did when I decided to > >>> just give up. I can deal with a disagreement. What I found > >>> frustrating was that it felt like the focus was only on > >>> justifying why the bug was elsewhere and there was no need to > >>> pursue it. > >> > >> So it sounds like one possible solution that is agreeable to most > >> in this discussion is to improve the documentation on menu.lst. > > > > I'm not sure it's a permanent solution or a step toward it to my > > thinking. I discussed this with a friend of mine who's RPM-centric > > and his comment was that RPM just automatically overwrites the > > config files (apparently with backing them up first) and we went > > over several topics. One comment he made stuck with me. It was > > something close to, "It just doesn't work to tell people how they > > have to edit a config file." The more I think about it, and think > > about FOSS, and how the F is for "Free as in speech," the more I > > think that is in line with comments and reactions from people who > > use FOSS and why they may use a version of Linux or BSD instead of, > > for example, Windows. > > > > Often I've heard (or read) people say the purpose is to enable > > people to have control over their computer, instead of letting > > their computer have control over them. Isn't that a major part of > > what FOSS is all about? > > > > And now we're saying, "But you should do it this way, otherwise, > > you're shooting yourself in the foot." Yet I've seen many times > > along the way where people were doing non-standard things for > > dozens of reasons. Maybe it's because those were the "good ol' > > days" when people were still pioneering and experiment. Or maybe > > things have gotten so tame and standardized in FOSS that there are > > now ways we're all supposed to handle different things. > > > > This friend is an admin, not a programmer, not a developer. He > > handles web hosting and setting up systems for other people. He > > reminded me of some of my points and how, along the way, those seem > > to have gone from important to not as important -- like the one > > about freedom. > > > > Here's an example: If I edit my CUPS config and update CUPS with > > apt-get, I'll get a prompt. Many of us have other things on our > > minds other than the systems we're administrating. For many of us, > > the computer is the tool, the means to the end, not the end in > > itself. In such cases, we can do something like apt-get upgrade > > and forget that it'll overwrite some of our config files. Apt has > > taken that into account and prompts us. When we get a prompt about > > overwriting the CUPS config, we'll remember, or we should. > > > > We can choose: Do we want to upgrade that file or not. We can keep > > our modifications that may be in there for whatever reason we want > > or we can give them up. > > > > Now it's true we can do that to a point with menu.lst and that > > there are ways to include changes so they're not overwritten, but > > on the other side, is the point of Debian and FOSS to tell people, > > "Handle it like this or ELSE!"? Or is the point to enable people > > to handle their systems with some sense of freedom and to make sys > > admin less dependent on our attention or more demanding of our > > time? > > > > Those are two important questions: Is the goal to tell people how > > to handle their config files or to let them make their own > > decisions? And is the goal to save effort or to require effort? > > > > Some will say, "But you have a choice. Do it wrong and get hosed > > or not." Not a valid choice. That's the same as, "Do it our way > > or get burned." And therein lies the road to mediocrity: turn > > control of your admin decisions over to the OS creators. If I > > wanted a computer that did that, I'd shell out several hundred and > > torture myself with a commercial OS. > > > > As it is, the choice we do NOT have is if we can experiment with > > that file without fighting our own computer. If we get a notice, > > "Upgrading or adding this package will overwrite > > /boot/grub/menu.lst," then we have a choice. Then, before apt > > automatically overwrites that file, we know it'll happen. Without > > such a prompt, it's a crap shoot. We can edit that file and > > *think* it's safe because we know we won't run update-grub (or is > > it grub-update -- I keep forgetting!). Yet it isn't safe because > > there are cases where that will be run without our knowing. > > > > So it comes down to where is the point where it's okay to overwrite > > a file the user/admin has edited and wipe out any comments or > > changes they've put in and where is the point where we should > > respect the admin's changes. > > > > Yes, many people say, "It's your problem." If that were true and > > the best way to do it, then it would be our responsibility to > > manually handle backing up all configuration files before an > > update. It isn't. That, in itself, shows us that the idea behind > > apt, as opposed to RPM, was to let people make their own choices > > and not assume/presume to make their decisions for them or tell > > them how to handle their config files and overwrite their changes > > with any update with the system's "good" config file. > > > >> I've found the best way to get something fixed in an open source > >> project is to develop a patch. Since this is documentation, it > >> wouldn't be that hard. You can find the default menu.lst around > >> line 260 of > >> /usr/sbin/upgate-grub. > > > > I've filed bug reports where I didn't know the language or enough > > of what was going on to write a patch but was able to specifically > > point out where the bug was and what it would take and still been > > blessed out because it was a "feature" (even when it was clear it > > was fubar). > > > >> I don't know how knowledgeable whoever decides to do this is, but > >> I can help a bit with the process if needed. I'm not a DD, but I > >> do file bugs from time to time. :-) > >> > >> Heck, one could even reopen the old bug, move it to grub, attach > >> the patch and hope for the best, but there's already another bug > >> that's very similar and might welcome such a patch (and a link to > >> this discussion): > >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383282 > > > > I'd love to see something happen, but, honestly, I've found it hard > > enough to just explain my point of view here and had a big enough > > hurdle getting some people to see what the issue was that it still > > leaves me with that feeling that I just don't feel like having to > > go through that whole thing with trying to fight someone in a bug > > report. > > > > I will say, though, that a lot of people in this discussion have > > been great to exchange ideas with because they could deal with the > > actual topic at hand and present some good points. > > > > > > Hal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
