Hi, On 8/23/19 9:44 AM, Theodore Y. Ts'o wrote: > On Fri, Aug 23, 2019 at 10:11:03AM +0000, Dallman, John wrote: >> >> LSB is at a point now where it can either be left to decline, or >> re-vitalized. The latter requires the Linux Foundation to either see >> it as a priority, or transfer the project to someone with money and >> energy to push it forwards. > > The real problem is that there isn't any business case for someone > *with* money to invest in the LSB. The big money in Linux these days > can be found in: > > *) Android, and other mobile use OS's > *) Embedded systems > *) Cloud applications > > In none of these cases does ABI compliance matter. There will be a > few companies that care about running Oracle or DB2, but they'll use > an enterprise Linux distro for that, and the rest of their servers or > VM's will run some other distribution and the applications will be > almost all open source or based on open source. > > You can see that in a demo IBM did showing off Linux running their > latest Mainframe a few years ago. What software did they have running > on the Linux-on-zSeries? Was it Websphere and DB2? No, it was MySQL, > Apache, and PHP. <Insert sad trombone noise here, at least for IBM > Software Group>. > > The other reason why HP, IBM, and other companies were pushing for ISO > adoption of LSB, way back when, was strictly mercenary. There were > some governments in Europe where having the ISO imprimatur made it > easier to sell into those markets, and so that was worth the large > amount of additional dollars needed to fund national body > representatives, etc., to attend the necessary ISO meetings to make > ISO/IEC 23360-2006 happen. > > But in the intervening ten years, Linux has gained a lot more > credibility. And, given the ISO/IEC 29500:2008 debacle, ISO has lost > a lot of credibility. Hence, I can't see any interest at *all* in > companies being willing to invest in further ISO standardization of > anything relating to Linux. Linux moves too quickly, and ISO moves > too slowly, and its insistence on voting based on national bodies > means that very few open source communities will be willing to trust > it for anything. > > Of course, ISO standardization is independent of continuing investment > in the LSB. And there, it all comes down to funding. The Linux > Foundation acts based on the direction (and especially, funding) of > its sponsors. Let's look at their current Platinum sponsors: > > * AT&T > * Cisco > * Fujitsu > * Google > * Hitachi > * Huawei > * IBM > * Intel > * Microsoft > * NEC > * Oracle > * Qualcomm > * Samsung > * Tencent > * VMWare > > How many of the above companies have a business model which is > dependent on the distribution of portability of commercial binaries to > run across multiple Linux distributions? None. > > And given the dominance of Red Hat in the enterprise market, and the > shrinking importance of the enterprise market in terms of companies > making money working with Linux, this shouldn't come as a surprise. > > Now, there will be some smaller ISV's, such as John, that would find > that it saves them testing and porting effort if something like the > LSB would exist and was strong and vibrant. And I feel very badly for > John, since he has been a long-time, loyal supporter of the LSB. But > these smaller ISV's don't have funds to do the detailed engineering > work which is necessary to update the LSB. > > Finally, we can't ignore the emergence of alternative packaging > technologies where the application is bundled together with all of its > run-time libraries. These includes AWS and GCE VM images which > include Oracle and Red Hat which are pre-installed and pre-tested. It > also includes flatpak and Snap. With all of these technologies the > LSB is moot, since it includes the userspace libraries needed by the > application. There are some downsides, of course. Chief among them > is the fact that if there is a security vulnerability in a core > library, such as glibc, it must be patched in all of the flatpaks and > snaps and docker images, et. al. The record to date on this happening > is at best mediocre, if not downright bad. On the upside, the > application vendor only needs to test how their application works with > a single set of runtime libraries, and a flatpak or snap will run on > essentially run on any Linux distribution without needing to do any > kind of compliance or conformance work.
Yes, packaging models have changed in the last 10+ years and they continue to evolve. However, I think the the "bundling" described above is overselling the "appliance model". There are still many thousands of ISVs that will not touch an appliance that includes system libraries with a very long stick. Providing an appliance implies support responsibility and ISVs do not want to be responsible for supporting glibc or other system libraries. The idea that an ISV application gets installed onto an OS chosen by the end customer is here to stay. Containers, VMs, snaps, flatpacks, you name it will not change that significantly for many applications. Never the less that does not make the case for some independent 3rd party that cares about ROI to invest into the LSB. The applications that remain as independent "install on a customer chosen OS" will primarily be enterprise grade applications and those ISVs will choose enterprise distributions to support. Even with the LSB in place ISVs were not completely absolved on testing on multiple distributions they intended to support. That testing effort grows without the LSB, granted. The only argument that should count against resurrecting the ISO is that the state of the current LSB as published is very old and irrelevant w.r.t. any reasonably modern distribution. Later. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Technical Team Lead Public Cloud [email protected] IRC: robjo
signature.asc
Description: OpenPGP digital signature
_______________________________________________ lsb-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss
