Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
GNU is Not Unix Software Linux Business Linux

LSB Submitted To ISO/IEEE 207

Posted by Hemos from the moving-forward dept.
mcneil@freestandards says: "The LSB has been submitted to ISO/IEEE for an ISO imprimatur. While this is not really new news, it is important that every Linux user get involved to make sure their country votes YES for Linux ISO standardization! With Linux achieving international standards recognition it will be that much easier for governments and other risk adverse organizations to include Linux in their procurement policies. This of course will further the normalization of free and open source software, lessen the world's reliance on sucky legacy platforms, etc. etc."
This discussion has been archived. No new comments can be posted.

LSB Submitted To ISO/IEEE More

LSB Submitted To ISO/IEEE

Comments Filter:
  • With Linux achieving international standards recognition it will be that much easier for governments and other risk adverse organizations to include Linux in their procurement policies.
    How will this affect the posible use of FreeBSD by the government agencies?

    • Re:How will this affect *BSD? (Score:5, Interesting)

      by tuggy ( 694581 ) on Monday January 17, 2005 @09:12AM (#11384811) Homepage Journal
      From linuxbase.org:

      Is the LSB only for Linux systems and applications?
      No. The spec has been written so it can be readily implemented on top of any UNIX-like operating system, natively or as a compatibility layer. There is also no fundamental reason why it cannot be implemented on other operating systems, although it is likely to be much more work. Note that this philosophy may be one of the reasons why a seemingly "obvious" Linux feature is not part of the specification if it raises needless barriers to implementing the LSB on non-Linux systems.
      • Yeah sure.

        Normative references to the Linux device list, init.d, run-levels, rpm as packaging, a bunch of user and group names that serve no purpose on other systems, and so on.

        Please go fool someone else into thinking you can make it work on BSD, there's a reason why BSD and System V differ, because they are different architectural paths.

  • LSB and rpm (Score:4, Insightful)

    by OmniVector ( 569062 ) <see my homepage> on Monday January 17, 2005 @09:06AM (#11384760) Homepage
    As much as I've used Linux, I have no idea how LSB helps per say. If two distros (lets say redhat and suse) both implemented LSB X.0, could I concievably use an rpm on both distros safely? Just curious if LSB guarantees this level if interoperability. If not, what the hell is the point?

    • Re:LSB and rpm (Score:5, Informative)

      by grumbel ( 592662 ) <grumbel+slashdot@gmail.com> on Monday January 17, 2005 @09:09AM (#11384793) Homepage
      You could use a LSB conforming RPM on both SuSE and Redhat, yes, but you could NOT just pick a random SuSE package and use that on Redhat.

      LSB packages work basically completly independend from what the distro provides. If a distro is LSB conforming it only means that it can install LSB-rpms (by using alien on Debian for example), it does not mean that the distro itself consist of LSB-rpms.

    • Re:LSB and rpm (Score:5, Insightful)

      by CAIMLAS ( 41445 ) on Monday January 17, 2005 @09:09AM (#11384794)
      The point is this:

      If I'm versed in the admin of one LSB-compliant distro, it's trivial to migrate to another (in most respects) as the location of config files and the like is identical.

      That's trival, however, compared to the power of influence it will have upon both developers and people looking to adopt linux for deployment. If a distro is LSB-compliant, then developers will be able to write simply for all LSB-compliant distros.
    • You should check LSB compliance from a distro perspective and not vice versa.

      ftp://ftp.freestandards.org/pub/lsb/test_results

    • Re:LSB and rpm (Score:4, Interesting)

      by IamTheRealMike ( 537420 ) on Monday January 17, 2005 @09:48AM (#11385094)
      In theory yes. In practice, not really. There are a few blocking problems with respect to making LSB RPMs (if you are doing it to make things easier for the user and not for regulatory compliance or whatever):

      • Out of the box none of the major desktop distros are LSB compliant as they don't provide the LSB release file or linker symlink. At minimum therefore the user has to locate and install the right LSB base RPM for their system
      • LSB doesn't formally specify much stuff. Hardly anything in fact. C++ is out as various distributions (like Red Hat) decided they didn't want to standardise on a buggy g++ ABI, instead they wanted to break the C++ ABI yet again and get a bit closer to Itanium compliance. Desktop toolkits are out, unless you want to statically link the whole thing which whacks up theming and makes your memory footprint huge. Pretty much any other library is out as it's not included.
      • You need to use their build environment. Not such a big deal this one but last time I tried it (a long time ago I must admit) most software didn't compile under it.

      Because the LSB is currently so small it's pretty useless for desktop Linux software developers, and it doesn't attempt to overrule upstream goofs like NPTL so it would not prevent things like the Loki Games breakages.

      I think it's useful mostly for big-iron server vendors right now - programs that don't need much stuff from the OS but must be certified.

      • Re:LSB and rpm (Score:5, Interesting)

        by Alan Cox ( 27532 ) on Monday January 17, 2005 @11:32AM (#11386033) Homepage
        Thats a fair summary on the whole although slightly inaccurate.

        Several distros are LSB compliant by default (notably the enterprise ones). C++ is defined in the LSB but not in the ISO standard. The reason for this was that the C++ the LSB defines is interim but was needed. Many of us felt it shouldnt be in, and definitely not in the ISO spec since we knew it was transitional. The compromise was LSB defines a transitionary C++ (which will remain supported) and ISO doesnt

        You don't need to use the LSB build environment - that is simply a tool for ensuring compliance.

        LSB as you rightly say is about server software right now. A push on the desktop front has begun and hopefully things like gtk will get looked at. In addition there is an exploratory working group on java/jvm packaging and standards (java itself is obviously standardised elsewhere)

        To get to the stage where you can go into a shop and buy packaged applications the LSB extending to desktop will be important. Many vendors don't stock Linux products because its too confusing in their eyes. At the enterprise level it doesn't matter for small business and home it does.

        • Re:LSB and rpm (Score:3, Interesting)

          by IamTheRealMike ( 537420 )
          The problem with not using the LSB build system is that GNU ld will automatically choose the latest glibc symbol versions (amongst other things) so you won't get a compliant binary out if you don't use it.

          When I said "major desktop distributions" I really meant "popular desktop distributions" - while the enterprise distros will get a lot more important in future right now not many people use them.

          The rest of your points are pretty much right. You have a more optimistic view of the LSB than I do, but we'

  • At least the writer isn't biased. (Score:3, Funny)

    by nberardi ( 199555 ) * on Monday January 17, 2005 @09:06AM (#11384764) Homepage
    At least the writer of this article isn't biased. :) "lessen the world's reliance on sucky legacy platforms, etc. etc."
    • At least the writer of this article isn't biased. :)

      Your smiley says it very well. The guy admits to being strongly biased, but he does it in a very open and slightly humourous way. I much prefer news written that way to cool "objective" "neutral" writing that's choc full of spin anyway - probably mostly unintentional. If nothing else we know where he's coming from.

  • Only if distros follow.. (Score:5, Insightful)

    by ThisNukes4u ( 752508 ) <tcoppi AT gmail DOT com> on Monday January 17, 2005 @09:08AM (#11384775) Homepage
    While I agree that standardization is a good thing, it will only have an effect if distros follow. Right now, one of the most LSB compliant "distros" is Linux From Scratch, which is not exactly a mainstream distro. I know that others have been making strides towards compliance recently, but unless all distros follow it close enough so that one person can work effectivly on different distros without having to relearn its directory layout, it won't affect adoption as it is just another unfollowed standard (HTML, CSS 3 in IE anyone?).

  • LSB not so great (Score:5, Interesting)

    by petrus4 ( 213815 ) on Monday January 17, 2005 @09:08AM (#11384780) Homepage Journal
    The LSB advocates RPM as the standard package management mechanism for Linux. To my mind that's a really bad idea...RPM has a lot of problems. So I for one can't really advocate this.

    • What problem (Score:4, Insightful)

      by samjam ( 256347 ) on Monday January 17, 2005 @09:16AM (#11384843) Homepage Journal
      what problems does RPM have?

      If you can name any, how confident are you that these are not user-ignorance?

      Finally, are you confusing RPM the package format with RPM the package manager? There is more than one RPM based dependancy manager just as there are many (and layers of) package managers for other package formats, e.g. deb.

      Sam

      • Re:What problem (Score:3, Insightful)

        by Zapdos ( 70654 )
        RPM Hell.
        example.
        In order to build a rpm package of the newest xmame you need sdl-dev
        sdl-dev needs arts-dev
        arts-dev needs kdelibs-dev
        This in turn needs kdelibs, arts etc.

        The real question, does sdl actually need arts? No it was a dependency question that was answered by the sdl-dev rpm package maintainer. The package maintainer must make decisions that are generic enough to suit the largest group of people.

        • Well, that's the maintainer's fault. The maintainer should be making the dependencies generic enough to satisfy a default version of the target distro(s), as well as an upgraded version (unless the upgrade legitimately breaks compatibility).

          The real problem is where upgrading X requires installing Y, which requires upgrading Z -- which is a buggy upgrade or which breaks other things on your system.

          I've always thought the modern windows way of installing/uninstalling is more graceful. Install the app, with
          • Bad idea. How do you prevent old libraries with security holes on your system with this?
            • When the update comes out, make part of the install the (optional but highly recomended, with the GUI giving the user the choice) outright replacement of the old version with the new version. When an update doesn't fix anything critical, have it simply install itself alongside the old version.
        • So use apt for RPM, or yum, or any number of other dependency resolution tools.

          As for whether or not the dependency is real, how is the way RPM defines dependencies any worse than how the Debian package manager handles them?

      • Re:What problem (Score:3, Informative)

        by Vo0k ( 760020 )
        Okay, I don't know too much about internals of the RPM format, I was just an user of the RPM package manager, and it was a few years ago when I abandonned it, but what I've seen...

        no automatic source selection.
        no automatic dependency satisfying.
        no "recommends".
        no "suggests"
        no "conflicts with (anything other than its own other version)"
        no "replaces"
        no "provides"
        Harder source rebuild.
        no "hold current".
        no install-time configuration (some consider this advantage. I don't.)
        no dist-upgrade alike.
        no --simulate

        I
        • Half of your problems have nothing to do with the RPM *format* and everything to do with RedHat's "rpm" command implementation.
          • And the moronic packaging made by some. It's gotten better though.

            And regarding RPM, well, the wrappers take care of most of that. urpmi, yum (presumably, never used it), etc.

            This being said, there is no perfect solution. Once the system gets complex, things do break every now and then.
        • I've been using SuSE and YaST since version 6.2 (1999 or there about) and although it also uses rpm, it also does exactly all the things you list AFAIK. I haven't ran into a problem yet, but have mainly used .rpm's provided by SuSE, maybe a handfull others.

          It's the reason I keep buying their CD's/DVD's every now and then (6.2, 7.1, 8.1, 9.1). Esp. before I had DSL, ftp was just to much of a hassle, if nearly everything can be bought on 2 DVD's at the shop around the corner.
          • That is another thing most rpm-based distros never get right.

            You have to upgrade your system with CDs every once in a while instead of simply upgrading by downloading the newest versions of your installed packages.
            • Actually, I have twice now upgraded Fedora Core boxes by changing my APT repository and doing a dist-upgrade.

              I did the same from Redhat 6.2 straight to 7.3 once (again with apt-get). THAT was painful, but it worked (after I reran apt 3-4 times).

              It's been getting steadily better, but there's still a lot of work left before I'd recommend anyone to try it without a backup, or a bootdisk and a lot of patience :)

        • Re:What problem (Score:4, Informative)

          by Yenya ( 12004 ) on Monday January 17, 2005 @10:20AM (#11385348) Homepage Journal
          Just FWIW, RPM has "conflicts" (with anything you want), "replaces" (obsoletes), "provides", "--simulate" (--test, actually). Source selection, automatic dependency satisfying, dist-upgrade, and probably others belong to a higher level than the package manager itself (yum, apt, up2date). The "recommends", "suggests" , and install-time config are deliberately missing, because RPMs are meant to be installable without an user attention.

          RPM has triggers (script executed when other package gets installed/upgraded), %verify script, %changelog, automatically generated debuginfo packages, etc. Every file is MD5summed, package has MD5 sum, RPM supports GPG signature (and this feature is actively used by distros).

          RPM has better source rebuild than DEB. It supports conditional compile (%ifarch, %if, etc.), so you can rebuild RPMs for several versions of a distro from one source package. It has a "BuildPrereq" dependencies. You can have more than one source file and more than one patch file, RPM makes sure you are compiling exactly along the lines written in the .spec file (so you actually get working and rebuildable source RPM, no manual editing/hacks behind the RPM's back). The build process automatically uses a subdirectory for installing files (so non-root rebuilds are possible). It warns you when you forget to package some file from the build root. You can even use a tarball instead of the source RPM, provided that the tarball contains the .spec file.

          There is still one problem with using RPM: distro-specific macros. Last time I have checked, Mandrake uses %make macro, so you cannot take MDK source RPM and --rebuild it on Fedora, because you get "%make undefined" error.

          • Just FWIW, RPM has "conflicts" (with anything you want), "replaces" (obsoletes), "provides", "--simulate" (--test, actually).
            Do you have an example of the "Provides"? I haven't seen that yet.

            • What do you want an example of? It works exactly like in Debian, allowing you to specify a "virtual" package name/capability that the package in question can be used to satisfy.
              • Great. So you claim that it works just like in Debian. So give me an example of a package in Red Hat or SuSE or whatever that does that.

                Don't just claim that some functionality exists.

                If you can't find any .rpm's that have that functionality, then why can't you?
                • $rpm -q --provides httpd | grep web
                  webserver

                  I understand skepticism, but you're a bit over the top. There's no Red Hat junta out to trick Slashdot into thinking that RPM has more features than it does.
                  • I understand skepticism, but you're a bit over the top. There's no Red Hat junta out to trick Slashdot into thinking that RPM has more features than it does.
                    Nope, but there are lots of people who make unsubstantiated claims.

                    I'll try building a .rpm tonight that depends upon "webserver" and see if that works. All I have at work are Debian machines.
                • I "claim that some functionality exists" because it is well documented, and it's existence easily verifiable.

                  As for examples, try Sendmail. Do an "rpm -q --provides sendmail" on a Fedora Core box, for instance, and you'll get "smtpdaemon" listed. Exim and Postfix for Fedora Core also provides "smtpdaemon".

                  It is not much used because there are very few cases where it is reasonable to use it - most applications that require something require a specific library or a specific application to be present, very

                  • It is not much used because there are very few cases where it is reasonable to use it - most applications that require something require a specific library or a specific application to be present, very few requires a capability that is met by many applications.

                    Yet it is used a LOT on Debian.

                    I'm not talking about libraries.

                    I'm talking about things like:
                    text editor
                    webserver
                    smtp
                    etc.

                    The PROBLEM is when an app is packaged via RPM and it REQUIRES a specific app that should have been sufficiently abstracted s

                    • The PROBLEM is when an app is packaged via RPM and it REQUIRES a specific app that should have been sufficiently abstracted so that any server of that type could fulfill it.

                      As I've pointed out before, and as others have pointed out, this has nothing to do with the package format. RPM supports it. If you have a problem with a particular RPM based distro, then fine, but it's annoying when you keep on bashing RPM for something that has nothing to do with RPM.

                      I've already mentioned some fairly large applica

          • Re:What problem (Score:3, Insightful)

            by cortana ( 588495 )
            The Debian package format provides all the stuff you list as being specific to RPM. Except for a warning about forgetting to package a file that was built.

            It seems the two formats are more similar than many people suspect.
            • Why then is triggers not allowed in LSB compliant packages specifically in order to maintain compatibility with Debian based systems? Or is that a restriction due to limitations of Alien and not the .deb format?
              • I don't know what RPM triggers are, but a cursory Googling indicates that they are similar to the {pre,post}{inst,rm} scripts found in debs. Perhaps the typical contents of an RPM trigger are too dissimilar to a postinst script for the same script to work on two different distributions?
                • RPM has {pre,post}{inst,un} scripts, which are called when the package is installed/upgraded/removed. Triggers for a package is a script which is called when some other package is installed/upgraded/removed. Think adding your daemon to some startup script of another package.
                  • Ok, dpkg can't do this. However at the risk of sounding like a pompous twat, it sounds liek the kind of thing that shouldn't be necessary if you factor the operations that your packages perform correctly in the first place. :)

                    A Debian package that could be extended with other packages would tend to use a method more along the lines of this: /etc/init.d/foopackage sources all scripts in /etc/foopackage.d/
                    barpackage contains a file: /etc/foopackage.d/barpackage.sh

                    FYI, barpackage would then probably declare
            • The Debian package format provides all the stuff you list as being specific to RPM

              Last time I have checked DEB packages weren't GPG signed and did not contain MD5 sums of every file in the package (altough I think I have heard that the package format supports this; it is just not widely used in Debian distro). There were no debuginfo packages. No rebuilding from a taball with .spec (or what) file included. No triggers. Are you really sure everything I have mentioned is really in Debian/dpkg too?

              I can t

              • > weren't GPG signed

                There are two ways that this is done in Debian, IIRC. The first way is to sign the actual .deb file itself. This is used to confirm the authenticity of a particular package, and the checking is done by the debsigs package.

                The second way is to sign the Release file that each Apt repository provides (the Release file contains a cryptographic hash of the Package files, which contain hashes of the individual packages). You can start digging down the chain of trust from http://ftp.uk.deb [debian.org]
                • Most packages generate MD5 sums at build time.

                  So the packager have to do something special to generate MD5 sums? What if he forgets to do it? What if his script is not correct? RPM does this for you automatically.

                  Packages with debugging symbols? There are plenty; look for, eg, libc6-dbg[...]

                  No. RPM's debuginfo packages are created for every package automatically. So you can have debugging symbols for just any package you want. Not only libraries. When some customer (or user) have a problem with your p

          • Re:What problem (Score:3, Interesting)

            by Qzukk ( 229616 )
            RPM has better source rebuild than DEB.

            (as part of apt-get source -b blender:)
            dpkg-checkbuilddeps: Unmet build dependencies: ftgl-dev (>= 2.0.9-1) libglut-dev libopenal-dev (>= 0.2003011300-1) libsdl-dev python-dev scons

            as for "Triggers", debian's got the better way, with the /directory.d/ concept outlined by someone else, as well as update-foo, and install scripts that do whats needed for them to work together. Or would you rather enumerate every possible package you'd want something special to h
        • Hmmm, provides is definitely there.

          And please do not compare RPM to apt-get.
          RPM is equivalent to dpkg.
          YUM/URPMI/up2date are equivalent to apt-get.

          Of course, nothing matches portage, or BSD ports.
          cd /usr/ports/mail/postfix-current && make install replace is hard to beat :)

      • Re:What problem (Score:4, Informative)

        by sanityspeech ( 823537 ) on Monday January 17, 2005 @09:53AM (#11385128) Journal
        Before the my-format-is-better-than-your-format debate kicks into high gear, it should be said that the LSB intends to use the RPM format as a stop-gap measure [linuxbase.org]

        Of course, you [catb.org] know [wikipedia.org] who [helsinki.fi] is on record about how stop-gap measures "...have a way of staying around. Forever." [iu.edu]
      • The main one that I can think of, off the top of my head, is that the specfile/macro format is obtuse, utterly abominable to work with, and encourages sloppy coding. Then there's the truly awful practice of downloading binary RPMs from who knows where...Great security there.
        • First, nobody is forcing you to download binary RPM's from who knows where. However, the very purpose of a "standard" packaging format is that that is exactly what most users want. To make that less painful and risky, RPM's can be signed, but you still won't get around the fact that users WANT to be able to install and run binary packages from "anyone". Deb's allow the same thing, and source is no safer unless you inspect it, which the typical binary package installing user is never going to consider. What
      • See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?i d=73097

        RPM has been broken for years. RedHat's official answer seems to be that you should just delete and re-create the RPM database every time you use RPM, if necessary. (It was on a system I had.)
    • Mod this puppy up. But hey, if a little sacrifice is what it takes to make Linux easy and compatible for Mr Home User, so be it.
      • I would rather have Mr Home User using Windows or some other crap and have the diversity of distros we had for the past years. Who the hell said every Operating System must cater to any users needs?
    • So I for one can't really advocate this.

      Judging from the rest of your post if I aked you "Why" you would only answer "Because".
    • IMHO what someone should really do is finally implement a working version of ports for Linux, and submit THAT to the LSB. I got basic dep tracking working for my own little version of it a bit back...doing it nearly gave me a brain aneurism, but it worked. We'd want to do it actually with pmake, as well...not the (comparitively speaking) perverted abomination that is GNU make. ;)

    • Re:LSB not so great (Score:3, Informative)

      by crumley ( 12964 ) *
      As others have said, deb and rpm really are quite similar. its the care that goes into making the debs and rpms that varies. Here's a nice comparison of package formats [kitenet.net].

  • Linux Standard Base (Score:5, Informative)

    by AndroidCat ( 229562 ) on Monday January 17, 2005 @09:09AM (#11384786) Homepage
    The LSB FAQ [linuxbase.org] (for those whose first question was "What the heck is LSB?")

  • ya but distros will just ignore it (Score:2, Insightful)

    by Anonymous Coward
    Every distro thinks it knows best.

    Debian doesn't do a lot of LSB stuff because it just thinks it knows better.

    I'm sure gentoo and slackware are the same.

    Basically Redhat and Suse will comply and all the other distros will not bother to meet the standard.
    • Well, Redhat and SuSe are the ones who are actively trying to capture the corporate and government markets. Gentoo, Slackware, Debian, Ubunto, etc are not.

      Only businesses really give a rats ass about ISO.
    • Managing /etc/sysconfig alone in SuSE requires RPM's built specifically for SuSE, no one else's RPM's will work with their system management tools and vice versa until and unless SuSE gives up on everything being managed from YaST.

      Frankly, they need to throw in the towel on YaST and hire a few webmin developers to give them a far more powerful, effective, and flexible tool that actually does the job.

    • Re:ya but distros will just ignore it (Score:4, Interesting)

      by cortana ( 588495 ) <sam@robots.orRASPg.uk minus berry> on Monday January 17, 2005 @10:35AM (#11385483) Homepage
      On Debian, installing 'lsb' from apt gives you a fully LSB compliant system.
      • n.b. I'm actually running Ubuntu as you'll see, but it's the same package from Debian unstable.

        $ apt-cache show lsb
        Package: lsb
        Priority: extra
        Section: misc
        Installed-Size: 188
        Maintainer: Chris Lawrence
        Architecture: all
        Version: 1.3-9ubuntu7
        Depends: lsb-base, lsb-release, xlibmesa3-gl | libgl1, xlibs, libz1, exim4 | mai
        l-transport-agent, at, bc, binutils, bsdmainutils, cpio, cron, file, libc6-dev |
        libc-dev, locales, lpr, m4, make, man-db, mawk | gawk, ncurses-term, passwd, pa
        tch, pax, procps, psmisc, rsy

    • Every distro thinks it knows best.

      Rather each distribution was started because someone looked at the other distributions and didn't find one that s/he liked 100% so s/he started his/her own.

      This isn't about who "knows best" but which approach works for different people.

      Why do we have Red Hat and SuSE and Mandrake when they're all Linux and they're all RPM-based?

      Why are each of those slightly different from the other two?

      The simple answer is because different people are using different approaches to do

    • Debian knows better. (Score:3, Interesting)

      by xant ( 99438 )
      Look, it's not just about apt. Even if it were just about apt, the people advocating apt being used with RPM are misguided.. the RPM package format lacks a lot of the functionality that dpkg has, and the system as a whole will suffer for it. But apt is only the smallest part of what makes Debian work well together. Pursuing "LSB compliance" will never produce a system that works as well as Debian.
      1. There are hundreds of pages of manuals for covering every aspect of a Debian package's existence. As a pa

  • No love given (Score:3, Insightful)

    by Anonymous Coward on Monday January 17, 2005 @09:10AM (#11384801)
    "lessen the world's reliance on sucky legacy platforms, etc. etc"

    Legacy platforms aren't sucky, they're just dated. Improvements on that technology have been significant, but unstable, thus the call for Linux standardization.

    No insults needed on legacy, a concept that has been serving the PC community just fine for about 30 years.

    Brooklyn.

    • Re:No love given (Score:3, Insightful)

      by stratjakt ( 596332 )
      I don't know what they're trying to pull, but to me *nix is as legacy a platform as you're going to see.

      Which is a good thing. Here's how you market linux to PHB's.

      PHB's decomissioned all their old unix systems and bought Windows, thinking it would be newer and better and synergistic, blah blah blah. Instead they get a whole mess of various headaches.

      So in comes Mr Pro-Linux Consultant, who says: "Hey, remember the computer system you had before this, you know, the one that just chugged along 24/7 and
    • You mis-parsed the comment. It was alluding to specific platforms which are both legacy platforms and sucky.

  • LSB will be valuable when... (Score:5, Insightful)

    by Glasswire ( 302197 ) on Monday January 17, 2005 @09:19AM (#11384868) Homepage
    1) All distros clearly say that their disro ver X is LSB ver Y compliant and stand behind that.
    2) LSB mandates a sufficiently detailed configuration and fileset that a developer can build an app under any LSB ver Y.Z and expect it to install and run (with no missing libaries, re-configuration, config file editing etc) on any other LSB Y.Z compliant disro installation.
    3) Oracle ver nn runs under LSB ver Y.Z NOT ONLY RH AS3.x and Suse EL 9.x (or whatever).
    4) There's an automated validation that can determine if an initial distro install is (or is still) valid LSB ver Y.Z configuration.
    • 5) When there is a painless way to build LSB-conforming binaries and packages. lsbdev and lsbcc might sooner or later provide that, but last time I tried I wasn't really able to get much done at all.
    • 1) All distros clearly say that their disro ver X is LSB ver Y compliant and stand behind that.

      The major distros (SuSE and RedHat) do this.

      2) LSB mandates a sufficiently detailed configuration and fileset that a developer can build an app under any LSB ver Y.Z and expect it to install and run (with no missing libaries, re-configuration, config file editing etc) on any other LSB Y.Z compliant disro installation.

      Have you read the LSB? This is what it does.

      3) Oracle ver nn runs under LSB ver Y.Z NOT O
  • You've got my vote. I'll be contacting my national standards body soon to vote YES on LSB ISO.
  • Have any countries given any indication that they are leaning in a direction for the vote?
  • Last I heard, LSB was requiring a version of gcc's C++ ABI that the gcc people said was broken and was being replaced. Due the scheduling desires, LSB 2.0 (IIRC) was released with the broken one, because a stable version of gcc which supported the new one wasn't ready yet. Did this ever get cleared up, or is it still broken?

    The problem with getting ISO involves now is that not everything is completely correct at this point. Of course, it's not like people generally exactly follow ISO standards, either, so

  • Maturity (Score:2, Insightful)

    by SunFan ( 845761 )
    lessen the world's reliance on sucky legacy platforms

    This reeks of a teenager raving about Britney Spears vs. Lindsey Lohan. Either shut up or say something meaningful.

  • GNU? (Score:2, Interesting)

    by rpsoucy ( 93944 )
    Sorry, but I hope I never see a "Linux" standard that deals with anything other than the Linux kernel.

    In all honesty, not enough thought has gone into creating a standard for GNU+Linux. I don't want to see good ideas like debian's package managment system go to waste because everyone decideds to make a bad descission and adopt RPM for package managment.

    What about a standard GUI framework? Don't make me start up the KDE vs. GNOME vs. GNUstep fights :P

    Standardization of BAD ideas would just hold back pro
  • Comment removed based on user account deletion

Slashdot Top Deals

Life is a whim of several billion cells to be you for a while.

Close