Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Linux

Linux Standard Base 2.0 released 242

Posted by CmdrTaco from the standard-this-people dept.
prostoalex writes "Linux Standard Base 2.0 has been released by the Free Standards Group. The release will allow application developers to ensure their product works on multiple flavors of Linux. FSG keeps a list of compliant distributions on its Web site."
This discussion has been archived. No new comments can be posted.

Linux Standard Base 2.0 released More

Linux Standard Base 2.0 released

Comments Filter:

  • Good, though already outdated (Score:3, Interesting)

    by Adam Avangelist ( 808947 ) on Monday September 13, 2004 @03:39PM (#10239493)
    It should be stated that the gcc c++ abi for 3.4 series is incompatible with later versions.

  • Why? (Score:3, Insightful)

    by Anonymous Coward on Monday September 13, 2004 @03:40PM (#10239503)
    Why do companies need to pay to be registered as compliant?

    Why not use an open/free option?

    • Re:Why? (Score:2, Interesting)

      by Arker ( 91948 )

      Terpstra himself summed [debian.org] it up pretty well on a debian list:

      The objective we have is to allow commercial software houses to build portable binary only packages of their software for Intel systems running Linux.

      Let me repeat the operative words here: commercial software, binary only, Intel.

      This has nothing to do with Free and/or Open software, except in that it's an attempt to get Free and Open Software developers to be more helpful to commercial software houses that want to use their work for free (as in

      • Terpstra DOESN'T work for Caldera (Score:3, Informative)

        by Anonymous Coward
        Read the date on your link. Terpstra worked for Caldera in 2001, when they were a Linux company. As far as I can tell, he never worked for SCO, new or old.

        Try Google. You may have heard of it. He now works for PrimaStasys, Inc.

        I'm disgusted that you attempted to link someone who has done so much for Free software with SCO.

      • bullshit (Score:2, Interesting)

        by edxwelch ( 600979 )
        Sorry, I seriously doubt that, as any software written for Intel will probably work for AMD as well. Also, don't agree that all commercial software is evil, nor that binaries are evil.

        • Re:bullshit (Score:2, Informative)

          by jschottm ( 317343 )
          Intel being x86, in exclusion of Power, Sparc, Alpha, and the other architectures that Linux runs on. Use your mind a little before spouting naughty words.

      • Not really (Score:4, Informative)

        by Alan Cox ( 27532 ) on Monday September 13, 2004 @07:44PM (#10242068) Homepage
        Firstly the LSB covers several platforms nowdays, secondly its goal is to create common packages. That means getting the same package running on Red Hat and SuSE regardless of whether its proprietary or free software.

      • Re:Why? (Score:3, Insightful)

        by IGnatius T Foobar ( 4328 )
        Let me repeat the operative words here: commercial software, binary only, Intel.

        Get off your high horse already. There are plenty of good reasons to support the idea of a "one binary runs on any distribution" architecture. There are a lot of potential users out there who would be more willing to give Linux a try if they could do Next-Next-Next-Finish installs. Yes, LSB makes life easier for commercial software, but it makes life easier for everyone else too.

        You won't win any converts to the open sour

      • Let me repeat the operative words here: commercial software, binary only, Intel.

        This has nothing to do with Free and/or Open software, except in that it's an attempt to get Free and Open Software developers to be more helpful to commercial software houses that want to use their work for free (as in beer, not speech.)

        You say that as though it's a bad thing.

        I write binary only commercial software, and we do have users requesting Linux and FreeBSD versions. Harp on about our efforts to rape and pillag

    • Re:Why? (Score:2, Interesting)

      by Brandybuck ( 704397 )
      They pay for the privilege of being certified as "no different from our competitors' offerings".

  • Theres a linux standard? (Score:3, Funny)

    by Foo-Barz ( 156852 ) on Monday September 13, 2004 @03:40PM (#10239507)
    Who would have thunk it...

  • SCO... (Score:5, Interesting)

    by Nos. ( 179609 ) <andrew@nOSPAm.thekerrs.ca> on Monday September 13, 2004 @03:41PM (#10239509) Homepage
    Has two products listed on the compliancy page. Caldera set to expire near the end of this week, and SCO Linux Server set to expire next month. I wonder if they'll try to get renewed.

  • All your base (Score:5, Funny)

    by hhg ( 200613 ) on Monday September 13, 2004 @03:41PM (#10239513)
    All your standard-base are belong to us!

  • So... (Score:2, Insightful)

    by Power Everywhere ( 778645 )
    Which versions of the various distros will be compatible with LSB 2?

    I am thinking somewhere around Fedora Core 6 or so. Anyone want to hazard a guess? This could get sticky with so many options and yet another standard to abide by...

  • Compliant Distributions (Score:5, Insightful)

    by adam mcmaster ( 697132 ) on Monday September 13, 2004 @03:43PM (#10239540) Homepage

    I'm kind of disappointed looking at the list of compliant distributions - there aren't many on there, especially when you consider how many distributions there are out there.

    With that in mind, how much can this "allow application developers to ensure their product works"?

    • That's the problem with trying to impose a standard from above. If the "market" hasn't already provided a standard to follow, providing one in hopes that everyone will is pointless.

      That there are so few distros following the LSB tells me that there's not much of a need or desire out there for such a standard. Either that or the need and desire for product differentiation has a higher priority. LSB should make compliance less costly by making their standard easier to comply with (not so extensive, fewer com
      • First off, you have to make sure your new standard SOLVES AN EXISTING PROBLEM and does so without creating new problems.

        The LSB doesn't solve any problems for the Open Source developers (they're restricted to outdated libraries).

        Nor does it solve any problems for the current users.

        But it needs both of those camps to adopt it so that the commercial ISV's can write to it.

        But that is not in the best interest of the various commercial distributions (Red Hat, SuSE, etc). Their best interest is to form partne
    • Let me repeat an earlier post:
      commercial software, binary only, Intel

      There's nothing 'open' about this. It's just a publicly declared 'standard'. It's a bunch of companies agreeing on a set of rules that they own.

      There's no free beer or speech here.

  • then again... (Score:5, Funny)

    by Anonymous Coward on Monday September 13, 2004 @03:43PM (#10239544)
    >>ANOTHER PLUS. "This would make life easier. Anything that allows us to move to the different flavors more easily is a good thing,"

    Easy? Bah! I want spend 30 hours searching for HOWTO's! I want to type "apropos -k" until my fingers are numb! I want to scan scripts until I hallucinate ascii!

    Bah! Bah I say!

  • slackware and debian (Score:4, Insightful)

    by Anonymous Coward on Monday September 13, 2004 @03:44PM (#10239552)
    If they're not on this list, I have a hard time taking this list serioulsy

    • Re:slackware and debian (Score:2, Informative)

      by Anonymous Coward
      LSB is a goal for debian that should be satisifed in Sarge. see:
      http://people.debian.org/~taggart/lsb/

    • Actually... (Score:5, Informative)

      by yoshi_mon ( 172895 ) on Monday September 13, 2004 @04:05PM (#10239787)
      Debian is listed as a "Silver Member" on their group member page. [freestandards.org]
    • Well, neither uses the required RPM format. I know, it's screwey. RPM shouldn't be the standard...tarballs should. Alas, nobody wants to deal with tarballs anymore--except Slackware and Gentoo users.

      But one must admit that installing DEB packages without using some kind of apt-get is a bit of a pain.
      • Actually, it's not like Gentoo users *deal* with tarballs, however that is one of the ways (the most common I guess) that source is delivered for portage to deal with. Very practical, since almost *every* project at least releases a tarball. Makes for really good availability, really soon after releases.

        Tarballs are an excellent choice for Gentoo - then again, you may not like that it compiles everything locally, then maybe it is not such a good choice for you. At least we have the choice. =)
      • Rather than specify apt or rpm or whatever, why not specify the FUNCTIONALITY that is required and let each package tool handle that however it deems best.

        Focus on including the required information in the package itself. That makes cross-platform easier.
      • Gee, because dpkg -i is so much harder to type than rpm -ivh .

    • Re:slackware and debian (Score:5, Funny)

      by Arker ( 91948 ) on Monday September 13, 2004 @04:21PM (#10239985) Homepage

      Debian, god only knows why, is attempting to support this stuff. Doesn't seem to fit their social contract at all, and the LSB folks have thumbed their nose at Debian repeatedly, but for some reason they keep trying.

      Slackware doesn't and has no interest in it. Another case, I think, where Volkerding gets it.

      Given the background and goals of the LSB, I'll be using their certified list as a list of distros to avoid at all costs.

      • Re:slackware and debian (Score:2, Interesting)

        by Anonymous Coward
        The thing I like about Slackware is that Volkerding is Slackware. He really answers to nobody but himself, which means that no matter what the masses think or want they won't get that unless he sees that is it necessary and good.

        This lets him keep everything working toward his ultimate vision, if what the masses demand doesn't fit in that vision it doesn't happen--this is good because that means that someday he'll arrive at that vision (if he hasn't already), and well that there actually is a vision.

        Its a

      • Re:slackware and debian (Score:3, Informative)

        by Nailer ( 69468 )
        the LSB folks have thumbed their nose at Debian repeatedly, but for some reason they keep trying.

        How? Last time I checked, it was Red Hat and Suse who had to make sure their init scripts were under the LSB decided standard location - not Debian, whose location was chosen as the standard.

        Having software work consistently anywhere is a good thing.

        And most Debian gripes about RPM are from people who think apt is a packaging system. It isn't - dpkg is. And most of your gripes are solved with up2date, yum,

  • Where's the community? (Score:5, Insightful)

    by nadamsieee ( 708934 ) on Monday September 13, 2004 @03:46PM (#10239571)

    FSG keeps a list of compliant distributions on its Web site.

    All of the certified distros are commercial products. Where are the community distros in all of this?

    Could it have something to do with the Fee Schedule [opengroup.org]? The fees don't seem that steep.

    • Free Standards (Score:4, Insightful)

      by Anonymous Coward on Monday September 13, 2004 @04:01PM (#10239737)
      On sale this week for only $3000.

    • Re:Where's the community? (Score:5, Insightful)

      by iabervon ( 1971 ) on Monday September 13, 2004 @04:06PM (#10239796) Homepage Journal
      Ideally, they'd have a test suite for systems available, and a distribution could claim to be compliant if it passed. Or, better, end users who are concerned could run the test suite themselves to find out.

      For that matter, install scripts could include the test suite and check before installing whether your system seems plausible, with sufficient information to complain to your distro if it's not right.
      • The LSB already has a set of test suites [linuxbase.org], but my question is "why aren't there any certified community distros" not "what would be an ideal way to get a community distro certified".
        • The reason there aren't any certified community distros (listed on the FSG page) is probably that community distros tend not to care much about how they are listed. I'd guess that Fedora Core is compliant with some version and just doesn't care about being listed. Most of the other ones, as people have noted, don't use RPM and are probably missing a bunch of things that are only important for strict conformance. (E.g., you're supposed to have a /lib/ld-lsb.so.2; actual programs seem mostly to use /lib/ld-li

    • Re:Where's the community? (Score:3, Insightful)

      by Otter ( 3800 )
      Where are the community distros in all of this?

      Realistically -- what for? Is there a single user not running Gentoo because it isn't LSB-approved? The sort of environment that demands or even cares about LSB compliance has no interest in "community distros" at all. By definition, almost.

      • Realistically -- what for?

        If somebody writes a LSB compliant application that you want to run at home on your Debian or Gentoo or {insert your favorite here} distro, LSB certification suddenly becomes very important to you. The whole idea is that developers write their applications to the LSB spec instead of worrying about particular distros.

        • If somebody writes a LSB compliant application that you want to run at home on your Debian or Gentoo or {insert your favorite here} distro, LSB certification suddenly becomes very important to you. The whole idea is that developers write their applications to the LSB spec instead of worrying about particular distros.

          *SARCASM* Yes, because LSB Compliant software goes online to make sure that your current distro has paid it's dues and is still certified . . . *SARCASM*

          LSB is just a bunch of versions of lib
    • For political reasons, the LSB standardised on RPM. Most (all?) of the community have moved onto something better than RPM and so do not comply in that regard.

  • Next big push? (Score:2, Insightful)

    by photonagon ( 721776 )
    Can't read the article of course, but will this be the next big push for linux on the desktop? Or is it more for the server crowd?

    Being able to install apps without going into a dependancy hell should boost the public's view of the user friendliness of linux.

  • I've said it before, and I'll say it again... (Score:3, Insightful)

    by Anonymous Coward on Monday September 13, 2004 @03:47PM (#10239590)
    Standards like the LSB are absolutely useless as long as the vast majority of distributions do not fully implement them. Even worse, is when the big distributions don't.

  • Patching Questions/Comments (Score:4, Interesting)

    by Eberlin ( 570874 ) on Monday September 13, 2004 @03:50PM (#10239617) Homepage
    Interoperability is a great goal, but is anyone addressing patching/updating? Currently, it seems that these updates are handled as follows: download new packages, remove old packages, install new packages.

    That seems fine for smaller bits of software but for a KDE bug fix or an OO.o update, downloads can go to the 100MBs or more. Fine on a DSL line, but dial-up users are still going to get hit hard.

    I understand that OSS is better at fixing bugs and that's great -- but between Mandrake 10CE and now, it feels like I've downloaded another distro worth of updates. Is there something being done (maybe the whole binary diffs thing mentioned before) to decrease the size of update files?

    I'm posting this as part of an LSB thread in the speculation that binary compatibility may one day lead to (smaller) patches that can be applied to LSB-compliant distros...so a KDE bug stays a KDE bug and not a MDK bug, SUSE bug, RH bug, Debian bug, etc.

    • Currently, it seems that these updates are handled as follows: download new packages, remove old packages, install new packages.

      That seems fine for smaller bits of software but for a KDE bug fix or an OO.o update, downloads can go to the 100MBs or more. Fine on a DSL line, but dial-up users are still going to get hit hard.

      This is up to the packager/developer/distributer of the packages.

      It would be easy for a packager to split the big packages into smaller pieces. However, they typically only test wi

    • That seems fine for smaller bits of software but for a KDE bug fix or an OO.o update, downloads can go to the 100MBs or more. Fine on a DSL line, but dial-up users are still going to get hit hard.

      That would be great, but most end-users (read MS Windows users) are used to these huge updates. Do a fresh install of MS Windows XP and see how many hundreds of megs you need to download. XP SP 2 alone is huge, then add the weekly virus signature updates and most MS Windows users are use to big downloads (if th

    • One of the reasons a KDE bug becomes a RH, MDK SUSE bug is because the main distro's had a tendency to move things arround a bit and sometimes rename things (Bad Dog, No Bisquet) to differentiate themselves. Personaly, I think the biggest real difference should be the initial configuration.

      A big help in this area would be if the developers would actualy put things where they are supposed to be (as in LSB) rather than where its easier for them to develope from (as in stick everything in /usr/local). Life wo

  • This is nonsense (Score:5, Funny)

    by mpcooke3 ( 306161 ) on Monday September 13, 2004 @03:54PM (#10239664) Homepage
    I mean what are they going to come up with next, a standard packaging format?

    Jesus, they're just taking all the fun out linux.

    • Re:This is nonsense (Score:5, Insightful)

      by nadamsieee ( 708934 ) on Monday September 13, 2004 @04:09PM (#10239843)
      Actually, RPM is the standard packaging format for LSB. Thank God for gentoo...

      • Why the hell is RPM the standard format? Oh wait, I remember. Red Hat has commercial backing. Mandrake has commercial backing. Gentoo and Debian don't.

        Despite this commercial reasoning though, I'd still wager that these guys have their heads up their arses.

        • While Debian doesn't have corporate backing directly, there are a good number of distributions out there that are based on Debian, therefore would greatly benefit if it were LSB compliant. Lindows^H^H^H^spre is a big one that comes to mind, but there are others too.

      • Re:This is nonsense (Score:3, Insightful)

        by mpcooke3 ( 306161 )
        They need a format that only contains meta information about files/services rather than actual commands to execute (pre/post install sections in rpm).

        Atleast I think that's what they need, they sure as hell need to sort something out that is better than RPM...

      • Re:This is nonsense (Score:5, Insightful)

        by Nailer ( 69468 ) on Monday September 13, 2004 @08:38PM (#10242425)
        Actually, RPM is the standard packaging format for LSB. Thank God for gentoo...

        Why do you need a different packaging system to download and compile software and its dependencies based on your preferred compiler options?

        Last time I checked, you don't. up2date can download source packages, rpmbuild can rebuild them, and you can use cflags with RPM just like anything else.

        Sure, Gentoo automates that, but there's no reason they need a seperate packaging system to di it.

        Additonally Suse, Red Hat and everyone else already use optimized bianries where it matters, automatically installing the right kernel and c libaries based on processor type. Multimedia sites for Fedora / RHEL and Suse also include optimized packages for totem / mplayer etc to, and up2date / yast automatically picks them out.
  • I was under the impression something like the LSB doesn't change much. Does anyone have a summary of the new or changed items?
    • LSB 2.0 was released on August 30, 2004. This major new version adds Pthreads support, C++ support, a modular specification, alignment with current standards (Posix 1003.1-2001 / SUSv3) and a large number of quality improvements to the LSB. A complete set of test tools, development tools, sample implementation and application battery are available from the downloads page.

      My favorite change is the modularization. It didn't make any sense to me that X11 libraries were required for LSB 1.x. Most servers I r

  • standards are good (Score:4, Funny)

    by prockcore ( 543967 ) on Monday September 13, 2004 @03:57PM (#10239699)
    I wish Solaris was LSB compliant even though it's not Linux. Here's a good reason for standards:

    There is a killall program on Linux, it kills all processes that have a processname that matches the argument you pass to it.

    There is a killall program on Solaris, it doesn't take any arguments and will kill every process running.

    • This has nothing to do with the LSB. The LSB is simply about making linux-on-intel friendly to people that want to put out binary-only commercial programs.

    • Let's turn your argument around, and ask why "killall" under Linux doesn't kill every process running. After all, that's what the command implies.

    • Re:standards are good (Score:4, Interesting)

      by Michael Wardle ( 50363 ) <mikel AT mikelward DOT com> on Monday September 13, 2004 @05:40PM (#10240898) Homepage

      What did you expect killall to do? It has been around since System V and kills all processes. It was introduced to Linux in the PSmisc [sourceforge.net] project and took on another meaning.

      The Solaris equivalent is pkill and is also available on Linux from the procps [sourceforge.net] project.

      The more sensible thing would be for all distributions to remove killall and standardize on pkill. killall5 could be retained if necessary.

  • They specced out C++ ABI and libraries this time.
    This is a nice addition, since many developers prefer C++ in spite of considerable rifts between it and the Unix culture.
    At the time LSB 1.3 was written, there was no open C++ ABI standard, and the issue was left dangling. There is such an ABI [codesourcery.com] now, and g++ supports it fully. In fact, the entire LSB 2.0 C++ spec is written around libstdc++ from gcc 3.x.

  • C++ ABI issues? (Score:4, Interesting)

    by dwheeler ( 321049 ) on Monday September 13, 2004 @04:09PM (#10239838) Homepage Journal
    At one time, there was concern by some that the LSB was trying to freeze the C++ "too soon". See this LWN posting [lwn.net] for more info.

    I presume that LSB is simply spec'ing existing practice, correct? Or have things changed since that posting? Is this really an issue, even, since a system might be able to support an "old" and "new" C++ ABI by having both the "old" and "new" libraries installed?

    Also: if the C++ symbols will be stored as (name space + package + class + method) in that order, ELF is used, and there are many hash collisions, this might create a lot of overhead loading large C++ libraries. The reason: while linking, you'd have to compare a lot of text before matching, because so many symbol entries would have a common prefix that you'd have to keep matching over and over again. Am I reading this correctly?

  • /opt ? (Score:2)

    by cymen ( 8178 )
    Is the LSB responsible for /opt?
    • I think it's System V that's responsible for /opt.
    • /opt comes from the Filesystem Hierarchy Standard [pathname.com] (FHS). A lot of what the LSB tries to do is codify existing practice or point to existing standards wherever possible -- doesn't make sense to create something entirely from scratch if nobody is going to adopt it. The FHS is just one example of where the LSB pointed to an existing standard and said "This be good!"

      Given that the FHS is headed up by notables Rusty Russell and Dan Quinlan, I've got a lot of confidence in their judgement.

      • The FHS is responsible for /media, which is even more useless than /opt. Yay Slackware for not shipping that useless wart.

        • Re:/opt ? (Score:3, Informative)

          by DenialS ( 21305 )
          Declaring something "useless" means nothing if you haven't backed up your opinon with some rationales. You don't like /media because Redhat put cdroms in /mnt/cdrom? Fine, say so. Or you don't like it because it has too many vowels and should be /mda? Okay, great. But back up your opinion with some rationale. Otherwise it's just an assertion that takes up space.

          Oh, and provide your rationale to those (like Rusty and Dan) who actually set the standards. Whining about it on Slashdot is hardly the way to ach

  • quote (Score:5, Insightful)

    by dtfinch ( 661405 ) * on Monday September 13, 2004 @04:38PM (#10240204) Journal
    "For payment terms please contact The Free Standards Group"
  • Last time I did an install when I selected LSB packages it told me I needed to use the 2.4 series kernel? This could just have been a glitch in the distro I was using, but considering I've never installed a piece of software that needed the LSB I immediated unselected it.

    Whenever I hear the word standard regarding Linux I tend to think its a good thing, but I've started to feel pretty indifferent regarding the LSB. Is there any reason I shouldn't?
  • IIRC, your system doesn't have to use RPM natively to be compliant. It just has to deal with RPM v.3 packages. This can be done by either installing RPM (can be done), or using alien to change the package format.

  • Finally, about time. (Score:3, Insightful)

    by aristotle-dude ( 626586 ) on Monday September 13, 2004 @05:30PM (#10240793)
    I've been advocating this for some time. If linux wants to make a dent on the desktop, they have to do stuff like this.

    Guys don't give me this crap about companies feeding off the work of Open source. These companies have worked hard on their closed source applications and want to be able to port their software as binaries to Linux. This is a good thing.

    To use that analogy, would a developer releasing software for windows be feeding off the hard work of MSFT? This standard will help create a symboitic relationship between commercial developers and the linux platform.

    The average joe does not want access to the source, all they care about is compatibility and interoperability of software. Open standards are something the average joe might support but they could care less about the source.

    • "Guys don't give me this crap about companies feeding off the work of Open source. These companies have worked hard on their closed source applications and want to be able to port their software as binaries to Linux. This is a good thing."

      I'm not going to argue whether those ISV's are "feeding off" of anyone or not. That's not the point.

      If everyone adopted the LSB tomorrow, it would be a good thing for those ISV's.

      But what is the incentive for anyone who is NOT one of those ISV's to adopt it?

      "This stand

  • About F. Time... (Score:2, Interesting)

    by Spy der Mann ( 805235 )
    Finally the Linux guys agreed that there SHOULD be a standard (even if it's not implemented yet).

    Seriously, saying Linux is 1000 times better than Microsoft is kinda being hypocritical when they make MS's same mistake: Despising standards in favor of proprietary implementations. (NO, i DON'T mean open vs closed source. I mean standard vs proprietary).

    Anyway let's see if in a couple of months, this resolution helps programmers deploy Linux binaries that run on _ALL_ compliant Linux distros, ending to the .

Slashdot Top Deals

"I'm a mean green mother from outer space" -- Audrey II, The Little Shop of Horrors

Close