* Alan Cox: >> > There, I clearly and repeatedly mentioned, Smart city, Smart home and >> > Smart Society, Smart Car and many other things which are related to the 4 >> > th Industrial Revolution, Internet of Things, Cloud Computing, etc as the >> > business case and the market for the LSB. > > The cloud runs on source code. IoT generally doesn't care about ABI > because you don't link third party binary only blobs any more.
If that's true, why does Fairphone have so much trouble upgrading to newer Android versions? > Nobody gets up in the morning and says 'lets launch a big new C++ > project', or if they do their security compliance team explains to them > why it's a bad idea. Eh, no. People write new C++ software all the time. It's still the default choice for security-critical software such as web browsers and their Javascript engines. > From an application perspective the world has solved the problem of > compatibility in at least four ways > > 1. There is far better consistency between the Linux vendors now just > down to commonality of what is shipped and also the much lower rate of > evolution in the C/C++ space The different branching points create a lot of friction. Most ISVs (and free software projects that distribute binaries) want to build and test their binaries once, and not one per distribution. As a result, you still end up with ABI issues when moving from distribution to another. Several core libraries are fine if you move forward in time, though, and the set of libraries which aim for this level of compatibility appears to grow over time. > 4. Languages define their interfaces strictly and carefully in the > first place (as most post C++ languages have mostly done), learning > from the past I don't see that. Most newer languages where the default implementation uses ahead-of-time compilation do not have a notion of ABI stability. If they support dynamic linking at all, they do not allow replacing a shared object with a new version, without rebuilding all reverse dependencies. And the build tool enforces that. (Most C++ ABI problems stem from lying to the build tool and not rebuilding and retesting everything that needs to be rebuilt according to the file dependencies.) The main problem is that LSB can only describe what actually exists. Someone needs to do the ABI management and ABI testing. Once this work is done upstream, what's the point of extracting the ABI and documenting it separately? It's not that there's going to be a separate implementation that could serve as a drop-in replacement. There will be different *versions*, but if upstream implements proper ABI management, they will already ensure compatibility. At that point, as far as I can tell, no further work is necessary. Thanks, Florian _______________________________________________ lsb-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss
