I'd be more sympathetic to this argument, by a lot, if I wasn't constantly encountering bugs in systems where there wasn't (or shouldn't have been) any guesswork needed.
To (substantially) rephrase the point, you're saying "there's this additional source of bugs" without an argument that it's a significant enough source that it will stand out against the background of all the other sources of bugs.
There's also a strange flip side where abnormally competent people are doing the work, so I might even believe the bug-rate is likely lower than average.
> I'd be more sympathetic to this argument, by a lot, if I wasn't constantly encountering bugs in systems where there wasn't (or shouldn't have been) any guesswork needed.
In my experience, you can take any consumer PC (laptop or desktop), install Linux on it, and find a firmware or hardware bug or unsupported hardware feature in the time it takes to read through the kernel log. Often the broken functionality becomes obvious just from the process of trying to boot, log in, and type dmesg. Unless the broken feature in question stems from a component that is wholly unsupported, it is very likely that the flaw is a result of the hardware or firmware's behavior differing from what the documentation or relevant industry standard specifies.
So the status quo is that everybody is always deciding to live without some features that their computer "should" be providing based on its hardware capabilities. Of course, it's perfectly valid for some users to not care about a feature like having a working fingerprint sensor or sensible fan control or automatic brightness, and even more understandable for features that are less readily apparent to the end user (eg. idle power management). But when those gaps between theory/design and reality do get closed, it's usually a result of reverse engineering leading to an acceptable workaround, not the OEM coming back to finish the job.
reply