(no title)
amenod | 3 years ago
So it's your vendor who doesn't care about backwards compatibility - Linux does. Whatever hardware you have, once it was supported, it will stay this way until it is really ancient, and even then you will have special builds that will support it. That's the beauty of open source (or even source available) licenses. No corporate interests that would render your solution obsolete. [0]
[0] assuming your hardware doesn't need some binary blobs (khm nvidia khm) to work
shadowgovt|3 years ago
(b) If Ubuntu (and I'm going to say "the Linux ecosystem in general") cared about backwards compatibility in the same sense Windows does, a minor-version bump to glibc wouldn't introduce API breakages that mean I can't build a codebase that's doing nothing new and special on my machine right now purely because a 31-subver bumped to a 32. They aren't doing anything new in the code; their JNI dependency just bumped up and so they bumped up the whole codebase's requirements.
That's fine, but it's not The Windows Way. The Linux Way doesn't think about compatibility issues like that in anything like the same way. It's a source-code-and-patch-it-yourself world. The approaches are completely alien to each other.
caf|3 years ago
The reverse scenario that seems to be what you have - where you compile against a newer library version then run it on an older one - is forwards-compatibility which is a different kettle of fish. Even on Windows it's not like you can compile against the latest DirectX and run it on an older Windows?