4 ms·

The "solutions" are hacks at best. This is not the way to build stable software. > I hope you can see that "keep libraries backwards compatible forever" is not

The "solutions" are hacks at best. This is not the way to build stable software. > I hope you can see that "keep libraries backwards compatible forever" is not really a good option ??? Why would I be able to see that? You've given zero explanation or evidence for why that would be the case. I see a whole lot of people in this thread in addition to the article explaining why backwards compatibility is good. Nobody is giving valid reasons as to why it's bad. Microsoft has managed to keep the whole Win32 API compatible "forever". GUI apps built for Windows 95 still work out of the box on Windows 10. Backwards compatibility is a major part of why they are still the dominant platform: businesses actually care about this. They use ancient proprietary software that is critical to their business whose source code has long been lost to the sands of time. A platform that breaks their software is no platform at all. > probably orders of magnitude more work than just doing all the things you said. Really? How hard is it to not break things? It's sometimes more work to add new features or support new hardware without breaking the ABI but clearly it's feasible. glibc 2.1 was released in 1999 and the maintainers decided at that point that they would preserve backwards compatibility forever. We're now at 22 years without a major ABI break. There have been some hiccups of course (the memcpy() fiasco) but they've been fixed. The GCC team have decided to follow in their footsteps. Since version 5 they've decided they're not going to break the libstdc++ ABI anymore. The culture of backwards compatibility is finally growing on the Linux desktop. This is a far better solution than Flatpak.

md8z 5y ago
AFAIK the win32 API is kept backwards compatible by doing exactly as we describe, shipping older versions of the system libraries and automatically using them when it's detected that an application needs them. So it's the same thing you call a "hack". Please don't misunderstand, I'm not saying backwards compatibility is bad. But it does cost a non-trivial amount of money and time, it's not just a magic solution to reduce the maintenance cost of something down to zero. If you're doing a cost comparison, that always has to be taken into account. Glibc isn't really a good example, that has a ton of unfortunate broken APIs that should probably be removed entirely (the most notorious example probably being gets) but never will be, and I suspect they will continue to be a source of bugs as long as applications use them and aren't patched. I mean the whole reason musl exists is to get away from some of these maintenance issues in glibc.
gpderetta 5y ago
To be fair the equivalent of libstdc++ on Windows has broken the ABI on every MSVC release until very recently. The difference is that Windows applications historically shipped with the appropriate version of the C++ runtime bundled in (and there wa no guarantee that one was provided by the OS), while Linux app usually rely on the system .so.
bluGill 5y ago
The C++ standard committee regularly has debates about breaking the ABI. They forced it for 11, who knows if they will again.

md8z 5y ago

AFAIK the win32 API is kept backwards compatible by doing exactly as we describe, shipping older versions of the system libraries and automatically using them when it's detected that an application needs them. So it's the same thing you call a "hack". Please don't misunderstand, I'm not saying backwards compatibility is bad. But it does cost a non-trivial amount of money and time, it's not just a magic solution to reduce the maintenance cost of something down to zero. If you're doing a cost comparison, that always has to be taken into account. Glibc isn't really a good example, that has a ton of unfortunate broken APIs that should probably be removed entirely (the most notorious example probably being gets) but never will be, and I suspect they will continue to be a source of bugs as long as applications use them and aren't patched. I mean the whole reason musl exists is to get away from some of these maintenance issues in glibc.

gpderetta 5y ago

To be fair the equivalent of libstdc++ on Windows has broken the ABI on every MSVC release until very recently. The difference is that Windows applications historically shipped with the appropriate version of the C++ runtime bundled in (and there wa no guarantee that one was provided by the OS), while Linux app usually rely on the system .so.

bluGill 5y ago

The C++ standard committee regularly has debates about breaking the ABI. They forced it for 11, who knows if they will again.