“Backwards compatibility” is a totally different thing from “cross compatibility”. Of course proprietary software is going to be less cross-compatible.

Good points, but there’s undeniably some poor choices here and there. Like trying to recompile a bunch of kernel modules every time the kernel version changes makes me wish they had a better system in place… or even worse , if you have a blob driver, you’re SOL or stuck on an old version.

never break user code

That’s a fine mantra to have but is rarely true in practice. I’ve seen way to many needlessly breaking changes in open-source libs that are explained away with “users can just pin the old version until they update their code”.

To be clear, the linux kernel itself is almost never the cause of the breakage per se, but some other library often implementing one of the APIs it defines. Often the reason for the breakage is under-specification of the original API, for example including a uint32 flags field that is not checked against a known set of valid flags, and inevitably ends up populated with vendor-specific (and often conflicting) usages.

As much as API design is about exposing the functionality you want, it also involves avoiding exposing functionality you dont’t want to expose. Open-source software often omits that critical design consideration, waving it away under the false virtue of “openness”.

Some super old version of GIMP will run on both XP and Win11.

I had to modify and recompile my laptop’s Broadcom WLAN driver for it to run on the latest kernel.

Fight me 🤪

If it “just works” with linux it’s probably using a standard protocol like LPR that you can just as easily use on MacOS without a driver. The driver is usually just for non-standard functionality like color level monitoring or scanner/AIO integration that you won’t get on Linux anyway.