The Linux Standards Base offers binary compatibility
Linux has become a pervasive operating system for developing and deploying enterprise applications. But there are many different Linux distributions, available through many different vendors, and so a key milestone for Linux is binary compatibility for its application stack. That is, ensuring that compliant applications will run on conforming distros -- without recompiling.
The LSB was chartered to help insure just that, and Red Hat 8.0 and UnitedLinux 1.0 are now both examples of conformant distributions. To find our more about how Linux apps can become Linux Standards Base compliant, and about an important developer survey the LSB is conducting, we talked with George Kraft IV (gk4), LSB Chairman, and IBM LSB liaison. Here's what he had to say.
George, could you tell us about the work that the Linux standard-based project does? Why it was started, and why does it matter?
George: The key thing was to help alleviate the differences or the possible divergences of Linux’s to come up with a standard framework that all the Linuxes were to provide for applications. So that’s kind of built into our mission statement and our goals. We want to minimize incompatibilities and keep the application software stable, so it doesn’t have runtime failures.
How do you make sure that the standards you specify are consistent with the way that most ISVs are coding their applications?
George: The LSB is conducting a survey to gather information about how software products are being built. This may give the LSB an opportunity to see if we are on track for ISV adoption. We think it is very important to get the broadest possible ISV participation, and we encourage any ISVs who develop Linux applications and care about binary compatibility to participate. It's a very quick survey to complete, and the results will be tabulated at the end of May.
Where do conflicts usually turn up when people try to run Linux applications on different distros? Are there particular areas where ISVs have more problems than others?
George: Problems mostly occur when programmers or coders code to the private interfaces of the operating system, things that weren’t intended to be coded to. The source changes from release to release, so that means when they move their application around to various Linux distros, which are based on different versions of different upstream source, then the application will fail because they used a private interface they shouldn’t have. The LSB helps police that.
What does the certification process look like? If I have an application and I wanted to get it certified, what am I going to be doing?
George: The first thing to do is to compile using the LSB stated ABIs (Application Binary Interfaces). We provide tools to help you do that. Then, you take the application that you’ve built, and if you think it’s LSB-ready; run it on an LSB certified system of your choice. Then you run it on an LSB certified system of the LSB’s choice. And finally, you run it on what we call the sample implementation... a little mini-Linux that only provides LSB-specified things.
The goal is to make the LSB tests a part of the development process. So after you run your binary on those three systems, you run your functional verification test, or whatever QA test you have for your application. Then we have a good sense that your binary is portable -- here are these three LSB systems; and you ran on all three of them. If you can run on those three, then you can run on any others that are certified. So it’s kind of proof by induction that it will work.
So you get a reasonable level assurance that, having jumped through those hoops, you’re going to be binary-compatible on most LSB-compliant systems?
George: Correct. We also have a useful tool called LSB App Check. LSB App Check basically opens the binary, looks through it, and makes sure that you use absolutely only the ABIs specified by the LSB. If you use something other than what the LSB specifies, it kicks it out and tells you right then that you’re not compatible. So during your build process, or during your development process, you can actually use this tool to double-check your application.
There’s another tool that's not quite released yet. It’s a packaging checker, because part of the specification for an LSB application says it needs to be specified in RPM format. So this checker will look at your package, and make sure that you’ve got the proper things where they need to be.
The application needs to be packaged in RPM format?
George: Yes, and there's a packaging question in the LSB certification about this. That doesn’t mean that the RPM tool was used to package it, and it doesn’t mean that the RPM tool has to be used to install it. It just means that it’s RPM formatted, because any packaging tool should be able to read and write RPM files; so it’s just a common way of trying to put all your packages together.
There’s also a question about whether your application is being installed in the correct place. Do you comply with the file system hierarchy standards? An ISV or a third-party product that installs on Linux should install itself in /opt. But if you’re a large company like IBM, you’d put all your software into /opt/ibm. That prevents any name space collisions with other similar packages.
For example, if IBM were to ship a Java and Sun were to ship a Java and Red Hat were to ship a Java, and we all put them on the same system, we wouldn't want these different Javas to be overwriting each other’s files. If IBM puts their Java in /opt/ibm, then they won't collide with /opt/sun.
How can an ISV determine how hard LSB certification will be for their particular solution?
George: I think the best way to size that is to actually complete the survey.. The survey asks, what compilers are you using? How are you building? What libraries are you using? Then one of the steps in there is saying "run App Check;" and another asks, "do you comply to the file system hierarchy standards?" So within half an hour, you should be able to get a good idea about how close you are, and what you need to go investigate.
What benefit do you provide to Red Hat and United Linux?
George: The benefit that we provide the distros with is a new QA suite. We’re saying, if you care about binary compatibility, here’s this quality assurance piece to add to your distribution. And see that you provide these to the applications, or to your ISVs, too. ISVs are seeking a stable environment that their binaries can run on without recompiling. This is about using our branding to validate that your distro can do that.
We’re seeing people start to require LSB. For an example, the Department of Defense now requires LSB for Linux. The Hong Kong government requires LSB for Linux as well. So we’re starting to see these requirements turn up in procurement cycles. Each of the different distro brands can provide their unique value to customers, but the LSB brand is going to be the brand customers look for first.
Is there anything else you'd like to add?
George: The biggest point that LSB certification is a new piece that most people aren’t used to, but it's very important. This is binary compatibility.
Most people are used to thinking about source code compatibility. I was on Solaris, and now, I’m working on HP-UX so I had to port it. That's not what we're talking about here. If my app is LSB compliant, and I built it on Red Hat, then it runs on SuSE without a recompile, even though it’s the exact same binary image. People need to understand and embrace this new capability that Linux has to offer. At the end of the day, for the Linux distros it means more Linux applications, which means more customers. And for ISVs, it means a larger base of Linux customers who are able to use their applications -- without recompiling
I also want to again to encourage ISVs to take part in the LSB ISV survey. We want to continue to make sure our standards are consistent with the way most ISVs are doing their Linux development, and the survey will help us do that.
Thanks for taking the time to talk with us.
Note: All trademarks are the property of their respective holders.
