On Fri, Aug 23, 2019 at 03:42:07PM +0200, [email protected] wrote: > > How much money is needed? and for what purpose?
Defining what is supposed to happen at the ABI level (e.g., at the ELF library link level) is non-trivial. This gets *especially* difficult for C++, where changes in the base class can screw up the ABI compatibility *for* *all* *subclasses*. Inside Google, the use of C++ has caused people to completely give up on C++ ABI stability, and so things get linked statically everywhere. (Use of a monorepo makes the tooling to force a tree wide rebuild when there is a bug detected in a class library much easier.) In Debian, the general approach for many packages is to force a major version number bump at every release where any header files change. I recall one package in Debian where there were 11 major (incompatible) shared version bumps in a 12 month period. (In which case, why bother shared libraries?) We've had similar problem with OpenSSL which is written in C, but upstream had zero interest in maintaining ABI stability guarantees across even minor versions, due to bad design decisions made 10+ years earlier. And then you also have to define what happens semantically above that level. It's a huge effort. If you only care about what happens at the libc level, then it's possibly to simply draft behind the work of the Austin Group[1], which only worries about standardizing the API, not the ABI. However, the Austin group has no interest going beyond libc, so it doesn't cover the many, many other userspace libraries which are covered by the LSB. [1] https://www.opengroup.org/austin/ > > Can we make a revised low budget lsb with a good chance in the market? > I don't think so, especially given the glacial pace, and heavyweight process, used by ISO. The open source community is a do-ocracy, which is to say technical decisions get made by the implementors, not by voters of national bodies which have nothing to do with the open source code which is being "standardized". Companies who care about their use case will hire engineers which contribute to the open source project. This is much more efficient than packing national bodies to engineer the vote at ISO meetings, and is also much more likely to result in a sound technical outcome. This dynamic was true with the LSB as well, but it worked because it was a backwards-looking description of the ABI; we never tried to define new technology[1]. But the problem is that the ABI of interest to applications programmers has getting more and more complex, and the business model for defining that ABI and then asking distributions to make sure they were shipping code that conformed to that ABI doesn't really exist in 2019[2]. [1] Such for example the what the C standards committee is trying to do, with the result that us Kernel developers will have to figure out new ways to tell the compilers, nixnay with the stupid optimization sh*t dreamed up by the C standards committee... [2] And barely existed in 2006, if we were honest with ourselves; we had SuSE at the table, but Red Hat had not been interested in participating ever since it walked away with the enterprise market. IBM cared because it wanted to keep SuSE as a viable competitor to Red Hat in the enterprise space, and to make life easier for IBM Software Group. But IBM owns Red Hat now, and IBM Software Group isn't really where the money is in the Linux world, anyway. > the new ISO SC22/WG24 Linux WG has attracted quite a few experts, > many from the California area, but I dont know their level of > expertise, nor the overlap with the LF LSB WG, so maybe we can put > together a team for a revision, on a low budget. But if they are > unexperienced with the work it may be problematic... I doubt there was much overlap, from what I know. Professor Yong Woo Lee tried to invite me to the SC22/WG24 meeting in Souel, as well as the earlier meeting in Toronto. However, it wasn't just the travel funding for which I couldn't justify asking my company to expend. It was my *time*, which was far more valuable. I tried asking Professor Lee for what he thought the business case and the market for the LSB, and he couldn't give me one. He pointed me at some ISO web site that talked about how standards were good for Toilets and the Plumbing industry. There is a reason why Docker, flatpak, Snap, D-BUS, etc., are not things which are being standardized by the ISO. Quite bluntly, the ISO doesn't add much if any value in the computing world. - Ted _______________________________________________ lsb-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss
