The less source you have the more important having a stable ABI is.
Conversely the more source you have the less important a stable binary interface is.
I use a lot of openbsd. The openbsd project is actively hostile to closed source commercial programs with their laissez-faire attitude toward abi stability. However I have this enormous stable of open source software. and it all runs just fine.
ABI stability implies API stability and breaking the API wont help you if you have the source unless you plan to go and change every single project using the broken API in existence. Considering how many years it took for multiple projects to manage the Gtk2->Gtk3 API breakage (with some projects deciding to just not bother - see Ardour) this isn't something to handwave with a "just a concern for closed source software".
> The openbsd project is actively hostile to closed source commercial programs with their laissez-faire attitude toward abi stability
OpenBSD has the "benefit" of having everything in a single repository and when they break something they can also fix any uses in the same commit. I'm also certain that because of that they rarely actually break things that would need a huge number of updates, so that single repository also acts as a "do we really need this?" filter.
This is an exceptional case that doesn't apply to the overwhelming majority of projects out there which are projects that either expose an API/ABI of their own or projects that consume 3rd party API/ABIs that they have no control over.
> I have this enormous stable of open source software. and it all runs just fine.
This is because others are doing the work of keeping that software working on OpenBSD but once you encounter a situation where you need some software that hasn't been updated for a while to keep up with OpenBSD's API breakage, it'll become apparent that having access to the source code isn't some magic bullet and someone will need to do the work to bring it up to date.
Of course not having access to the source code is worse, but having the code is only one part of keeping things working, not the entire story. And IMO when we're discussing about projects that mainly or completely run by volunteers in their free time, i think it is a good idea to avoid situations where APIs and ABIs break so that limited free time is spent doing more useful and/or interesting things (i do not think anyone really likes fixing API/ABI breakage).
On practice, ABI expressivity (not so much stability) is something very important that people have insisted on overlooking for decades because of that single-compiler fallacy.
> I'd just like to clarify that it's specific _compilers_ that produce code that complies with an ABI specification (or don't). Neither the C nor the C++ language standards specify an ABI format.
somat|2 years ago
Conversely the more source you have the less important a stable binary interface is.
I use a lot of openbsd. The openbsd project is actively hostile to closed source commercial programs with their laissez-faire attitude toward abi stability. However I have this enormous stable of open source software. and it all runs just fine.
badsectoracula|2 years ago
> The openbsd project is actively hostile to closed source commercial programs with their laissez-faire attitude toward abi stability
OpenBSD has the "benefit" of having everything in a single repository and when they break something they can also fix any uses in the same commit. I'm also certain that because of that they rarely actually break things that would need a huge number of updates, so that single repository also acts as a "do we really need this?" filter.
This is an exceptional case that doesn't apply to the overwhelming majority of projects out there which are projects that either expose an API/ABI of their own or projects that consume 3rd party API/ABIs that they have no control over.
> I have this enormous stable of open source software. and it all runs just fine.
This is because others are doing the work of keeping that software working on OpenBSD but once you encounter a situation where you need some software that hasn't been updated for a while to keep up with OpenBSD's API breakage, it'll become apparent that having access to the source code isn't some magic bullet and someone will need to do the work to bring it up to date.
Of course not having access to the source code is worse, but having the code is only one part of keeping things working, not the entire story. And IMO when we're discussing about projects that mainly or completely run by volunteers in their free time, i think it is a good idea to avoid situations where APIs and ABIs break so that limited free time is spent doing more useful and/or interesting things (i do not think anyone really likes fixing API/ABI breakage).
marcosdumay|2 years ago
On practice, ABI expressivity (not so much stability) is something very important that people have insisted on overlooking for decades because of that single-compiler fallacy.
dang|2 years ago
To save C, we must save ABI - https://news.ycombinator.com/item?id=30660528 - March 2022 (128 comments)
jmclnx|2 years ago
But the title seems to be misleading. the title should be "to save c++, ....", c++ is not c nor is c the same as c++.
In the old link you provided, no one mentioned this is strictly about the c++ ABI.
>That's why I think C++ should be forked... Not to mention microsoft is probably the main culprit here.
But jokoon came close with the above quote.
zabzonk|2 years ago
> I'd just like to clarify that it's specific _compilers_ that produce code that complies with an ABI specification (or don't). Neither the C nor the C++ language standards specify an ABI format.
vpastore|2 years ago
[deleted]