An operating system’s success is inextricably linked with the number and quality of applications that run on top of it. Linux and its variances between distributions, however, present ISVs and individual developers with a unique set of challenges: different distributions of Linux make use of different versions of libraries, important files stored in different locations, and so on. If an ISV wants to reach a global Linux audience, they must support more than one distribution of Linux. These challenges and variances make it difficult–and costly–for ISVs to target the Linux platform.
It is somewhat of an irony: choice is what drives Linux adoption, yet this very choice can make things difficult for application developers. The costs and resources involved in targeting multiple Linux distributions for application development is not something that can be taken lightly.
The Linux Standard Base was created to solve these challenges and lower the overall costs of supporting the Linux platform. By reducing the differences between individual Linux distributions, the LSB greatly reduces the costs involved with porting applications to different distributions, as well as lowers the cost and effort involved in after-market support of those applications.
The Linux Foundation and the Linux Standard Base were created to enable ISVs to cost effectively target the Linux platform, reducing their porting, support, and testing costs while helping them address a global market for their applications.
The LSB solution not only makes life easier for individual application developers and independent software vendors (ISVs), it also makes a huge positive impact on the entire Linux ecosystem.
Beyond the reduction of porting costs, the existence of the LSB solution means that Linux will also avoid the fate of the UNIX operating systems, where commercial interests caused the fragmentation of a single UNIX OS into several UNIX variants that, unlike Linux distributions, are very incompatible with each other.
There are other solid benefits of the LSB:
Less complexity for ISVs to support Linux, thus reducing support costs.
Greater reach for ISVs in more geographic markets, where a specific distribution may be more dominant.
The ability to support additional Linux distributions with only a small increase in support and development costs.
Support from the Linux Foundation and the Linux Developer Network to make ISVs' development process easier and their marketing more effective.
Clearly, the LSB solution is a positive force in the Linux environment. But what, exactly, is it? Understanding the components of the LSB is key to understanding all the things it can do for developers.
The LSB is a core standard for the Linux operating system that encourages interoperability between applications and the platform. It includes a written binary interface specification, a set of test suites for both distributions and applications writing to the standard, and a sample implementation for testing purposes.
Currently, the distribution vendors are the enablers of the LSB standard. Without their participation, the standard cannot achieve any success. And without their participation in the creation of the LSB, their support for it would be unlikely. Luckily all major distribution vendors are certified to the LSB.
In order for the LSB to be successful, the Linux Foundation has built an organization that makes it as easy as possible for distribution vendors to come to consensus while balancing the needs of other constituents to have a timely and useful standard.
Community support is key, too. The open source community represents an amalgamation of software projects that are integrated into a single computing solution. It is important that the maintainers of those projects are aware of existing computing standards such as the LSB so they can work in a cooperative fashion to accelerate the adoption of their technology. All of these cooperative elements—distribution vendors, community developers, and application developers, work together to make the LSB happen. But what are the technical elements of the LSB? What's under the hood?
The key component of the LSB is the written binary interface specification, which informs developers of Linux applications the standard ways to build and configure their applications. Specifically, the specification lists:
Common Packaging and Install Guidelines
Common Shared Libraries and their Selection
Configuration Files
File Placement
System Commands
Application Binary Interfaces (ABIs) for System Interfaces (both application and platform levels)
Built from a foundation of existing standards, LSB delineates the binary interface between an application and a runtime environment. Existing standards that the LSB draws from include the Single UNIX Specification (SUS). the Standard CABI, and the System V ABI. Other standards referenced include PAM, X11, and the desktop standards hosted on freedesktop.org.
LSB formalizes the framework for interface availability within individual libraries and itemizes the data structures and constants associated with each interface. These components include shared libraries required by developers (including C++), file system hierarchies (defining where files are located in the system), specifications for the behavior of public interfaces, application packaging details, application behavior pre- and post-installation, and so on.
The LSB provides backward compatibility at both the source and binary level beginning with LSB 3.0. In other words, applications that target version X.Y of the LSB (where X.Y >= 3.0) will run on distributions certified to or compliant with LSB version X.Y //and newer//. For example, applications that target LSB 3.0 will run not only on LSB 3.0 certified/compliant distributions but also LSB 3.1, LSB 3.2, LSB 4.0 etc. certified/compliant distributions.
To achieve backward compatibility, each subsequent version is purely additive--in other words, interfaces are only added, not removed (our [[https://www.linuxfoundation.org/en/Deprecation_Policy interface deprecation policy]] does provide us with a mechanism for removing interfaces, but only after the interfaces have been marked “deprecated” for at least three major versions, or roughly six years).
This policy allows application vendors to certify to the version of the LSB that provides the interfaces they need and not require them to recertify to newer versions unless the newer versions provide functionality the applications require.
Please note that the application compatibility policy has changed with LSB 3.0: previously, in LSB 1.x and 2.x, binary compatibility was only provided within a major version–now application compatibility is provided between major versions.
When an application can meet all of these specifications of the LSB, it is well on its way to becoming LSB-certified. If application certification is your goal, it is recommended to start with testing your application. There's no better way to know whether you're compliant, or how far away from compliance your application is. Testing can be done with native builds, but that can often introduce spurious errors that would not be present when building with the LSB Software Development Kit (SDK), so developers are encouraged to use the LSB SDK early in their development and testing process.
Beyond testing the application, certification also requires running the application on the LSB Sample Implementation, as well as running on a number of LSB-certified distributions.
When you are ready to submit your test results for official certification, you will need to register your product with the certification system. After your product is registered, you will be able to upload your test results. And sign the LSB Trademark License Agreement (TMLA) and pay the applicable fees. Once the TMLA has been signed and the fees paid, the Linux Foundation will audit your test results, and if your application passes, it will become fully LSB certified.
A similar set of steps are used for distribution developers who wish their product to become LSB-compliant.
The “Standard” in the LSB isn't just for show, either. The LSB is a full International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) standard, specifically ISO/IEC standard 23360. This means the LSB is and will always be maintained with the highest quality and will always be open.
The LSB is targeted to help developers on a variety of platforms, as the following architectures are covered:
* Intel IA32
* Intel IA64
* x86-64/EM64T
* IBM PPC 32
* IBM PPC 64
* IBM 31-bit S/390
* IBM 64-bit zSeries
======Using the LSB======
Now that you know what the LSB is and why it is such a great benefit to Linux and Linux application development, what's the best way to get started using it? This is what the Linux Developer Network (LDN) is all about.
First, what are your goals? Do you want to fully certify you application under the LSB, or is that not a choice you want to make at this time? While the LSB is a great standard, we also recognize that it's not in everyone's interest to always go for LSB certification. Smaller ISVs or individual developers, for example, may not have the time in their development plan to attempt LSB certification. For some applications (especially those who touch the kernel), LSB compliance may not be achievable today.
That does not mean, however, that those applications have nothing to gain from following LSB guidelines. In fact, the LSB eliminates many of the complex moving parts that face those ISVs today.
With this in mind, there are two basic paths for application developers to take:
* Maximize Portability. This solution path allows developers to use the Linux Application Checker provided on the LDN to determine how portable their application is right now. Key elements of the application that may hinder portability are identified, allowing developers to make changes that should make the application far more portable. The Linux Application Checker also makes recommendations and guides the developer down a path of best practices for developing their application.
* LSB Certification. Tools are available for developers of new Linux applications to build complaint applications from scratch. Tools such as the LSB Software Development Kit (LSB SDK), created and maintained by the LSB working group, consists of a build environment and the required tools to streamline porting software applications to conform with the LSB SDK.
In summary, resources available from the LDN include:
* Linux Application Checker. Check your application's portability and get recommendations to make it more portable.
* LSB Database Navigator. Identify the components that may prevent portability and learn alternatives and solutions to achieve that portability. The database navigator is a wealth of information for C/C programmers looking to program on Linux.
LSB Build Tools. LSB SDK enables developers to validate the binaries and RPM packages to ensure LSB compliance and monitor the
API usage by the application while the build is taking place so that conformance is assured.
LSB Sample Implementation. The LSB Sample Implementation (LSB-si), is a minimal LSB-conforming runtime environment used for testing purposes. LSB compliant applications should be tested inside the LSB-si to insure they haven't picked up any distribution-specific quirks. The LSB Certification program requires an application be tested under the LSB-si.
LSB Certification and General Marketing Support. No matter which path you choose, LSB or portability, resources will be available for developers to determine how to maximize their application's exposure in the Linux ecosystem. Certified applications can be included in the product directory.