Verily I say unto thee, that François Patte spake thusly:
> Keith G. Robertson-Turner a écrit :
>> Verily I say unto thee, that François Patte spake thusly:
>> [snip rant]
>
>> 1. The kernel is in a constant state of flux. Some versions work
>> well on most hardware, and some don't. If an updated kernel does
>> not work on your hardware, then simply reboot back into the
>> previous one, and be happy. There is no law that forces you to use
>> new kernels, unless your current one is lacking in some way. If the
>> kernel you use now works, then keep it. End of story.
>
> In that case I don't understand too much many warnings about too old
> versions of softwares.... You can read these warnings on this list
> and on some others.
>
> I believe, but I seem to be wrong, that a new version is done to
> correct and enhance previous ones, not to make what was working no
> more working.
This is sometimes true, sometimes not. Often an "update" is actually the
*addition* of features (e.g. in the case of the kernel - new hardware
support). By adding features, one invariably adds bugs. In fact simply
by fixing bugs, one invariably creates others. E.g.:
9 little bugs in the code
9 little bugs in the code
Fix one bug, compile it again
10 little bugs in the code
Unless you read about a *specific* security vulnerability then there may
be no reason to upgrade the kernel, *unless* you are currently having
difficulties with that kernel.
It *is* important to keep up with *security* updates, and obviously
you'll want updates that address stability (bugs) issues, but don't feel
pressured to update a package just because it's "there".
There will be occasions where you don't have a choice, because in order
to install or update a particular package you *need* another to also be
installed or updated so as to meet dependencies. Previous examples of
that in the kernel include udev and SELinux.
I have machines on my network with uptimes in excess of three years, or
IOW no kernel updates for three years, and all those systems work
perfectly well, so trust me when I say updates are not always
*essential*, although they may be *desirable*. YMMV.
This is why I stress that if you update a package (in your case - the
kernel) and it has severe issues, then the solution is not to rant about
it, but rather:
1) ... Go back to the previous (working) kernel.
2) ... File a bugzilla report.
3) ... Discuss (amiably) this issue with others, who *may* have a
solution or workaround.
4) ... Have a coffee and relax.
>> 2. As much as I'm sure there are some very helpful people in the
>> group, you're unlikely to get much help with a rant, especially one
>> severely lacking in detail. Keep it calm and clear and you may get
>> an answer.
>
> I put in my message all what I was aware of: even turning the
> log_error to "debug" in dev.conf file, for instance, did not give
> other information about my usb scanner.
>
>> 3. This is not a bug reporting service. See bugzilla.redhat.com.
>
> Before reporting a bug, I want to know if it is really a bug, not
> something misconfigured. I sent on the list the error codes returned:
> what are these codes if you can't find their meaning somewhere (and
> not in the 300Mb man pages you refer to).
I saw the OP in this thread, but not the previous message. One little
detail that's missing is the kernel *version*, which is in this case
absolutely essential for determining the (possible) cause. IIRC you also
missed the sequence of steps needed to reproduce the given errors
(specifics are important).
In any case, let me repeat ... this is not a bug reporting service, and
there is no one here under any contractual obligation to even read your
messages, let alone answer them. Most of the people here are just
ordinary users, *not* devs ... although there are a few devs who monitor
this list too.
As for man pages ... it is my considerable experience that if one
carefully reads the documentation for any given problematic component,
then the solution presents itself quite readily, even if specific error
codes are not explicitly mentioned.
As a recent example, I had difficulty using a tool called "nut" (Network
UPS Tools) on one of my servers. As far as I could tell, the
configuration files were perfectly correct, but it produced an error
stating that it had "lost communication with the UPS" every time it
started (from init). After reading the documentation I discovered that
the actual initscript was calling upsd using the wrong flags, so I
edited the script and now it works. Actually that reminds me - I should
file a bug on that ;)
>> 4. "Threatening" to switch distros unless your demands are met,
>> will likely just result in a good hearty laugh all round, followed
>> by the traditional "don't let the door hit your ass on the way
>> out". Even the infamous Eric S. Raymond didn't impress with that
>> stunt, so I doubt anyone else can.
>
> OK! I apologize... I don't want to be kicked out in my ass! Though it
> is difficult to accept that things that were working are no more
> working after an update. I use redhat/fedora since redhat 5 and it
> used to go better and better.... I am not sure that it is still the
> policy when I read here some messages about fc6 and now f7....
Heck, I'm still using Red Hat 7.3 on some machines, which was for many
the pinnacle of Red Hat on the Desktop. I'd say that the many technical
innovations since then, make modern Red Hat/Fedora systems a very
worthwhile upgrade, although you still need to beware certain issues
like bloat and featuritis. I even have one using 5.1 (Manhattan) on
Motorola 68K hardware running at a whopping 8MHz, which I very much
doubt would run Fedora 7 :)
Updates are optional ;)
>> Bonne chance.
>
> Merci.
Je vous en prie.
--
K.
http://slated.org
.----
| "Our enemies are innovative and resourceful, and so are we. They
| never stop thinking about new ways to harm our country and our
| people, and neither do we." - George (Dubya) Bush.
`----
Fedora release 7 (Moonshine) on sky, running kernel 2.6.21-1.3194.fc7
15:02:35 up 1 day, 7:59, 3 users, load average: 0.05, 0.17, 0.24
