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."

posix?

Pardon me, as someone who uses linux, but is not a guru...isn't this the whole idea of "posix compatible"? seems redundant to me.

Re:posix?

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:posix?

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

Thats all well and good

I see all the major players are involved too.

so, how many of the major distros are/will be compliant ?

when will I be able to buy a book on administing an LSB 1.1 system ?

LSB is about deployment

A Linux distribution can consist of 90% software not covered by the LSB. Therefore, it makes no sense to discuss "administering an LSB system".

LSB is about minimum requirements for a distribution in order to make distributions more compatible, i.e. it's about deployment. If you distribution is LSB 1.1 compliant, then you should be able to install all software that only requires LSB 1.1. compliance. For a start, this will not cover ordinary GUI software.

In order to create a long-lasting standard, you cannot cover issues that are constantly changing or under development, so don't expect LSB to cover a whole distribution anytime soon. But LSB is an important step to make sure that distributions don't fork into something incompatible.

Wired Article

Here [wired.com][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. =)

would be great

The LSB is, in my opinion, crucial for the adoption of linux by the average Joe. But who actually follows the LSB? We can create system guidelines all we want, but until they are widely followed, they aren't "standards."

Distros are in but...

Linus and Alan Cox aren't mentioned. Surely having the distros agreeing is one thing but if Linus and Alan change things within the kernel this would render the LSB pointless.

Windows manages to have some compatibility between 95/98/2000/XP because the control all of the OS, the distros don't control the kernel.

Interesting to see how often LSB has to be updated to keep up with the kernel.

Package format

How much does standardizing on RPM as the package format affect systems like Debian? From my understanding the whole apt (.deb) system has a lot of nice features that RPM doesn't... Not that it's a bad thing, I just wonder how much debate went into this particular aspect.

Derek

Re:Package format

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 [connectiva.com]. More on apt-rpm at this site [sourceforge.net], or at a search engine near you. [google.com] 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:Package format

IIRC .deb doesn't have some of the nice error checking that rpm has, like signing. Also compare files on a system to the originals in an .deb to check for tainted files (though while looking I see that debsums(1) might do the trick.

Other problems is the PITA it is to do an non-interactive install of debs. One of the biggest bitches I hear about debian is that when doing an initial install, and you've gotten to the part where packages are installing it goes something like this:

*install*
*install*
*install*
*ask question via debconf*
*install*
*install*
*ask another question*
*install*
*install*
*install*
*ask same question again*
*install*
*install*
etc...

Also .deb's inadequate logging is mentioned, as well as keeping the install messages somewhere, or keeping previous versions of a package (what happens when you find out that libfoo is completely b0rked in the latest version, and have to run around searching for a mirror site that hasn't been updated yet. This generally only happens in unstable, but it's still a PITA :)

There were a couple of other features that .deb didn't have, but I don't recall them right now.

Some references and info is here [debianplanet.org] though that's a lot more pro-deb than discussing this exact issue, but there's good info there.

Oh, and before you start flaming, I'm a long time debian user :)

What is the point of this?

I mean, honestly, don't we already have POSIX? Isn't this what this is really all about? i.e getting a standard out that all unixes can use, with the reliability and scalability to boot?

I believe that linux has partial POSIX compatiblity, but if the kernal was 100% compatible, would we have this "group" of large companies wanting to add features to "ensure" compatibility?

From whatis.com

POSIX (Portable Operating System Interface) is a set of standard operating system interfaces based on the UNIX operating system. The need for standardization arose because enterprises using computers wanted to be able to develop programs that could be moved among different manufacturer's computer systems without having to be recoded. UNIX was selected as the basis for a standard
system interface partly because it was "manufacturer-neutral." However, several major versions of UNIX existed so there was a need to develop a common denominator system.

