4 ms·

And yet in practice, the number of steam games on linux that I can't run because the developers compiled them against a newer version of libc than I have is in

And yet in practice, the number of steam games on linux that I can't run because the developers compiled them against a newer version of libc than I have is in the dozens.

quotemstr 11y ago
Compatibility works the other way around. You can run binaries compiled against an older libc on a newer glibc, but there's no reason to expect that binaries compiled against a newer libc should be able to run against older versions of libc. If you demand that, you demand software stasis.
- sdijf8sdhf 11y ago
  It's a libc implementation for christ's sake. If ever a library should remain in stasis, it would be a libc implementation.
  - oldmanjay 11y ago
    There's a clue in your formulation that guides you to the right answer - no useful library should ever remain in stasis. Or as it's generally said, the only software that never changes is software no one uses.
    - sdijf8sdhf 11y ago
      That's just, like, your opinion, man; tell it to the retrocomputing folks. IMHO, the reluctance to "finish" a project and the stigma against something being "in maintenance mode" is responsible for most of the bloat and messes in modern software. Perhaps it's related to "CADT": http://www.jwz.org/doc/cadt.html http://www.jwz.org/doc/cadt.html It's also, ironically, the cause of numerous security flaws. Maybe we wouldn't have to worry so much about security flaws in our libraries if we weren't constantly tearing them down and remaking them. Regardless, in the case of libc, I genuinely cannot think of a reason to break binary compatibility, backwards or forward. The POSIX standard is set in stone, the interfaces are stable, the data types are opaque, etc. Of course you can create new implementations of memcpy etc that take advantage of new instruction sets, but I don't see why you need to break binary compatibility to do so.
      - jjnoakes 11y ago
        > in the case of libc, I genuinely cannot think of a reason to break binary compatibility, backwards or forward Well, since you can't think of one, there must not be one.

And yet in practice, the number of steam games on linux that I can't run because the developers compiled them against a newer version of libc than I have is in the dozens.

quotemstr 11y ago

Compatibility works the other way around. You can run binaries compiled against an older libc on a newer glibc, but there's no reason to expect that binaries compiled against a newer libc should be able to run against older versions of libc. If you demand that, you demand software stasis.

sdijf8sdhf 11y ago
It's a libc implementation for christ's sake. If ever a library should remain in stasis, it would be a libc implementation.
- oldmanjay 11y ago
  There's a clue in your formulation that guides you to the right answer - no useful library should ever remain in stasis. Or as it's generally said, the only software that never changes is software no one uses.
  - sdijf8sdhf 11y ago
    That's just, like, your opinion, man; tell it to the retrocomputing folks. IMHO, the reluctance to "finish" a project and the stigma against something being "in maintenance mode" is responsible for most of the bloat and messes in modern software. Perhaps it's related to "CADT": http://www.jwz.org/doc/cadt.html http://www.jwz.org/doc/cadt.html It's also, ironically, the cause of numerous security flaws. Maybe we wouldn't have to worry so much about security flaws in our libraries if we weren't constantly tearing them down and remaking them. Regardless, in the case of libc, I genuinely cannot think of a reason to break binary compatibility, backwards or forward. The POSIX standard is set in stone, the interfaces are stable, the data types are opaque, etc. Of course you can create new implementations of memcpy etc that take advantage of new instruction sets, but I don't see why you need to break binary compatibility to do so.
    - jjnoakes 11y ago
      > in the case of libc, I genuinely cannot think of a reason to break binary compatibility, backwards or forward Well, since you can't think of one, there must not be one.