Linux.com

Feature: News

Linux Standard Base approved as international standard

By Stephen Feller on November 03, 2005 (8:00:00 AM)

Share    Print    Comments   

An international organization is preparing to publish its approval of the Linux Standard Base (LSB) as a worldwide standard, which could potentially lead to easier migration to and software development for Linux.

The nonprofit Free Standards Group (FSG) announced at the Open Source Business Conference in Boston this week that the International Standardization Organization (ISO) and the International Electrotechnical Commission (IEC) unanimously approved the FSG's Linux Standard Base Core Specification 2.0.1 and is expected to publish the standard in December.

The FSG, which funds and maintains the LSB workgroup, spent most of the last year working toward adoption of a set of software that it hopes developers will include with the Linux kernel, to allow applications to work in a multitude of distributions. The ISO/EIC approved the LSB as a Publicly Available Specification (PAS), and it will continue to be open source and available for free.

Jim Zemlin, executive director of the FSG, said the approval offers proof to the world that Linux is a real companion to Unix systems that use the POSIX standard, and that the largely free, open source operating system is serious and in the mainstream.

"It's very important since many governments and large organizations look to ISO as the world's official standards-setting body," Zemlin said. "When ISO 'blesses' your standard, you basically have agreement from all the parties that really matter."

The ISO, formed as an outgrowth of the 99-year-old IEC in 1946 "to facilitate the international coordination and unification of industrial standards," is made up of a network of the national standards institutes of 156 countries and is coordinated from Geneva, Switzerland, according to the organization's Web site.

Although the ISO has no legal authority, it sets standards for everything from the size of handicap accommodations to technical manufacturing concepts through consensus for the good of people worldwide.

The LSB, according to Zemlin, is at its most basic a uniform set of APIs, libraries, and interoperability standards that if used would allow developers to port software to only one specific operating system, rather than having to rework applications for the plethora of Linux distributions in use worldwide. He said this ease of use could be key to preventing the fragmentation of the Linux market.

"It's death from a thousand cuts -- look at Unix," Zemlin said. "Fragmentation occurred and enabled a competitor to take significant market share. It's one thing for Microsoft to compete with a single vendor like Sun. It's quite another for it to compete with a global ecosystem of vendors and volunteers all united around an international standard."

From the FSG's standpoint, the approval of LSB as a global standard means that individuals, companies, and governments will have a unified program to work with, and as Linux grows in stature and use, the standard will help economic growth more than licenses and patents combined.

Not everyone is happy

Ulrich Drepper, lead contributor and maintainer of the GNU C standard library project Glibc, posted a scathing denouncement of the LSB on September 17 on his blog. His criticisms ranged from issues with the testing of the LSB's code to his perceived lack of effectiveness of professionals dealing with standards. He said the LSB could not be successful until the project "loses the monetary backing" and is kept alive by volunteer developers instead of those "who have everything to lose" because their livelihoods depend on the success of the project.

"I think all this futile," Drepper wrote about his doubts that the LSB will be successful in any way. "Regardless of how much time is sunk into this, there will always be holes big enough to drive a truck through."

Drepper, who did not respond to requests for an interview for this story, suggests to FSG that it "cut its losses" and make no promises to developers that their software will in fact work with the LSB until all the bugs have been worked out it, many of which he refers to catching and reporting himself.

Jeff Licquia, a main Debian developer, responded on his own blog that Drepper was concerned with self-preservation, or at least the preservation of his employer, Red Hat. Drepper suggested replacing the LSB with source specifications and identical binaries to solve compatibility issues.

Licquia questioned Drepper's motives. "He doesn't answer the question of whose binaries those should be, probably because he's happy with the current de facto answer ... Red Hat," Licquia wrote. "No doubt he would prefer a world without competition, but should the rest of us?"

Seeking to provide a benchmark for developers, as well as the forward movement of the various distributions, FSG sees the approval of LSB as a huge step forward for Linux and the identification of a standard basis for those distributions as another way to preserve both competition among developers and to protect the Linux community as a whole.

"This approval really sends the signal that Linux has matured and is a serious alternative for users everywhere," Zemlin said, adding that "it shows the global standards community sees the importance of both Linux and the LSB. There is only one standard for Linux -- this unification makes it an excellent option."

Share    Print    Comments   

Comments

on Linux Standard Base approved as international standard

Note: Comments are owned by the poster. We are not responsible for their content.

LSB winners and loosers

Posted by: Anonymous Coward on November 04, 2005 01:44 AM
Jeff Licquia, a main Debian developer, responded on his own blog that Drepper was concerned with self-preservation, or at least the preservation of his employer, Red Hat. Drepper suggested replacing the LSB with source specifications and identical binaries to solve compatibility issues. Licquia questioned Drepper's motives. "He doesn't answer the question of whose binaries those should be, probably because he's happy with the current de facto answer<nobr> <wbr></nobr>... Red Hat," Licquia wrote. "No doubt he would prefer a world without competition, but should the rest of us?"

Thanks God for Debian and its developers who are not afraid of competition to make the best product available. (But then - what would we expect from RH and its "corporate Linux" mentality?!)

#

Re:LSB winners and loosers

Posted by: Anonymous Coward on November 04, 2005 02:51 AM
When did Debian start supporting the LSB?. huh

#

Re:LSB winners and loosers

Posted by: Anonymous Coward on November 04, 2005 03:05 AM
Since Sarge. LSB v1.3 Compliance has been added to Sarge RC Policy. You can read about it here:

