On Sat, Aug 31, 2019 at 12:46:20PM +0100, Alan Cox wrote: > > > This is a dying mechanism of software distribution. You can achieve the > > > same goal by shipping a container or some container-like thing that > > > includes all the shared libraries you care about. > > > > I am puzzled. I run a Linux distro mirror, and most of the distos > > have vast binary repositories or appstores, some have source repositories. > > I don't see them going away. They are vital for the distro infrastructure, > > > > Android and Apple have even vaster binary appstores, which were key to > > their successes. > > Microsoft failed to have a well-equipped appstore, and I think this was key > > to MS > > failing and folding in the smartphone market. > > > > So this is key technology for Linux/unix systems, or am I wrong? > > I understand that this was not the percieved purpose of LSB, which was > > intended for ISV's > > I think the fundamental distinction is that a Linux distribution such as > in your mirror is *self consistent*. All the bits of Fedora 30 work > together and match. It's not necessarily consistent with a five year old > CentOS but it is mostly consistent ABI-wise with say a modern Debian or > recent Ubuntu because ABI tends to be driven by the application/toolkit > owners and they've learned about consistency being good - plus the > tooling for it is now way better. In other words grab a random Fedora 30 > binary and try and run it on CentOS 7 and it may well fail. > > A binary that works on Fedora 30 probably works on Ubuntu 18, modern > Debian and RHEL8. Quite probably on many older things too but its not > defined to do so. > > I don't think an ABI document can actually fix that any more. The nature > of software development has changed. > > When LSB was founded software came in releases - say 1.0 one year, 1.1 9 > months later to fix what 1.0 should have been, 2.0 two years after that. > Releases involved lumps of plastic, shipping, manuals, advertising > collateral, press interviews, trade show timing, product placement etc > > Today a point release for open source involves some testing, two git > commands, and distribution is pretty much friction free. The cost of a > 'release' has dropped to nearly zero, but the cost of compliance testing > to some pile of paper is a constant. For proprietary software it's not > that much more (except in the USA where you can spend months on export > compliance ;-) ) > > The ABI issue is being fixed with decentralized API ownership, rapid > updating and automated build/test and test suites. Part of that rapid > flow is also the decision that it's lower cost to fix breakages across > boundaries than nail them down and six year old forks of code are > generally toxic waste.
I appreciate all your guidance, Alan, and also all the info others are contributing in this thread. Is there something that we can give as guidance or as standard, in LF or in ISO? I don't care how and where, but rather that different agents, business or not takes it up, for the benefit of users and the society. I have different aims, as I stated in an earlier mail for what I wanted LSB to do. I understand from your description above that current distros almost have ABI compatibility, and it is a rolling target, so it is difficult to state the library versions in a LSB fashion, as the versions change all the time. could we give some guidance so avoid unintended differences? And then maye some guidance to ISVs on containers and the like... and could we make architecture to avoid the future security problems of embedded, iot, telephone tech that we already see today? I see that the debian family has some techbology thet could be a canidate. I myself have been in the red hat camp for decades, but I am not so happy about having to install new systems every 10 years or so. I want my systens to run forever.... Keld _______________________________________________ lsb-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss
