Hacker News Reader

Comment by shadowgovt | Hacker News Reader

> Google and Apples's

... and Linux (well, Ubuntu specifically). I'm staring down the need to upgrade from Ubuntu LTS 20.04 to Ubuntu LTS 22.04 because some software I maintain now relies on GLIBC v2.32, which is an absolute bear to back-port. The party line is "So just upgrade," but there's no guarantee my hardware is compatible with Ubuntu LTS 22.04 because the vendor doesn't support that config and I'm not really interested in dealing with all the joys of figuring out every fiddly-widget little config on a laptop to make it work myself.

Microsoft is nearly unique in caring that much about backwards compatibility. It's the value-add they bring to the market these days relative to the competition.

View on HN

> ...but there's no guarantee my hardware is compatible with Ubuntu LTS 22.04 because the vendor doesn't support that config...

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

(a) Of course it needs binary blobs. This is the real world where medium- to high-performance machines need binary blobs. The GNU dream never materialized.

(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.

glibc goes to great lengths to ensure binary backwards-compatibility. If a binary interface has to change it uses symbol versioning to keep around the old interface - for example if you have a program compiled against glibc2.2 on x86-64 that calls timer_create(), it will call through the function __timer_create_old() that provides the old interface when run on a system with a newer libc.

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?

Reply on news.ycombinator.com