Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Three Major Linux Distributions Certified LSB Compliant 192

Posted by timothy from the oh-you're-so-compliant dept.
KevinDumpsCore writes "RedHat, Mandrake, and SuSE are now certified LSB compliant!" Here's the announcement on the Free Standards Group's site. The Linux Standards Base (check out these related Slashdot posts) has been working for years to perhaps tame the what-lives-where cross-distro craziness. (Of course, distro makers are under no obligation to comply with the LSB's choices.)
This discussion has been archived. No new comments can be posted.

Three Major Linux Distributions Certified LSB Compliant More

Three Major Linux Distributions Certified LSB Compliant

Comments Filter:

  • What about Debian? (Score:2, Interesting)

    by shadwwulf ( 145057 )
    What's Debian's status in this matter?

    • Re:What about Debian? (Score:2, Informative)

      by sporty ( 27564 )
      LSB seems to require redhat packages. They can't use triggers and some other things, but it is required they used rpm.
    • The are some problems, for some reason LSB specifies a standard package, ie RPM
      I do not know why, I see no reason for it, but obvious this is a problem for Debian, which has its own (imo superior) package (debs).

      This article [debianplanet.org] from Debian planet, is about a sudo package you can install, which depends on all the LSB stuff (thus gets them installed, with some caveats)
      As to RPM, Debian wont move from debs, but I believe they make a wrapper so that dpkg can understand them, see /usr/share/doc/lsb/README.Debian.gz

      I will not install lsb, cause it wants lpr (BSD print deamon) and I already use CUPS (a SysV print deamon), as well as other stuff.

      • Re:What about Debian? (Score:3, Informative)

        by printman ( 54032 )
        LSB requires the lpr command, not the lpr software. CUPS, LPRng, Berkeley lpr, and GNU lpr all satisfy the LSB requirement IIRC.
      • a sudo [sic] package you can install, which depends on all the LSB stuff (thus gets them installed, with some caveats)

        For all of you out there wondering what the hell the 'sudo' command has to do with the LSB, I believe the poster meant a pseudo-package.

      • Re:What about Debian? (Score:4, Informative)

        by noahm ( 4459 ) on Saturday August 17, 2002 @08:12PM (#4090775) Homepage Journal
        The are some problems, for some reason LSB specifies a standard package, ie RPM I do not know why, I see no reason for it, but obvious this is a problem for Debian, which has its own (imo superior) package (debs).

        Grr, I'm so tired of people not getting this. The LSB usage of RPM is simply not a problem for Debian. We have no problems handling .rpm packages. See the rpm and alien packages (particularly alien) to see how we do it. The RPM thing is a non-issue regarding Debian's LSB compliance.

        To see how seriously Debian takes LSB compliance, go have a look at the archives of the various LSB related Debian mailing lists [debian.org]

        noah

    • Re:What about Debian? (Score:5, Funny)

      by Macrobat ( 318224 ) on Saturday August 17, 2002 @05:40PM (#4090352)
      What's Debian's status in this matter?
      I believe they're aiming to be GNU/LSB certified.

    • It's close (Score:4, Informative)

      by hendridm ( 302246 ) on Saturday August 17, 2002 @06:26PM (#4090461) Homepage
      Debian 3.0 did pretty well [freestandards.org] compared to SuSE.

      Link shamelessly stolen from this post [slashdot.org].

  • Ok, GREAT now merge Gnome and KDE (Score:2, Insightful)

    by Anonymous Coward
    Ok, GREAT now merge Gnome and KDE. I hate it when I cannot easily copy from application to another.

    Competition is great, but only to a certain level.

    The LSB ought to have that merger as a long time goal. Get the Gnome/KDE guys together more, and eventually... I know they have had discussions, but, where are the actual results.

    Let, Gnome 3.0 and KDE 4.0 be the same!!!
    • Actually, the best parts of each should be integrated with X. Right now, a lot of the bloat the common user experiences on the Linux GUI is because of the seven layers of translation the average API call goes through -- every window draw, every mouse click, every sound has a huge timing penalty incurred by the three or four extra layers over and above what you would find under Windows or even in Mac OS X. Building in icon support, sound support, font support, higher-level networking, drawing primitives, and OpenGL could make X anywhere from 12% to 37% faster on the average platform (depending on the features involved), bringing us that much closer to the Windows refresh rate.

      Window managers should really be little more than themes; otherwise, we're just reinventing the wheel every time another person has to redevelop an algorithm that's already present in five other places.

      • could make X anywhere from 12% to 37% faster on the average platform

        So, did you just pull those numbers out of your asterisk, or can you actually point to some analysis to back that up?

        Even assuming that were true, on most machines (ie, anything better than a 386 with 4 MB memory), the difference won't be noticeable because even a 200% improvement in event response is lost in the noise of human reaction/perception times.
        • on most machines (ie, anything better than a 386 with 4 MB memory), the difference won't be noticeable because even a 200% improvement in event response is lost in the noise of human reaction/perception times.

          So, did you just pull those numbers out of your asterisk, or can you actually point to some analysis to back that up?
      • And who will get to decide what components to use? What WM functionality to implement? What toolkit to base it on?

        Me? Great! I say we go All XFCe, All the Way! We won't even implement the letters K or G in our brand new environment! Oh, and the WM functionality will be tiled, not overlapping, and will be sloppy focus only, and with themes implemented in an inbedded Haskell interpreter.

        Not good? Haskell is a drag? You maybe wanted to work in Qt? You maybe wanted a different feature set? Well, golly, let's put all your wishes in as well, and those of everybody else. Once we put in the superset of all current (and future) desktop-type projects, I'm sure X will be a lot faster and smaller!

        And once it's all in, I'm sure everyone with a hankering to try some new ideas regarding desktops or window management will be just thrilled at the prospect of having to demand their users to install a custom version of X to use it.

        Serously, I really don't get this "One OS, One Desktop, One Community" kind of reasoning. That we can use different stuff for environments (or even just different tastes) is a _strength_ of the platform, not a weakness.

        If you are _really_ desperate for more speed, why not start a project to make a desktop bypassing X altogether? If the speed difference is really that important, people will flock to it. And BTW, I'm really impressed with the precise percentages you have, especially since you've not even decided _what_ components should be integrated... /Janne

        • I agree with you, but, there should be some efforts made towards compatibility between the various environments. This brings up an idea I;ve been kicking around for a few months: meta-theme packaging. These would be tarballs of themes for different environments. The client system would provide scripts to install themes for different environments/toolkits. So now one theme could be installed for Sawfish/Metacity, GTK, Qt/KDE, WindowMaker, or Enlightenment.

          • Look up Metatheme - it's supposed to do that eventually.

            And there _is_ work on improving compatibility; with KDE3, the clipboard now works the same in just about every desktop, there is a common menu description format, Gnome is moving towards using arts as the soundserver, they use the same XML lib, and so on. There's even a site for coordinating desktop-interoperability in Linux (though I don't have the link handy).

            The most difficult problem is of course theming. It would be all but impossible to make a common theme format; you'd probably end up with a 'compatibility engine' that can take themes written for it - and that nobody will use, as the native themes will be cooler and faster anyway. Something like Metatheme will probably have a better chance, and even then, it greatly depends on multiple people working together to create a unified theme. /Janne
        • If you are _really_ desperate for more speed, why not start a project to make a desktop bypassing X altogether

          This is actually a very good idea. We will need X for some time to come, but it supports alot of junk that isn't needed; and it fails to support many things also (sound, most input devices).

          If we want a common standard there should be one windowing API, which probably bypasses X altogether. This is hardly a trivial task, but in the long run makes alot of sense. If you are writing an app today, it really needs only two interfaces to the user: Command line and GUI. It shouldn't need to care about X.

          Now for my personal impression - this isn't meant to start a flame war, but probably will be taken that way. The KDE environment (at the moment) appears the best local environment. By this I mean the GUI, themes, and smaller apps (konqueror for file browsing). Unfortunately (or fortunately, depending on your view) many of the best apps are GNOME (Evolution, Galeon for the web). For the newbie it can take a while to go find these apps if they use the KDE desktop.

          Serously, I really don't get this "One OS, One Desktop, One Community" kind of reasoning. That we can use different stuff for environments (or even just different tastes) is a _strength_ of the platform, not a weakness.

          I don't believe that is true when it applies to fundamental, underlying services. We have one kernel, and it works. The prospect of a kernel fork came up recently in the 2.4 series, and it wasn't a nice prospect. The current fork in GUI's that overlie X windows is much less critical, but still not good. And the two projects went their own ways at about concept time, when everyone agreed that linux needed a better GUI for end user apps.

          Linux's strength is in a rock-steady kernel, a secure file and operating system all open to scrutiny, and a mass of interested developers. This produces a diversity of quality applications, and Linux needs that too. But GNOME and KDE? Two GUI's - no, in the long run we will want one good gui with the good features of both.

          My 2c worth,

          Michael

      • Eh? What ya talking about? (Score:5, Insightful)

        by jmorris42 ( 1458 ) <jmorris@[ ]u.org ['bea' in gap]> on Saturday August 17, 2002 @04:51PM (#4090213)
        I don't see seven layers of API. That's just FUD you are spouting from either the Windows or Berlin camp.

        A typical GNOME app makes calls into the GNOME libraries, which are linked at the hip to GTK. GTK directly talks the lowest wirelevel X protocol which gets stuff on the framebuffer.

        A KDE app talks to the KDE libraries which are built on Qt. Qt talks Xlib (QT experts feel free to call me an idiot and correct me) which, like GTK, talks directly to the X server.

        And if you want to argue that X imposes too much overhead, that is why we have things like the shared memory extension and Xrender.

        But NO, window managers must remain ordinary applications, otherwise X turns into something brain damaged like Windows or a Mac.
        • Quoth the heathen:
          > But NO, window managers must remain ordinary
          > applications, otherwise X turns into something
          > brain damaged like Windows or a Mac.

          Brain damaged? Who's spouting FUD now? Mac's have Window Managers too:

          [localhost:~] david% ps axwww | grep Core
          73 ?? Ss 3:15.50 /System/Library/CoreServices/WindowServer
          228 ?? Ss 0:00.29 /System/Library/CoreServices/coreservicesd
          272 ?? Ss 0:00.10 /System/Library/CoreServices/SecurityServer
          286 ?? Ss 0:00.71 /System/Library/CoreServices/loginwindow.app/login window console
          289 ?? Ss 0:03.53 /System/Library/CoreServices/pbs
          303 ?? S 0:05.07 /System/Library/CoreServices/Finder.app/Contents/M acOS/Finder -psn_0_262145
          304 ?? S 0:01.21 /System/Library/CoreServices/Dock.app/Contents/Mac OS/Dock -psn_0_393217
          306 ?? S 0:08.16 /System/Library/CoreServices/SystemUIServer.app/Co ntents/MacOS/SystemUIServer -psn_0_655361

          Mac OS X is less brain damaged than you think.

          -David
          • Yes it is a seperate process on OSX, but don't expect replacements anytime soon if Apple has any say in it.

            On the whole, OSX does kinda toss old views of the Mac into the trash. I have been playing around with some iMacs running OSX recently and it's almost but not quite familiar territory. Neither fish nor foul if you take my meaning. But gimme three buttons on a TiBook and I'm there when my Thinkpad's warranty runs out.
          • Then you've just given a reason why window managers in X should stay.
      • Actually, the best parts of each should be integrated with X. Right now, a lot of the bloat the common user experiences on the Linux GUI is because of the seven layers of translation the average API call goes through -- every window draw, every mouse click, every sound has a huge timing penalty incurred by the three or four extra layers over and above what you would find under Windows or even in Mac OS X. Building in icon support, sound support, font support, higher-level networking, drawing primitives, and OpenGL could make X anywhere from 12% to 37% faster on the average platform (depending on the features involved), bringing us that much closer to the Windows refresh rate.

        12% to 37% faster? 7 layers of translation? Timing penalties for SOUND? How the hell did this techno-babble get moderated up as insightful? It's a load of codswallop. I don't think there's a single fact up there.

  • I think this is Better than 'United Linux' (Score:3, Informative)

    by BroadbandBradley ( 237267 ) on Saturday August 17, 2002 @04:33PM (#4090150) Homepage
    a nice open standard like LSB, imagine the improvement in install docs, cross distro rpms...this is a good thing.

    • More exciting is conformance to a single ABI standard in combination with installation script support. This is a godsend for package maintainers; in the future they will only have to compile and package once, and your app is supported on multiple distros.
      • More exciting is conformance to a single ABI standard in combination with installation script support. This is a godsend for package maintainers; in the future they will only have to compile and package once, and your app is supported on multiple distros.
        Isn't that what United Linux was all about? LSB compliance, plus a standard filesystem layout, plus a standard set of libraries, plus standardized international language support.

        Forgive me, but I feel that United Linux was on the right track. The only problem with it was that Ransom Love's name was on the list of founders. Well, that and the obvious fact that it is pretty much still vaporware at this point.

        Still, it seems sad that a good idea gets the shit treatment simply because people have a bad attitude about one of its supporters.
  • Did they just finish evaluating the latest stable distros from each company or are they looking at the betas that just developed into FSB compliance?

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

    by matman ( 71405 ) on Saturday August 17, 2002 @04:48PM (#4090199)
    It's too bad that the LSB people havn't yet taken on packaging issues. They've effectively chickened out by just recommending RPM. The best features of RPM, DEB and the BSD ports system should be reflected in a new packaging format for people to work towards using. Not only should this format be recommended by the LSB, but the LSB should define policies for the use of the format - package name and version formats, dependencies and package alias names, source package handling, non-official packages, etc. This really is necessary to get distribution of commercial software on Linux; testing for and supporting distribution differences is just too expensive for most companies. This is not to say that everyone supporting RPM won't help, but rather that policies are needed to really make it work, and that we may as well get a more optimal package management system happening :)

    • Re:RPM... (Score:3, Insightful)

      by jmorris42 ( 1458 )
      RPM is just fine for a packaging standard. It does EVERYTHING a packaging system needs to do and none of the bogus crap that consumer friendly monsters like InstallShield do. Deb may very well have a equal featureset but nobody in the commercial world uses it because it is only used on Debian, a non-commercial distro. Since the big need for the LSB is for commercial software packagers.... see the problem? As for the BSD Ports system, it has ZERO to offer in this situation despite being a wonderful system. The BSD ports setup pretty much requires source distribution and the target audience for LSB isn't interested in that.

      The apt groupies can't get it into their pointed heads that apt can work just fine with rpms. Apt and .deb are entirely seperate issues. Yes rpm needs something like apt to come into popular usage. (ya know, maybe apt would be just the ticket! Now if all of the apt groupies would promote it's use with rpm instead of constantly saying ya gotta go to Debian to get the wonders of apt. Ya, I'm talking about you Taco.)

      Not that I would ever be insane enough to put apt in a cron job like the typical Debian user, but it does do wonders to solve rpm dependency hell situations.

      • Maybe there should be a meta-program called "autopkgmanager" (or something else) that would serve as a unified front-end for apt-get, urpmi, up2date, emerge, etc.

        For example, on a mandrake box:

        autopkgmanager -i kde

        would call:

        urpmi kde

        while on debian, the same command would call:

        apt-get install kde

        On gentoo:

        emerge kde

        And so forth...

        • [root@aragorn /]# urpmi kde

          The following packages contain kde: kdevelop kde-i18n-ro kde-i18n-ru kde-i18n-cs kdeaddons kdev_htdig kdegraphics kde-i18n-ko kde-i18n-da kde-i18n-de kde-i18n-sk kde-i18n-sl kde-i18n-he ksetiwatch kdeadmin kde-i18n-sr kdesdk kde-i18n-zh_CN.GB2312 kdetoys-devel kdebase kdenetwork-devel kde-i18n-sv kdeutils kdepim kdemultimedia-devel kde-i18n-pt_BR kde-i18n-hu kde-i18n-af kdelibs kdenetwork kdetoys kde-i18n-ta kdebindings kde-i18n-pl kde-i18n-lt kde-i18n-lv kde-i18n-en_GB kdebase-nsplugins kde-i18n-th

          etc. It won't install anything. urpmi is a half brain-dead, half-backed version of apt. Portage is a God send, as is apt. But urpmi needs some SERIOUS work. MDK USED to support apt, but stopped support of it back in Janruary or so.
          • Something beyond my understanding is why anybody and his dog want his own pet upgrading thingy !

            I mean Redhat felt obliged to come with it's brain dead up2date, same thing for Mandrake. I mean there is this thing called apt, wich has been tested for years, and which has been ported to work for RPM. I use it every day, and it works insanly well.

            Yeah I know, I know ! the official Linux motto, the party line is that "Choice is good". But I sure would prefer one good standard over 10 half backed brain dead programs.
            • up2date makes perfect sense when viewed in light of RedHat's business model. Whether allowing important standards to be defined to support a single company's business model is a good thing is a question for another day.

              After instantly removing up2date and all it's associated cruft after an install/upgrade for a couple of years I finally left it on my new laptop and signed up for RHN just to give it a chance. It does work slicker than owl snot. Never a worry about finding a mirror, no dependencies, etc. Not sure if the time savings justifies the fee, guess I'll know next year when resub time comes if I actually give up the CC # again. ;)

              In the end, apt-get is a fine thing for the Debian folks because they are few in number. I just don't think there is enough free bandwidth to host package repositories for the rpm using hordes. I especially have those sorts of thoughts when a Debian user starts talking about installing or doing a major upgrade directly from the mirrors. Can you imagine the meltdown that would happen if, when RH8 drops if every RH user tried to upgrade directly off of the mirrors? The slashdot effect would be as nothing compared!

      • Re:RPM... (Score:1, Informative)

        by Anonymous Coward
        Thank you for making this point! Debian is a fine distribution, but to any outsider it's bound to look like a bunch of kooks and cultists -- especially when people don't get their facts straight. At the risk of trolling, a lot of this tripe comes from people who haven't so much as touched a Red Hat distribution in years. Weak. There are certainly differentiating factors which may make Debian a better choice than other distributions, but -- in many cases -- apt isn't one of them, thanks to apt-rpm.

        Red Hat, SuSE, Yellow Dog, Solaris, and Mandrake users can give it a spin by heading to:

        http://apt4rpm.sourceforge.net/

      • Re:RPM... (Score:4, Insightful)

        by inkfox ( 580440 ) on Saturday August 17, 2002 @05:53PM (#4090382) Homepage
        Not that I would ever be insane enough to put apt in a cron job like the typical Debian user

        A typical Debian user would not do this. Good god, that's a recipe for disaster!

        "Typical" Debian users are more concerned with stability than they are in "upgrading" constantly.

      • Apt-get has been ported to RPMs.

        Mandrake's urpmi does the same thing as apt-get for RPMS.

        You can use RPMs as your packages and use either apt-get or urpmi.

        My personal experiences are these:
        1) apt-get on a debian box is the reason to use debian.
        2) apt-get on Debian is a rock-solid way to add/subtract packages.
        3) urpmi with RPMs works ok most of the time. When it doesn't work, it's usually beause it dependencies that urpmi can't find in other rpms. In this respect, Debian still beats the RPM-based distros.

      • Re:RPM... (Score:3, Informative)

        by blaine ( 16929 )
        Exactly who the hell puts apt in a cron job?

        I mean, I have a short script that I wrote that checks to see if there are any updates, and emails me the results. I have it run every night on my domain box, and thus, every morning, I find out if there are needed upgrades. At that point, I can go check out why the upgrades are needed, and perform the udpate manually.

        However, I would never have apt upgrade my system without me being there, and I highly doubt anyone else with any brains would. So please, stop spouting bullshit about how the "typical Debian user" does something that retarded, because I've never met a single person who has done that, and I've known a lot of people running Debian.

      • Re:RPM... (Score:3, Insightful)

        by rossz ( 67331 )
        bogus crap that consumer friendly monsters like InstallShield do

        This is the kind of attitude that is keeping Linux out of the mainstream. Consumer friendly crap like InstallShield are exactly what is needed.

        Typical installation on installation on Linux...

        Download rpm and try to install. Now go look for the dependency rpm needed. Download that and try to install. Oops, that has a dependency, too. Can't find an rpm, get the source in a tar.gz. Unpack it and run ./configure, make, make install. Oops, need the source for a missing library. Go find that....

        Typical install using InstallShield...

        Run InstallShield, choose directory, choose components (though the defaults are usually correct for the average user). Wait for install to finish. Sometimes reboot (yuck, that's stupid).

        Now which method is a typical computer user going to prefer?

        • You forgot to mention the typical install using apt:

          apt-get &lt;package&gt;

          That's it. And when it comes to directory to choose, there should not be a choice in a package system. If it's that important to break things sufficiently that they are not in the standard dirs, then the user should download the package. This is Unix, where we can graft in disk space where we need it, not Windows, where it must be dealt with on a volume level.

        • Microsoft , to it's credit, seemed to make a concious effort to make sure it's API's remined consistently backwards over time. DLL's from microsoft, (notable exceptions.. Fucking wang/kodak imaging library, grrrr) can be updated without too high likelyhood of slaying previous versions of software.

          Unfortunately the haphazzard linux update cycle has tended to mean that one needs the correct libraries for each expected invokation (eg ver 6.7 AND 6.8 rather than just 6.8).
          Think KDE here.
          That's where the magic of debians apt stuff kicks in. The program really does not much except maintain a well pruned dependancy tree and make sure that libs are there (and autogets them if necesarrily), the magic is that Debian lords with an iron fist over packagers and make sure that package descriptions list EXACTLY what is needed. I have no doubt that apt & RPM are a groovy enough combo, but one still depends on a central body to enforce strict rules to enforce compliance.

          With out that, dependancy-fucking your box hasn't gone away, it's just become automatic.
        • If InstallShield is the answer it was a dumb question. It doesn't really solve DLL Hell, can't run non interactive and generally sucks. And it is a PITA to build packages with.

          I'm not defending the status quo, I think having something like apt become standard issue for rpm based distros would be a good thing.

          My idea of a GOOD installer would be a simple Tcl/Tk (or for the Python Bigots out there, Python/Tk would be just as nice, save your napalm) script that threw up a welcome splash, checked for an existing install, etc but basically did an apt command to do the actual install would be just hoopy. Vendors should include the RPMs they depend on, from several popular distros, if there is a chance of a problem, just to avoid the user having to swap in a handful of distro CDs looking for packages. But there is NO need for a graphical package manager like Install Shield and DON'T allow the user to pick where to install to! And if you aren't packing the CD full of bundleware/spyware you usually don't even need to allow a choice of what to install. (But there are legit exceptions to that statement.)

          For 95% of cases install should be a matter of "Do you want to install Foo?" Ok, wait a minute..... done. Enjoy Foo!

        • I love this stuff. (Score:2, Interesting)

          by ubernostrum ( 219442 )
          I've been running Red Hat for two years now. Where's the "dependency hell" everybody talks about? I've gone from 7.0 to 7.3, doing each upgrade in turn, installed all sorts of stuff in between upgrades, never had any problems. So I have some issues with what you call a "typical" install on Linux...

      • Re:RPM... (Score:4, Interesting)

        by cant_get_a_good_nick ( 172131 ) on Saturday August 17, 2002 @07:34PM (#4090672)
        The BSD ports setup pretty much requires source distribution and the target audience for LSB isn't interested in that.

        BSD also has binary packages, which mesh with the ports system. They're .tgz packages with the normal pre and postinstall scripts available in the package. I always thought of the BSD system as pretty slick, a source model and a binary package model that mesh well. Anything I installed from ports I remove with the package tools. I can check for new versions of all externally installed software (packages and ports) with the same command. They blend well enough for me that I kind of see them as one system.
      • Lotsa mentions of apt and RPM, but not many seem to know of Gentoo's emerge system yet. It's similar to apt (from what I know of apt), and it allows for both binary and source distributions. I assume apt does as well, and I know you can make an RPM recompile to install, but it's just another suggestion.

        As an aside, does anyone know if Gentoo is even remotely LSB-compliant?

        • Here [gentoo.org] is a discussion of LSB compliance and Gentoo on the Gentoo forums. In short, Gentoo won't be LSB certified, but it will "likely maintain the 'spirit' of LSB standards."

          I think the RPM requirement and probably the requirement to maintain two separate init-script implementations would be undesirable for most Gentoo users.

      • There's nothing wrong with running apt from a cron job. You do the downloads in a cron job, and you upgrade manually if and when it makes sense.
      • Suppose that some commercial development tool requires gcc-3.0.1 or above. They make an RPM. What should they require? "gcc >= 3.0.1"? Wrong. A user of RedHat 7.2 can have gcc-2.96 and gcc3-3.0.4. Maybe "gcc3 >= 3.0.1". Nope. RedHat 8.0 will have gcc-3.1 (maybe even gcc-3.2) and no gcc3 package.

        Handling of incompatible versions of the same software is done ad hoc, without any strictly established and well designed rules. Either the old or the new version gets a number appended to the package name (glib10, kde2, gcc3).

      • As for the BSD Ports system, it has ZERO to offer in this situation despite being a wonderful system. The BSD ports setup pretty much requires source distribution and the target audience for LSB isn't interested in that.
        FreeBSD doesn't have to compile source to download and install a package with it's dependencies. Use pkg_add -r, and you'll get binaries along with their dependencies in binary. I prefer most of the time to use the ports system, however, because I've got a fast CPU so compiling usually is fast enough for me.
    • If they won't do this, I would like to see RedHat improve their system to not gradually degrade into a pile of confused and intensely interdependent RPMs. ~geogeek
    • As the poster above states:
      • There are many front ends such as up2date, urpmi and apt for RPM that do dependency handling. Until a week ago, my Red Hat 7.3 machine has KDE 3.02 and GNOME 2 plus a bunch of other stuff from Freshrpms all fetched from apt.

      • There are things that RPM does better than Dpkg, including more detailed package verification, ghost files, and simpler source rebuilds. There are also things that Dpkg does better than RPM, including suggested/recommended dependencies. Policy issues aren't technical ones and there are many RPM based distributions with policy.


      I think the real chickening out has beeen the acceptance the alien is an OK solution for RPM support.. Alien does not implement the RPM packaging system. It implements CPIO archives, stripping all the `management' facilities of the package. How many Debian users would install large chunks of their system using alien? They wouldn't, because its a hack and not much better than installing tarballs all over your system. Accepting Alien, seems to have been a compromise, and not a good one. If Debian doesn't want to use RPM in its current state, they should make RPM better, not try and get the LSB to let them avoid it.
    • Interesting thread RE comparisons between RPM, apt, ports etc which I have some familiarity with but not enough to argue with the beards. However what I would like to see is some work on how an admin can centralise package distribution to internal users.

      From personal experience, most of these package managers are focused on the end user making the decision to instigate an upgrade, however that is achieved. The execution of the upgrade is also within the hands of the end-user. However consider the scenario where you have a number of open source desktops and you have responsibility for ensuring that your users (a) have access to the applications they need (which will vary from user to user), (b) incorporate upgrades on a mandatory basis based upon criteria that you specify (e.g. security patches, other app patches you decide are required), (c) these applications are available to users wherever they log in, (d) they integrate well with whatever window manager you choose to use.

      Now, I know this is easy to say and represents a lot of work, especially the WM integration (exactly how many WMs are there out there?) but consider from a corporate perspective - it's not going to look to good when you start advocating the current methodologies for obtaining packaged software for desktops when compared with MS Group Policy package distribution, Novell ZENworks, IBM Tivoli ...

      If you're going to review the current approaches to package distribution, and hopefully build an open standard at some point to fit in with LSB, then at least keep the door open for a centralised software distribution mechanisms.

      Aegilops
    • Look, after using Slack, I find RPM obnoxious and much more difficult to track down. The Slack package installer is much better. But one can get around these differences tanks to the -f tag.

      What gets my goat is the location and use of config files. It's very clear on Slack what files handle what and the configs can be handled on the file level. On RedHat or Mandrake, this is inconsistent. Example. If you DON'T boot into X on Mandrake, tell me how to switch the default Window Manager. In slack it's a matter of changing a symbolic link. There are other examples.

      I don't want to start a distro holy war (and there is always one brewing just under the surface), but these differences are not good. A better commercial example is Mandrake vs SuSE. Both have pretty widespread use in the commercial arena, I've used both on commercial projects, but again, the config loacation and use is not consistent.

      I don't know if ALL of these things have been solved by the LSB, but if not, then there is a failing which needs to be resolved...

      /rant

      need beer

  • a system, may it be whatever, needs certifications only when it becomes bloated and looses focus. Soon, we will have these certifications in 42 main classes, and 42 subclasses of each, each with different meaning.

    I believe that the user's free choice is the best standard-making-body it does not matter if you got a certificate or not if your distribution is crap.

    • I believe that the user's free choice is the best standard-making-body it does not matter if you got a certificate or not if your distribution is crap.

      That's great for users. We can and do use whatever the hell we want. If it wasn't intended for that use, someone will come up with the right hack.

      Certification isn't about users. At least, not about current users. Except maybe non-coders like me. It's about companies. IT geeks can now tell their PHBs that it's certified, which will carry a lot of weight. It's an unfortunate situation, but it is the proper response. Linux will seem less of a freestyle, knocked together geek alternative thing, and that's what needs to happen to expand the business market. The desktop market isn't where Linux's growth is going to be for quite some time.

    • Certification has little to do with being bloated. It has to do with compatibility. Compatibility sometimes aids to bloatedness because you have to support both new and old. Look how big XP is vs NT 2000, a good deal of bloat is to get the Win95 kernel stuff working. Even with all that bloat, there is stuff that doesn't work. Microsoft isn't certified, and it can break things as it pleases, sometimes intentionally.

      Linux certification has less to do with forward and reverse compatibility than across distros. Testing's a bitch. Last professional project I did on Linux, we had to support 3 different startup models: Slack 3 and inittab, SVR4, and RedHat SVR4 where they moved the rc?.d directories. (granted this was a long time ago and all may have changed since). Because it's a pain to test for 3 different distros, most folks only do 1, and they might as well do the biggest, and that's RedHat. Slack was dropped, and Mandrake was a one time deal. The group that contracted us said screw these other distros, we'll just support RedHat.

      The reason for certification is to get more software. If I can target one installation file, one file system layout, then I'm more likely to make software for that. The easier it is for me to support you, the more likely I am to do so.

      Yes the user is free to do whatever they want. You could make it where your startup directory isn't /etc/rc{1,2,3,4,5,6}.d but called /MyReallyCoolStartupDir/runlevel/{un,deux, trois...}. I doubt if most software would work though. If you want to make your mark on your install, go ahead. There's plenty of stuff you can do. There's just some stuff you should leave where others can find it.
      • To be tacky and reply to my own post...

        The other fun thing was RedHat kernel by default had ip masquerading on. The software had a listen port, 61000 IIRC. IP masqueradig kept all ports 50000 to 65000 I think. So we had two choices...
        Make folks recompile their kernel to support this software.
        Change the port and have folks be incompatible with others.
        Change the port and have UI to change which port to coneect to.

        We felt nobody would (or should) recompile to get user level softwrae wotking, so we picked "use different port, but show a hidden UI pref if you wanted to talk to other machines", figuring most folks would want to check their own box only, and if they wanted to check other machines, they'd have to work.

        Mind you this was only in RedHat. If there was a standard it would be easier. But no, now we had to have a UI for this, have soem confusing things about "ports" and "IP masquerading". It made it difficult to support Linux. There were major differences between Slack and RedHat because of this. This all led to them dropping Slack, then (after they dropped us) dropping UNIX support altogether. The Windows world is much easier to support. There's fewer variations. This is one of the reasons why you can get whatever software you want for windows.
    • > a system, may it be whatever, needs
      > certifications only when it becomes bloated and
      > looses focus.
      Linux' distributions are getting bigger all the time and have many vendor specific tools - as such it has lost some of the tight focus it had in the early days when there were few distributions.

      Certification is neccessary to satisfy the requirements of some software producers and users. A software producer needs to know what clib to compile to, what package system to deliver, what is neccessary to read the help files of the app etc... The LSB addresses such issues and more.

      RPM may not be perfect in some folks' eyes but it is used by many distributions.

      The LSB provides minimum functionality standards! There is nothing to stop others from building on them. Who knows, maybe deb will get even more popular and the standard will then adopt it instead of rpm?

      Heck, I like jar files with Installshield for Java in them. I also like tar.gz/Z/bz2 files and shell scripts with embedded install files in em. I personally don't care as long as they work.

      > I believe that the user's free choice is the
      > best standard-making-body it does not matter if
      > you got a certificate or not if your
      > distribution is crap.
      What is wrong with having your cake and eating it too? Why not have these minimum standards to satisfy the commercial software producers AND still keep the ability to innovate with new technologies?

      Example:
      In the USA, most electrical sockets have the same format. Two vertical slots sometimes with a ground and maybe a different size for one of the slots. You can go out and buy a commercial appliance and almost always be able to plug it in. The voltage present on the socket is approx 110-120VAC which is also good.

      Now, imagine that you couldn't depend on the voltage or the configuration of the socket? Life would be needlessly more difficult. Get it?

      Remember, you are free to fsck with your power socket as much as you want but you will have to live with your modifications. Don't expect everyone else to feel the same way you do.

      Anyway, peace.
    • "I believe that the user's free choice is the best standard-making-body it does not matter if you got a certificate or not if your distribution is crap."

      Well, as a programmer, I would prefer to write code for a distribution that contains standard lib versions etc. I don't see 42 main classes of standards with 42 subclasses of each coming down the pike.

      I can see products coming out for Linux that have "This software runs on LSB Compliant platforms" labels on the packaging.
    • Hey, I am too much a coward not to admit at this point, that the previous comment by me was crafted just as provocation to get good reasons why we need this certificate. Now, we got plenty of them :) Thanks! :)))

  • Versions? (Score:2, Interesting)

    by anakog ( 448790 )
    The article forgot to mention which versions of these distributions got certified.

    I am curious in particular about Red Hat's distro. I am sure that 8.0 will be LSB compliant but does anyone know about 7.3?

  • LSB vs FHS (Score:2, Interesting)

    by peterpi ( 585134 )
    Forgive my ignorance, but how does the LSB relate to the Filesystem Hierachy Standard [pathname.com]. Is it a replacement?
  • I'm all for a standard here, but MDK? How is MDK compliant with something like this:

    ~/.kde/share/applnk-mdk-simplified/.hidden

    for a menu item location. Are they all using the MDK extension now? Unlikley. Is MDK changing that? Unlikley since the 8.2 release was tagged as "Standards Compliant" somehow.

    Don't get me wrong I like MDK, I'm on a 8.2 (heavily upgraded) box typing this, but "Standards Compliant"? No way.

    • Re:MDK? (Score:2, Informative)

      by tg_schlacht ( 570380 )
      IANALE - I am not a Linux expert. (But I ain-t Joe Six-Pack either.)

      From my reading of the LSB it seems to address base level system issues:

      - Having at least the minimum standard set of base, utility, and graphic libraries.

      - Having at least the minimum standard set of system commands.

      - Having standard init script actions, comments.

      I don't see anything in the LSB regarding the location of window manager configuration files. Maybe they will add something regarding that to the standard in the future.

      For now the focus of the LSB seems to be standardizing distros so that applications will install to standard locations, can expect standard libraries to exist, and can expect that system configuration information will be the same across distros.

  • But it is interesting to note that the three standards all have soimething in common ...

    1. Built on Red Hat
    2. Commercially sold and focused distros (sure you can download them all but Suse is some 7gb of packages with no ISO and to purchase personal in AU costs $175...) they are the 3 distros which appear most focused on packaged box products
    3. ALl 3 like to see themselves as leaders in the open source movement

    This comes to mind after the self annoucement on Mandrakes site that they were on of the standard distibutions of linux.... and they are part of the standards groups as well...

    Come on - the fact is that the three distros are built on one base - Red Hat. They use the same packages in most case and in my mind are pretty much the same thing.

    If LSB wants to be a serious thing instead of a back slapping software tick then they need a diverse Standard - the best GNU Linux at the moment for development and use from all i have tried is Debian yet its not a standard... What about Slackware ?...

    In short doing a bit of investigating of the members of the LSB groups and the supposed standard bearers may make some things clear... i did - and the terms of the standards make it clear that rather than the 3 mentioned distibutions being the best the fact that they were the 3 who submitted and that they all use the one base and RPM seems to indicate simply that Red Hat is an industry standard..something we all knew anyway.
    • > But it is interesting to note that the three standards all have
      > soimething in common ...
      >
      > 1. Built on Red Hat

      Sorry but Mandrake isn't built on Red Hat.
  • so, how does this relate to base development libraries? it's a major PITA to d/l a cool project to see how the source works, only to have ./configure bomb out 7/8ths of the way through.
  • Unless it becomes possible to manually update your rpm database so that when you later use rpm it will realize you have some package that you may have grabbed as a tarball and compiled from source rather than used the rpm for. You can't just get away with using --force in this case because you may _WANT_ it to check dependancies, just that for certain packages already on your system, you may have a better idea of what's actually on your computer than rpm does. I know I did when I lost my RPM database, with no way to rebuild it.

    (rant concluded)

    • Have you read all the other comments? deb != apt && rpm != no auto dependency downloading! [sourceforge.net]

Slashdot Top Deals

Kiss your keyboard goodbye!

Close