Post by Andreas Radke
Am Wed, 4 Aug 2010 09:22:41 +0100
Post by Peter Lewis
WARNING: Constructive part of the post!! :-)
Post by Andreas Radke
If you think you need a list of packages to remember where you
should interact, go on and create one your own.
Absolutely, why not? If someone really wants to implement this, why
not have a flag set somewhere that tells pacman whether you want
"package hints" or something turned on. Then let packages set a one
line package hint. Not for everyone, but some people with poor
memories (like me) might find it useful.
Read again the Arch way: You make it what you want. We don't know if
you install a pkg like dovecot to work on its documentation, to code
stuff depending on its libs or headers or if you want to use it in
its main direction as a daemon.
Why should we make Arch more and more complex just to satisfy a few of
you with things that are almost self explaining???
If you run a daemon or application that gets upgraded it's first your
fault you didn't stop it before and 2nd your task to decide after
reading the Changelog/commit-list if you have to solve your mistake by
restarting the stuff.
One of the things I've learned with Arch is system administration. A
talent I lost when I moved from DOS to Windows and one of the things
I've learned to dislike about most of the major Linux distros. It's
much easier to to the work when you do the install than when another
persons version of how your box is set up breaks your box. As to
making a list of things to do on upgrades, I made my own but It's only
relevant to my machines and the software I have installed. Now I'm
working on an install list and a package dependency list for all the
software (started prior to the latest pacman release that grabs the
deps for you when using makepkg). I have an extremely poor memory
that's why I made my own lists. It's up to you the user to know how to
maintain your own system.
IMHO the Arch way is great.
Now to step on some toes, both sides. Years ago I was pointed to esr's
"How to ask questions the smart way". His philosophy is excellent and
very relevant and provides many insights to developers. It took a long
time for me to realize just how annoying someone can be. It also made
me realize some of Gnome/Ubuntu's etc canned responses to filing bugs
isn't a bad idea. If someone files a bug with little or incorrect
information, they get a simple reply requesting the information they
need. Not sure that would work on a mailing list, but it might be the
way to go. It would let the user know they need to provide more info
and possibly keep the agitated responses from developers down.
I realize the developers are very busy and only work on Arch when they
have time. They don't always have time to go through the twenty
question routine of normal tech support and I appreciate that. I also
appreciate the job their doing in making Arch the best Linux distro
around. If someone were trolling, I can see an extremely tacky
response. If someone just doesn't get it, I can see an extremely tacky
response. I've seen some individuals like that on this mailing list.
That makes it easier to understand tacky responses. The best response
is the one you think about before firing away, no matter how agitated
you are. I know that for a fact. After thirty years working in the
oilfield service business, I given and received many quick agitated
responses. A lot of them to the wrong people.
Just my 2c worth.
Life's fun when your sick, psychotic, adhd challenged, and see the
world in a different way.!