Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×

Latest Linux Standards Base Gets Vendor Support 96

Posted by ScuttleMonkey from the friendlier-tux dept.
Neopallium writes to tell us that in a recent announcement at the Desktop Linux Summit the Free Standards Group reports fourteen of the leading Linux vendors have pledged support for the newest release of the Linux Standards Base. From the article: "'The Release of LSB 3.1 is another milestone achieved by the industry and the Open Source Community that delivers ever increasing value to customers,' said Reza Rooholamini, director of enterprise solutions engineering at Dell. 'It enables further uniformity and standardization across applications and distributions that allows quicker deployment of Linux solutions with higher levels of quality.'"
This discussion has been archived. No new comments can be posted.

Latest Linux Standards Base Gets Vendor Support More

Latest Linux Standards Base Gets Vendor Support

Comments Filter:

  • Dear ScuttleMonkey, (Score:5, Funny)

    by Anonymous Coward on Tuesday April 25, 2006 @05:07PM (#15200244)
    You may remember me, I am old friend. Please don't be a stranger.

    Sincerely,

    Mr. Comma

    • Re:Dear ScuttleMonkey, (Score:2, Insightful)

      by mmd ( 8484 )
      Dear Mr. Comma, your own commacentric biases may have blinded you to the fact that a semicolon is called for here:

      You may remember me[;] I am [an] old friend.

      Though the Comma family may be a fan of the Comma Splice, most consider it poor form.
  • "LSB is not to be taken internally lest you wear the robes of Richard Stallman."

  • Interesting Version Number... 3.1 (Score:5, Funny)

    by Chordonblue ( 585047 ) on Tuesday April 25, 2006 @05:10PM (#15200273) Journal
    Soooo... 3.1. The first usable version of Windows was 3.1 also. Coincidence?!

    Maybe this WILL be the year Linux arrives on the desktop!

  • Never mind the Linux vendors (Score:4, Insightful)

    by overshoot ( 39700 ) on Tuesday April 25, 2006 @05:13PM (#15200305)
    I want to know when we'll get LSB support from the application vendors.

    No matter what the roadmap [edac.org] from the EDA Consortium says, too freaking many of the tools I use at $WORK refuse to run on anything other than Red Hat 7.2 (I kid you not!)

    And, yes, they actually check /etc/redhat-release

    • Yeah, I've seen the same thing. This is the whole purpose of the LSB. If application developers won't support it, the whole project is pointless.
    • I had a thought yesterday that Xen virtualisation might sort a lot of these problems out. Couldn't a program include its own version of linux to be run under Xen, thus stopping the, "to many distro's" problem? Admittedly it wouldn't be good to be running all your applications in virtual windows, but games would be good.
      • There is a technical term for this:

        Swatting a fly with a sledgehammer.

        On top of the fact that virtualization has numerous problems with accelerated graphics while you're suggesting games for this purpose; I can't believe you're posting this seriously.

        There are a lot of people that think having to have a separate library to run a program (gtk vs QT et al) is bloat. Now we're thinking about a separate OS for each App? Ack.
    • I want to know when we'll get LSB support from the application vendors.

      We won't. That's why LSB is such a big joke.

      What the application vendors do is this: they go to Redhat and say, "What should we do to support your system? Do you want Redhat packages or LSB ones?". Redhat reply, "We want Redhat packages, not LSB ones". This process repeats for all other major platform vendors which the application vendor has an interest in.

      Having supported each of these platforms, the application vendor has no motivation

    • What tools are these? Checking for a particular distribution seems bizarre to me. My own code, and most code that I'm familiar with, checks for particular features using autoconf, not distributions.

      • What tools are these?

        An annoyingly large number of EDA tools -- it's gotten better, but there are still quite a few that do. For another example, I could name a Nortel VPN client and a well-known meeting-host service that still seem to be fixated on RH7.x -- I think it dates to the bubble, when they thought RH was going to replace Microsoft. Since then they haven't bothered.

        • Interesting. To the extent one can generalize from this, it seems that Free and academic software configures on features while it is proprietary commercial software that configures on distributions. It's like they think of distributions as traditional brands.

      • My own code, and most code that I'm familiar with, checks for particular features using autoconf, not distributions.

        Doesn't autoconf have something to do with compiling source code, which you wouldn't be doing with closed-source proprietary apps?
    • The latest version of Oracle is supported on not only Red Hat, but most Debian derivatives including Ubuntu.

      Or maybe you mean desktop apps like just about anything based on Eclipse?

      I will concede that Microsoft doesn't support Office on any non-Redhat version of Linux. But, then again, they don't support Office on Redhat Linux either.

  • Linux vendor support isn't critical. (Score:3, Informative)

    by khasim ( 1285 ) <brandioch.conner@gmail.com> on Tuesday April 25, 2006 @05:14PM (#15200306)
    It's the Linux app ISV's who need to write their apps to this "standard".

    So far, that isn't happening.
    • That's not really a valid point. As a Linux app. developer, I have skimmed through the LSB, and it seems to be at a much lower level than I work it (e.g. what functions should be included in libc). It's more for the distro makers who need to know what base libraries and library versions to ship.

  • Is LSB a good thing? (Score:3, Insightful)

    by tenchiken ( 22661 ) on Tuesday April 25, 2006 @05:17PM (#15200331)
    As we watch competition help the Linux landscape considerably, is LSB a good thing? Gnome and KDE push each other to become better, Java and Mono compete for developers and even Rails and J2EE go after the web market.

    Here is a standard that specifes how to package APIs and which APIs to use if you want to have a a LSB complient desktop and application. Isn't that a bit restrictive?
    • Here is a standard that specifes how to package APIs and which APIs to use if you want to have a a LSB complient desktop and application. Isn't that a bit restrictive?

      It depends on what you call "restrictive"...
      Tarzan not like roads.
      Roads make Tarzan not move freely.
      Road lights threaten Tarzan with big noisy cars.
      Tarzan likes tree ropes.
      Tarzan prefers jungle.

      In jungle, Tarzan goes wherever he wants! AAAAA aaaaAAaAAaa AAA!


      • Is this sad, but I consider that comment more insightfull than funny.
        • Is this sad, but I consider that comment more insightfull than funny.
          Actually I thought of my post weeks ago as a parody to the "freedom" that Linux zealots preach so much about. Why do they insist on KEEPING everything low-level and chaotic?

          And they forget that it's the LACK OF STANDARDS that got us aberrations like ActiveX and ugly html.

    • As we watch competition help the Linux landscape considerably, is LSB a good thing?

      There is no "good" or "bad".

      There are objectives that you would like to see achieved and there are avenues to achieve those objectives.

      So the question becomes, what objectives will the LSB achieve and whether you believe those objectives should be achieved.

      The LSB was, originally, an attempt to make it easier for ISV's to port their apps to a "standard" that would run on any Linux box that was LSB "compliant".

      One problem wa

    • If you find a standard too restrictive for your purposes, just don't follow it. You'll then see whether your additional non-standard features are worth more than incompatibility to the users. Netscape and IE are both good examples of products that ignored prevailing (and slow-moving) standards that gained user acceptance. On the other hand, there are any number of computer languages that will not survive because they're not C/C++/Java and whatever they do well wasn't worth enough to developers and users.

      T

  • Neopallium writes to tell us that in a recent announcement at the Desktop Linux Summit the Free Standards Group reports fourteen of the leading Linux vendors have pledged support for the newest release of the Linux Standards Base.

    ALL YOUR LINUX STANDARD BASE ARE....

    ...oh, nevermind, you knew that one was coming.

  • Important time saver (Score:3, Interesting)

    by Zaai ( 817587 ) on Tuesday April 25, 2006 @05:21PM (#15200361)
    This is excellent news. Linux application developers write their applications against a particular distribution. Some add code to detect what distro the installation is for and adjust their paths accordingly. All other distro's have to spend time to write an installer to map that configuration to their distribution's file system layout. This is repeated every time a new release of a package comes out. With 100,000+ packages, that is a lot of work. Take Gentoo's ebuild system. Can you image how much effort it takes to maintain all those ebuilds? Any standardization of the Linux filesystem layout will reduce this effort and saves countless hours. Hours now can be used to improve applications themselves. Good news indeed :)
  • There's plenty of concern that the LSB platform is restrictive, but I think it's going to be a huge step forward for 'normal' users who don't want to know how to make an application work - we just want to run it. Linux is still an open model and so LSB is not compulsory, and if an application can be built better in an alternative way, great!

    I've had plenty of hassle trying to get various packages to work on older Linux systems, spent endless hours trying unsuccessfully to get services for a wireless networ
    • I think you are completely right about installation on windows computers. I consider it to be so much easier on Windows. That is not to say that the Linux way isn't better in many (and perhaps more important) ways - security being the biggest. Windows does have a lot of aplications which seem to "just work" on it also. Still I actually can run more of my stuff on linux than on windows so that seems to be a swings and round-abouts situation too. I end up not really knowing if either is "better" here, alt
  • "delivers ever increasing value to customers - It enables further uniformity and standardization across applications and distributions that allows quicker deployment of Linux solutions with higher levels of quality"

    Now we're speaking the language management can understand. All the stuff about "symmetrical multiprocessing" and "system bus throughput" was just a bunch of incomprehensible gobbledygook.
    • Good for a start, but this might be better:

      "LSB aggregates the various Linux, UNIX and POSIX system standards into an integrated framework. The resulting synergy allows better leveraging of the benefits of each standard than would be possible if they were utilized alone. It provides a standardized framework for system infrastructure, thus enabling more uniform, reliable, rapid and scalable deployment of applications in the enterprise, thus providing increased ROI and a better client experience for both inte
    • Comment removed based on user account deletion

  • LSB is a Pipe Dream Really (Score:3, Interesting)

    by segedunum ( 883035 ) on Tuesday April 25, 2006 @05:48PM (#15200558)
    The only way to reliably guarantee binary compatibility (especially with the test suites the LSB use) and compatibility to any important degree is to have the same binaries, and henceforth, the same distribution. It is actually possible to pass the certification for the LSB with one set of hardware and fail it with another.

    LSB compatibility is a nice badge to put on your software boxes (management love accreditation logos!), but whether it will mean anything to the ISVs who should be taking notice of it and anything practical for end users is another question.

  • Has LSB fixed RPM hell yet? (Score:5, Interesting)

    by sinewalker ( 686056 ) on Tuesday April 25, 2006 @06:44PM (#15200959) Homepage
    I hope 3.1 addresses my main gripe with RPMs: an RPM built for Fedora won't install into SUSE because of dependency issues, or vice versa.

    I'm still reading the latest spec to see if this has been or is going to be addressed. When/if it is, then I'll be very happy, because it will mean finally the end to confusion about using the "right" RPM repositories for your distro: if the distro is LSB compliant, then any RPM repository for that distro should work with other LSB compliant distros, with the dependencies for packages containing Base libraries being met or at least consistant accross the distros.

    Until that happy day, the LSB doesn't add a lot of value to me as an end-user. As a developer, it does have some small value, in that it provides me a consistent API, but that's about it...

    • Re:Has LSB fixed RPM hell yet? (Score:1, Interesting)

      by Anonymous Coward
      The dependency problem goes away because a single package "depend" (lsb >= 3.1) implies the entire set of functionality required by the LSB must be present on the system. See here:

      http://refspecs.freestandards.org/LSB_3.1.0/LSB-De sktop-generic/LSB-Desktop-generic/desktoppkg.html [freestandards.org]
    • http://rpmforge.net/manifest.php [rpmforge.net]

      This will be the beginning of the end of these issues.

      If RPMForge can succeed then 3rd party developers can use their lessons-learned (build tools) to release packages or create repositories that work on as many systems as possible.

      Also I hope (as mentioned by another poster) that some base RPM dependancy names are adopted for truly cross-distribution packages.

      I think the best solution would be for RPMForge could create distribution-specific packages that add these symbolic e
    • Ever tried to install new kernel RPM using different distro than intended? Number of failed dependencies ~ number of lines in kernel code.
    • I doubt it will solve your problems. Red Hat & SUSE might share exactly the same layout, but it doesn't meann the libs or the dependencies of the RPMs even will be shared. Still, all of the different formats are a pain in the arse. I wonder if it would be possible to produce a meta package - one which contains dependency information for different dists in the same RPM.
    • ...from the start!

      I hope 3.1 addresses my main gripe with RPMs: an RPM built for Fedora won't install into SUSE because of dependency issues, or vice versa.

      Application distributors aren't supposed to build RPMs for Fedora or SuSE or Mandriva; they SHOULD be building RPMs for LSB. ALL RPMs built for LSB should have exactly ONE dependency: the LSB package. The old LSB troll on here from supposed Debian fans alternately makes me chuckle or want to smack then upside the head. Basically they say "but RPM suck

  • LSB is lamelamelame. (Score:3, Insightful)

    by farrellj ( 563 ) on Tuesday April 25, 2006 @08:28PM (#15201561) Homepage Journal
    As long as the standard requires rpm files, its going to be a non-starter for many. The rpm format sucks the big one. I would much rather almost anything else than be stuck in RPM HELL. Give me slackpacks, apt-get, or even tarballs...but please save us from RPM Hell!

    ttyl
              Farrell

    p.s. I don't like rpm, can you guess?

  • All Major Vendors? (Score:3, Funny)

    by Radical Rad ( 138892 ) on Tuesday April 25, 2006 @09:26PM (#15201769) Homepage
    The LSB has garnered support from all major vendors in the Linux Community including AMD, Asianux, CA, Dell, HP, IBM, Intel, Mandriva, Novell, RealNetworks, Red Flag, Red Hat, Turbolinux, Xandros and others.

    I sure hope Caldera is one of the others!

    (SCOre: 5 Ironic)

  • said Mark Shuttleworth, Ubuntu founder and chief developer

    Er, it is the first time that I know Mark is the Chief Developer of Ubuntu....

  • Considering most if not all of the commercial linux companies specialise in the server market and pay little regard to the Desktop, it would make more sense to have one desktop linux distro and base their products around it. It is a more efficient way of concentrating resources by maintaining just one packaging and linux system to the LSB standard. It would also mean that more resources could be diverted to projects that are both benficial to the commerical and home desktops like KDE, Gnome etc. The only

Slashdot Top Deals

Stellar rays prove fibbing never pays. Embezzlement is another matter.

Close