[ltp] The fix is in -- kernel fix that is...

[Dan Saint-Andre]

On Tue, 2013-07-16 at 12:01 +0200,
linux-thinkpad-request@linux-thinkpad.org wrote:
> You say you're running a business and you can't afford the risk
> of using bleeding edge kernels?  That's when you have to pay $$$
> support to distribution company.  There are real costs involved with
> backporting patches to older kernels, since while *you* might consider
> a patch a critical one to backport, for *other* enterprise customeres
> it's a patch which might cause regressions on their systems.  So there
> are huge costs involved when enterprise distro's have to test patches
> to make sure they don't cause problems for any of their other paying
> customers.
> 
> If you are using an enterprise distro, such as Ubuntu LTS, or RHEL,
> but you're not paying the support costs, you're a free-rider.  So you
> can report a problem to Ubuntu or Red Hat, and you can request that
> they backport the feature, but since it costs them real money to
> backport and QA a fix, if you're not paying them any more, why would
> you expect that they would treat your request with anything other than
> the lowest priority?
> 
> The frustration from the technically proficient people is that uppity
> users are demanding that they provide free services for no cost.  It
> may be that we'll backport fixes to the stable kernels, on a best
> efforts basis, but then someone still have to build the stable kernels
> and package them for Ubuntu, Red Hat, etc., and someone still has to
> test and run quality assurance on the stable kernels.
> 
> Regards,
> 
>                                                 - Ted
> 
I paid for support from two different "enterprise" vendors. I got
precious little results. In spite of my hardware's listing in various
compatibility lists for the distro involved, the support folks always
seemed to find something resulting in "... we don't support that ..."
(No surprise -- support folks do this for clothes washers and
entertainment systems, "... we only support the -C-42-Q4- model ..."
etc, why not workstations?)

I joined various email lists. I read all sorts of posting and forums, I
have accounts with the bug reporting sites. I try to contribute within
my skills and available time.

I found "developers" for one troubled sub-systems (suspend-to-ram and
suspend-to-disk). After weeks of effort, and numerous emails, no one ***
absolutely no one *** was able to offer any directions to enable even
modest data collection, logging, and such. Yes, I could read the code or
run the kernel in debugger modes. Given that win-dose (win-doze)
"sleeps" and "hibernates" without fault tells me that the hardware
works. This tells me that there is something on the Linux side that is
not working for my hardware. If I knew how to gather the data, I'd
experiment and report all that I learn.

Don't dismiss me and say, "... well go use win-dose if you like it so
much ..."  I don't LIKE it, but it runs my hardware correctly. Those
facts offer a set of data points:  some sort of software will correctly
(or adequately) operate hardware features F1 ... Fn. A Linux end-user
with modest technical skills deserves functionality that will at least
gather information about what is happening so that they can submit an
acceptable bug report. There are a large number of reasons why this same
end-user might not be willing or able to "read the code."

Regards,
~~~ 8d;-/ Dan
>