Slashdot Mirror
Linux Standard Effort Edges Ahead
ErikPeterson writes "The Free Standards Group has released its third version of the Linux Standard Base, an effort to unify some of the workings of the open-source operating system.
The LSB is designed to make it easier for those producing higher-level software to support different versions of Linux. Pledges to conform to the requirements of Version 3 are Red Hat, Novell's Suse Linux, Asianux and Debian."
I think you are well aware Mr Monkey, that if Debian, Suse and Red Hat commit, the rest will follow (for instance Ubuntu will pick it up naturally next time they snapshot debian unstable).
On a different note, when I last subsribed to the debian lists (some time ago now), I remember a bit of a flame war over an earlier incarnation of LSB.
Basically - the argument was over whether the Debian GNU/hurd and Debian GNU/*bsd projects should follow the Linux standard base or just Debian GNU/linux.
Here's a good (mid thread) post about it.
Does anyone know if Debian GNU/hurd and Debian GNU/*bsd will follow the LSB3? Or just Debiam GNU/Linux.
My pics.
Don't get your hopes up. While the LSB appears like a very useful standard, as many have noted there are some real holes, and the test suite is by all accounts utterly useless. Further, there's not as tight of control of the testing so it appears at least some vendors are doing bizarre things to be compliant without waivers, despite tests that don't run in real world situations.
One example that Ulrich Drepper of RedHat pointed out is the thread test, which won't run on an SMP box. The LSB people's response? Run it on a slow uniprocessor. What's the point of this again?
I mean, do software developers usually keep to this standard, or is it more like them cutting some slack due to numerous distros not adhering to it?
What if those releasing the libs/support files (QT/GTK2, etc.) _only_ allowed you to use them for free, _IF_ the end product adhered to LSB specs.? --It'd force developers to be less sloppy, and some form of unity might come sooner than expected..
Yes, an arrogant idea, but just read it as an "what-if" -kind of thing.
A horse can't be sick, you know, even if he wants to.
I know the debian port for AMD64 decided to make the 64bit arch a first class citizen. i.e. there is a /lib directory. Fedora OTOH uses a /lib64 directory. This is like saying there is something special about 64bit libraries on a 64bit arch. Does the new LSB specify how this should be handled? Who will have to change, debian or Red Hat? I run Fedora and am disappointed to have a /lib64 full of stuff and /lib that is almost empty. Thoughts on this?
It would be nice if Ubuntu committed to it seeing as though they've become the 10,000 pound gorilla of Linux distributions.
Note: this isn't anti-Ubuntu. I run Ubuntu.
Now, THIS move by the "Penguin People"? A smart one...
Why, imo?
WELL, it will hopefully STOP the "fragmentation @ binaries levels" that UNIX (the predecessor, inferior currently imo to Linux in many ways) encountered!
(Which is, imo, the ONLY real reason we are not all running some form of UNIX on our PC's today instead of Windows, Mac, or Linux as OS' etc./et all).
Kudos on such things happening to the "Penguin crowd", because it's needed imo. Linux 2.6x core is IMPRESSIVE (most impressive) & KDE rocks too imo.
Would be a shame to see that fall apart between Linux versions!
APK
P.S.=> Next, is standards as much as possible between Linux & Win32 (if not MacOS X) so they interoperate on MANY levels (document formats, webpage standards, heck even binary level compatibility which tools like Delphi/Kylix, C/C++, & mostly imo, RealBasic 2005) will be of GREAT aid/help in doing...
E.G.-> Imagine writing code ONCE, & running that same sourcecode as an executable anywhere!
(AND, not using interpretation layers like the Java runtimes, VB runtimes, MSVC++ runtimes as intermediaries which to be blunt about it, slow things down in message-passing overheads & translations on Win32 alone)!
Speed & binary compatibility IS possible, if everyone acts together on it imo... this is the future, & what ought to be the "thinking behind 21st century personal computing"... apk
And, I might mention, I think it matters A Lot.
s p
/ 1128201
http://www.eweek.com/article2/0,1895,1861272,00.a
From where I sit, Red Hat's Drepper
http://linux.slashdot.org/article.pl?sid=05/09/19
wants to throw the baby of open standardization out with the bathwater of LSB standardization testing, which could still stand a lot of improvement.
With open standardization, Linux could go the way of Intel Unix--shudder!
Steven
I think you are well aware Mr Monkey, that if Debian, Suse and Red Hat commit, the rest will follow (for instance Ubuntu will pick it up naturally next time they snapshot debian unstable).
/. last week about the necessity/relevance of Slackware when v10.2 was released. The over-riding point I tried to make was that Slack was still relevant and the reason it is, is because Pat follows his own set of standards, namely, simplicity, reliability and stability.
While I agree that all the derivative distro's will follow suit (like Ubuntu), I really doubt Slackware will adopt something just because Red Hat did. I seem to recall a nice little debate here on
Personally, I think this whole thing is waste of time until all (or an overwhelming majority) distros adopt them. Until then, it shouldn't even be called a standard. They're guidelines.
I'm torn on whether a bad standard is actually better than none. I don't think the problems lie so much in the LSBv3 standard itself, as in the poor management of the standard that such a young standards body is having.
RedHat is really the company which needs to drive this standard, and while so far they've been doing a lot to do so, its not really in their best competitive interests. Consider that all the major "enterprise" products that folks would want on Linux (WebSphere, Oracle, WebLogic, etc) all specify RedHat as their supported distro.
I think we need to heap scorn on the crappy test suite now, to try and force them to clean up their act before they engender too much negative press and reputation. Once we hit a certain point where the negative reputation builds up, the standard will be doomed forever.
"Despite the original post, it wasn't Debian who pledged to conform to this standard, but the Debian Common Core Alliance [dccalliance.org]."
s .pl?keywords=lsb&searchon=names&subword=1&version= unstable&release=all
;)
Debian has supported the LSB in the earlier versions, what makes you think it would be any different with 3.0.
You can go to their website now:
http://packages.debian.org/cgi-bin/search_package
: and see these.
Package lsb
* unstable (misc): Linux Standard Base 3.0 support package
3.0-7: all
3.0-6: all
Package lsb-base
* unstable (misc): Linux Standard Base 3.0 init script functionality
3.0-7: all
3.0-6: all
Package lsb-core
* unstable (misc): Linux Standard Base 3.0 core support package
3.0-7: alpha arm i386 m68k mips mipsel powerpc s390
3.0-6: amd64 sparc
3.0-5: hppa hurd-i386 ia64
Package lsb-cxx
* unstable (misc): Linux Standard Base 3.0 C++ support package
3.0-7: alpha arm i386 m68k mips mipsel powerpc s390
3.0-6: amd64 sparc
3.0-5: hppa hurd-i386 ia64
Package lsb-graphics
* unstable (misc): Linux Standard Base 3.0 graphics support package
3.0-7: alpha arm i386 m68k mips mipsel powerpc s390
3.0-6: amd64 sparc
3.0-5: hppa hurd-i386 ia64
Package lsb-release
* unstable (misc): LSB release command
1.4-8: all
Package lsb-rpm
* unstable (devel): Red Hat package manager for LSB package building
4.0.4-31.1: alpha amd64 arm hppa i386 ia64 mips mipsel powerpc s390 sparc
4.0.4-31: m68k
Package lsbappchk
* unstable (misc): Linux Standard Base application compliance checking tool
1.3.4-1: amd64 i386 ia64 powerpc s390
: looks like support to me.
Later, Seeker
A bad standard will ensure everyone suffers and everyone does things equally poorly.
I'd rather no standard. People are then not pressured into doing stupid things. Eventually the software people judge to be better prevails and becomes a pseudo-standard. If nothing's significantly better than anything else out there I'd still rather we were forced to deal with the headache of incompatibility than have everyone use a system that is bad and will eventually die.
These posts express my own personal views, not those of my employer