[npunt]

Yep, as much as we want hardware and software to be conformant to whatever standards exist, in practice an important part of the job of a production OS is to work around the myriad quirks of hw/sw users will likely encounter. Standards are the input, experience is the output, and users judge on output. Related is yesterday's post about ensuring DOS app compatibility in Win95 [1]

[1]: https://news.ycombinator.com/item?id=37311508

[sho_hn]

Linux contains lots of code to work around a myriad of EDID quirks (and loads of other HW quirks), too:

https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...

There certainly isn't any big philosophical point to make here, Linux doesn't take a hard stance of expecting correct HW.

Ultimately this is a symptom of (1) bugs happen (here, at LG) and (2) Linux has a lower market share and therefore sees less testing. It's certainly fine to say "then I will use Windows to run into statistically fewer problems", so long as you're aware the same argument applies to any entrenched incumbent. As mentioned earlier, it'd have applied to MSIE in 2005 as well.

[llimllib]

> As mentioned earlier, it'd have applied to MSIE in 2005 as well.

What's funny is, I was around in 2005 and had already adopted Firefox well before it was called Firefox. (I was also around for the release of IE 4, and spent half a day downloading it on our 56k modem on release day! Exciting times.)

That's because the web is what I work on, and I am OK taking on buggy/beta stuff in the web domain because I learn useful things.

In the OS space, I was a linux user for a decade before I realized that I was wasting tremendous amounts of time and energy debugging stuff very like this monitor issue, and getting no transferable benefit out of it.

I switched to mac at the time, and have experienced vastly less of this sort of configuration nightmare since.

I love linux and I root for it, and occasionally I still try to switch again, before I end up having to figure out this sort of issue that just empirically doesn't exist on my mac, then I get sad and switch back.

[sho_hn]

I think that's fine and a respectable choice. I think it's even OK to argue that Windows has a value prop as a paid product because MS spends more effort on HW-specific quirks handling, or arguments along those lines.

Still, I think it does matter what's technically going on and where the fault lies. I also think that just like browser diversity, OS diversity is a net positive for the enforcement of good standards that makes things work better for users overall.

For example, I'm willing to bet (and it's because I know cases of it :-) that many PC peripherals work better on Macs because Linux existing has made HW-manufacturers more standards-conscious than a Windows-only world would have, especially since so many HW/embedded engineers run it.

> I was wasting tremendous amounts of time and energy debugging stuff very like this monitor issue, and getting no transferable benefit out of it

You got me there - in my case it lead to a career of making cars, phones, game consoles and other stuff running Linux, so I guess the over-under on the direct utility shakes out a bit differently here :-)

That said, it's been a very long time since I've done any fiddling/debugging to make any HW work privately. Ironically, I've had a lot more issues making HW work correctly on the M1 Mac I also have, e.g. my (quirky) Bluetooth earbuds work a lot better on PipeWire than macOS ...

[wzdd]

Linux* actually does have a tendency towards more hardline stances, simply because it's not answerable to market forces in quite the same way. For example, say 0.5% of monitors out there have dodgy edid values like this. For a commercial OS, that's a lot of unhappy people, many of whom have social media accounts, so "When displaying a new resolution, always start at max(60Hz, lowest available refresh rate) so if something's wrong people can at least see what's going on" might be a good rule of thumb for a commercial OS.

For Linux, however, the equivalent might be "report the bug so an exception can be made for this specific monitor". In other words, it's less important that everybody be immediately happy, as long as bugs can be reported and eventually fixed.

* Shorthand for any OSS kernel and its associated ecosystem

[hedora]

I’ve seen many more monitor compatibility issues under MacOS than Linux, and have plenty of older hardware that works with reverse engineered Linux drivers, but no longer works with Windows.

I think the common case is that vendors test with the current version of Windows, MacOS and/or Linux (in decreasing priority order), then hope that it the hardware is EOL’ed before the drivers bit rot.

[TillE]

This reminds me of a recent complaint about some software which didn't work properly with a certain sync service, and the developer response was that the third-party service was buggy so it wasn't their problem.

Ok, but personally quite a lot of my job involves working around the bugs and quirks of old unmaintained Windows OSes. The customer rightly doesn't care, they just want your software to work. It is almost always possible to at least mitigate the problems of whatever buggy garbage hardware/software you have to deal with.