Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Linux Software

Linux Standard Base 1.1 162

Posted by michael
from the so-many-to-choose-from dept.
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."
This discussion has been archived. No new comments can be posted.

Linux Standard Base 1.1

Comments Filter:
  • posix? (Score:2, Interesting)

    by Pharmboy (216950)
    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? (Score:5, Informative)

      by bourne (539955) on Friday February 01, 2002 @09:27AM (#2936974)

      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.

    • You know, I've been using Linux for about four years now, and I still have no idea what POSIX is. Anyone care to risk being modded off-topic to explain? =)
      • Re:posix? (Score:5, Informative)

        by The G (7787) on Friday February 01, 2002 @09:45AM (#2937059)
        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
        • Re:posix? (Score:2, Informative)

          by Anonymous Coward
          Just adding to what you are saying -- POSIX is a US Government standard where some level of conformance is required to get certain contracts. That's why Windows NT has a useless minimal POSIX subsystem tacked on, and the Linux boot sequence has a "POSIX certification by so-n-so" message. There's different levels of the standard, so MS and Linux can get away with advertising some POSIX conformance.

          As pointed out, POSIX is all about making it easy to port source code and has nothing to do with binary compatibility or runtime issues like paths and libraries.

          POSIX is also part of a greater set of standards called the Single UNIX Specification (SUS). If you meet the SUS specs and pay a fee, you can advertise your product as "UNIX", even if it's entirely reverse engineered.
      • Look at the post about a dozen spaces above yours. Since I'm such a nice guy, just click here instead: What is the point of this? [slashdot.org]
    • Linux isn't quite Posix compatible yet. Don't worry about it though, I think it's some esoteric thing like a couple of totally obscure function calls. Not something simple like "ls".

      Oh yea, this organization gives us the opportunity to say, "All your Linuxbase are belong to us!". (ducks and runs...) OUCH! Hey! quit throwing shit at me!
  • by steve.m (80410) on Friday February 01, 2002 @09:08AM (#2936869) Journal
    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 ?
    • by dybdahl (80720) <(info) (at) (dybdahl.dk)> on Friday February 01, 2002 @09:26AM (#2936972) Homepage Journal
      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 (Score:4, Informative)

    by L-Wave (515413) on Friday February 01, 2002 @09:10AM (#2936878)
    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 (Score:2, Insightful)

    by aoty (533561)
    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."
  • by MosesJones (55544)

    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.
    • they both give it their 'virtual blessing' accroding to an article on the register [theregister.co.uk]
    • I really don't get it... IIRC the linux standards guy was sometime ago here on /. bitching and quarreling with Free Sofware advocates because you all complained that having to pay to get a vote was agains the principles of Free Software. Now I see "ooohs" and "aahs", why?

      Why in hell do we need standards based on what paying corporations say? Isn't it the whole point of Free Software, not depending on corporations?

      LSB "may?" be useful, but surely is annoying. And I don't think we really need it. We develop by darwinistic evolution of code, and not by commitee!
      • you don't get it.........the structure of how the distro is layed out is not based on code (other than that of the installer) it is based on where the distrobution creaters what to put stuf, and how they want to link things, and how they want the directories layed out.....it is the structural placment of the programs......code is darwinian, but you need to have certain aspects remain the same.......the lattest stable glib, the latest stable KDE/Gnome, etc.....that is all...this will just put all the distrobutions at the same base at the same time......and the LSB will update as frequently as needed when a new stable library comes out.....
    • by smooc (59753)
      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.


      You are forgetting that the Linux which to
      which you are referring is actually GNU/Linux.
      Linus and Alan have nothing to do with the
      GNU part (ok, they have something to do with it but not in this particular case). The LSB doesn't describe the API of
      the kernel; it describes for example how
      files are being layed out across the filesystem

    • Look for the section entitled Kernel Requirements.

      You won't find one. There isn't one.

      This actually has a really entertaining implication, namely that despite saying "Linux" a lot, the standard hasn't anything forcibly to do with Linux.

      • I'm fairly sure that the FreeBSD folks are likely to be able to take this standard and make some changes to conform their "Linux compatibility" subsystem with it.
      • I'll bet that SCO (A division of Caldera) could take this standard and make SCO UNIX, with some layering of GLIBC, compatible with it.
      • Ditto for BSDi, AIX, HP/UX, and Solaris. I'd almost bet anything Sun will do some work to get Solaris "conformant," at least looking ahead to Solaris/IA-64
      • It would be quite the shock if Microsoft were to throw some effort into their "Linux Emulation Environment" (it exists; I don't recall the name...) to make it "LSB-Conformant."

      The notion that this standard has much of anything to do with the Linux kernel is desparately ignorant of a reading of the standard.

    • Look at LSB mailing list [debian.org], and see how many times Alan Cox has posted in just the last month. I count 23, myself.
  • Package format (Score:5, Insightful)

    by d-rock (113041) on Friday February 01, 2002 @09:20AM (#2936935) Homepage
    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
    • Debian is one Contributor to the LSB. I don't think they would've agreed with it if it would harm them.
    • Re:Package format (Score:5, Informative)

      by Cpyder (57655) on Friday February 01, 2002 @09:27AM (#2936977) Journal
      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.
      • So what are some disadvantages of .debs? I hear statemts like yours all the time but I don't think anyone ever points out a downside to the .deb format.
        Care to enlighten me?
        • its only used on one major distribution

          Its easier to add RPM to Debian (for those packagers that only want to supply one binary) than the add .deb to RedHat, SuSE, Mandrake, Connectiva, Turbo Linux, Caldera, etc.
          • Thats an argument for choosing one over the other not a measure of one package against the other. By your reasoning we should all use windows because its already used by so many people.

            Choose the right thing because of its own merit not because it is already pervasive.
        • Re:Package format (Score:4, Interesting)

          by Alan (347) <arcterex.ufies@org> on Friday February 01, 2002 @12:35PM (#2938038) Homepage
          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 :)
          • Re:Package format (Score:2, Informative)

            I'm pretty sure that .debs have error checking. FWICT apt checks md5sums to verify the package is intact and dpkg will verify the signature. I don't know for certain that it actually does this but thats what the man pages say.

            The bugging questions is another issue. Personally I don't mind the questions. It IS possible however (as im sure your aware) to set the importance level of the questions. I don't know how many that could eliminate but it probably couldnt' be worse. dpkg probably also has a setting to always assume defaults.
          • Actually, most of those deficiencies are actually fixed.
          • IIRC, there is a way to sign packages, and there's also a way to do all the questions up front with debconf (apt-utils? not sure) - debconf also has a noninteractive mode, but i don't know if that's any good, never tried it.

            You're right about the logging. I disagree about the previous versions of packages, i sometimes have four previous packages in apt's cache. Do you apt-get clean every time you upgrade?
        • .deb doesn't allow for different versions of the same package to be installed at the same time. This is useful for packages that are explicitly designed to be parallell-installed.

          .rpm-based distributions usually make use of this for the kernel. It's perfectly valid to have two or more versions of the "kernel" package installed.

    • IIRC, RPM was mandated as the package format in LSB for downloading packages. Distros can still use whatever format they want for internal packages.
    • Were you to read the standard, [linuxbase.org] you might be able to figure out answers to these and other meaningful questions.

      The ans wer is, by the way, that it doesn't affect Debian in any meaningful way.

      • The standard does not require that Debian drop its own packaging scheme.
      • The standard does not mandate the use of RPM packaging within the distribution.

      Read the standard; it's not particularly painful to read.

      A much more entertaining thing is to think about how this might affect folks using FreeBSD [freebsd.org] It is entirely possible that this standard allows FreeBSD, which is conspicuously not Linux as well as not based on RPM packaging, to nonetheless become a nicely "compliant" Linux Standard Base platform.

      Heck, Microsoft might be able to modify the "Unix Emulation" environment they have running on Windows NT (it's sold as something; I don't recall the name...) become compliant with LSB

      This wouldn't be any stranger than when Microsoft made Windows NT a "POSIX" platform, or when IBM got OS/390 certified as a Branded Unix (tm)

      The notion that this creates some massive problem for Debian is just plain ignorant, and when the article links to the publicly-available-on-the-web standard, being so ignorant is quite inexcuable.

      • The ans wer is, by the way, that it doesn't affect Debian in any meaningful way.

        I disagree.

        * The standard does not require that Debian drop its own packaging scheme.
        * The standard does not mandate the use of RPM packaging within the distribution.


        The standard mandates that RPM is the preferred packaging system for people creating applications to run on Linux. Debian;s LSB support is based on the existence of Alien. I don't know too many Debian people who would trust alien to install large parts of their system.

    • It affects it not at all, since this so-called standards organisation has no authority over anyone, and everyone who matters has already decided to ignore them.
    • It won't affect Debian at all.

      This is the Redhat Linux Standard Base, as witnessed by the complete stacking of board members in favour of Redhat, hence Debian and other non-rpm-based distributions can completely ignore this so-called "standard" and continue to distribute their technically superior distributions in peace while Redhat make the Redhat Linux Standard Base their next marketing tool. "Hey, we're compliant with our own standards, aren't we cool!". Hmm, sounds very familiar *cough*Microsoft*cough*
  • 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)
    • here is the most credible argument.....

      we want computer stores to start to carry software for Linux, with out the LSB, we will not see this or will see things such as, "made for RedHat x.y"

      that is why the LSB is needed, so _consumer_ application makers will make software for Linux.
    • 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).

      Is there a POSIX definition as to where packages go in the filesystem and what libraries are to be included? If so then I would say that your post is on target. If not then perhaps the LSB and FHS should be rolled into the POSIX standard. One stop standards shopping.
    • by Diabolical (2110) on Friday February 01, 2002 @10:26AM (#2937295) Homepage
      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..
      • How does this differ from the various *NIX flavors who attempt to mimic (for instance) System V behaviors?

        FS layouts are part of SysV Layout [washington.edu] (of course you also have BSD Layout [washington.edu]).

        I understand that *NIX variants with Sys V behaviors are largely inherited (Just their branch of the *NIX tree) but doesn't standarding on this behavior address some of this already. (Although maybe not libraries) I'm not arguing the points above -- I'm just looking for clarification
    • Without actually having read the LSB, I would figure it addresses things like whether it is /etc/init.d or /etc/rc.d/init.d, or whether it is glibc 2.1 or glibc 2.2, or whether bash or csh is the standard shell, whether /sbin is part of your PATH or not, or whether /opt is optional or not, or whether perl lives in /usr/bin/perl or /usr/local/bin/perl or someplace else again.

      POSIX is not a standard in the sense that LSB is a standard. Even Windows NT can claim some degree of "POSIX compatibility", which should tell you something.

      • And what about development packages?

        Where about standard include directories?

        Trying to compile something on SuSE is a bitch.

        It would be nice to have this addressed in a standard too, at least for kernel headers and "standard" include files.
  • Wee (Score:1, Offtopic)

    by NiftyNews (537829)
    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.
    • well, maybe this won't happen on this release: since this is the .1 release instead of .0, it'll be mainly bug fixes; everyone knows .0 releases suck ass.
  • 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.
    • As for the RPM part, I would assume it is because it is
      almost a de-facto standard (sorry Debian people/deb-users).
      The number of RPM users outnumbers by a fair margin the
      number of deb users. Instead of driving all the RPM users and
      RPM-based distros from all jumping into deb, they call for a smaller
      number of users and distros to take up RPM.


      Yes, I like virtually all other RPM users, have been in RPM-dependency
      hell. This shouldn't be a problem inherent in RPM. Surely there is a way to
      "apt-get" RPMs and handle their dependencies just as well as with apt-get
      and deb?


      Overall I like the spec. I'd like ANY standard spec, particularly for the filesystem
      layout. I would like to know that no matter what distro I install I will ALWAYS find file x in
      /etc or binary y in /usr/bin instead of /usr/local/bin (or vis versa).

      • "Overall I like the spec. I'd like ANY standard spec, particularly for the filesystem layout. I would like to know that no matter what distro I install I will ALWAYS find file x in /etc or binary y in /usr/bin instead of /usr/local/bin (or vis versa)." I agree with that. The question is are you getting that from this spec?
      • "Yes, I like virtually all other RPM users, have been in RPM-dependency hell. This shouldn't be a problem inherent in RPM. Surely there is a way to "apt-get" RPMs and handle their dependencies just as well as with apt-get and deb?"

        Yes, there is. Apt can handle rpms as aptly as debs, as shown in Connectiva's apt-rpm. The thing people always seem to forget, though, is that, while apt is a wonderful tool, it's not the (only) thing that makes installation of packages on Debian so sweet. What makes apt really, really good is the blood, sweat and tears of the Debian package maintainers, who are amazing when it comes to handling dependencies in packages. Sure, the dependencies sometimes break in testing and unstable, but on the whole it works amazingly great.

  • 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.
  • by Chanc_Gorkon (94133) <gorkon&gmail,com> on Friday February 01, 2002 @09:51AM (#2937080)
    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.
    • "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)."

      They don't _need_ to switch to RPMs. I've earlier argued that there is no point in switching from RPM to Deb-packages, but the reverse is equally true.

      All they need to do is make sure "alien" works as it should, and let Debian-users install lsb-based RPM-packages easily. Internally they can and should keep using debs. Debs is what they can, debs is what they do, and switching to RPMs will earn them nothing except a lot of work. Besides I'm willing to bet that at least some of their volunteers would leave the Debian project if someone forced this change.

      In addition Debian should make sure that their debs are easily converted into lsb-rpms.

      I _really_ want to see software distributors start to offer packages looking like this: gnome-core-2.0.386.lsb.rpm

      .. instead of .mdk.rpm, SuSE-rpms, Red Hat-rpms, Connectiva-rpms.. etc..
    • Also, Debian has the RPM tool available for installing. DPKG and RPM are not mutually exclusive, you can have both packaging systems at once.
    • The notion that switching to rpms would be "rather easy" demonstrates considerable ignorance.

      There is a sizable set of tools used in the construction of Debian that are tightly tied to .deb packages.

      apt is only the start of the "advanced" aspect of package management; what's far more critical are the set of development tools, like lintian, debscripts, jablicator, deb-make, deb-helper, equivs, dpkg-dev, apt-move, and such.

      Eliminating all of that would be like telling the Linux kernel developers that they have to stop using C, and write Linux in assembly language.

      It's not simply apt-get that "eliminates the dependancy hunt;": in order for the set of packages to be kept coherent, so they're not merely a jumble of RPMs of dubious provenance strewn across the Internet, you need the development tools.

      To move Debian to RPMs would require rewriting all those tools for RPM use. There's merit to such an idea; if there were coherent tools for dealing with the development of a complete RPM-based distribution, you'd doubtless get better stability. But that's a big task, and your non-recognition of the issue doesn't make it go away...

      • Sounds to me like Debian is a little too tied to it's package format. And now it'll have to support 2 package formats to be LSB complient. In addition, none of the debian .deb packages can be considered LSB complient since they are not .rpm. In my opinion, too much time has been wasted on .deb, and anymore time wasted on it is time wasted. Going forward, packages HAVE TO BE .rpm to be standard and cross LSB compatible, which is a good thing.
        • 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.

      • I would oppose debian switching to rpm on the basis that the rpm database is more readily horkable than deb's text files.

        Yes, it has happened to me, and that is what made me finally switch to debian.

      • Hmm....how about....apt-rpm??? The things behind dpkg and all of that sure, they are nice, but how are they all that really different from RPM? I agree that I may not be totally clued in about all aspects of apt, dpkg and all of the other stuff Debian uses, but to say that it's so tied to a packaging format??? Debian is no more tied to it then Redhat is tied to RPM. If they are, then the Debian project made a major mistake! I agree alien can assist in installing RPM's on debian, but will alien, dpkg and the rest of the debian stuff scan for dependency with in the RPM? Vice versa? Also, what's with Debian losing all of these people? Developers are leaving left and right. Also, Redhat, Mandrake SUSE and several others have gotten SEVERAL releases out since Debian released Potato. I am not saying that what they are trying to do isn't noble or right, but rock stable systems are hard to do. Don't get me wrong, I like Debian, and I like the fact that it it does try to do the right thing and the technically right thing as well, but sometimes their approach, while good, adds extra time. Time that, in my opinion, they don't have to waste. Maybe now is the time for Debian to actually form a company or form a different way of making the decisions instead of democracy. Maybe they need to modify the DFSG to be more lienient? I don't know, but there has to be someone who is going to draw a line in the sand and get the volunteers in action and get Woody released (and with a 2.4 kernel as well...). In the future, Debian may die, but the project will have donated alot of stuff to the community that can be used to advance Linux as a whole. Personally, I would like to see everyone unite so Linux can move forward without critics panning it.

        LSB is a good thing and their shuld be equal input from everyone. But someone needs to push for adaptation. PHB's and Joe Sixpacks like hearing and seeing commercials like Mandrake Linux is compliant (it isn't but) with the LSB which means no matter where you buy or download your software it will work! I think the LSB folks need someone (besides Caldera or other only Linux companies.....a company with money) like IBM to put up money for a prize. The prize could be x amount of dollars go to the distro who fully complies with the LSB first. Y amount could go to the distro who is second and so on and so on. Everyone would bite, even Debian.
        • Debian doesn't have to change package managers in order to comply with LSB.

          For that matter, FreeBSD could comply with LSB without either:

          • Using a Linux kernel

            Look at the standard; it specifies nothing about what OS kernel you are using.

          • Using RPMs instead of pkgs and Ports

            Again, look at the standard. The set of package names to be managed by RPM, which runs on FreeBSD, is intentionally completely disjoint from any set of package names being managed "natively" by the distribution.

          Careful reading of the standard shows that there is no requirement to be running Linux in order to conform with the standard. You could conceivably run some other kernel, like those from FreeBSD, NetBSD, Sun, SCO/Caldera. I'll bet it's at least theoretically possible that Windows NT with the "Unix emulation environment" could be made LSB-compliant.

        • The things behind dpkg and all of that sure, they are nice, but how are they all that really different from RPM? I agree that I may not be totally clued in about all aspects of apt, dpkg and all of the other stuff Debian uses, but to say that it's so tied to a packaging format??? Debian is no more tied to it then Redhat is tied to RPM. If they are, then the Debian project made a major mistake!

          Debian's primary advantage is that its packages are consistent. When you select a package, it comes with a very specific set of dependencies. That, and the fact that Debian is the source of the vast majority of .deb packages (especially the sort of "core" packages likely to come up in a dependency), mean they can get away with a lot of splitting up components, compiling platform-independent bits once and binaries many times (Debian isn't just an i386 distro like many others), shared libraries that get shared properly, and all sorts of other consistency stuff. Where a release-focused distro might concentrate on making all the packages in version 9.2 (say) work together nicely and consistently, Debian does a pretty good job of keeping all the packages consistent, all the time. (OK, so it doesn't always work 100% on 'unstable', but if you wanted stability you wouldn't be running that version anyway).

          Maybe now is the time for Debian to actually form a company or form a different way of making the decisions instead of democracy.

          The democracy/meritocracy structure is exactly what Debian is about - it's run by a non-profit org. called Software in the Public Interest. They don't exist to make a profit, or to make themselves popular - they exist to make a distribution of good software freely available.

          Maybe they need to modify the DFSG to be more lienient?

          And that would help how?

          If it's free (free as in DFSG), it goes in 'main' and goes on the official CDs. If it's free as in DFSG but requires non-free software (like a GPLed "helper" application for PGP for instance), it goes in 'contrib'. If it's not free-as-in-DFSG (this includes shareware and closed-source freeware), it goes in 'non-free' - contrib and non-free are easily available over ftp or as the last CD in the set. If it's not in non-free, either nobody's tried packaging it, or Debian aren't sure if it would even be legal for them to distribute it.

          Again, things like the DFSG are why Debian exists.

          I don't know, but there has to be someone who is going to draw a line in the sand and get the volunteers in action and get Woody released (and with a 2.4 kernel as well...).

          It looks like it'll be installed with a 2.2 kernel by default, and a 2.4 kernel as an option (fairly easy to install thanks to the magic of apt/dpkg - install, reboot, Lilo offers you a choice of kernel). Woody already includes precompiled 2.4.17 kernels for 386, Pentium, 686 (PPro/P2/P3/Celeron), K6 and K7 (Athlon/Duron), and that's just the i386 builds.

          OTOH, if Debian was a company, where would all those volunteers be? Probably starting their own distro or doing Linux from Scratch.

          PHB's and Joe Sixpacks like hearing and seeing commercials like Mandrake Linux is compliant (it isn't but) with the LSB which means no matter where you buy or download your software it will work!

          This is why volunteer efforts like Debian have a niche. They don't like hearing and seeing commercials, they like giving people a stable OS. They're not trying to make a profit, which is why they can get away with doing what they feel is The Right Thing.

    • SuSE has been tracking the LSB for a couple of releases now. In fact, all of their boot scripts moved to the LSB defined locations in 7.3. As far as I can tell, SuSE comes the closest to LSB compliance today.

      Red Hat has a long way to go.

      Mandrake not only has problems with LSB, but mangles core packages like Apache.
    • Any why should Debian switch from .deb packages to Red Hat Package Management packages? Why shouldn't other distros switch .debs?
      • I agree with this, as debian is not a corporately controled entity there is no incentive for them to make money, only to create a distro people wish to use. dpkg is a mature solution though it could be better in many ways just as rpm. Either way they'll have to pry my deb's from my cold dead fingers or demonstrate that rpm has come at least as far as deb's and apt.
    • Everyone is missing a big point that the .deb package format has many more features than .rpm. I'm not saying this to start a flamewar, but .debs have more advanced dependancy information such as depends, suggests, conflicts, replaces, provides etc, many scripts to run pre/post install, the scripts look after package config files well, also installation ordering, smooth upgrades between different versions of the same package etc. etc.

      I would not not want to take a step back by switching to .rpms (unless RedHat or Connectiva hack in all these extra features, which would make them incompatible anyway and need everyone to upgrade so what's the point?)
  • 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.
    • IMHO, anything that causes more conformity between distros is A Good Thing, though I am sure many would not agree with me.

      The key is having conformity where there is no advantage to non-conformity. I wouldn't want Linux to adopt DOS-style drive letters, but the big-endian/little-endian difference between PCs and Macs helps no one and makes for a lot of file conversion work. Ditto difference end of line indicators for ASCII files.
  • Mandrake (Score:5, Insightful)

    by xanadu-xtroot.com (450073) <xanadu@inorb i t .com> on Friday February 01, 2002 @10:06AM (#2937178) Homepage Journal
    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.
    • Mandrake menus:
      If you don't like it why don't you switch it off (hint: menudrake).
      I actually like the menu system (it's not a Mandrake's invention, it comes from Debian). To create a menu entry you just need to add a simple description of it to ~/.menu or /usr/lib/menu and update-menus creates the menu entries for all installed GUIs (KDE/Gnome/WindowMaker/IceWM...., see /etc/menu-methods). As a Linux developer I don't need to worry about all possible GUIs. I just need to create one simple entry and update-menus takes care of the rest. (It is also much easier for Mandrake packagers to maintain one set of menu entries than to have to manage entries for all GUIs in the distribution)
      So, if you decide to keep Mandrake menus then don't create "symlinks all over the place" but just simply add one entry to ~/.menu (man menufile).

      Mosfet's Liquid theme:
      Get a Liquid Mandrake rpm from PLF.
      • The problem with the menu system is that software coming from anyone other than Mandrake or Debian won't use it, and you end up having to create all these menu files. I wish there was just a way for update-menus to be told not to fudge up menu entries that it didn't create. Then at least Mandrake could put the KDE menus where they belong, and I could just install StarOffice and QuakeIII and have my icons. As it is, I just turned the menu thing off.

        Actually, it would be even better if KDE/Gnome/WindowMaker et al would just agree on a single location for menu entry files. Then there wouldn't be a need for another package just to update menus. Seems like that would be a good thing for a standards document to specify, actually.
    • Firstly, at this point in time the LSB is not making any stands on issues like windows managers and desktop environments. It's all strictly back end stuff (general support libraries and installation methods and standard shell scripting languages etc).

      Secondly as far as menu items is concerned, why not just use menudrake. With this you can set menu items for either global users or just for your own login. It's all point and click and it's quite easy to use. Then when you install new software, your custom buttons are there. I've used it to add all the star office icons as well as a set of shortcuts to my more heavily used folders. Works great. BTW This is all explained on their web site [linux-mandrake.com].
  • by joestar (225875)
    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?
  • 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... (Score:3, Interesting)

    by StarbuckZero (237897) on Friday February 01, 2002 @11:44AM (#2937740)
    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 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?
  • 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?
    • They already do. In fact, distros can't distribute Dan Bernstein's software (like qmail) because its licence doesn't allow it to be distributed in a different place than DJB wants it.

      When you install a Red Hat or a Mandrake, /usr/local/bin is empty. In my case, I use /usr/local for software I compile from source, but RPMs always go in /usr.
    • /usr/local (Score:2, Informative)

      by smcv (529383)

      That's exactly what /usr/local is for - locally compiled software. On most GNU and GNUish software the author sets it up to install to /usr/local by default, but you can do ./configure --prefix=/usr if you're building a distro package.

      I don't know what other distros are like about this (I've only ever used Mandrake and Debian, and I didn't get experienced enough with Mandrake to know any of the internals), but Debian source packages come in two parts - a tarfile of original, unmodified source, plus a .diff.gz file containing the changes ("Debianizations") the Debian package maintaniner made to make it fit in with Debian conventions (moving all documentation to /usr/share/doc/name-of-the-package, for instance). If the original author's makefile or other code doesn't conform to Debian conventions, the maintainer will change it so it does.

      For a program like you describe where (presumably) /usr/local/bin is hard-coded somewhere, the diff would include replacing that with /usr/bin - you, as an "upstream" developer, can probably make this easier by defining PREFIX to /usr/local and always referring to "$PREFIX/bin" and so on.

  • * 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

Any given program, when running, is obsolete.

Working...