<a href="http://people.debian.org/~taggart/lsb/" title="debian.org">http://people.debian.org/~taggart/lsb/</a debian.org>

#

Re:LSB winners and loosers

Posted by: Anonymous Coward on November 04, 2005 02:54 AM
You're a bit harsh on Red Hat after all the money and work they've put into developing Linux under GPL.

#

Re:LSB winners and loosers

Posted by: Anonymous Coward on November 04, 2005 03:00 AM
oh but they also MADE plenty of money with GPLed products. nothing wrong here, but you make it sound like they are acting out of philantropy or something. besides, I used RH as an example of "corporate linux" mentality, but I could have mentioned Suse or Mandrake (which I recently ditched for Debian because of that) or any other. I do not believe that corporations can act in any other way, its their nature. all they care about is getting a max of money out of us. the rest is all window-dressing. With Debian, I found both a vastly superior product and a non-corporate, truly communal, mindset. and yes, a willingness to do whatever it takes to make the superior product. and the result really, really rocks<nobr> <wbr></nobr>;-)

#

Re:LSB winners and loosers

Posted by: Anonymous Coward on November 05, 2005 02:10 AM
No, Drepper was actually correct. If you change the hardware that something runs on you can actually break any LSB compatibility in most cases, as well as the way they are developing test suites for it. The LSB is an absolutely useless standard for ISVs to code to.

#

Clueless, so asking

Posted by: The Spoonman on November 04, 2005 03:30 AM
Okay, in non-programmer language can someone explain the upsides and noted downsides of the LSB? It was my understanding that the LSB was designed so that closed-software vendors can port their software to Linux and be assured that their software will run because a pre-defined set of pre-compiled binaries and libraries will be there. Why does the standard force me to install pre-compiled binaries on my system? I use LFS, so I don't want someone else's "base" binaries on my system. It kinda defeats the whole purpose of using LFS. Yes, I have to use someone else's precompiled, closed-source binaries on my system if I want to use a commercial app, but I can live with that as long as I'm clear what's running as the base system. I also install closed-source apps to their own folders in<nobr> <wbr></nobr>/opt like they're supposed to be so that they're isolated.



I guess it comes down to this: why specify pre-compiled bins and libs? Why can't they specify a "recipe" of how the components are compiled, which features are or are not activated (such as during a<nobr> <wbr></nobr>./configure step), and which dependancies must be in place prior to their compilation. If you do that, and the final binaries do not conform to the expected results, there's obviously something wrong somewhere. Shouldn't source compiled on my machine produce relatively similar (assuming gcc optimizations, etc) binaries on yours? If it doesn't, then the problem's the toolchain, right?



For example, if you compile Samba, and have PAM already installed, I believe configure will detect PAM and compile in support for it (I'm not saying Samba should be part of the LSB, just using it as an example. Also, I'm not sure if PAM detection is automatic for Samba, but some packages do activate various features automatically when it detects the required dependancies).



If you follow a pre-determined recipe for setting up a distro in this manner, for the most part pretty much everything should install and run just fine. I've never had any trouble running any commercial product (which includes biggies like Crossover Office 4.x, Vmware 5.0 and a few others) on my LFS-based system without a single LSB binary anywhere near the machine. But, then again, I'm pretty anal about making sure EVERY listed prerequisite be in place before compiling a package whether it's listed as required or optional. Disk space is cheap, why risk issues by not installing 100k of libs?


#

Re:Clueless, so asking

Posted by: Anonymous Coward on November 04, 2005 08:58 AM
Maybe I'm completely off base but my understanding is that you have a standard POSIX that defines a number of things.

EG. pipes,<nobr> <wbr></nobr>/bin,<nobr> <wbr></nobr>/lib, how files are treated, cp, cat, mv and a number of other core programs.

While this is good and means that it is easy to port apps from Freebsd to Openbsd to Linux to Solaris etc it doesn't mean it will just run.

The LSB tries to standardise more. Some of the things I'm aware of are<nobr> <wbr></nobr>/media for cdroms and usb sticks. DBUS for automatic hardware detection. Various extensions for X.

Also as far as I knew it didn't require you to use their binaries BUT the binaries that are used REQUIRE a specific ABI (I think) so other programs can link to it.

This basically means you have a couple of options.

1. Code to POSIX and Standard X - A rather limited environment that doesn't include binary compatibility or many features.
2. Code to a specific Distribution. Rich environment but limits your customer base.
3. Code to minimum of a set of distributions. Not as rich as a single distribution but a bigger customer base also you'll have to do a release for each distribution as they are all a little bit different. (This is what tends to happen at the moment)
4. Code to the LSB. Not as rich as a single Distribution BUT YOU ONLY HAVE TO HAVE ONE RELEASE. If you look at a lot of packages at the moment you've have about 5+ different release.
Redhat 7.3
Redhat ES 2.1
Redhat ES 4
SuSe 8
SuSe 9
Mandrake 6
etc.
While the LSB won't get rid of the old distributions it's aim it to make it better in the future. Instead of:
Redhat 2006
Redhat 2007
Redhat 2008
Redhat 2009
SuSe 2006
SuSe 2007
SuSe 2008
SuSe 2009
Mandrake 2006
Mandrake 2007
Mandrake 2008
Mandrake 2009
you'd have
LSB 2.1
LSB 3.7

That is my understanding. The only other thing that it seems to be doing is getting new stuff locked down and working between KDE and Gnome and getting new stuff into X (DBUS and some X extensions)

That is my impression anyway.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya