Linux Standard Base 1.1

Staili writes: "Zdnet is reporting that The Free Standards Group released version 1.1 of the Linux Standard Base (LSB) as well as the first version of the Linux Internationalization Initiative standard to deal with Linux language barriers."

Comments

Wired Article

[L-Wave]

Here[wired.com] is an article on wired that i had jsut submitted before I saw this go up...its pretty good, lists some big players. =)

Re:posix?

[bourne]

isn't this the whole idea of "posix compatible"?

I'm no expert, but I believe that POSIX compatibility only involves things like system calls and library interfaces. LSB includes things like filesystem layout and recommended locations, so that (for example) you don't have /usr/bin/sendmail on one distribution but /usr/sbin/sendmail on another distribution.

POSIX is an OS standard, LSB is a distribution standard.

Re:Package format

[Cpyder]

Both package formats have their (dis)advantages. Standardizing on RPM does not mean you can't get the advantages of apt, however: Apt has been adapted for RPM. It's used in Connectiva. More on apt-rpm at this site, or at a search engine near you. I hope that with the wider adoption of LSB and FHS standards it will be easier for both users and programmers to use "cross-distro" packages. Nowadays too many packages are wrongly linked to libraries, making them hard to use on other distros than the ones they were made for. Try to install a SuSE package on a RedHat system and you'll know what I'm talking about.

Re:posix?

[The G]

POSIX is a documentation of minimal standards for the things we all take for granted in UNIX and UNIX-like systems. Things like "time is represented as seconds since the epoch" and "regular expressions are available through the regcomp() function, which returns an opque object to be passed to regexec()" and "all POSIX systems will provide threads, mutexes, etc. that meet the following interface, in addition to whatever platform-specific threading they may have."

Linux is almost, but not quite, POSIX compliant -- I don't recall why it isn't, but in practice you're unlikely to run across the boundary cases.

POSIX, however, does not speicify things like the difference between /bin, /sbin, /usr/sbin, etc. It provides only a fairly minimal set of tool requirements (for instance, .tar files aren't guaranteed to be cross-platform compatible, iirc).

This is the hole that the LSB is trying to address -- creating a standard that actually provides real consistancy not only to programmers but to users.
--G

Those who read the standards might have a clue

[Christopher B. Brown]

Debian packages do not HAVE TO BE .RPM.

If you were to actually read the standards document, the requirement is:

Distributions must provide a mechanism for installing applications in this packaging format with some restrictions listed below. [2]

And if you were to look for note [2] you would find that it reads:

[2] The distribution itself may use a different packaging format for its own packages, and of course it may use any available mechanism for installing the LSB-conformant packages.

The point of LSB is to allow third party applications to be portable across distributions. That does not mandate anything about how a distribution chooses to package the Linux kernel, GLIBC, or much of anything else that it itself chooses to package.

Indeed, nothing mandates that an LSB-compliant distribution even has its own packaging scheme. A distribution could have all the components required by LSB in all the right spots, and just plain put them there. No "packages;" just files.