On Wed, Aug 28, 2019 at 8:26 AM Robert Schweikert <[email protected]> wrote: > 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.
This is a business model problem, and I disagree with your analysis. You can provide applications layered on top of base images provided and updated by vendors e.g. Red Hat Universal Base Image. If your customer has a support subscription and runs RHEL then they will get support for products built on top of UBI. The industry is moving quickly to make container isolation for applications a supportable reality. There is no commercial reason to pick the LSB. If you are commercially afraid of shipping binaries then ship a docker file, your binaries, and a command to assemble the container from a universal base image. > 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 problem is that it also has to deal with LSB certification quality at the distribution side, and LSB certification quality of the application, and so the risk simply remains high enough that you have to do your own testing anyway and then what's the value of the LSB? I think deployment models have moved beyond the need for the LSB, and the business models are moving too. > 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. This is the strongest argument I have raised for the removal of ISO Linux. Cheers, Carlos. _______________________________________________ lsb-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss
