Linux Standard Base .9 Released

Scott McNeil e-mailed me regarding Linux Standard Base releasing .9 - check out the full release of information below.

The Linux Standard Base is in the final stages of the LSB written specification for Linux. The workgroup has published the LSB v0.9 written specification, and is undergoing a 30 day Request For Comments from the public until Wednesday June 6th, 2001. Afterwards, this draft will be submitted to the Free Standards Group for adoption.

http://www.linuxbase.org/spec/lsbreview.html

The LSB is built on pieces of existing standards that are widely used by the industry and supported by the development community. These include:

• ELF & TIS 1.2
• FHS 2.1
• ISO C90 & C99
• LFS 1.5
• POSIX.1
• POSIX.2
• SUS (CURSES, XBD, XCU, XNS, XSH, XSH95)
• X base interface standards

Work is primarily being done by the development community and the major Linux distributions including Caldera/SCO, Debian, Mandrake, Red Hat, SuSE, and Trubolinux. Further contributions have come from IBM, Intel, Linuxcare, Metro Link, VA and others.

The goal of the LSB is to develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant Linux system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.

http://www.linuxbase.org/

The LSB is but one of several open source standards efforts run by the Free Standards Group, a nonprofit organization founded by community developers to accelerate the use and acceptance of open source technologies through the application, development and promotion of standards.

http://www.freestandards.org/

Comments

Misnamed

[Anonymous Coward]

In that the "Linux standard base" specifies nothing about the Linux kernel, but how userland files, system utilities, and configuration data should be layed out and installed on a file system, shouldn't this really be called a "GNU Standard Base", or at the very least, "GNU/Linux Standard Base", as this specification has far reaching implications on many of the GNU packages that make up "GNU/Linux".

This specification actually says very little about the kernel itself other than where the boot image may reside and where the modules directory may be found, and in fact specifies nothing that need even be relevant to a Linux based GNU system at all. Substitute Hurd as the kernel, or even something else, and most of this document could still apply equally well.

Re:Misnamed

[Azog]

You are correct - the reason that the kernel is not specified is that applications do not (normally) depend on the kernel. Perhaps a better name for the Linux Standard Base would be the "Gnu + X11 + Filesystem Layout Standard Base" but lets be realistic, it's going to be Linux kernels in there for a while. On the other hand, a specification like this should make it easier for alternate kernels to be accepted - if the Hurd can be used to make an LSB-compliant system, that should accelerate it's acceptance.

The point of the LSB is so that big companies can write applications and installers that will run and install on any LSB-compliant system. This is a good thing, otherwise we will continue to get applications that are "supported on Red Hat Linux 6.2" only.

The key parts to the specification seem to be the Gnu C Library (although a different C library could probably be made to work) and X11. I am happy to see that an OpenGL library is part of the spec! This should make it much easier for 3D games to work on any Linux system without all the messing around that you have to go through now.

Hopefully in the next version they will specify:

1. Fonts - how to use them, where to keep them.
2. X Extensions - X Render, for example
3. Audio

And maybe in future versions they can nail down the locations of configuration files. Beware of the inevitable holy war over init scripts... Probably the best thing about this spec is that it will make management happier about Linux, and make it harder for Microsoft to FUD about Linux fragementing.


Torrey Hoffman (Azog)

C90, C99--what about ISO C++?

[Kostya]

I see that C90 and C99 are used in the LSB (or drawn from). What about ISO C++?

