Linux Standard Base .9 Released
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/
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.
(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?
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
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.
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
-- john