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

 


Forgot your password?
Close
typodupeerror
×
Linux Software

The LSB Delivers Again 158

Posted by CmdrTaco from the all-your-base dept.
gk4 writes "The LSB has updated and published the gLSB v1.1 draft for review. The LSB has also published for review the new psLSB for IA32 v1.1 draft and the completed LSB v1.0.1 Test Suites. Review ends Friday January 4th; however, the LSB welcomes comments from the community at any time."
This discussion has been archived. No new comments can be posted.

The LSB Delivers Again More

The LSB Delivers Again

Comments Filter:

  • LSB (Score:1, Funny)

    by FigBug ( 69370 )
    What is LSB? Some new drug?

    • Re:LSB (Score:1, Funny)

      by Fly ( 18255 )
      Duh, it's the Least Significant Bit.
      ;-)

    • Re:LSB (Score:1, Informative)

      by Compact Dick ( 518888 )
      LSB = Linux Standard Base. As to what it is...

      From their site:

      The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.

      ========

      Geddit? :)

      • Re:LSB (Score:1, Interesting)

        by FigBug ( 69370 )
        There needs to be a WSB... windows standards base... all the differences between 95, 98, ME, NT, 2000, XP are really starting to piss me off. arg.
    • Thank you for asking. I hate when someone post one of these articles and thinks everyone who reads slashdot knows all the acronyms in the world.
  • Just a fair warning: Prepare for your eyes to glaze over reading all of it.

    MS would call this a "robust" feature

  • How are the Distro's doing? (Score:4, Interesting)

    by reaper20 ( 23396 ) on Friday January 04, 2002 @07:40PM (#2788690) Homepage
    This is great and dandy and all, but which distro's are going to pay attention to this? Anyone have a link as to the state of LSB-compliance for the major distros?
    • I was browsing rpmfind.net [rpmfind.net] a few days ago, and I found a bunch of packages in Mandrake Cooker which were modified for LSB compatibility. That's probably a good sign.
    • SuSE [suse.com] is LSB compliant.
    • How are they doing? Piss-poorly, if this [redhat.com] is any indication. Red Hat (and several other Linux vendors, apparently) recently diverged from the published [net-snmp.org] API and ABI for a couple of routines in the UCD/Net-SNMP library. The result? Any application that calls these routines core dumps on these systems. They do this sort of thing a lot.

      The result is that most major Linux distros can't keep binary compatibility between updates and errata on the same OS release, much less between releases. Even with the LSB, I think it will be a while before we see binary compatibility between distros.

      • It's a bug, that's why it's in bugzilla. And please note, the bug is not closed! I don't think that anybody would break ABI compatibility intentionally.

        You contention that "major Linux distros can't keep binary compatibility between updates and errata" is not corroborated by any evidence. It is only RedHat and they seem to be working on the correct fix now.

        • I don't think that anybody would break ABI compatibility intentionally.

          I don't think so, either. However, intentionally or not, they do exactly that. And the SNMP example I provided is evidence. They changed the API/ABI in the SNMP packages for 7.2, as well as in the updates released a couple of months ago for 7.1, 7.0, and 6.2. Run a search for "red hat" on http://www.ethereal.com for more examples.

          The point I was trying to make (and ended up ranting instead) was that I don't think the ultimate goal of the LSB (compile a binary on one distro, run it on another) is very likely given the way distros are currently produced.
      • Debian is doing fine. This bug was reported and fixed [debian.org] two weeks before it was registered as a bug in the RH bugzilla.

        Oh yeah, it was fixed the same day it was reported.

        Anyway, here's the maintainer response:

        This is most likely due to the ill-advised security patches I had applied. Please try version 4.2.2-1. I think it will probably fix the problem.
        Looks like RedHat applied the same ill-advised security patch.
      • What do library bugs have to do with LSB compliance?
    • SuSE [suse.com] Linux is LSB and FHS complient. This of course makes it have less compatability with all other distributions because (Red Hat is an egregious offender) the norm is to be non-complient. :-(

  • The hell is the LSB? (Score:5, Informative)

    by Magus311X ( 5823 ) on Friday January 04, 2002 @07:47PM (#2788735)
    For the lazy... (from the document):

    The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.

    The LSB defines a binary interface for application programs that are compiled and packaged for LSB-conforming implementations on many different hardware architectures. Since a binary specification must include information specific to the computer processor architecture for which it is intended, it is not possible for a single document to specify the interface for all possible LSB-conforming implementations. Therefore, the LSB is a family of specifications, rather than a single one.

    The LSB is composed of two basic parts: A common part of the specification describes those parts of the interface that remain constant across all hardware implementations of the LSB, and an architecture-specific part of the specification describes the parts of the specification that are specific to a particular processor architecture. Together, the generic LSB and the architecture-specific supplement for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.

    -----

    • Re:The hell is the LSB? (Score:5, Interesting)

      by Anonymous Coward on Friday January 04, 2002 @08:10PM (#2788824)
      Yesterday RDF, today LSB. Would it kill the /. authors to define their acronyms, preferably in the title but at least in their text?

      I wonder how many sites get /.'d simply because folks are trying to find out "what the hell" the acronym means.
      • wonder how many sites get /.'d simply because folks are trying to find out "what the hell" the acronym means.

        Same with random other sites that have are not related to the project, but share a similar acronymn.

        I'm sure the owner's of www.lsb.org [lsb.org] are right now thinking... "Where the hell is all this traffic coming from?"

    • It's a drug they did back in the 40's. In the 50's they upgraded it to LSC, and in the 60's they upgraded it again to LSD. I think we're up to LSH or so now, but my brain's too fried to keep track anymore.

  • first read that as "The LSD Delivers Again"?

    I was a bit confused there for a second!

  • "L" is the problem (Score:5, Interesting)

    by chrysalis ( 50680 ) on Friday January 04, 2002 @08:03PM (#2788791) Homepage
    LSB is an excellent initiative. But the bad thing is the "L" ("Linux") in it.
    This standard is designed for Linux, and only Linux.
    Standardization of the filesystem namespace is needed on *ALL* Unices. And an unique document that would apply to *ALL* Unices would be a big win, both for developpers and for end-users.
    DJB's packaging system isn't that bad. The only trouble is that only DJB promotes it and very few software are packaged that way because it totally changes the traditionnal namespace layout.


    • Re:"L" is the problem (Score:2, Insightful)

      by finity ( 535067 )
      Yes, I'd agree. Unix was supposed to be the great standard, and then stuff started branching off. I've never used any other unix (than linux) except freeBSD briefly, but I think that someone needs to unify our unices. It'd certainly set a good standard.
    • Agreed. There is a similar project for the BSD
      world at http://www.openpackages.org/. It would
      be _great_ if the two would cooperate to define
      a common *nix platform that vendors could depend
      on.

      b
      • Problem is http://www.openpackages.org/ was last updated in July
      • Trouble with BSD is that it doesn't have a sysv init. Rather than /etc/rc[0-6].d/[S|K][0-99]blahblah, it all lives in one file.

        Which I detest with a fury and is one reason why I never have xBSD installed for more than 2 months at a time, but hey, that's just my opinion. :P

        So that, plus the bits that specify exactly how Linux binaries work (which might not mesh with how BSD or Solaris or anything else would work), makes it difficult. Solaris could use the init piece, though, since it's sysv-compliant.

        But what would you call it? Unix[like] Standard Base? I think someone else already has that acronym. :)
        • ...it all lives in one file.

          Okay, some serious clarification needed for folks who don't normally use FreeBSD. The "one file" in question is "rc.conf". This file has no scripting at all in it. It looks far more like a simple config file, with variables and values, then an rc.d startup script.

          This file only affects core OS kinds of things, like basic network settings, host name, and stuff like that. For most folks this file is something like 10 lines long. It can get a healthy bit longer depending on what you're doing. Without looking, I'd guess mine is about 20 lines with comments and such added.

          For daemons not expressly part of FreeBSD there are still start up scripts. They live in /usr/local/etc/rc/ and are just simple shell scripts. They can be as simple as 2 lines, or as complex as any shell script can get. Every shell script in this directory is run in alphabetical order. This is where stuff like Apache, MySQL, and the like would keep it's start up stuff.

          I personally found the FreeBSD far simpler for me to grasp what all was going on then the sysv startup. On RedHat those scripts looked so darn complex for a newbie not then familiar with shell scripting (a bit smarter about that these days) that I was forever afraid to alter them. The whole time I had RedHat installed I just started up Apache manually rather than try to tackle where in them rc.x files I needed to add the stuff I wanted. Even as a relatively new Unix user I totally "got" what was going on with FreeBSD, and had very little trouble altering which services started, or didn't.

          I've just heard this "one file" argument against FreeBSD too many times now as though there was some sort of monstrous 1000 line file a user had to figure out. This simply isn't the case at all. Regardless of your preference I felt that a fair comparison of the two systems needed some clarification from the other side.

        • SysV isn't necessarily the answer. All that /etc/rc[0-6].d/[S|K][0-99]blahblah crap isn't even need to get all the advantages it offers. While BSD has it's problems, too, new work is needed in this area to get a simplified and cleaned up init. I definitely want to get rid of the symlinks which are not needed to do runlevel controls (there is another way). The trouble with standardizing this is that you cutting off the possibility of new development that can improve things. Of course lots of standards tend to do that.

          Besides, init should strictly be an administration policy issue, and not a package development or installation issue, at least for those who don't want packages to mess around with init scripts. After having 3 different packages foul up the init scripts on Redhat, and similar problems in the past with Solaris and SCO (SCO has a really really bad form of SysV init scripts), I swore off SysV forever.

        • Obviously, you haven't used more than a single BSD, and not anytime recently either. :)

          NetBSD has a system fairly similar to SysV, only better. The NetBSD rc. system is also being ported over to FreeBSD as we type. Even a cursory grep of the mailing list archives would have netted you that info.

          I don't know enough about the NetBSD rc system to explain it (check their site or the FreeBSD rc group on Yahoo!), but it is much nicer than the horrid mess of symlinks and shell/perl scripts that make up the SysV init system.

          Oh, and the "single huge file" used in FreeBSD isn't that huge. 90% of the installs out there only use about a dozen lines. This file only controls the base OS subsystems, and all options are documents in /etc/defaults/rc.conf. The only thing you have to do is add your preferences to /etc/rc.conf and be done with it. All my FreeBSD systems have fewer than 20 lines in rc.conf, hardly unmanageable.

          All software installed via ports/packages will add a shell script to /usr/local/etc/rc.d/ and these scripts are run in alphabetical order at boot. Most also come with start/stop options for interactive use (and it's not all that hard to add that manually if needed).

          Personally, I never understood the need for more than 2 runlevels: multi-user and single-user. Everything else can be controlled via startup scripts. Why have 7 runlevels?? What's the point??
      • is the standard base for bsd systems called the bsd? i know unix folks are fond of those crazy recursive acronyms..
      • I think you mean POSIX. At least it is largely included in LSB and does provide for minimum base functionality for cross-platform applications. I like the work LSB is doing.
    • No no, it's ok, really...

      Other Unices can just use the L-SBE (The Lesser [gnu.org]
      Linux Standard Base).

      :)
    • What is DJB's packaging system?

    • Re:"L" is the problem (Score:5, Insightful)

      by Wesley Felter ( 138342 ) <wesley@felter.org> on Friday January 04, 2002 @10:25PM (#2789215) Homepage
      Standardizing Unix has been tried; the results were things like POSIX and the Single Unix Spec. They cost millions to develop and didn't completely solve the portability problem. Why try again?
      • Your statement also could have started with: "Standardizing the Internet" or "Standardizing PC hardware" or "Standardizing MPEG4 Compression" or a crapload of other things.

        Standards are not intended to completely remove compatability issues between platforms. All they do is ensure that most things will work most of the time.

        What you fail to grasp here is that UNIX (or any of the above things) is in practice nothing more than a standard, if it is not defined then its existance becomes something of a moot point.
      • So, the first time you hopped on a bike and fell down you gave up? How about the 10th time? Eventually you figured out how to ride a bike, but it took a couple of times to get it right. (for those who can't actually ride a bike, substitute something appropriate, such as learning to read).

        -I know I've got a sig around here somewhere...
    • It's called POSIX [ieee.org]
    • Do we really need another USB v1.1 (Unix Standard Base)? I know the open source world is terrible at checking to make sure that acronyms aren't already used and thereby confuses people but sheesh. ;-)

  • What is Linux to us? (Score:4, Funny)

    by Accord MT ( 542922 ) on Friday January 04, 2002 @08:05PM (#2788801)
    There is a poison that is affecting this great land, and that poison has a name: Linux.

    You may have heard of this dangerous hacker's program. Developed by the Soviets during the Cold War, Linux is a "UNIX-like operating system." In layman's terms, this means it is computer software that allows criminals to perform unauthorized (and illegal) tasks with their computers. What may shock you, however, is that this program has begun to slowly make its way through our nation's computer networks, and now threatens the economy, the stock market, and the great corporations that founded our country and keep it running.

    Linux, and other hacking tools with such strange names as "emacs," "PHP" (an obvious drug reference) and "gcc," have been used by thousands of foreigners and terrorists to undermine the American way of life. Okay, I realize you might be skeptical. How, you ask, could the United States, the world's peace-keeping police force, allow such harmful programs to enter our great country? Folks, I wish this was just an alarmist rant. But the threat to capitalism is real. Although the former Iron Curtain is long gone, its final creation is coming to bear on our own soil, in our own backyards.

    Yes, friends, leftist groups and individuals, although mostly confined to covert computer hideouts called "chat rooms," are actively spreading Linux into corporations and other organizations as you read this. Why would any American do such a thing? We may never know. Perhaps these misguided individuals have been shunned by legitimate software development firms like Microsoft and America Online. These poor souls, many of whom are but children, have sadly devoted themselves to a life of crime, by secretly learning programming techniques such as "debugging" and "optimizing," techniques previously reserved for patriotic, God-fearing professional engineers like Bill Gates.

    The time to act is now! As proud citizens and voters, we owe it to our children to stand up to this new "red scourge" and voice our concerns to our elected representatives. It is a sad testament to our country's deteriorating moral fiber that, despite the efforts of righteous Christian organizations such as the RIAA and the MPAA, the use and possession of Linux is still legal. Frightening, yes, but through faith and determination, we shall drive these Linux terrorists from our holy American soil.

  • Timely...NOT! (Score:1, Informative)

    by V. Mole ( 9567 )

    Was there any point in publishing this on the afternoon of the day of the end of the comment period?

  • An RPM Standard (Score:4, Insightful)

    by finity ( 535067 ) on Friday January 04, 2002 @08:15PM (#2788842) Homepage Journal
    So RPM is now the "standard?" I'm not sure I like that. RPM is great and all, and many distros use it or at least can handle them, but I think maybe it should be refined a little more. I like debian's package manager as it is easy to use and fairly straightforward. I know RPM is supposed to be that way as well, but I've had a lot more dependency problems with RPMs than I have with apt.

    • Re:An RPM Standard (Score:5, Interesting)

      by big.ears ( 136789 ) on Friday January 04, 2002 @08:47PM (#2788953) Homepage
      Well, debian's packaging system isn't going away anytime soon--they are committed to using alien to maintain compliance with the LSB here. But, .debs are not necessarily technically superior to .rpms either. However, there are probably two reasons why them may appear so:

      1) APT (Advanced Package Tool). This is even available and usable on .rpm systems so its not much of an advantage. It does take care of some of the headaches of dependencies automatically, but is probably a only minor advantage of Debian's packaging system.

      2) Debian's packaging policy and community structure. This is where Debian shines--because each individual maintainer only handles a handful of packages, and there is a strict policy for them to follow, the packages tend to work well together. It's not that .debs are superior to .rpms--if you try to use Ximian .debs, or had in the past used Stormix or Progeny .debs, you can run into rpm-like dependency hell quite easily. You even can run into trouble if you try to mix stable and unstable debian packages.

      But, all this comes at a price. debian's packagers are volunteers, and so you sometimes have to wait until the volunteer is good and ready to get the packaged software you want. For example, the new control panel and XST upgrades took a couple month's to appear, and there has recently been a little trouble with KDE--the package management changed hands. At least with a commercial system, you (hopefully) have better guarantees about package availability.

      • deb format (Score:3, Informative)

        by CatherineCornelius ( 543166 )
        I agree that rpm is a good package format, but my own experience on Debian is that it's by far the nicest distribution for upgrading and installing new packages. dselect was actually very good, but apt is divine.

        But this isn't the reason why I use Debian. That reason is the deb format. It's quite simply far more powerful and more consistent.

        Here's a discussion of the issues by a Debian package maintainer [debianplanet.org]

        But deb format maintenance requires a certain package developer/maintainer culture that might tend to clash with the requirements of the kernel/base developer/maintainers, which are rather different from those of general package maintainers. And Debian-based systems can already deal with rpms, no problem, using alien. So using rpm for standardized base is a no-brainer.

      • You can make your own damn debs or install non-debian debs. Deeeuuuuurrrhhrrrr!
        • You can make your own damn debs
          Sure you can. You can also write your own damn applications in machine code, solder your own damn microprocessor together, and make your own damn electricity using your own damn dynamo. How many of these do you do?

          or install non-debian debs.
          As mentioned in above post, the leads down the path of dependency hell. My system has never run more smoothly since I hunted down and killed every progeny and ximian .deb, and I hope not to return to those days.

          The consequence of a large, distributed, volunteer organization is certain drawbacks. Like, sometimes you have to wait for things to happen if you can't do it yourself, or don't want to, or don't want to pay some do it for you.

          Deeeuuuuurrrhhrrrr!
          Ok, I'll concede that point.
      • While I agree that many of the advantages of Debian lie not in the .deb file format, etc., but in apt and in Debian policy, there are some advantages that other distributions do not have: debconf and various aspects of the packaging format for developers, such as debhelper.

        Regarding the change of a KDE packager, this is no problem at all. The package maintainer was changed and there's no problem to the end user because of it, anymore than there's a problem if a package maintainer at Red Hat changes. In that case, no one would ever even know about it. Regardless, that's unrelated to the file format.
    • RPM and apt are different tools. Debian's equivalent of RPM is DPKG. Using dpkg without apt running on top of it would be just as much pain as
      when you use stand-alone RPM right now. There is clearly need a need for a tool that runs on top of RPM that takes care of dependencies and such. RedHat's up2date looks good. Too bad it is not a free service.
    • What irks me is that previous versions of LSB kept assuring us that rpm was an interim standard, until a vendor-neutral LSB binary package format could be designed. A new format that would learn from Red Hat, Debian, FreeBSD, and everyone else.

      Now they took the cheap route and just used rpm.

      I guess this is good, though. I never liked the LSB, and the LSB isn't going anywhere without Debian, and Debian's not going anywhere without their packages.
      • Debian is working with LSB. Why would a completely new packaging system be any better for Debian than RPM?

        In any case, just say it's RPM isn't quite accurate. The LSB standard is an older version of the RPM spec, with features (like triggers) removed that would be hard to support on non-RPM systems (like Debian).
    • I know RPM is supposed to be that way as well, but I've had a lot more dependency problems with RPMs than I have with apt.

      I too have had more problems with apples as opposed to oranges :). Anyway, do the following on your Red Hat box:

      1. Visit FreshRPMS [freshrpms.net]
      2. Download and install the APT p[ackage from there
      3. Use APT to check your system for dodgy package, then apt-get update.
      4. You may now APT all of Red Hat 7.2, sources, extras, and a bunch of brand new cutting edge packages created on request by FreshRPMs ninja Matthias Saou.
      5. Smile :)

      PS - Matthias needs more mirrors and Python / Perl ninjas to help him with RpmForge, his upcoming project. get his contact details from the web site.

  • LSB is not a standard (Score:5, Informative)

    by jgarzik ( 11218 ) on Friday January 04, 2002 @08:19PM (#2788863) Homepage
    It should be noted that LSB is not really a standard, and not really intended as a standard. It is intended as a common practices document, as the LSB mission statement [linuxbase.org] points out.

    My personal objections to the LSB are large, and centered around one single fact: The LSB documents as "standard" the GNU C library and command line utilities. This means that every Linux /bin/cat must support odd and non-Unix GNU options like --number-nonblank and --squeeze-blank and --show-nonprinting. /bin/cat must support cat -E, which could easily be replaced by a sed script (GNU cat implementor was apparently unaware of sed's existence). This means that, according to the LSB, libc[56] is non-standard because it does not support glibc-specific functions and interface.

    So, the net effect is that any system claiming to be Linux-standard [according to the LSB] must support all these wacky, underused, GNU-specific extensions in their commands and C library. Given the proliferation of C libraries under Linux this seems like a mistake of a large order.

    Jeff

    • Re:LSB is not a standard (Score:4, Insightful)

      by Jason Earl ( 1894 ) on Friday January 04, 2002 @08:57PM (#2788985) Homepage Journal

      By that logic the GNU tar maintainer shouldn't have included the -z flag either because you could always pipe the output from tar through gzip. The -E flag for cat was almost certainly added for the same reason that many commandline flags are added to GNU software. It was easy to add, and it makes the software a little easier to use. Why in the world would I want to use sed to put a '$' at the end of the line when I can simply do cat -E?

      I also think that the LSB is fundamentally flawed, but not because it specifies GNU software (complete with their various and sundry GNUisms). The LSB is flawed because it isn't self hosting. In other words there really isn't a good way to know that your binary application is LSB compliant. You can't just install the LSB onto some test machine and bang away on it. They are working on a test script that hopefully will eventually allow you to check for compliance but currently the README states:

      There is not yet a complete set of official test suites released by the LSB that can be used for compliance testing. You can download unoffical development versions of test suites planned to be used in the future from the beta directory in the directory above.

      And if that isn't bad enough, the LSB isn't a particularly exciting platform to port to. Most of the cool new Linux features are not included. Basically the LSB is Linux with all of the joy sucked out. No wonder commercial vendors simply test against RedHat and call it good. It simply doesn't make sense to do anything else.

      • In other words there really isn't a good way to know that your binary application is LSB compliant.

        The slashdot blurb has a link to version 1.0.1 of the LSB test suite.


        And if that isn't bad enough, the LSB isn't a particularly exciting platform to port to. Most of the cool new Linux features are not included. Basically the LSB is Linux with all of the joy sucked out. No wonder commercial vendors simply test against RedHat and call it good. It simply doesn't make sense to do anything else.


        The LSB specifies a BARE MINIMUM. The "cool features" can be added by any LSB complaint Linux vendor very easily. Just because the LSB says that these features MUST exist, doesn't mean that ONLY these features must exist.

        • The slashdot blurb has a link to version 1.0.1 of the LSB test suite.

          If you would have read my quote more carefully you would have realized that I actually included the README from that package. They have a test suite in beta. Which basically means that they have a half-baked idea of a way to mostly check to make sure that a binary is LSB compliant. Only the most foolish of companies would actually release a binary package that this suite said was LSB compliant without actually testing on the various and sundry Linux distributions. Not that it would help much anyway. There are still a lot of bugs that could potentially be triggered that aren't checked by the LSB.

          Besides, who says that Linux developers want to develop against a BARE MINIMUM. If I create a binary package that uses one of the newer features not found in the LSB, then my package isn't LSB compliant. I could include the necessary libraries statically linked, but that makes my package larger than it needs to be, especially if the libraries I need are already installed on most of the systems that my software will be installed on. Not to mention the fact that many important packages aren't part of the LSB. The LSB doesn't include, for example, a Java virtual machine, nor any of the necessary libraries for important packages like QT, or GTK+ (not too mention KDE or Gnome).

          In other words, unless the LSB package you are distributing is a commandline application originally written for the original BSD Unix chances are good that you are either going to have to link a huge pile of libraries statically or include a regular smorgasbord of dependency RPMs. I would bet that most Linux developers expect their distribution to take care of these sorts of things.

          This is why many commercial applications are simply tested against RedHat. You can use any of the new features that RedHat has included, testing is greatly simplified, and it is possible to get excellent support. Fortunately for the rest of us (I prefer Debian) if we really want to use a different distribution there really isn't anything stopping us from simply downloading the required libraries and installing them on the distribution of our choice. The fact that the LSB has mostly moved the distributions into being FHS compliant means that at least all of the necessary files will be in more or less the right places.

          And that's why the LSB will ultimately fail. It makes the developers lives a lot harder for very little gain. Most folks running commercial software on Linux will be using RedHat, so it makes sense to primarily target RedHat, and the rest of the distributions mostly follow RedHat's lead (for obvious reasons) so there generally isn't a problem.


          • And that's why the LSB will ultimately fail. It makes the developers lives a lot harder for very little gain. Most folks running commercial software on Linux will be using RedHat, so it makes sense to primarily target RedHat, and the rest of the distributions mostly follow RedHat's lead (for obvious reasons) so there generally isn't a problem.


            I disagree. Right now if software people want to release binary software, they have to release packages for many different distros at once because they are _not_ all compatible at the lowest level (the c library, and other low level libraries that practically everything links with). With the LSB they should be able to release just one package and save a lot of work.

            As for all the extra dependencies you mentioned, those could potentially cause a few problems, but I think it will be significantly less than are caused by differences in the really low level stuff.

            I could be wrong though. I have never released binary packages for multiple systems.

      • Re:LSB is not a standard (Score:5, Insightful)

        by Arandir ( 19206 ) on Friday January 04, 2002 @10:02PM (#2789159) Homepage Journal
        By that logic the GNU tar maintainer shouldn't have included the -z flag either because you could always pipe the output from tar through gzip.

        You completely missed the point. Standards need to be lowest common denominator. Having a -z flag in GNU tar is damn useful. But it should not be the standard.

        There are standards for most Unix utilities, and those standards should have been used instead of the mandating the GNU extensions.
        • There are standards for most Unix utilities, and those standards should have been used instead of the mandating the GNU extensions.

          What, standard Unix? ROTFLMAO. The Linux folks had better jump quick and try to make everything Linux work just like Solaris, err no, AIX, NO! True....

          The parent of this thread was flamebait. No normal person would say a developer was unaware of sed because they implimented a function.

  • LSB and it's failure (Score:1, Insightful)

    by Anonymous Coward
    I can understand wanting to have a standard Baseline to have across the platform but it fails miserably.

    Redhat,slackware,Debian....

    all are completely different to the point that only one will work correctly if you download a major project's sourcecode and install it, it works. and that is slackware. Redhat decided to place apache where is isnt supposed to be, and Debian decided to move KDE around. Why? they wont give any good reasons other than ,"We like it that way"

    Creating incompatabilities like this does nothing but create problems and fractures in the Linux camp. Apache needs to be installed in EVERY distro where APACHE or the end user wants it. X,KDE,GNOME, etc... wherever the sourcode for that phoject drops things after an untar,make make install happens is where it goes. not where Alan Cox wants it, not where Linux wants it.. where the Apache or that project's Development team wants it.

    and then we have lib dorectories all over the place, redhat not coming with /usr/local/lib in the ld.so.conf (pretty retarted of them)

    The things covered in the LSB are not important... What is important is getting a linux filesystem layout standard in place and FORCING it upon every distro.

    it wont happen......

    and linux will remain a nitche until it does.

    • It won't happen because it's a bad idea. This kind of standarization stifles innovation. Of course it is a good idea to have a way for packages to know where things can be found, but that's generally going to be standard executeables, libraries, headers, and various resource files. One of LSB's problems is it's aiming to become the ultimate distribution where everyone else is just forced to make a copy of them.

    • Nah, Linux will remain in several niches, all of them relatively virus/trojan/worm/whatever-free.
      It gets a bit hilarious when the *BSDs can run Linux binaries and the various distros have trouble running each others.
      What's the problem with where RedHat puts Apache? I find it a bit convenient to be able to run two default Apache installations on the same computer at the same time.

  • Good, but don't forget FHS. (Score:3, Insightful)

    by PrimeNumber ( 136578 ) <PrimeNumber&excite,com> on Friday January 04, 2002 @09:37PM (#2789094) Homepage
    Standards/guidelines are good for the Linux community, how many times have you followed a installation readme, or read a HOW-TO and *nothing* is where it supposedly should be?

    Try typing which filename with common executable names on two different distros and you will know what I am talking about.

    That is why I think the FHS is slightly more important. The Filesystem Hierarchy Standard is supposed to help prevent this, so hopefully the LSB compliments this cool document supported by freestandards.org.

    This sig is taken.
    • " That is why I think the FHS is slightly more important. The Filesystem Hierarchy Standard is supposed to help prevent this, so hopefully the LSB compliments this cool document supported by freestandards.org."

      The FHS is part of the LSB.
      From the first sentence of Chapter 17: "An LSB conforming system must adhere to the FHS 2.2."
    • So what do we need FHS for if we can just do "which filename"?
      • So what do we need FHS for if we can just do "which filename"?


        Hahaha! I'm sure you were being sarcastic. But if not, here's a clue:

        $which filename
        which: Command not found.

        • So your distribution doesn't have the "which" command? Or maybe the PATH environment variable doesn't have the default setting with the paths where commands are found on that system? Standardize a few things that let you find other things, then the other things only need to be standardized in what keywords are needed to find them, and not their exact path.

  • Why the LSB ain't so hot... (Score:5, Interesting)

    by augustz ( 18082 ) on Friday January 04, 2002 @11:19PM (#2789377)
    I'd like to just get a few objections in on the LSB while everyone runs around cackling with perverted glee.

    I for one am sick of finding files from install packages all over the place. Everyone and their mother is sick of this. Apps should install into ONE directory only. They can symlink everything they want everywhere else (/etc and /log come to mind) but at least that lets us get an idea of where the mess all came from, and when we delete the directory we can also delete all dangling symlinks and truly get rid of stuff.

    Linux is literally worse then windows on this count. PLEASE PLEASE contain the spawl. Someone needs to do an ls -l on /usr/bin and the lib directories.
    • Not so simple. What happens when you want to NFS
      mount /usr, /var, /log to ease maintenance of a
      room of machines? The sundry file locations are
      partitioned <pun> like they are to group _types_
      of files together. In practice, most good admins
      will build a machine to maximize access to each type
      of file -- /var and /log on fast disks, /usr
      mounted read-only (and often remotely)....

      There is a necessary complexity in creating a
      well-behaved computer system -- packaging systems
      and common practices address this complexity. I
      would like to see the complexity handled similarly
      enough across all unices that software can be
      more efficiently developed and deployed without
      doing the job for each *nix.

      cheers.
      b
    • You want the filesystem to be the packaging system. That's certainly possible, but a good packaging system will mostly solve all the same problems, for whatever filesystem layout you want or are stuck with.

      Anyway, Linux distros don't seem to be made up of "Apps" in the way Windows is. It's made up of... well, I don't know what to call them except packages. I have way more packages on my system than applications, and not every package is clearly part of an application. It's not as easy as putting everything in its own directory.

      Still, the unfortunate part of a packaging system is that they do poorly with 3rd party applications. For tarballs, the most organization you have is from the filesystem. If they could solve that -- I guess, come up with a standard (lowest-common-denominator) package system that 95%+ of software was distributed in -- then the filesystem really won't matter too much.

    • Use SCO Open Server some time. They do this. All packages are installed in a "per directory" manner and then sym linked to the "/bin, /lib, /etc" heierarchy.

      I thought it ws an interesting idea until I had to admin about 50 of these things. . . I can't even begin to explain why it is a bad idea. . .let me hit a few quick points. . .if you're very interested I could write a large paper about why it is a bad idea. . .

      It's a complete mess not to mention the massive performance hit from derefencing every symlink (afterall you're not going to have your PATH contain hundreds of variables to EVERY package's sub-directory so you'll still be referncing the current heierarchy after which you file system will have to dereferance every single stinkling sym link).

      If you *REALLY* want every single file for a program in the same directory you can easily do it with the RPM database. . .this simple script will symlink every file into a "package heierarchy" [untested]:

      #/bin/bash

      mkdir /Program-Files
      for F in `rpm -q -a`; do
      mkdir /Program-Files/$F
      for G in `rpm -q -l $F`; do
      ln -s $G /Program-Files/$F/$G
      done
      done

      Have Fun!

      BTW having files in the /bin /lib /etc format is an EXTREME advantage. You can optimize mount points based on file types (ro,rw in NFS rsize, wsize, etc) and most of all with NFS you can remote mount filesystems off of a large server that are not likely to change (such as the /usr/local directory but unlike the /etc diretory) and thus have a central install base that only requires ugrading *ONE* server.

      Having a central install base is a *BITCH* in Winblows and a lot of it has to do with the filesystem heierarchy.

      Lastly the RPM database is the answer to your dilemma. It keeps a record of where every file is for every program. If you want to get rid of every file to a program you simply do a "rpm -e". That's it! Rather then doing "make install" with your builds simply write a .spec file and use rpm to build them. That way they'll be in the database and you can easily un-install them later.

      The advantages to the current heierarchy is massive and frankly if you don't like it learn how to use the RPM database or get the SRMS to everything, do a little editing on the install scripts and create your own custom distro.

      I hope that most people will agree with me that the current heierarchy has many many high-level administrative benefits (that you only realize after you've managed a few hundred UNIX boxen at a time). . .I think that's why most people won't even bother attempting to reply to this. . .

      As a note SCO OpenServer used to be known as XENIX, a Microsoft product. . .
    • I for one am sick of finding files from install packages all over the place

      I assume you are talking about packages you compiled and installed by yourself, since what are you talking about is clearly a non-issue with packages handled by a proper package manager.

      Apps should install into ONE directory only. They can symlink everything they want everywhere else

      Well, for packages based on autoconf/automake that you compile by yourself, there is GNU Stow [gnu.org] doing exactly what you ask.

    • I for one am sick of finding files from install packages all over the place. Everyone and their mother is sick of this. Apps should install into ONE directory only. They can symlink everything they want everywhere else (/etc and /log come to mind) but at least that lets us get an idea of where the mess all came from, and when we delete the directory we can also delete all dangling symlinks and truly get rid of stuff.
      Please read the Linux FHS 2.2 doc and subscribe to the FHS mailing list [mailto]. To summarize for our impatient friend:
      • Distro packages go into /usr.
      • Anything other than distro packages is a "local issue"; i.e. explicitly left out of the spec.
      • Most distributions are constantly changing what is part of the distro by including popular packages. Thus, the drive by RedHat and others to install everything in some subdirectory of /usr, with the idea that "it's OK to install there now, since the package may become standard in the future, and we need to be forward-compatible".
      • That having been said, after-market packages should go into /opt, with the understanding that there is no central namespace authority for directories under /opt. One (of many) current (non-normative) proposals is to have /opt/package/rev/{bin|lib|...}.
      • The main point of contention seems to be, where do you put packages which may be part of one distro and not another? The answer seems to be, if it's part of the distro, it goes under /usr, but if it isn't, the very same package goes under /opt. Deal with it, or send your ideas to the mailing list.
      • RedHat's package manager doesn't follow the standard. The only fully-compliant package manager I personally have seen uses relative-path tarballs.
      Most distros install everything into /usr/bin instead of /opt/package/bin as they should because it leads to fewer $PATH headaches. It has been suggested on the mailing list that there should be an /opt/bin which contains symlinks into all of the /opt/package/bin directories, but this is not official spec.

      There are several problems with installing everything in one place:

      • Some distros support more than one hardware platform. In particular, some distros support both 32-bit and 64-bit architectures. So where do you put your glibc and interpreters? Some have suggested /lib and /lib64, or /lib32 and /lib as the case may be. What about /etc in this case?
      • Some distros consider sh to be fundamental, and bash as an add-on. Most sane people put sh in /bin, some duplicate it in /sbin, but where should bash go? If you have system startup scripts written for bash but not sh, then you need /bin/bash. Some distros don't care, and have /usr/bin/bash. Who's right? They both are.
      I could mention about 15 other incompatibilities, but I suggest you go read the mailing list archives. The upshot is, this is a work in progress, and if you feel you have anything to contribute, send us mail.

  • What LSB really needs... (Score:3, Funny)

    by Skapare ( 16644 ) on Saturday January 05, 2002 @12:44AM (#2789592) Homepage

    What LSB really needs is some alternatives to choose from. The thing I most dislike about standards, especially those that try to codify existing sloppy practices, is lack of choice and the end to new ideas.

  • Judging from the amount of posts to their comment section along the lines of "Don't use RPM #$!@#^&", and more describing the utter stupidity of it, I doubt the will be welcoming comments now, and they certainly haven't in the past.

    LSB has a good potential, but unless they start excepting better standards instead of more popular, nobody is going to adopt it but redhat, and LSB will have been a waste.

Slashdot Top Deals

"All the people are so happy now, their heads are caving in. I'm glad they are a snowman with protective rubber skin" -- They Might Be Giants

Close