You mean many don't want to spend time bisecting and building the kernel with proposed fixes to test if they work?

If the bug really bugs them, they'll probably overcome the reluctance to do the above. Not sure if it's many, but it's usually enough in case it's not some obscure component of the kernel but something more widely used like amdgpu for example.

The more obscure the use case though, the worse it gets.

One of the phenomena the industry identified back in the Windows days was subconscious bug avoidance.

Some tech savvy people have a sense of what interactions with the OS are fraught and they steer themselves around them often without even realizing they are doing so. So you have one class of users who believe the system is much more stable than it really is, and an underclass who seem to bounce off every step as they tumble down the proverbial stairwell.

So the bugs that cannot be avoided get fixed and the ones that are avoided by the “elites” may escape their attention if not in fact their knowledge.

I feel this. I recently ran into a problem with a kernel update breaking Bluetooth on resume from suspend. My Logitech keyboard and mouse that I use at my desk stopped working after each resume, and I had to go to the laptop keyboard and manually stop and start Bluetooth. On each resume.

Look, I'd love to contribute to the kernel, but the amount of time I have to play around with these things is now measured in minutes per day. So no, sorry, I don't have time to rebuild my kernel from mainline, and then bisect, and then cherry pick patches, and then test out proposed updates, and then help shepherd it through my distribution's patching mechanism.

So I just gave up on Bluetooth on Linux and plugged in Logitech's proprietary Bolt dongle, and re-paired my devices with it, and haven't had trouble since. I'd prefer to use standard protocols, but this isn't the first time a kernel update broke my Bluetooth setup, so I think I'll stick with what just works.

Not really applicable to Linux kernel bugs, but I have a story of it being much harder than one would expect to convince my ISP (a generally cool company, as opposed to some behemoth telecom) that their payment system would allow me to pay them essentially nothing, but their system recorded it as a payment in full.

I pay my ISP using a method where I use an app on my phone to scan a QR code and I can then pay with my credit card (and get associated rewards).

For reasons of maximising my rewards, I decided one month to try split the payment and pay a small part with one credit card, and the remainder with a different one.

I opened the app, scanned the QR code, changed the default payment amount to about 10%. A moment later their system says “Thank you, paid in full!”.

I send customer service an email explaining that there is a flaw in their system which has allowed me to me to underpay.

Them: “Don’t worry, we can see you’ve paid us.”

I reply: “I really haven’t, you need to escalate this to someone technical over there to investigate this further.”

Them: “I can confirm you’ve paid.”

Fortunately for my ISP, I’m a good person and they have a presence on a local forum, I PM’d one of the reps on there who based on their posts was possibly one of the founders.

And he responds saying something to the effect of “thank you very much, I have no idea why customer service didn’t escalate this” and goes on to explain that the payment app evidently did not respect a flag in the QR code which should prevent me from editing the payment amount and he had fixed their code to actually check the incoming amount.

Same rep a few years later was able to resolve unstable Spotify streaming issue I reported by getting Akamai to fix their DNS resolution to use the PoP on my ISPs network as opposed to the one on a different ISPs network which was throttling their peering link.

I once worked at a mom-and-pop ISP back in the late 1990's. The previous sysadmin overloaded the UNIX password field in /etc/shadow to be used for account suspensions, when somebody wasn't paying their internet bill, the custom "Web UI" he built would allow the business owner to lock out the account by changing the shadow password field to "*", thus denying the user dialup internet access.

At least one customer figured out that they could call the girl at reception, tell her they'd forgot their password, and she'd reset the password for him, which restored his access without paying his bill for another month. He started to do this on a monthly basis.

The punchlines:

1) the front desk girl was the girlfriend of the business owner; you'd think they'd communicate about a customer who was getting away with this, and how they were doing it

2) the sysadmin who built this system went on to become a well known project leader for an major open source encryption project that is in wide use today

FWIW using * or ! in shadow to indicate lockout was a common thing; it's even mentioned in the man page for shadow.

There's a special meaning to x in the crypt field for passwd, too.

See pwconv.

I had some experiences with emacs that were like that. After 2 or 3 of those, I stopped bothering.