On Mon, Aug 26, 2019 at 02:16:28PM +0200, Florian Weimer wrote:
> >> > 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?
That has nothing to do with C/C++ ABI's. It has to do with the fact
that they don't have a business model to sustain the necessary
engineering work. You can blame closed source proprietary hardware
interfaces, some of which are only released under NDA, or by SOC
vendors who use hardware engineers to do a software engineer's job,
bludgeoning the Linux kernel so that their proprietary hardware works,
but in an upstream no-go fashion --- heck, sometimes their "board
support kernels" don't even *build* on x86 any more. Again, that has
nothing to do with C/C++ ABI compatibility.
(Heck, many phone manufacturers don't have the business model to
sustain shipping security updates, never upgrading to newer Android
versions. And the IOT world is even worse from a business perspective
model. Remember, the "S" in IOT stands for Security...)
> > 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.
And there are multiple solutions to building and testing only once.
(1) Shipping the binaries in VM image (example: AWS and GCE
marketplace). (2) Using flatpak and snap solutions. (3) Static
linking. (4) Shipping your own copies of your libraries.
The bottom line is that all of these are cheaper than trying to
standardize the Linux C/C++ ABI.
> 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.
A lot of the work of the LSB was trying to convince upstream projects
to take ABI management and testing seriously. Some were better than
others. Most C++ based projects didn't care about ABI compatibility.
They would just recompile of the shared libraries in GNOME or KDE, at
each release, and call it good. (Without naming names, some of these
projects were also actively hostile to proprietary, closed-souce
binaries. And those that were receptive to the concept jumped ship to
.NET, and some now hold high-ranking positions at Microsoft. :-)
But again, the industry has found ways around this, by packaging above
the C/C++ level (i.e., VM images, Container images, flatpak/snap
images), or by switching to web applications and eliminating the local
application executable entirely.
- Ted
_______________________________________________
lsb-discuss mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss
