Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Linux

How the LSB Keeps Linux One Big Happy Family 171

Posted by Soulskill from the behave-or-i'll-turn-this-distro-around-right-now dept.
blackbearnh writes "The Linux Standard Base is the grand attempt to create a binary-level interface that application developers can use to create software which will run on any distribution of Linux. Theodore Tso, who helps maintain the LSB, talked recently with O'Reilly News about what the LSB does behind the scenes, how it benefits ISVs and end users, and what the greatest challenges left on the plate are. 'One of the most vexing problems has been on the desktop where the Open Source community has been developing new desktop libraries faster than we can standardize them. And also ISVs want to use those latest desktop libraries even though they may not be stable yet and in some ways that's sort of us being a victim of our own success. The LSB desktop has been getting better and better and despite all the jokes that for every year since I don't know probably five years ago, every year has been promoted as the year of the Linux desktop. The fact of the matter is the Linux desktop has been making gains very, very quickly but sometimes as a result of that some of the bleeding edge interfaces for the Linux desktop haven't been as stable as say the C library. And so it's been challenging for ISVs because they want to actually ship products that will work across a wide range of Linux distributions and this is one of the places where the Linux upstream sources haven't stabilized themselves.'"
This discussion has been archived. No new comments can be posted.

How the LSB Keeps Linux One Big Happy Family More

How the LSB Keeps Linux One Big Happy Family