(please note at this time, if you are going to post a "C rocks! We don't need no stinkin' C--!" please don't. I could care less what you think about the C/C++ holy wars raged by various loonies)

C++ is heavily used in the industry, and especially in Windows shops. If Linux industries want to steal that developer-share from Windows, they need to hammer out what C++ libs and standards compliance will be considered a part of "standards compliance" linux.

Is the absence of C++ standards due to gcc not having a ISO C++ compliant release? I know that 3.0 is in the works and that Red Hat ships a snapshot of GCC in an attempt to get better libstdc++. Is this lack of a viable free option the reason for no C++ standardization?

Re:package formats.

[Yohahn]

I agree, while they point out there is no standard, they do not back up their reasoning for using RPM as the supposedly "de facto" standard.

As RPM is the reason I originally left redhat to go to debian, I would suggest that they should either support their claim, or they shuold remove the suggestion.

In practicality, RPM used to be alot more dominant, I find that alot more projects are supporting .debs than used to.

I think Redhat is trying to promote its "redhat network" as sees Debian's apt-get as a significant problem.

I normally do not like to talk about distribution being against distribution, but in this case it has already been done and I am just pointing it out.

I use Redhat in some cases and appreciate all that they do. I just see this as obvious manipulation.

How about a standardized font system?

[Logger]

1. a standard location for fonts
2. a standard lib that renders the fonts that
a. X Windows uses
b. ghostscript uses
c. anything else uses (StarOffice, Tex ?)
3. anti-alias support (yes, X4.0.2 has this, but you have to explicitly use it)
4. You don't have to do anything other than copy a font file to the aformentioned standard location to get it recognized by everything!
5. Maybe, an extensible font library, supporting some sort of plugin architecture for adding new font formats.

Re:How about a standardized font system?

[BlowCat]

How about a standardized font system?

One should design and implement it first. If it works well and many applications support it then it may be a good candidate for a standard.

package formats.

[gimpboy]

well i've played with rpm and apt-get. from the page
Currently the LSB does not officially specify a package format; however, the recommended package format is RPM (Version 3) with some restrictions listed below. RPM is the defacto standard on Linux and supported either directly, or indirectly by the widest number of distributions. The intent is to in the future replace this format with a new format currently being developed

i really think more consideration should be given to the debian system of package management. it appears both redhat and debian are contributors, but i would imagine redhat contributes a bit more. i really think this is going to hurt things.

use LaTeX? want an online reference manager that

There was no spokesperson for gcc...

[devphil]

...because those maintainers in a position of authority (mostly the Steering Committee) have been too busy getting 3.0 ready for release. Herb Sutter had contacted the GCC list but apparently got no reply.

As you can see, as far as compliance goes, Gnu C++ is pretty good for a compiler, but is lacking in the library department. I find it interesting, and I'm sure the GNU C++ team is looking at the numbers, considering how important the library is to the standard (it really does make C++ more powerful).

The last releases, 2.95.x, as well as RH's snapshot-based spinoff of 2.96, all shipped with the old, nonstandard, noncompliant v2 C++ library, which has been mostly unmaintained for years.

Everybody's been working on the rewritten-from-scratch v3 C++ library, which has ISO compliance as its primary goal and criteria. If you get one of the nightly 3.0 build snapshot RPMS, you'll find that the new C++ library is the default.

When will 3.0 be released? Sooner, if you help.

Lets just hope

[joq]

That this project doesn't go astray or become another one of the 10,546,673,132,895,345,923,566 neat sounding projects to bring the hopes of Linux users only to falter somewhere down the line due to ego's, vendor differences in opinion, lack of insight, etc.

Well not to be a troll or say something out of place to the Linux users out there, but I think at this point Corel can come off that page (you think) lets start things on the right foot with an up-to-date site.

What about ISO C++ - (C/C++ User's Journal Tests)

[JWhitlock]

C++ is heavily used in the industry, and especially in Windows shops. If Linux industries want to steal that developer-share from Windows, they need to hammer out what C++ libs and standards compliance will be considered a part of "standards compliance" linux.

Is the absence of C++ standards due to gcc not having a ISO C++ compliant release? I know that 3.0 is in the works and that Red Hat ships a snapshot of GCC in an attempt to get better libstdc++. Is this lack of a viable free option the reason for no C++ standardization?

I'm grabbing my copy of C/C++ User's Journal, April 2001, which had a Compiler Conformance check (see it online). They have always avoided rating compilers, but now that there is a standard, they decided there was now a somewhat objective means to judging a compiler - conformance to standards. They go on for about 5 pages, explaining the tests and giving justifications for testing. The folks who create the test suites get to comment, the folks who wrote the compiler get to comment, and it looks like everyone involved will work toward meeting the standard in the next release.

Gnu gcc 2.95.2 was tested, as well as Borland BCC 5.5, Microsoft's Visual C++ 6.0, Intel's C/C++ 4.5, as well as 6 others. While just about everyone else commented on the results, there was no spokeperson for gcc.

You'll have to go to the web-site for full results, but here's a few. Three test suites were used, from Dinkumware, Perennial, and Plum Hall. The compiler was tested as well as the library, and results were given as percentage compliance.

Borland
Dinkumware: library - 75%
Perennial: compiler - 63%, library - 67%
Plum Hall: compiler - 89%, library - 74%

Gnu C++
Dinkumware: not tested
Perennial: compiler - 98%, library - 41%
Plum Hall: compiler - 94%, library - 21%

IBM C++
Dinkumware: library - 99%
Perennial: compiler - 99%, library - 97%
Plum Hall: compiler - 95%, library - 85%

Intel
Dinkumware: not tested
Perennial: compiler - 96%, library - 72%
Plum Hall: compiler - 90%

Microsoft
Dinkumware: library - 84%
Perennial: compiler - 77%, library - 64%
Plum Hall: compiler - 83%, library - 74%

You can look up the other number if you so desire.

As you can see, as far as compliance goes, Gnu C++ is pretty good for a compiler, but is lacking in the library department. I find it interesting, and I'm sure the GNU C++ team is looking at the numbers, considering how important the library is to the standard (it really does make C++ more powerful).

Re:What is this?

[phaze3000]

Like it says above, it's an effort to standardise Linux distributions' layout, with an aim to ease the use of applications across distributions. It has a standard set of directories which should be used for things like config files and documentation.

--