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.
"You must be the change you wish to see in the world."
-- Mahatma Gandhi
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!
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
--
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
