3 ms·

Keeping a existing binaries working is the definition of backwards compatibility in an OS. glibc broke that. Never Change Anything is far from the ask here. Th

Keeping a existing binaries working is the definition of backwards compatibility in an OS. glibc broke that. Never Change Anything is far from the ask here. The ask is that when real actual breakage is found, the benefits of keeping said breakage justify not spending the engineering costs to fix backwards compatibility. Near as I can tell, the benefit is 16kB disk space savings, and glibc's engineering cost to maintain compatibility is nothing. Like, another backwards compatibility breakage I saw recently was Graphene switching from 39-bit to 48-bit virtual address space, which also broke games. That has a real measurable security benefit, and actual engineering costs to develop a backwards compatibility story. But they still spent effort to fix breakages.

ajross 4y ago
> Keeping a existing binaries working is the definition of backwards compatibility in an OS. glibc broke that. No, that's simply wrong. No "glibc binary" that could have been even theoretically compiled within the past few decades will fail to run because of this issue. What happened is that this EAC product had reverse-engineered the internal formats glibc uses to provide the APIs it implements. And that format changed. I repeat what I said elsewhere: it is simply not possible for any software product to anticipate all possible external users of its internal implementation details. What you want, you cannot have. (And I repeat what I said elsewhere too: you don't have this, even on windows. Microsoft breaks things like anti-cheat hackery with every release too, it's just that you don't notice because the proprietary vendors care enough to fix it, where they don't on Linux.)
- brigade 4y ago
  > No "glibc binary" that could have been even theoretically compiled within the past few decades will fail to run because of this issue. That's obviously not true. The entire story is how a new glibc binary broke existing binaries. > What happened is that this EAC product had reverse-engineered the internal formats glibc Okay I missed this; I thought EAC was parsing the libc binary as per ELF. What was reverse engineered? > it is simply not possible for any software product to anticipate all possible external users of its internal implementation details Correct. Which is why I never asked for stuff that never breaks. What is important is that when stuff is found to break, the breakage and refusal to provide backwards compatibility has a compelling reason. glibc's justifications here are laughable; they're spending more effort to not revert the breakage than it would take to fix. Which is kinda why the story blew up.
- dark-star 4y ago
  > What happened is that this EAC product had reverse-engineered the internal formats glibc uses No, you got it the wrong way around. EAC has used the well-documented and SysV-standard DT_HASH mechanism. The DT_GNU_HASH is the (almost) undocumented one that they would have to reverse-engineer from GNU ld's source code

ajross 4y ago

> Keeping a existing binaries working is the definition of backwards compatibility in an OS. glibc broke that. No, that's simply wrong. No "glibc binary" that could have been even theoretically compiled within the past few decades will fail to run because of this issue. What happened is that this EAC product had reverse-engineered the internal formats glibc uses to provide the APIs it implements. And that format changed. I repeat what I said elsewhere: it is simply not possible for any software product to anticipate all possible external users of its internal implementation details. What you want, you cannot have. (And I repeat what I said elsewhere too: you don't have this, even on windows. Microsoft breaks things like anti-cheat hackery with every release too, it's just that you don't notice because the proprietary vendors care enough to fix it, where they don't on Linux.)

brigade 4y ago
> No "glibc binary" that could have been even theoretically compiled within the past few decades will fail to run because of this issue. That's obviously not true. The entire story is how a new glibc binary broke existing binaries. > What happened is that this EAC product had reverse-engineered the internal formats glibc Okay I missed this; I thought EAC was parsing the libc binary as per ELF. What was reverse engineered? > it is simply not possible for any software product to anticipate all possible external users of its internal implementation details Correct. Which is why I never asked for stuff that never breaks. What is important is that when stuff is found to break, the breakage and refusal to provide backwards compatibility has a compelling reason. glibc's justifications here are laughable; they're spending more effort to not revert the breakage than it would take to fix. Which is kinda why the story blew up.
dark-star 4y ago
> What happened is that this EAC product had reverse-engineered the internal formats glibc uses No, you got it the wrong way around. EAC has used the well-documented and SysV-standard DT_HASH mechanism. The DT_GNU_HASH is the (almost) undocumented one that they would have to reverse-engineer from GNU ld's source code