On Thu, Oct 31, 2024 at 10:40 PM Tim via users <users@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, 2024-10-31 at 19:16 -0500, Roger Heflin wrote: > > And note I was the person that worked the hard cases for a company > > with > 5,000 licenses, so if most senior linux resource at a company > > with that sort of licenses are getting this story then everyone else > > is screwed.. > > > > All paid gets you is the security updates and other new/package > > updates, the typical support is to blame the customer and give you the > > run around for months and maybe (or maybe not) fix it and/or simply > > hope the customer gives up. For almost everything else you are on > > your own. > > Reminds me of that court case where a business sued a computing company > over a product that never worked right. They *won* their case arguing > that they got the runaround, forever being asked to try updates that > didn't do much good, and, in their view, based on all their prolonged > experience, it was *never* going to get fixed. > The company we bought from had the policy that you had to have paid support to download firmware updates after the warranty expired. The court case for them not being free would be pretty bad if they got sued, since after the warranty period they were still fixing bugs that cause the product to not work Really stupid stuff like whena raid5/6 disk starts getting bad sector errors the firmware returns WRONG data. The people coding it seem to assume the disk will fail to respond (rare) and did not write code to handle a simple common bad sector. The crappy code of course "passed" testing because testing did not simulate the real world and have bad sectors. Typical bugs are in the exception/error handling code. The worst scsi bug I found (that redhat fixed--actually it looked like a kernel.orig developer really fixed it, 2+ years after we gave them kernel dump details) was when a scsi command timed out and was being canceled (but competed while being canceled) then a kernel corruption/crash happened. We had the bug often because we had multiple SAN arrays zoned to the same machine and sometimes under high load if 2 SAN arrays with say 8gbit ports each are trying to stuff data into a machine 8gbit port then data can be lost, and the SAN is designed for an unreasonable perfect world were data loss should not happen, but when it does happen it is pretty bad. The computer companies are lucky so far that they have not pissed off any of their customers enough that they do sue them because the court case would be ugly for the manufacturer as this entire ship software out the door barely passing the simple basic test case (and failing if anything happens--even stuff that is expected to go wrong) is not good enough. -- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
