Slashdot Mirror
LSB to Provide Standards as Optional Modules
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."
'Optional' standards?
Explain to me why this makes any sense.
yay for more standards MS can ignore!
The only thing better than standards are optional standards!
Who will standardise the standardisation of the standards groups?
One good turn - gets all the covers.
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...
_O_
.|< The named which can be named is not the true named
A certification should be awarder by a consistent comitee, why franchise it ? Alsoi, the modularity of standard is a really good thing because of the development cycle of new application and technology reducing at an higher rate these years. What I'm waiting for is something like "Appli. server LSB", "Web Server LSB" etc... With consistent versionning (no more specific distros range of application versions...).
Yes, we need several "standard" ways to do a particular thing. For example, do you need a standard way to store documents? text files, HTML, XML, PDF, DOC, take your pick. We don't need a wider variety of standards.
will enable standards flexibility and allow for a wider variety of standards
...and the list goes on...
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
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, nothing else will compare, no matter what the price.
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?
...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
Live today, because you never know what tomorrow brings
when I read "Standards as Optional" I thought this was a story about Microsoft.
Trolling is a art,
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.
"Ask not what your country can do for you." --John F. Kennedy
a wider variety of standards
maybe i'm missing something, but how is that a good thing?
It's not often you see the word 'standards' five times in one sentence. Now if only that sentence had actually made sense...
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)
I want to drag this out as long as possible. Bring me my protractor.
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.
Sounds like object oriented databases to me...
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
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 RedHat decided they were the standard, and didn't need to comply with some piddly forum's decisions.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
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...
To err is human, but to forgive is beyond the scope of the Operating System...
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.
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!
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.
Whence? Hence. Whither? Thither.
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?
Hold your horses!!! I never said I read the article:
Of course, I never got to the end. See? I think I'm finally getting used to this place. Now, with a little bit more effort...
To err is human, but to forgive is beyond the scope of the Operating System...
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 have.
I'll say a dozen Hail RTFA's and promise to be a good slashbot in the future.
That's the spirit!
I want to drag this out as long as possible. Bring me my protractor.
I would like to announce that Anti-slash is closing shop, after having been the biggest and most successful troll of all time, especially aimed at trolling the trolls themselves. For months we styled ourselves as freedom fighters, exploding petty grievances against Slashdot (OMG, dupes! REVOLUTION D00DZ!) and generally stirring up all the petty crybabies we could find. All of those who really believed our crap and signed up to Anti-slash, posted our 'manifesto' and campaigned for us ... well done! We have totally fucked pwned your stupid asses. And now thanks to your overblown shit-stirring, you've managed to get an editor fired, congratulations! ... I HAVE SO FUCKING TROLLED YOU ALL. You fail it times a hundred.
Once again
You'll note that our website (http://www.anti-slash.org) has been down for some time now. It won't be coming back, as it's served its purpose of baiting all you pussies. One final 'Well done' to the brave anti-slash crew!
Yours with love, Ackbar
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 experience with developing software (open or closed source) and are mainly consumers of these open source projects you vehemently defend and comment on.
If you guys did have experience with that, you would know how important it is for the average joe user for you application to run out of the box without any need for tinkering.
Honestly, if you guys don't get your act together, instead of gaining market share from MSFT, you will start loosing it to Apple instead. The OSS community should get off their high horse, stop listening to freaks like RMS and look at Apple for ideas to borrow concerning application development.
Here are some things that Apple as done right:
-consistent user interface standards for different application types/classes.
-consistent base install to write software against.
-packaging additional proprietary extensions with the third party application (avoids dll/so/framework hell).
-easy to understand/use API with sufficient documentation
Linux can have a real future if they provide easier install/uninstall and a robust base set of libraries closed and open source binaries can be built against for distribution to the general public.
Jesus was a compassionate social conservative who called individuals to sin no more.
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 not comply with seperately of others.
So, for instance (making up names for hypothetical distros and programs for the sake of example), the LSB Packager standard might specify the use of gnupackager, the LSB Window Manager Standard might specify the use of SpiffyWM, and the LSB Compression Standard might specify the use of Linzip.
The ZippyLinux distribution, which uses gnupackager, SpiffyWM, and Linzip, would be compliant with all three standards.
On the other hand, the MondoLinux distro, using gnupackager for packaging, SuperWindows for a window manager, and Linzip would be compliant with the LSB Packager Standard and the LSB Compression Standard but would not be compliant with the LSB Window Manager Standard.
A compression GUI frontend might specify that it runs on distros compliant with the LSB Compression Standard and the LSB Window Manager Standard, and you'd know from reading this that it would work on SpiffyLinux but that MondoLinux might have problems.
If this is the approach they're taking, it could be quite useful.
Rather, why not specify the functionality that needs to be present and the format of the packages.
Don't use
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. That functionality can be added to rpm and apt and whatever other managers are out there as those maintainers desire.
Also detail the features/functionality of whatever is used to store the package data.
That also allows those maintainers to add the functionality as they desire.
It will take more WORK than simply saying "use
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 has already been broken into modules and with LSB 3 more modules will be added that do not have to be included to be an LSB certified OS or app. The BASE modules are required for all compliant software. For the "server" options there will be libraries and daemons that must be available that are not appropriate for desktop use. Similarly having X and a desktop environment and sound libraries on a server just to meet a standard is stupid, so they are part of an optional "desktop" standard.
I think that is what has been one of the barriers to widespread adoption of the LSB--in order to be able to say you are LSB compliant in the past you couldn't depend on C++, GNOME/KDE or some other fundamental components of modern distros--you either had to not use such components or bundle them with your install (making your package very large). Soon a GUI/Desktop app can say "LSB/Desktop compliant" and a web server application can say "LSB/Server compliant" and OS makers can market an LSB desktop OS without including irrelevant server components.
Without optional components in the standard you could end up with something like what you have with MS Windows--a desktop OS that (until quite recently anyways) had open ports and services that do nothing for users but consume resources and introduce security risks, and a server OS that requires megabytes more RAM and drive space so that it can provide pretty graphics, media player, paint program, etc in its default installation.
I think it's a great move. Multiple/optional standards are only a problem when they cover the same thing (VHS/Beta, RPM/DEB, DVD+RW/DVD-RW, etc etc etc...) and this is just providing some needed granularity to the standard. As long as it doesn't get too fragmented it'll be great for software distributors (LSB/Desktop, LSB/Server would all that would be needed in the software requirements list instead of a list of arcane dependencies).
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 the LSB implementation that Red Hat has, where is the guarantee that the app will run on a Debian LSB system? Or even a SuSE LSB system?
In which case, you're back at the beginning with the "problem" that a package built for Red Hat will not be guaranteed to run on a SuSE box.
>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 community can't sort these things out as they have almost no say in the enterprise domain.
>"The key conundrum is that the LSB is a complex specification, and we want to avoid duplicating the certification efforts the Linux vendors are already doing."
Oracle on any Linux! Not so soon, but ultimately.
> Zemlin said he is not asking users to require LSB compliance for their applications as yet. "Today, it is only being specified at the distribution level," he said.
Read: We can't deal with everyone and everything right now, please ask your distribution to LSB certify first, then when LSB 4.0 is out we'll tighten the screw and put pressure on application vendors to certify as well.
By LSB 5.0 you'll be able to move your data and apps between distros in seconds....
Nasty scenarios:
1. Everyone gets certified
Imagine how many engineer months it will take to RH to get compliant. Then imagine CentOS getting the same certification without any effort (as they build from the Red Hat Enterprise Linux sources).
As the cert will probably be free, then imagine which of the two distros will the average company use - the $1,500/year RH EL or the free CentOS...
2. Sun gets certified
Sun, of course, doesn't like RH's domination. I don't know if it's technically possible, but it's easy to imagine Solaris for x86 being one of first OS'es to get the certification for LSB-server OS and then hang that in front of RH's nose (and their customers). What's even "worse" (depending on one's MS stance) is that real standardization is going to be great for Microsoft - they'll finally need to do only one compatibility and cross-platform effort for Linux-related shit.
Novell and Red Hat do have some apps that work on top of their distros, but the thing is those aren't really the best of the breed, so I think tough times are on the horizon. It did sound great a year ago - RH Enterprise Linux with value added thingies like Red Hat Network, RHCE, the apps, etc. - but both them and Novell will have to work harder just to defend what they've gained so far.
8 years? 10? (FBSD2.2.5) not sure, but when i started exploring ms_alternatives, i chose *BSD because it seemed (to me, at the time) to be "simpler" because they seemed more homogeneous. every time i "discovered" YADistro(tm), in the back of my mind i'm hearing "we don need no steenkin LSB!". on the other hand, the idea of a "desktop standard" and a "server standard" could be a good idea across ALL of the F/OSS community
especially if the F/OSS community were to ever do "open source" stuff that included more than just Linux!! reading through these comments, i'm reminded again about how much the "Linux community" is beginning to look more and more like the "proprietary community" (ok, so it's a community of one, but..) with so much of your/their efforts seeming to require a lot of work to run on "your older step-brother"; the closest thing we have, today, to Unix, IMHO. (right, i know "Linux Is Not UniX". so sue me; i'm a "traditionalist"!) it just seems so weird to have to have a "Linux(an "open source" "os") compatibility layer" to run "open source" software on FBSD(another "open source" "os"). (yeah, i know; one is a kernal and the other is more of a "fuller" operating system.)
(how many others in the house had RPGII included in their earlier computer training? (20 years ago
MS-KILA
Thank you. It seems LSB has changed significantly, and I stand corrected. At least, from what it looks like on paper.
It didn't always used to be this way, and I had written them off back then. Now I will probably sign up with an individual membership and see how they really are.
If it's true that individuals can indeed have the type of voice that they claim, this is a Really Good Thing.
Have you never heard the expression, "if you can't beat 'em, join 'em"? ;)
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 difference and are they compatible. Maybe i got all this wrong...but, if i didn't. I don't think this is a good idea.
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.
SIG: TAKE OFF EVERY 'CAPTAIN'!!
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, etcetera.
All in all, I don't think this is very good
news for the linux community as a whole, or
for the struggle against the (un-named) 800
pound gorilla in the opposing corner.
I must have missed the point at which desktop Linux had 1000+ developers working on it and a billion dollars to play with.
... wait. It has that too, albiet still an immature implementation you need a good box to run. But that's true of MacOS and Longhorn as well.
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 going to discount every operating system that draws from other sources, in which case Linux would be one of those.
Linux has had hardware accelerated graphics for a very long time now. You must mean hardware window compositing, but
The classic OSS response. "We have it too! Well, not really, it's immature and 'coming soon.'" Referencing random unfinished Sourceforge projects whenever someone mentions features Linux doesn't have makes you look foolish. Meanwhile, you didn't refute the point whatsoever--OS X uses the GPU for its window compositing. Let me know when GNOME/KDE get around to it.
I won't bother replying to the rest as it's simply provocative opinion (there's a shorter word for that).
I acknowledge your lack of a valid counterargument.
Next.