Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Linux Software News

LSB to Provide Standards as Optional Modules 99

Posted by CmdrTaco from the step-in-line dept.
An anonymous reader writes "The LSB will begin providing certain standards as optional modules to the core LSB standard that will enable standards flexibility and allow for a wider variety of standards, eWeek is reporing Free Standards Group officials said at the OSDL Enterprise Linux Summit today. The article goes on to say that the FSG is also looking at possibly franchising out the application certification component of the LSB to the distribution providers themselves."
This discussion has been archived. No new comments can be posted.

LSB to Provide Standards as Optional Modules More

LSB to Provide Standards as Optional Modules

Comments Filter:

  • Wait just a second... (Score:2, Insightful)

    by Anonymous Coward

    'Optional' standards?


    Explain to me why this makes any sense.

    • Re:Wait just a second... (Score:5, Funny)

      by aeakett ( 561176 ) on Wednesday February 02, 2005 @10:04AM (#11550402) Homepage Journal
      My favorite part was "wider variety of standards". You know what they say... "The nice thing about standards is that there are so many to choose from."
      • "You know what they say... 'The nice thing about standards is that there are so many to choose from.'"

        And like many other Slashbot mantras, that one doesn't make any practical sense either. For once I'd like an answer to the "why so many standards?" question that doesn't contradict itself.

    • Yeah, yeah. I wish I could force a packaging system on all the distros at one time. On the other hand, whatever packaging system does become the "optional standard" will be the best one out there, or at least the best combination of security/stability and ease of use.

      Do you know how many mail handling programs there are? Do you know how many are actually popular? Sendmail used to be the only choice, but now a lot of people use qmail.

      Give this GUI Linux desktop stuff some time to mature. In five years, not

      • On the other hand, whatever packaging system does become the "optional standard" will be the best one out there, or at least the best combination of security/stability and ease of use.

        I don't see that happening.

        Rather, why not specify the functionality that needs to be present and the format of the packages.

        Don't use .rpm's, use .lsb's instead.

        That way they can take the best parts of all the packages and specify them in their own format.

        Then detail the functionality needed to install those packages. T

      • Give this GUI Linux desktop stuff some time to mature. In five years, nothing else will compare, no matter what the price.

        That's what people five years ago were saying.

        I am fully convinced now that Linux will never mature on the desktop due to the very nature of OSS. There are no global standards or goals. Instead, toolkits compete with each other, entire desktops compete, packaging systems compete, and so on. That's nice if you want to preach about "choice" but it won't get you anywhere with a powerf
        • Think about it. Darwin/Aqua is a totally new thing that took them about five years, drawing from the same kind of open resources available to Linux at the time.

          I must have missed the point at which desktop Linux had 1000+ developers working on it and a billion dollars to play with.

          In five years, they had a completely new OS shipped and ready.

          No, they did massive imports from code bases they either bought or were BSD licensed. It's certainly not "completely new".

          On the other hand, Linux has been ar



          • Linux has 1000+ developers, and you don't need a billion dollars. The point I was making, which clearly shooshed right over your head, was that Darwin draws from open source technologies like BSD.

            No, they did massive imports from code bases they either bought or were BSD licensed. It's certainly not "completely new".

            They installed a Mach kernel with BSD subsystem, created a new version of the NeXTStep APIs called Cocoa, and created the Aqua interface on top of it. Yes, it's a new OS, unless you're g
          • I must have missed the point at which desktop Linux had 1000+ developers working on it and a billion dollars to play with.

            Linux has 1000+ developers, and you don't need a billion dollars. The point I was making, which clearly shooshed right over your head, was that Darwin draws from open source technologies like BSD.

            No, they did massive imports from code bases they either bought or were BSD licensed. It's certainly not "completely new".

            They installed a Mach kernel with BSD subsystem, created a new ve

    • Re:Wait just a second... (Score:1, Insightful)

      by Anonymous Coward
      Say, someone may want to compile VIDEO for LINUX modules, but may not want to take the arduous time required to actually go about recompiling the kernel and doing everything for oneself, but some distributions (like knoppmyth) may want to include video packages and still remain within the LINUX standard base. So ha.
    • Hmmm..."optional standards"...kind of like "advanced BASIC" and "*Micro*soft Office Professional" (a product that a friend remarked some time ago was so big it should've been sold on its own hard drive instead of floppies or CD-ROMs).

      Having "optional" standards makes sense. I think a few posters here haven't been able to catch the clue--this doesn't mean "parallel" options like an option for debian or red-hat style package formats. The options are just an extension of what the FSG has done with LSB 2--it
    • I think the whole post was based on a bet to see who could use the word "standard(s)" the greatest number of times in one sentence.

  • woot (Score:1, Funny)

    by Shardin ( 696999 )
    yay for more standards MS can ignore!
    • Why would you want Microsoft doing anything with regards to the Linux Standards Base?

      I suppose the one case compliance would be useful would be with MS Linux [mslinux.org].
      • I don't want them doing anything... whenever they touch standards they always mess them up.. this is one they can safely ignore and should steer clear from!
    • By making tons of standards (optional cause it would be hard to respect them all) eventually Microsoft will HAVE to respect some! THAT's the idea!
  • The old observation that standards are wonderful because there are so many of them springs to mind.

    Can't wait for the optional RedHat module and the optional Suse module and... but that's silly, they'd have to franchise out... er...

  • will enable standards flexibility and allow for a wider variety of standards

    Bummed that there is only one LSB standard?
    Wish you could make your own standard?

    Don't worry, more LSB standards are on the way!

    Don't like the LSB?
    You can choose from:
    * The Mandrake LSB standard
    * The RedHat LSB standard
    * The Gentoo LSB standard
    * The Debian LSB standard ...and the list goes on...
    • Sounds like object oriented databases to me...
    • The decision to make LSB modular basically
      boils down to the fact that each major
      Linux distribution ISV "agreed to disagree"
      on a unifying standard. This preserves their
      IP, their branding, and also their revenue
      stream. It does NOT forward a unifying LSB
      common standard for all to adhere to. Methinks
      it will also lead to chaos among the F/OSS
      application/tool suite ISVs to try and support
      different flavors of GNU/Linux. I can forsee
      a RedHat version of Apache (LAMP) competing
      with a different Suse version, etcet
  • Why do we need more standards defining the Least Significant Bit?

    Back when I was a youngin', we had us our big endian and little endian computers, and that's the way we liked it!

    Seriously, why can't articles explain what all of the acronyms mean?


    • Why do we need more standards defining the Least Significant Bit?
      ...
      Seriously, why can't articles explain what all of the acronyms mean?

      Here is your big pointy hat - go sit in the corner.

      From the FIRST PARAGRAPH of the article:

      The Free Standards Group has decided to move away from a single, core LSB (Linux Standards Base) specification, and is instead going to break this down into different modules that can be combined to give a server or desktop LSB standard.(emphasis mine)
      • Heh, thanks for pointing that out. I read that paragraph two or three times trying to figure out what LSB meant, and my mind just totally blanked out the parenthetical part. I've been writing papers, and I use the reverse format - I would've written "Linux Standards Base (LSB)," and gone on to use LSB for the rest of the paper.

        I'll say a dozen Hail RTFA's and promise to be a good slashbot in the future.


        • Heh, thanks for pointing that out. I read that paragraph two or three times trying to figure out what LSB meant, and my mind just totally blanked out the parenthetical part.

          Remember 'Please Excuse My Dear Aunt Sally'? Parentheses and exponents should be parsed first. :-)

          I've been writing papers, and I use the reverse format - I would've written "Linux Standards Base (LSB)," and gone on to use LSB for the rest of the paper.

          That would have made more sense, of course, but we must work with what we
    • According to the article:

      "To make for easier processing and power saving, the LSB can now be fixed as a one OR a zero (according to which standard you use) for ALL operations.

      1) Fixing this bit means one less digit to process (or shift) because its state is now globally known - for 16-bit computations, this will save a nominal 1/16th of the effective processing time, thus speeding up programs with only a marginal loss of numerical accuracy.

      2) Because the bit no longer needs to be toggled between logic s
    • Agreed, I was about to comment that.

      Posted summaries are supposed to be descriptive.

  • Bad idea.... (Score:3, Interesting)

    by Kjella ( 173770 ) on Wednesday February 02, 2005 @10:12AM (#11550461) Homepage
    ...let's see now. You have a fringe OS (at least in the desktop space), with a bunch of incompatible standards (deb, non-lsb rpm, ebuild etc.) and instead of actually getting one standard used (how many USE lsb packages?) they're going to make more?

    At most, they should have TWO - LSB-server and LSB-desktop. Not a "LSB-foo-bar packet" which doesn't run on a "LSB-foo" machine. The rest? Forget it.

    Kjella
    • Could not agree more.

      Unfotunately wherever you look at human endevours, unless there is an all powerful overseer (i.e. like Microsoft), standards tend to get tossed around for ages until one becomes generally agreed upon due to its popularity, which is then used, though it tends to always be a compromise of a sort. And during this period, people tend to be interested in arguing than furthing the actual project.

      The cases are many and varied, take nomenclenture of living organsims/geological time periods e
      • This is creating an all powerful overseer (ie LSB) While not that powerfull yet they are gaining. Many distrubitions are supporting the LSB and those that don't will be doomed to thier nitch for better or worse.

        with LSB we have one LSB with diffrent levels for diffrent applications giving a common base to anyone who follows it.

        before LSB we had Redhat Linux, Suse Linux, Debian Linux, Mandrake Linux, and many others all with very little common ground.
    • RTFA, what you suggest is exactly what they are proposing:

      As such, there will be different modules, and assembling a set of modules will give you the LSB server standard, while assembling another set of modules will give you the LSB desktop standard going forward

    • Re:Bad idea.... (Score:5, Informative)

      by drew ( 2081 ) on Wednesday February 02, 2005 @11:25AM (#11551318) Homepage
      I think you miss the point of the LSB. LSB is not a package format- there is not such thing as an "LSB package", and deb, ebuild, rpm, etc. have nothing to do with the LSB.

      LSB defines a set of libraries and applications that will be present on all LSB compatible distributions/installations. It specifies things like kernel version, libc version, etc. so that a commercial application provider can say that "This application is certified to work with LSB 1.x" instead of "This application is certified to work on redhat 7.2, and may work on debian 2.2, suse 8.0 and possibly other installiations that have kernel 2.4.x, glibc 2.y, and foobar 3.0"

      What they are talking about doing now is adding optional components to the LSB. That way an application provider can say for example "This product is certified with LSB2.x + LSB Webserver 1.y" without having to add a web server as part of the LSB and thus requiring it to be installed on non-server computers. Likewise the current LSB defines few (if any) X toolkits, libraries, applications, etc. so in order to say that a commercial desktop application will run on any LSB certified platform, providers would have to statically link a lot of libraries that are already present on most desktop linux machines because the LSB doesn't include them. Also, as the article points out, there is a lot of interest in having Java be part of the standard, but so far they have not made it required because of the licensing issues. This way, Java installations could be standardized but made part of a separate module so that they would not be required for all LSB compliant installations.

      However, while having optional modules for the standard doesn't seem like a bad thing to me, the idea of having the distibution providers doing the certification seems like a mistake.

      • I think you miss the point of the LSB. LSB is not a package format- there is not such thing as an "LSB package", and deb, ebuild, rpm, etc. have nothing to do with the LSB.

        (A previous version of) RPM is actually part of the LSB standard.

      • Re:Bad idea.... (Score:3, Informative)

        by kaisyain ( 15013 )

        LSB is not a package format- there is not such thing as an "LSB package", and deb, ebuild, rpm, etc. have nothing to do with the LSB.

        You might have to have a re-read of the Linux Packaging Specification section of the LSB. The LSB does not currently require that packages be in RPM (although it is "encouraged" and in the future may be required) but there definitely is an LSB package format and it is RPM.

      • However, while having optional modules for the standard doesn't seem like a bad thing to me, the idea of having the distibution providers doing the certification seems like a mistake.

        Bingo. What incentive does Red Hat have to ensure LSB compliance in addition to (or instead of) Red Hat compliance?

        The original stated purpose of the LSB was to guarantee that an app you got from an ISV who had certified that app against the LSB would run on any LSB compliant system.

        If Red Hat certifies an ISV's app against

        • Presumably, if red hat certifies too many applications as LSB when they won't run on Debian, their license to certify gets revoked. Maybe they could say 3 separate distros have to certify an app for it to get full certification
          • but the point of the LSB was that vendors would only have to do one certification, rather than certify against every distro. if they still have to certify against multiple distributions, it doesn't gain the community much, because app makers wll go back to just certifying against redhat like they used to.
    • deb, rpm, ebuild, emerge - those aren't standards, they are just ways to pack or install software. Windows also has several installers.

      The article says that indeed there will be two LSB's, the server and the desktop variety, and people will be able to do fine selection of sub-varieties. For example, if you build a Linux distro for notebooks you might want to follow the LSB-desktop standards with an additional compliance with some sub-standard guidelines or specs for notebooks, power saving, touch-screens,

  • whoops... (Score:3, Funny)

    by grub ( 11606 ) <slashdot@grub.net> on Wednesday February 02, 2005 @10:14AM (#11550483) Homepage Journal

    when I read "Standards as Optional" I thought this was a story about Microsoft.
  • What is the point of having so many standards? Why have all these "standards" if everyone is using a different one?

    I always regarded standards as some level of uniformity and consistency. And yes, I know that standards restrictions can impede innovation, but I think there's a time when one "best" method of doing something should be chosen as THE standard.
    • Microsoft has "standards" API's etc, that aren't defined, documented, etc. Standards mean that we can compare software, even (especially) different branches of the same software (i.e. linux) on an even playing field. we can say " Redhadt defines their standards this way, suse this other way, and gentoo a third." this information lets me build ebuild that work in suse, and rpms that work with gentoo. they're standard formats like ogg, aac, or mp3. why use a !doctype statement, when almost all doctypes a
      • I think ogg, aac and mp3 are good examples of my confusion. Yes they are all different technically, but essentially are the same thing: a compressed audio format.

        Now I don't know which audio formats are open and which are closed, but let's assume for the sake of simplicity that ogg offers the best quality/size ratio out of the open formats.

        Would it not make sense, then, to make ogg THE standard open compressed audio format? Wouldn't that make things like open source media players much simpler to create
        • ok, I thought ogg was the open sandard sound format but I understand. it's still better than saying "apple has a format" and "linux has a format" and "M$ has a format" we know what the formats are. they're defined. also, someone pointed out that the diferentiation with the various standards pertains to OS USE (i.e. desktop vs Server) which actually makes sense, you don't really want to require application compliance for the desktop and a server the same way, then linusx becomes widows, running X on a s
    • What is the point of having so many standards?
      The nice thing about standards is that there are so many to choose from.
    • Because we need different things, as someone else said. At the moment if you want to call your app LSB certified, you have to pretty much statically compile everything, which is a bad thing. If there were a "LSB gui" addon mandating X, gtk and qt in a particular place, a "LSB server" addon mandating perhaps a sendmail-compatiable mta and a webserver and database accessible through some standard interface, you could make any kind of app for the particular LSB. This is ultimately about expanding the LSB, but
  • It's not often you see the word 'standards' five times in one sentence. Now if only that sentence had actually made sense...

  • Closed standards for Open Source? (Score:2, Insightful)

    by Anonymous Coward
    Is it me, or does anyone else find it ironic that the main standards effort for Linux distros (LSB) has been closed to Debian and other community efforts? While instead catering to the big, commercial interests.

    We don't need closed standards for Open Source.
    • Do you want big, commercial interests to take interest in linux or not? Face facts. The average Joe Blow does not want to recompile the kernel, check for dependancies or make an application.

      They also do not want to be relegated to choosing from poorly implemented GUI apps. What they do want is to use a platform with closed source GUI applications they are familiar with. Without these apps, linux will never take a significant chunk of the desktop market.

      I think open source is great for infrastructure but

  • what are the chances that this "standardization on difference" will lead to a single standardized LSB which all distros can comply with, honestly?

    The best thing I can see coming from this is that every distro would be "required" to have a bunch of garbage packages to comply with the LSB now. Some distros (redhat for corporate reasons? debian for philosophical, minimalist reasons?) won't comply, I imagine, and we'll have a mess.

    What was wrong with the plain LSB, anyway? Oh, that's right - pricks like RedHa

  • Sounds funny but makes sense... (Score:5, Informative)

    by crazy blade ( 519548 ) on Wednesday February 02, 2005 @10:37AM (#11550679)
    The LSB will begin providing certain standards as optional modules to the core LSB standard that will enable standards flexibility and allow for a wider variety of standards...

    Upon first reading the above I almost laughed. What good are standards if they are flexible and come in great variety? Then I did what no other self-respecting slashdotter would dare to do: I started RTFAing...

    What these guys are saying is we should have different standards for different types of machines (e.g. Servers vs Desktops) which are based on a common denominator. Therefore the addons to the standard may go into greater detail for that type of usage.

    I guess they want to make the standard stronger in some directions, while at the same time not encumbering types of distros which need not concern themselves with the gory details of something they don't include. I guess that sounds reasonable...

    • Or, more importantly, not requiring a lot of inappropriate things for applications that only need other things. There have been UNIX standards in the past which have specified that you need to have a web server and X, even though most people don't use both on the same machine. The worst thing for security and stability is things that are kept running but never used, because they are easy to forget to update. On the other hand, a lot of desktop code could use standardization, such that, if you are trying to

  • posix (Score:2, Informative)

    by bile ( 169020 )
    Posix has optional sections of it's standards. Like multiprocess locking. Which isnt implimented in Linux before 2.5 because of the clone threading model.

  • Sure, this is 'standards creep'. But it's just baby standards creep compared to the W3C.

    These guys aren't working on more than one version concurrently. They aren't working on more than one 'level' for each version. They aren't working on more than one 'platform type' per level per version. Without techniques like that, they can never become the awesome standards mill that the W3C is.

    Sure, this plan of theirs will result in a linear increase in the total number of standards. But these are baby steps
  • I would hope this means that you can still have and LSB compliant system without having to have an SMTP daemon installed. I freaking hate that. If you want to install one on your machine, go ahead, but quit requiring me from putting one on mine where it's unwanted. I don't want log files mailed to root every night on my desktop machine with no servers running. If I need to read a log file, I will read it directly out of /var/log. But somehow I doubt that will be the case.
  • The LSB will begin providing certain standards as optional modules to the core LSB standard that will enable standards flexibility and allow for a wider variety of standards, eWeek is reporing Free Standards Group officials said at the OSDL Enterprise Linux Summit today.

    1, 2... 5 instances of the word "standard" in one sentence.
    Just a little overboard?
  • As only as they keep the core and only offer optional standard for different market segments (server/desktop/embedded), I'm ok with that.

    I do hope, however that the strongly encourage everyone targeting the desktop space to remain consistent in what they offer.

    I don't think many of you have much experience with developing closed source applications where you must depend upon certain minimum dependencies being on each machine you install the binary on. I think many of you don't even have any real experie

    • Nice post. I agree wholeheartedly with every point you make .. except this:

      The OSS community should get off their high horse, stop listening to freaks like RMS

      The fact is, there is nothing inconsistent about taking the approach you advocate (and I agree with), and working toward the important goals RMS is concerned with.

      You're advocating things like increased standardization, increasingly looking to leaders in innovation like Apple for ideas (rather than just to market leaders like MS), increasin

  • People've been going on and on about how it's silly to have different versions of the standard using examples like having a Debian LSB and a Mandrake LSB, and so on, which to me just seems an absurd way to do things.

    I haven't read TFA, but the first interpretation that struck me seems to be one that few people have mentioned so far. Perhaps, having multiple standards doesn't mean there are multiple standards for the same basic thing, but that each basic thing has a standard that a distro can comply or no
  • >any users perceive a lack of strong Linux standards, and that is creating a barrier to their adoption.

    To me this reads: users, ISVs and hardware OEMs are sick of having to buy or deal with Red Hat for every Oracle on Linux they sell.

    In other words, people don't want one or two or three enterprise distros - they want one server standard so that they can choose among all Linux distros.

    Now, if Debian (someone mentioned them being excluded) doesn't like something about it - that's too fscking bad... The
    • Solaris get certified? While I haven't read the details of the proposed standard, I'm pretty sure that given the name, for a distribution to be certified it has to be, at the very least, well... ~A LINUX DISTRIBUTION~. Solaris may be Unix but it definately isn't Linux, whether closed-source or open. If they certify Sun they may as well certify Microsoft.
  • What's the point of standards, if there'll be veriations to them? Till now when im downloading packages all i have to worry about is what is my distribution based on. If it's debian based i get debian package. With one standard you get one package that can work on all distributions supporting that standard. Now we'll have "optional" extra bit and what's next? One standard for one thing another for something else. Now I'll have to worry about standards. Is my linux distro standard zyx or xyz, is there a dif
  • What has Least Significant Bit to do with Optional Modules?

    Gawd I hate it when people use abbreviations without giving any explanation whatsoever.

    Here - take away my slashdot membership card.

Slashdot Top Deals

If I want your opinion, I'll ask you to fill out the necessary form.

Close