Comments Filter:

  • Hmmm.... (Score:5, Insightful)

    by Otter ( 3800 ) on Monday September 22, 2008 @04:29PM (#25111029) Journal
    I don't think I've even heard the LSB mentioned in the last five years. (Most of the distro-related squabbling and fretting died down after the number of meaningful distros contracted from the days of Corel Linux boxes at the aisle ends in CompUSA.) If they've been quietly doing something useful all this time, kudos for them!

    • Re: (Score:3, Funny)

      by Jeremiah Cornelius ( 137 ) *

      Proust on a poodle!

      Yeah. Doesn't the this have the nostalgic ring of soft, chewy, John "Maddog" Hall on the Slashdot front page, and crunchy goatse.cx [googlegoatse.com] on the inside?

    • I don't think I've even heard the LSB mentioned in the last five years.

      That, and arguably the largest distribution (Ubuntu) doesn't have any LSB modules available:

      tycho@mittens:~$ lsb_release -a
      No LSB modules are available.
      Distributor ID: Ubuntu
      Description: Ubuntu 8.04.1
      Release: 8.04
      Codename: hardy

      I think this is a good idea, but for a project that has been around for 10 years, it doesn't have the highest adoption rate. I only just read about it the other day on a mailing list (not that I'm

      • Re:Hmmm.... (Score:5, Interesting)

        by cyphercell ( 843398 ) on Monday September 22, 2008 @05:25PM (#25111669) Homepage Journal
        The LSB standardized on RPM. This was a rather contentious blow to distros that use a different packaging system. I *think* Debian achieved compliance by including the Alien package manager, but they specifically do not claim compliance.

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

          by Yfrwlf ( 998822 ) on Tuesday September 23, 2008 @03:14AM (#25117041)
          And that's one of the biggest problems right now with Linux is packaging, and the LSB is aware of it, and they're trying to do something about it [linuxfoundation.org]. Whether this is the best solution, I don't know, but any solution right now is better than nothing. I'm just appalled that ODF has such a march behind it, yet having at least one intelligent (upgradeable, removable, integrated with package manager) package format work across distros (all or most all existing managers made compatible with the format) gets completely neglected.

          It's ironic, because ultimately access to software so you can get done want you want to get done is the basis for the open source movement. Everyone gets all up in arms about "proprietary software", yet no one cares about proprietary distros and those issues with software lock-in. Why should I have to upgrade or change my LINUX OS just so I can use some LINUX software? Of course no one should. Or changing to a newer distro version just to have access to some drivers? That's total crap. The kernel was designed to have modules to allow it to be more modular, but obviously it's not modular enough yet, and/or because of the packaging mess, you just don't see driver packages shared out and such like you should.

          Linux won't be as successful until users start being able to have easier and more flexible access to software they want, so I wish the LSB luck in bringing order to that chaos since no other groups have really stepped up to address interoperability issues like they have that I know of besides the Freedesktop.org group.

          • Re: (Score:2)

            by jbolden ( 176878 )

            This argument has been on /. for the last dozen years. The Microsoft / Sun model of software distribution is:
            software creater -> reseller / OEM -> customer which allows for commerce.
            The Linux model is:
            creator -> distribution -> customer which allows for an integrated and functional system.
            There is no reason to bring to free software a distribution model intended for software sales.

      • [CronoCloud@mideel ~]$ lsb_release -a
        LSB Version: :core-3.1-noarch:core-3.1-ppc32:graphics-3.1-noarch:graphics-3.1-ppc32
        Distributor ID: YellowDog
        Description: Yellow Dog Linux release 6.0 (Pyxis)
        Release: 6.0
        Codename: Pyxis

        YDL6 is based on CentOS and thusly RHEL so that's why it's got LSB 3.1 compliance. And yes, mideel is a PS3. I chose YDL because my first Linux was the PS2's funky Kondara-ized Red Hat 6 and I wanted something Redhatty but with reasonably good online support via message boards and

      • Re:Hmmm.... (Score:4, Informative)

        by Anonymous Coward on Monday September 22, 2008 @07:48PM (#25113277)

        The truth is ubuntu doesn't have any LSB modules available by default. BUT, don't be lazy, open Synaptic Package manager, search for lsb package, select it for install and than:

        petar@aurora:~$ lsb_release -a
        LSB Version: core-2.0-ia32:core-3.0-ia32:core-3.1-ia32:core-3.2-ia32:core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:core-3.2-noarch:cxx-2.0-ia32:cxx-3.0-ia32:cxx-3.1-ia32:cxx-3.2-ia32:cxx-2.0-noarch:cxx-3.0-noarch:cxx-3.1-noarch:cxx-3.2-noarch:desktop-3.1-ia32:desktop-3.2-ia32:desktop-3.1-noarch:desktop-3.2-noarch:graphics-2.0-ia32:graphics-3.0-ia32:graphics-3.1-ia32:graphics-3.2-ia32:graphics-2.0-noarch:graphics-3.0-noarch:graphics-3.1-noarch:graphics-3.2-noarch:languages-3.2-ia32:languages-3.2-noarch:multimedia-3.2-ia32:multimedia-3.2-noarch:printing-3.2-ia32:printing-3.2-noarch
        Distributor ID: Ubuntu
        Description: Ubuntu 8.04.1
        Release: 8.04
        Codename: hardy

        So next time, before writing something, check your facts first.

      • jldugger@jldugger:~ $ lsb_release -a
        LSB Version: core-2.0-ia32:core-3.0-ia32:core-3.1-ia32:core-3.2-ia32:core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:core-3.2-noarch:cxx-2.0-ia32:cxx-3.0-ia32:cxx-3.1-ia32:cxx-3.2-ia32:cxx-2.0-noarch:cxx-3.0-noarch:cxx-3.1-noarch:cxx-3.2-noarch:desktop-3.1-ia32:desktop-3.2-ia32:desktop-3.1-noarch:desktop-3.2-noarch:graphics-2.0-ia32:graphics-3.0-ia32:graphics-3.1-ia32:graphics-3.2-ia32:graphics-2.0-noarch:graphics-3.0-noarch:graphics-3.1-noarch:graphics-3.2-noarch:lang

  • This should be interesting... (Score:5, Interesting)

    by EvilIntelligence ( 1339913 ) on Monday September 22, 2008 @04:32PM (#25111073)
    I'm very curious to see where this goes. The biggest issue I see is with adoption. There are so many distros out there, each with their own purpose and personality, and each one is focused on developing functionality first and foremost. I think it will be hard to convince all of them to pause that and shift their entire back end onto a standardized framework. Plus, the biggest strength in Linux is its diversity and flexibility. Adding such a standardized base might kill some of that flexibility. As I said, we'll see where it goes...

    • Re:This should be interesting... (Score:4, Informative)

      by Otter ( 3800 ) on Monday September 22, 2008 @04:39PM (#25111167) Journal
      FYI, the LSB started in 1998, the first Year Of Linux On The Desktop.

    • Re:This should be interesting... (Score:4, Interesting)

      by jedidiah ( 1196 ) on Monday September 22, 2008 @04:39PM (#25111171) Homepage

      Yet none of this stops Oracle RAC from installing on
      Debian or Ubuntu if you are stubborn enough to lie to
      the installation GUI.

      If the LSB makes it easier for a Loki installer to
      "work everywhere" then it matters. Otherwise it
      really isn't that meaningful. A lot of the stuff
      that people tend to complain about really doesn't
      matter so much in the end.

      Although better alien package handling all around
      could be beneficial to everyone.

      • Re: (Score:2, Flamebait)

        by turbidostato ( 878842 )

        "Yet none of this stops Oracle RAC from installing on
        Debian or Ubuntu"

        True. Yet no ammount of LSB stops Oracle to only certify this or that platform (like RHEL 4u2 or Ubuntu Strange Scarab, or SUSE 10 or whatever) instead of, say, LSB 2.0.

        So, the LSB is mainly aimed at attracting privative software like Oracle to Linux (who else need guaranteed ABI compatibility when you can recompile?), no wonder so many distributions don't care so much (especially when the "middle ground" that it's the basis of the stand

        • The first step would be dumping .rpm. (Score:5, Insightful)

          by khasim ( 1285 ) <brandioch.conner@gmail.com> on Monday September 22, 2008 @05:23PM (#25111649)

          I don't care if their "standard" only requires a "sub-set" of the RPM format. Just dump it.

          Write the specifications for a .lsb install format.

          Then encourage the other package systems to include your format in their systems. I should be able to apt-get install foo.lsb and have it SEEMLESSLY integrate with Debian's package management system. And the same file with rpm -i foo.lsb and so forth.

          There, the first problem is solved. People can easily identify the LSB packages and install / remove / upgrade / back-rev / whatever them.

          And they would be completely platform NEUTRAL which SHOULD have been their first goal.

          So, now that you can install their packages ... they need to start identifying which libraries and such are required by foo. Is there any reason that those libraries would not also be distributed as .lsb packages? Meta packages if necessary?

          And don't even get me started on where Apache gets installed vs where they tell you a commercial web server should be installed. Apps is apps. It doesn't matter whether the distribution shipped it, you built it from source or you bought it from an ISV. Unless you're the LSB. Then it matters.

          • Re: (Score:2)

            by amorsen ( 7485 )

            And they would be completely platform NEUTRAL which SHOULD have been their first goal.

            RPM is a cpio-archive with a header. DEB is a tar-archive with a header. Why should LSB invent yet another tar-like format with a header?

        • Re: (Score:3, Insightful)

          by Shulai ( 34423 )

          > So, the LSB is mainly aimed at attracting privative software like Oracle to Linux (who else need guaranteed ABI compatibility when you can recompile?),

          At this time I'm convinced that having to rely on distributions (or worse, 3rd party distro specific packages) for software is stupid. I'll be happy when I'll be able to install any binary package, free or privative, with source available or not, not being constrained by using distribution X or using the version and tweaks distro X provides for that part

          • What I like most about linux (or miss on my windows box) is the centralized software management that a distribution provides. Just compare a simple 'emerge -u world' (and a few hours wait ;-)) or 'apt-get upgrade' with Adobe Updater, Norton Updater, RealPlayer-Updater (and EVERY OTHER SOFTWARE under Win) either cluttering your taskbar with update-manager-processes or your screen with "do you want to search for upgrades now".

          • "just providing an easy to install package just as they do for Windows"

            I always find awesome that kind of stupidness and how it can be so prevalent among windows zealots.

            What is the "multiplatformness" of Windows? Zero, nada. You can seemlessly install binary packages designed for Windows on Windows... because, heck, it's Windows! Installing Debian-designed packages on Debian is even easier than installing Windows-designed packages on Windows. On the other hand, installing Debian-designed packages on Win

    • Plus, the biggest strength in Linux is its diversity and flexibility. Adding such a standardized base might kill some of that flexibility.

      Each distro can be as flexible as it wants to be within it's own native package manager's format. However _in_addition_ to that format, they would ideally all support a lowest common denominator. That way, software houses could package for that LCD and have it work on any distro.

      Just this week I am fighting with LabView, trying different versions of OpenSuse, Mandriva, and Ubuntu trying to get it to install along with daqmx. What a pain! Projects like the LSB attempt to make this as easy as with Windows.

      • Re: (Score:2)

        by jbolden ( 176878 )

        Under the Linux model end users aren't supposed to be doing this. Labview should be distributed from the distribution not directly to the customer. The problem is Labview doesn't want to offer their software the Linux way, they want to do it the Windows way and that doesn't work so well.

  • Source code (Score:4, Insightful)

    by TehZorroness ( 1104427 ) on Monday September 22, 2008 @04:43PM (#25111215)

    Source already seems to be an acceptable de-facto standard for distributing programs in the least OS-specific way. Let's stick to that :)

    • Yummie coincidence: I've got a box in arms reach right now make installworld'ing.

      While there are numerous benefits to using the source code directly rather pre-compiled packages, there is good reason to standardize pre-compiled package systems. Most prominently, there are cases where compile time / cpu cycles really shouldn't be wasted unnecessarily.

    • Re: (Score:3, Insightful)

      by cerberusss ( 660701 )

      You're kidding, right? Or at least trolling?

      Ever tried to upgrade or remove a package compiled from source? Even if 'make uninstall' was provided in the first place, it's now gone when you removed the original source.

    • Re: (Score:3, Insightful)

      by Excelsior ( 164338 )

      Wow, insightful? Suggesting source is the standard way is just awful. Source doesn't resolve its own dependencies. Source can result in a several day install. Source isn't appropriate at all for underpowered devices and devices with very limited drive space, such as a Zaurus or an Asus EEE (and why shouldn't small devices be able to participate in a standard?). Source distribution is extremely network inefficient compared to binaries. Source has no guarantee of building on your system (trust me, I ran

  • Yes, they all happily ignore it (Score:3, Funny)

    by harlows_monkeys ( 106428 ) on Monday September 22, 2008 @04:45PM (#25111245) Homepage

    LSB brings the distros all together--it gives them something in common to ignore.

  • LSB is not enough (Score:3, Informative)

    by slashdotlurker ( 1113853 ) on Monday September 22, 2008 @04:48PM (#25111291)
    The kernel API also needs to be stable (or so do vendors like National Instruments think).

    • If NI are writing kernel-level drivers, then perhaps.

      However, 99% of "normal" software shouldn't need to access the kernel directly. Even at that, modules seem to remain pretty stable. If NVidia and ATI can keep drivers for their hardware relatively stable, NI should be able to do the same, considering that their hardware appears considerably less complex. Similarly, one would think that a large percentage of NI's userbase would have a pretty strong interest in a Linux version.

      • Yes, they are. They need to support certain hardware beneath their own hardware abstraction layer (KAL/VISA).

      • Re: (Score:2)

        by Klivian ( 850755 )
        And NI are absolutely writing kernel-level drivers, since they in addition to software for measurement and automation they offers a huge number of different hardware. So to support all their measurement, dataloging and automation hardware, they have to write drivers for PXI (PCI eXtensions for Instrumentation), VXI, PXI- and PCI-based modular instruments and GPIB bus controllers. Their Linux offering have been rapidly growing for years, so obviously their userbase already have a strong interest in Linux.
        E

        • Re: (Score:3, Interesting)

          by radarsat1 ( 786772 )

          obviously their userbase already have a strong interest in Linux.

          If so, they sure are ignoring us. The last release of their Linux driver package (NIDAQ) was in 2005 [ni.com]. Installing it on a recent version of Linux proved practically impossible. Finally after a few days of installing and reinstalling different distros I got it working on a 2-year-old version of SuSE. But basically determined that outside of personal use, this is totally impossible to expect customers to use if we are to integrate an NI board

          • Just to clarify... don't get me wrong, I am actually really happy that they support Linux at all and generally seem happy working with "non-standard" operating systems and making their register-level descriptions open.

            This is a big improvement over other manufacturers. We had one data acquisition manufacturer who made us sign an NDA just so we could write a lean driver. (Which was significantly faster than the one they shipped.) This made distributing to customers particularly difficult since most of our

  • It would make my organization... (Score:5, Insightful)

    by HogGeek ( 456673 ) on Monday September 22, 2008 @04:56PM (#25111363)

    ... A lot happier.

    I'm really tired of having companies come in with some product that we are "dictated" to use (yes, I work for a US government organization), only to learn that my chosen linux platform isn't supported...

    That is a battle I would love to sweep under the carpet with, "why don't you support the LSB?"

  • Binary compatibility? (Score:5, Insightful)

    by Karellen ( 104380 ) on Monday September 22, 2008 @05:18PM (#25111609) Homepage

    "...to create an x86-32 (and maybe, if you're really lucky, x86-64) binary-level interface that application developers can use..."

    There, fixed that for you.

    Best of luck getting your binary package to run on Linux/PPC, Linux/ARM, Linux/Alpha, Linux/Sparc, etc...

    If you want your software to run on multiple Linxen, you need to make it open and let the distros compile it and build the packages. That's it.

    • Bollocks.

      s/Linxen/Linuxen/

    • Re: (Score:3, Funny)

      by shish ( 588640 )

      If you want your software to run on multiple Linxen, you need to make it open and let the distros compile it and build the packages. That's it.

      Or use Java :-)

      *ducks*

      • Re: (Score:2)

        by amorsen ( 7485 )

        Or use Java :-)

        That way you at least put all distributions on equal footing: None of them will run your program.

        If only the "Write once, debug everywhere" joke was true. It would be a vast improvement on the current state of Java.

  • Just guessing... (Score:3, Funny)

    by fahrbot-bot ( 874524 ) on Monday September 22, 2008 @05:28PM (#25111695)

    How the LSB Keeps Linux One Big Happy Family.

    Bender: Blackjack and hookers?
    (On second thought, forget the Blackjack!)

  • I honestly don't get the need for LSB. Perhaps 10 years ago when we still had problems with RPM, but not today. Most people will never need to download software that isn't in the Ubuntu (or insert favorite distro here) repositories. And most of the ones that aren't in the repos usually either A) Are minor software projects that very few people use B) Have .deb and .rpm files available for download C) Maintain a private repository to easily download software or D) have a binary that you can just click and it

    • Re:I don't get this... (Score:4, Insightful)

      by vidarh ( 309115 ) <vidar@hokstad.com> on Monday September 22, 2008 @06:06PM (#25112081) Homepage Journal
      Try installing that RPM on 10 different distros or versions of distros, and tell me again we don't still have problems.

      I've dealt with dependency problems far more than I'd care to - often even being able to rebuild a source RPM on a newer version of the same distro turns into a nightmare, much less trying to massage a binary RPM into place.

    • The problem isn't within the distro itself. Certainly all the RPM's in Mandriva's repositories will install just fine on Mandriva systems. And Fedora's on Fedora systems. But when you try to install a Mandriva one on Fedora, or a SuSe on Ubuntu... then the problems begin. Not just with dependencies, but with where the files are to be installed on the system.

      But the real need for LSB really has nothing to do with a distro's own native packages, it is about cross distro development, distribution, and insta

    • Re:I don't get this... (Score:5, Insightful)

      by SL Baur ( 19540 ) <steve@xemacs.org> on Monday September 22, 2008 @07:11PM (#25112821) Homepage Journal

      I honestly don't get the need for LSB. Perhaps 10 years ago when we still had problems with RPM, but not today. Most people will never need to download software that isn't in the Ubuntu (or insert favorite distro here) repositories.

      LSB specified file system layout when I was in the business about 10 years ago (I shared in the pain of converting Turbolinux from /usr/man -> /usr/share/man, etc. etc.).

      Library version numbers are still important. C++ binaries are notoriously sensitive to gcc version and we must be able to support truly alien (ie non-distro software).

      We will have truly arrived as a desktop O/S when it is possible to buy from Blizzard a World-of-Warcraft.tar.gz tarball that will Just Plain Work no matter which Linux distro we are using. Never mind packaging issues, though it would be nice to have RPMs of WoW.

      • Re: (Score:3, Interesting)

        by bcrowell ( 177657 )

        Most people will never need to download software that isn't in the Ubuntu (or insert favorite distro here) repositories.

        We will have truly arrived as a desktop O/S when it is possible to buy from Blizzard a World-of-Warcraft.tar.gz tarball that will Just Plain Work no matter which Linux distro we are using.

        The GP is basically right, even though he's technically wrong. He's technically wrong, because theoretically people want to run proprietary as well as free software on Linux, and, e.g., Ubuntu isn't n

    • Re: (Score:3, Insightful)

      by sentientbrendan ( 316150 )

      >Most people will never need to download software that isn't in the Ubuntu (or insert favorite distro here)

      People who are using Linux to make money almost invariably use it in conjunction with proprietary software, like databases, custom apps, etc. Until recently, you needed to download Sun Java binaries for any serious Java development. Also, some of us are *writing* proprietary software for Linux.

      But sure, if all you ever do with Linux is write a dinky php home page that you serve out of your mom's bas

    • Re: (Score:3, Insightful)

      by RegularFry ( 137639 )

      Most people will never need to download software that isn't in the Ubuntu (or insert favorite distro here) repositories.

      This is one of those maxims that sounds right, but inevitably isn't in practice. It's truer to say that all people will mostly only need software that's in the repositories. A stunning array of functionality is covered, but most people have at least one package they need that isn't. That can either be because it's proprietary (like Skype), or because it's too obscure, or because the version that is included is out of date. I've personally had all these problems, and I can't think of anyone I know who ha

  • Barriers to adoption (Score:5, Insightful)

    by camperdave ( 969942 ) on Monday September 22, 2008 @05:45PM (#25111883) Journal
    One of the main problems I see with adopting linux as a standard is that the distros vary too much from each other. One uses init.d, another event.d, one uses Gnome, another KDE, one uses LVM, another doesn't. I can see why companies don't want to support linux - there are too many variables. Linux is a mess.

    I think things would be a lot easier if there was a minimum support standard that all distros held to. ie, a standard desktop, a standard filesystem hierarchy, a standard package manager, etc. I don't mean that these are the ONLY desktop, package manager etc, just that on supported distros they are guaranteed to be there.

    • Re:Barriers to adoption (Score:5, Insightful)

      by vidarh ( 309115 ) <vidar@hokstad.com> on Monday September 22, 2008 @06:07PM (#25112093) Homepage Journal
      Gee, you've just described the LSB.

    • The developers don't have to care about desktops, they just have to use the xdg utils for menu entries etc.
      Application developers don't have to care wether the system is using LVM or not.
      The package manager situation is being alleviated with PackageKit, which all major distributions will support.

    • >I think things would be a lot easier if there was a minimum support standard that all distros held to. ie, a standard desktop, a standard filesystem hierarchy, a standard package manager, etc. I don't mean that these are the ONLY desktop, package manager etc, just that on supported distros they are guaranteed to be there.

      That's exactly what the LSB is (except for the standard desktop part).

      The problem is that distro makers only give the LSB lip service, and do the bare minimum to get supported, because

    • ...or have the different desktops all support a common subset of functions and call that OpenDesktop or dbus (IIRC thats what those two are for)

  • it would be nice if they could do something about unifying the audio subsystem on linux

    openal esd pulseaudio etc etc

    its a mess

  • Java... (Score:4, Insightful)

    by NullProg ( 70833 ) on Monday September 22, 2008 @08:54PM (#25113999) Homepage Journal

    Because I've given up on all the dual APIs with Gtk/Qt/Wx/GNUStep. I don't care anymore. Life is to short. Code with what works today.

    A desktop Java program under Linux works just as fast as a Qt/Gtk based one. Java has insignificant load times on my minimal memory PII test platform compared against the Qt/Gtk libraries running under Window Maker (A simple Dialog program to read /proc). If I need to, I can go JNI. I'm tired of trying to author different Qt/Gtk wrappers for different versions. Enough said. All my programs work fine under the JVM for Mac/Linux/Windows.

    Thank You SUN for Java 5 and 6. A much better VM platform than 10 years ago. Thanks to JavaME, I can run my programs on my Cell phone or my embedded Linux box.

    DISCLAIMER: As a programmer, I can't publish load times/Performance issues with any product from Microsoft against any other. I will get sued for posting benchmarking results that show Microsoft Windows based systems, performance wise, SUCK compared to BSD/Linux systems on the same box.

    My opinion and it doesn't matter. I reserve the right to be wrong.

    Enjoy,

    • Re: (Score:2)

      by dargaud ( 518470 )

      DISCLAIMER: As a programmer, I can't publish load times/Performance issues with any product from Microsoft against any other. I will get sued for posting benchmarking results that show Microsoft Windows based systems, performance wise, SUCK compared to BSD/Linux systems on the same box.

      Hmmm. And on what grounds would they sue ? Even if you publish completely imaginary 'benchmarks', that would still fall under the 1st amendment (assuming you are in the US).

      • Re: (Score:2)

        by NullProg ( 70833 )

        Hmmm. And on what grounds would they sue ? Even if you publish completely imaginary 'benchmarks', that would still fall under the 1st amendment (assuming you are in the US).

        I dunno, every EULA states you violate their virginity or something by benchmarking.

        This is a company that sued Mike Rowe Soft. http://www.cnn.com/2004/TECH/internet/01/19/offbeat.mike.rowe.soft.ap/index.html [cnn.com]
        Why wouldn't they start a lawsuit against me before public opinion changed their minds?

        I'm not rich enough to afford a team of la

  • In spite of SCO's reputation regarding Linux, it is a little-known fact that Darl McBride is a big support of the Linux Standard Base: http://ir.sco.com/releasedetail.cfm?ReleaseID=91330 [sco.com]>

    SCO and Mandrakesoft Achieve LSB Certification

    "This is an important milestone for SCO," said Darl McBride, president and CEO of The SCO Group. "SCO is very dedicated to the development and promotion of standards. We see standards adherence as central to the growth and progression of the Linux industry, and are committed

  • Propaganda (Score:4, Interesting)

    by JonSimons ( 1026038 ) on Monday September 22, 2008 @10:08PM (#25114935)
    Read what Ulrich Drepper thinks of the LSB here: http://udrepper.livejournal.com/8511.html [livejournal.com].

  • Are they still insisting on RPM, and acting surprised when the adoption rate is so low?

    • Re: (Score:2)

      by amorsen ( 7485 )

      Why does it matter which particular tar-like-format+header they use?

      • Why does it matter which particular tar-like-format+header they use?

        At the time when LSB was being heavily promoted initially (years and years ago) there was no clear leader (in terms of technical merit) in the packaging format arena, and worse, each of the leaders was somewhat flawed. Different distros used different formats for vastly different reasons. This was not an area in which they should have nailed things down to a single format as it would alienate too many distros. They did, and it did.

        I could g

        • Re: (Score:2)

          by amorsen ( 7485 )

          - No easy way to get the contents of an rpm out. The cpio tools at the time kept crashing randomly. I'd never even heard of cpio at the time. Why use that format?

          Because it's actually a standard, whereas tar is a bunch of different flavours (most of them very limited). Yes, cpio has a crap interface, but the archive format is excellent. pax reads it. Someone really should add support for it to tar.

          - An assumption that you'll be running build scripts as root. What sort of thought process led to that?

          There is no requirement that rpmbuild must be used to generate the rpm. It's just a cpio-archive with a header.

          - The RPM 4 upgrade RPM from Redhat, packaged in RPM 4 format. Think about that one for a while.

          That has nothing to do with the format.

          If you haven't had a play with rpmbuild, I suggest doing so. It's probably moved on since I last used it though, so perhaps they've cleaned up their act.

          I've packaged software for my own use since Red Hat 6 at least.

          • Combining what you've said, and I've said, we have RPM as using a poor, not well-supported interface, the official tools (rpmbuild) perhaps not being the best for the job, and the people behind the format historically not doing the best job to use or support it- we probably disagree on the relevance of the last point though. There's also the build-as-root issue I mentioned too.

            Might just be me, but that really doesn't seem much of an endorsement for RPM. ;)

            If you've worked with RPM since Redhat 6 then there

            • Re: (Score:2)

              by amorsen ( 7485 )

              In fact, with this vintage you would have experienced the RPM 3->4 fiasco first-hand.

              I don't recall it. I probably did rpm2cpio|cpio -I.

              And anyway, RPM isn't my baby. I just think it's silly that .deb is thought of as such a superiour format, when in fact the archive format is worse and the header is practically identical. It's dead easy to generate both formats without using the official tools.

              • I don't have too much to offer for debs either, I have had far less exposure to them. My knowledge on them was based mostly on other people's technical takes on it at the time, and from the sounds of it, neither deb nor RPM were really a clear leader. My original assertion probably came off as anti-RPM (and that is true, to a degree, due to my negative experiences with it), but my main focus was really on saying that there was no clear leader at the time, and each tool had advantages over the other, so stan

Slashdot Top Deals

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall

Close