Informally, each standard in the POSIX set is defined by a decimal following the POSIX. Thus, POSIX.1 is the standard for an application program interface in the C language. POSIX.2 is the standard shell and utility interface (that is to say, the user's command interface with the operating system). These are the main two interfaces, but additional interfaces, such as POSIX.4 for thread management, have been developed or are being developed. The POSIX interfaces were developed under the auspices of the Institute of Electrical and Electronics Engineers (IEEE).

________________________

So basically, we have a standard, not just for Linux, but for all *NIX's (BSD, IRIX, Solaris, etc) And this geat consortum wants to make a new standard. Hmm, I hope it doesn't break the thousands of programs already out there. I mean, I could live with a re-compile for quite a bit, but this Linux consortum is honestly going to have to come up with something pretty convincing to show me that this compatibility is not going to be broken.

From the Linux Base website:

A lot has been said of late regarding the possibility that Linux will fragment into incompatible versions. Some of the speculation has been well reasoned, some not.

The least credible argument has been that Linux will fragment because UNIX did. This completely ignores the market dynamics that caused UNIX to fragment, and
consequently why these dynamics do not apply to Linux. UNIX was a means to an end, and the end was to sell unique hardware solutions. Linux is the means to a
completely different end - a free (as in free speech), reliable, scalable open source solution. Linux is, in a sense, an end unto itself.

_________________________________

Ok, I can get that, but UNIX (as long as it was POSIX compatible) never split up to the point that it was completely unusable across platforms(and I am talking about CLI, not window managers)

Re:What is the point of this?

The LSB tries to standardize something completely different then POSIX does. It tries to standardize the minmum aspect that a distro must have to be compatible with others. Like mentioned in an earlier post, try to install a SuSE RPM on a RedHat system to see what the LSB means and tries to standardize.

POSIX is more on a programmers level where LSB and the FHS are more on the disk layout and library standardization.

For example: If i have a program for Linux it needs to use some libraries. There are different kind of these with every distro.. which library to include/use.. What is the disk layout? Do i install my package in /opt or in /usr/whatever. These problems are difficult to tackle when you write a linux program. If FSB and FHS are widely used and are really a standard one wouldn't have to worry about these trivial things..

Wee

I installed it and it took over my computer! But then again, I should have known better.

After all, everyone knows that All your Linux Standard Base are belong to us.

I don't get it...

Okay, I may be the only one on the short bus today, but I simply don't see the value in the details of the document. It seems to be very vague and incomplete. For instance, under filesystem, in which the question of where to put things is something that many people think about at some point. It makes three references to some special files in /dev. And for shell it just says to use a posix compliant one, well no shit sherlock. I'm personally not impressed by making rpm the standard packet format since in my 7 years of linux usage I haven't ever used a distro that used rpm. Like I said, maybe I'm missing the big picture here.

Only a little off topic

As far as standardization goes, is there any word as to when gcc will be able to compile ANSI C++ standard code? As in: using namespace std; and fun jazz like that. Or, contrariwise, is no one planning to do that with gcc as borland can already? Just asking to know, not trolling, honest.

LSB 1.1....great....now someone...

ANYONE start using it! Preferably everyone.

Some people will say well what does this does to debian/apt. I say nothing. Apt is not dependant on using deb as evidenced by apt-rpm. Debian can adapt the Connectiva apt-rpm package and switch to rpm's rather easily (unless they are too pig headed). Also, does LSB compliance not allow you to use other packages as well as accepting RPM's?? That way debian can stick to debs for the short term, and switch to RPM's in the long term. Then at some point in the future, LSB can change the spec and require RPM only.

I would also like to see apt or some advanced package manager included in the spec as well. Apt kicks major booty and takes away the dependency hunt.

Those who read the standards might have a clue

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.

Standards, well, are needed.

This is so needed. Just following a HOWTO doc can be gruelsome, at least for persons who truly needs them (the newbies), due to incompabilities in, for instance, the substructure of /etc, locations of different config files, which may be a hassle to find on your own in the often bloated directory-structures, etc.

IMHO, anything that causes more conformity between distros is A Good Thing, though I am sure many would not agree with me. Hopefuly something will be done about the /&#!"# dependency issues that comes with far too many installs of software not especially (re)packaged for your distribution.

Mandrake

I almost hate to do this but, I think Mandrake REALLY needs to start reading this and taking it into account. I've been using MDK for a few years now and I do really like the distro. Hell, infact, I'm burring the 8.2 beta2 [slashdot.org] right now. *BUT* one thing that makes me REALLY hate what they do is all this -mdk crap. Even something simply like the Kicker Menu icons are all stored in -mdk locations so no source that you use will get the icons right without you making symlins all over the place. And even when you DO make all the symlinks and copy stuff to MDK's locations, next time you install something, their RPM's will run "update-menus" and "fix" all their locations to their liking. THAT makes me not too happy.

For instance Mosfet's Liquid theme [kdelook.org]. He has a kcontrol module that he uses to control his theme. You can't have it on MDK if you don't copy his module to (something like, I forget): /usrshare/applnk-mdk-simplified/.hidden/Configurat ion. Not the two big problems there. First eh mkd specifck location and then a HIDDEN dir on top of that.

It's this sort of thing that (my understand is) the LSB is supposed to help "prevent". I wish MDK would follow it. I think it would REALLY help the newbies if they did.

It's very strange...

To notice that Mandrake, which is the most internationalized Linux distribution in the world [linux-mandrake.com], is not part of the li18nux initiative.
Also strange to notice that the logo used at li18nux website ressembles much to the one used for years at Mandrake's i18n main page! Anybody knows why Mdk is not part of the li18nux initiative?

Standard of RPM subset

While the standard does narrow RPM to a subset of commands. The set of commands seems too large, and the syntax of the commands is ambiguous. Should the commands always allow all GNU options or could a subset (like busybox) be sufficient.

The required command syntax should be complete spelled out, so you could write a portable rpm. If the command set was known, you could write rpm such that it is independent of system tools and does not require the root user to use --root option. This could be good for embedded systems.
rpm and busybox could share a .so.

I think it's time...

For RedHat, MandrakeSoft, Lycoris (Redmond Linux), Xandros and any other distro leader out they're to get involved to make Linux a better place for the average user. It would be nice to be able to click on a ONE link to download a program/driver off the net and not have search though this list. I'm sorry but it's time for a change... It's hard for every day people install programs and It's a pain for developers to repackage there binaries over for each distro. If you have time people check out Fiorina: [com.com]
Linux not a threat to Microsoft on cnet. You'll it under January 30, 2002 but there Fiorina talks about how we are fighting Microsoft, but she saying what I been trying to tell my friends all this time.

We need to build a better desktop and stop bitching about Microsoft. We need to put our time into something better besides bitching about Microsoft because the only way we can beat them is to build something cleaner, faster, easier and better then what they have now. So MandrakeSoft, Lycoris and Xandros you want the to be the king of the desktop well you better to start looking that the LSB 1.1 because you are not going to get anywhere with your just putting the newest KDE, GNOME and X11 on a CD and calling it Linux 8.x. I can tell you one thing I had a friend that switch back to Windows because it was as hell to install programs and to get his hardware configure. I was helping him maintain his system, but when I got busy with doing work on the weekends trying to help my friend out on this website I couldn't be their to help him with his system. The sad thing is I'm very happy to see that he switch back to Windows, hell I been using Linux for 2 1/2 years( no duel booting for 1 1/2 year ) and been thinking about it myself. I been paying for games/software and supporting the companies out there but it's not doing any good if you got some open source bigots are going to warez sites or newgrounds for close source software for Linux that's not GPL or FREE. Flame or mod me down if you like, I'm just saying what's on my mind. I'm a programmer for a CBT company and I love programming, but I got bills to pay. In the end it's all about money and what's the next big thing.

Which are the most conformant

Which Linux distros are the most conformant, or most closest to conformance with the LSB?

I've seen comments that Mandrake is the most internationalised. Is this true. How do other distros such as Debian compare?

On the issue of internationalisation, how is that accomplished from a programming perspective? Most of my development work occurs under Windows, where it is very easy to switch between single byte, multi byte and Unicode at compile time (based on TCHAR definitions). It is also very easy to switch resource DLLs. How is this achieved under Linux? And, does Linux make use of code pages, or something similar when it's not using Unicode?

Ok does that mean...

I will no longer be able to design my software to install in /usr/local//bin/

if I wanted it included in a major distro?

Or does that mean that the distros will have to adapt the software to the standard?

big names

* Caldera Inc * Compaq * Corel Corporation * The Debian Project * Enhanced Software Technologies, Inc. * Hewlett Packard (sponsor) * IBM (sponsor) * Linuxcare * Linux for PowerPC * MandrakeSoft * Metro Link, Inc. * Olliance * The Open Group * Oracle * SGI * Turbolinux Inc. * Red Hat Software * Software in the Public Interest, Inc. * SuSE GmbH * The USENIX Association * VA Linux * WGS Inc

Re:RSB (RPM Standards Base)

Would it actually be "GNU/RSB"?

Re:Wow

They do NOT standardize on GNOME. GNOME is mentioned ONE time in the entire LSB-document, and that is as an example for a packagename ("lsb-gnome-gnumeric").

They DO however standardize on RPM, which is fine, because almost all distributions use it. Debian probably only have to make sure they support RPMs as well as debs, something they already do through "alien". RPM is also in the Debian-repository.

Re:Ce que je pense...

I'll not attempt to respond in French. I'd like to see more non-angophone languages on /.. It makes the place more interesting ;) It also leads to interesting effects on moderation. I find it sad that some people might be offended by other languages here, which in my mind means it is more important to use other languages: this will forcibly challenge those people. Ultimately, perhaps /. needs a way of indicating posting language, and a way to either automatically include translations, or filter out stuff that one can't read. The main disadvantage that I see is that posting in an alternative language can reduce the number of readers and responses, so it's a choice of how big you want your target audience to be.

Re:i18n is easy.

• Greek is relatively an easy language for softwares to support, than other language like Chinese, Japanese, Thai, Hindi, Arab, Hebrew, and so on.
• Locale is a mechanism and framework for i18n and has been used for tens of years. (At least, every east Asian Linux users can do nothing without locale mechanism.) Unicode will be used within the framework of locale, i.e., through UTF-8 locales.
• Your software (which needs recompile to support Greek) seems not to use locale framework. Your problem seems to be very easy and you don't even have to use Unicode to solve your problem.