Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Linux Standard Base 2.0 released

Posted by CmdrTaco on Mon Sep 13, 2004 03:35 PM
from the standard-this-people dept.
Operating Systems Software Linux
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."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Linux Standard Base 2.0 released 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

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

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

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

      • 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

  • 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@th e k e r r s . 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!
  • 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"?

      • 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

  • 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

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

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

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

      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.

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

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

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

  • 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.
    • 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.
        • Both versions of killall are useful. But the solution shouldn't be to get rid of one in favor of the other, but to simply use different names for the commands. Tada! That's why Solaris has both killall and pkill!

          Why is it useful? I would think that's obvious. To write shutdown scripts with! killall doesn't kill all processes, it only kills all processes not directly related to the shutdown process. While the same thing can be done with a quick shell script, the current solution probably uses fewer resource

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

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

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

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

    • What I have found with gentoo, is that most of the programs that you emerge, will be in a different place than if you were just to untar, and make the package your self.

      This makes it quite hard to follow a general howto for a general *nix nox, while using emerge to get the packages.

    • considering the fact that gentoo is a source based distribution, it really can't. However gentoo trys to stay as similar as possible when it can for minimal pain

    • Gentoo... maybe kinda... (Score:5, Interesting)

      by temojen (678985) on Monday September 13 2004, @04:21PM (#10239986) Journal

      Certification of gentoo is almost certainly out of the picture, as you can't know from one system to annother which libraries are installed.

      This might be an interesting use for slots though. Someone could build a series of ebuilds that require the specific library versions that the LSB specifies, and keeps them in slots (so they're not unmerged when they're upgraded). Then a Gentoo user who has emerged "LSB-Base" would have a decent chance to be able to run any LSB 2.0 requiring binary package.

        • 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

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.