Re: Long File Path support
I pretty obviously wasn't talking about hardware compatibility.
Linux devs change APIs with great regularity without any concern for backwards compatibility, and that's a pretty well-known thing. I can run ten year old binaries on Windows without issue now; on Linux, you're lucky if you can do that with binaries a third of the age. Don't let your Linux fanboyism blind you to the deficiencies of Linux; the problems it has can't be overcome by pretending they do not exist. There's little hope for Windows, but Linux at least can evolve in the right direction (and generally it is, if slowly).
In Linux, the typical dev attitude is that since the source code is available for the program in question, it doesn't matter if the APIs change, just recompile it with whatever is the newest version of gcc, Xorg, what have you (often systemd, to the chagrin of many). That's great if you're the kind of person who can recompile things at will and if the program in question is actually open source, but those two things are not always going to be true, particularly if Linux is ever going to exist in significant numbers on the desktop. It certainly doesn't work with things like proprietary video drivers from AMD and nVidia, with their binary blobs that prevent drivers a few years old from working with recent distros. A lot of older GPUs don't have Linux drivers newer than that, so you either run the open source driver (often slow and lacking in features, including power management on laptops) or use a distro release that's several years old.
The idea that requiring users to recompile their programs 'cause we done just broke all the APIs again isn't compatible with the way regular people use computers. As a niche hobbyist OS, that kind of thing is fine, but if the idea is to compete with Microsoft head to head on the desktop, it's not going to fly. Linux is going to have to work with closed-source precompiled binaries if they want to get any traction on the desktop. Precompiled binaries that people have to pay for means they are going to want to keep using them for years; no one wants to pay hundreds of dollars for a program (precompiled binary, as is the norm with closed-source) only to have it go out of date in six months because the APIs it relies on have changed because reasons.