Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Standard Base 2.0 released

Posted by CmdrTaco on 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."

6 of 242 comments (clear)

  1. Good, though already outdated by Adam+Avangelist · · Score: 3, Interesting

    It should be stated that the gcc c++ abi for 3.4 series is incompatible with later versions.

  2. SCO... by Nos. · · Score: 5, Interesting

    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.

  3. Patching Questions/Comments by Eberlin · · Score: 4, Interesting

    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.

  4. C++ ABI issues? by dwheeler · · Score: 3, Interesting
    At one time, there was concern by some that the LSB was trying to freeze the C++ "too soon". See this LWN posting 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?

    --
    - David A. Wheeler (see my Secure Programming HOWTO)
  5. Gentoo... maybe kinda... by temojen · · Score: 5, Interesting

    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.

  6. Re:standards are good by Michael+Wardle · · Score: 3, Interesting

    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 project and took on another meaning.

    The Solaris equivalent is pkill and is also available on Linux from the procps project.

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