Slashdot Mirror
Linux Standard Base .9 Released
The Linux Standard Base is in the final stages of the LSB written specification for Linux. The workgroup has published the LSB v0.9 written specification, and is undergoing a 30 day Request For Comments from the public until Wednesday June 6th, 2001. Afterwards, this draft will be submitted to the Free Standards Group for adoption.
http://www.linuxbase.org/spec/lsbreview.html
The LSB is built on pieces of existing standards that are widely used by the industry and supported by the development community. These include:
- ELF & TIS 1.2
- FHS 2.1
- ISO C90 & C99
- LFS 1.5
- POSIX.1
- POSIX.2
- SUS (CURSES, XBD, XCU, XNS, XSH, XSH95)
- X base interface standards
Work is primarily being done by the development community and the major Linux distributions including Caldera/SCO, Debian, Mandrake, Red Hat, SuSE, and Trubolinux. Further contributions have come from IBM, Intel, Linuxcare, Metro Link, VA and others.
The goal of the LSB is to develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant Linux system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.
http://www.linuxbase.org/
The LSB is but one of several open source standards efforts run by the Free Standards Group, a nonprofit organization founded by community developers to accelerate the use and acceptance of open source technologies through the application, development and promotion of standards.
http://www.freestandards.org/
Dumbass, can you read? It says "not officially" and "de facto". Get a dictionary.
If XML is going to be standardized, then why not have everyone switch to "standardized XML" configuration scripts? Why not make it EASY to parse, read, and LDAP/RDBMS config files? Why not have config file versioning control? By making Linux Standards Base config files all be XML, there could be a BIG win in the administration of Linux boxes. Lots of good tools could be made (GUI, CLI, RDBMS, LDAP, etc.) to take that into account. Right now, though, everyone has their own way of writing config files, so it is difficult to get everything into a database.... I have heard of people putting all of their configs in LDAP, but it would be *SO* much nicer to keep plain text files that could be manipulated by tools, etc.
LSB standardizes on System V style init scripts. Slackware uses BSD style init scripts. The Slackware developers talked about moving to System V style, but the idea was unpopular with the user base, who considered it one of the major points of differentiation between Slackware and the other distributions.
In that the "Linux standard base" specifies nothing about the Linux kernel, but how userland files, system utilities, and configuration data should be layed out and installed on a file system, shouldn't this really be called a "GNU Standard Base", or at the very least, "GNU/Linux Standard Base", as this specification has far reaching implications on many of the GNU packages that make up "GNU/Linux".
This specification actually says very little about the kernel itself other than where the boot image may reside and where the modules directory may be found, and in fact specifies nothing that need even be relevant to a Linux based GNU system at all. Substitute Hurd as the kernel, or even something else, and most of this document could still apply equally well.
Offtopic, karma to burn, flame-war starter:
:)
A discussion went on on the trip home between me and a couple of other guys from my work about RPM vs. DEB. Basically it was put forth as such:
"Why doesn't RedHat just dump RPM and go to DEB?"
And why not? I'm not a developer of packages, so I don't know the differences between building a deb vs rpm, but what are the technical issues surrounding converting a redhat distro to RPM.
Yes, a lot of paths would have to change, and some other additions and subtractions would have to be made. Do debs support signing as RPMs do (or so I've heard)? No clue.
So from a technological, NOT a religious, view, why not?
Regarding the LSB move toward RPM (or at least indication), I think that's a very bad thing. Either put a lot of evidence and ask a lot of people which is better for linux, not for who is contributing the most $, or choose none at all.
Yes, I'm a debian user and have been for about 5 years now. I've played with redhat and mandrake) on occasion, and my experiences have been not good, not to do with the install (awsome) or the system (not what I'm used to but nothing wrong with it) but with RPM.
IE: I need to install rpm of package foo. Get package foo, try to install. unmet dependancies, get dependancies, install them, get more unmet dependancies. bitch on irc. Someone suggested using rpmfind. get rpmfind rpm, install, get unmet dependancies.... continue until hands were thrown up in the air and I gave up.
Now that's my experience, and as a debian user I don't know all the cool places to get the rpms I need, just as a redhat user when thrown in front of a debian box probably wouldn't know how to set up a sources.list from scratch or where to get xyz information. But I digress
Basically I think that deb, while still not 100% (signing, ssl support, plus whatever features it still needs to make it feature for feature the same as RPM), is still better than RPM as far as functionality. My vote is to either
a) make a judement based on technology
b) make no judement at all (which they've done)
c) don't lean one way or the other (which they've done)
Well, --nodeps works fine if it's the RPM being a PITA, but if the dependancies are actually needed...
:)
Besides, this is the Wrong Way(tm) to do it. I remember talking to the Helix Code guys at the last LWE I went to and how they shuddered every time someone "fixed" their install problems by just doing --no-deps.
Besides, wouldn't it make more sense to make a better distrobution mechanism so that the automatic response for people who have RPM problems is something other than --no-deps? I've used --force-depandancies exactly 0 times since I started using debian, and --force-overwrite approxitely 10 (for unstable packages that I was playing with).
This is why I'm bitching about RPM
rpm foo.rpm -Uvh --nodeps :)
Doesn't Conectiva have rpm-based apt?
The whole idea behind the LSB is to provide for a predictable minumum functionality.
:)
While it may be nice to have a whole bunch of bells and whistles like Java specifications and thouroghly debated package managers, it's more important to get a least common denominator first working draft on the table now.
Let's have some orderly anarchy here ok?
Codifex Maximus ~ In search of... a shorter sig.
I think Linux should migrate to using Donald Knuth's METAFONT for all its font needs. ;-)
-Paul Komarek
(please note at this time, if you are going to post a "C rocks! We don't need no stinkin' C--!" please don't. I could care less what you think about the C/C++ holy wars raged by various loonies)
C++ is heavily used in the industry, and especially in Windows shops. If Linux industries want to steal that developer-share from Windows, they need to hammer out what C++ libs and standards compliance will be considered a part of "standards compliance" linux.
Is the absence of C++ standards due to gcc not having a ISO C++ compliant release? I know that 3.0 is in the works and that Red Hat ships a snapshot of GCC in an attempt to get better libstdc++. Is this lack of a viable free option the reason for no C++ standardization?
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
Debian definately is the only one with FREE automatic upgrading.
Now see that's a feature I'd be willing to pay for. Debian has a great service contract option with the automatic updates.
"The intent is to in the future replace this format with a new format currently being developed." Anyone know what the new format is. All they really need to do is specify what the /var/lib/packages unified format is. Then rpm and apt-get could be modified to use the new unified format. And you can use either tool, and possibly even the old .rpm and .deb files.
AND, you can still roll your own. They haven't made a nice lil /etc/roll_your_own_compiler_defaults yet, which would be cool cause then you could just dump in -O6 and other goodies.
-l
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
Few questions (I really don't know the answers):
-- I am not a fanatic, I am a true believer.
Somebody asked about designing it. Well here goes:
Fonts are stored in /usr/share/fonts and /usr/local/share/fonts. FreeType, GhostScript, X, and all other programs that load fonts are modified to look for all their files there.
The files are all of the form .. is a USER FRIENDLY name that can easily be typed and rememberd. The extension is used to distinguish various incompatable font formats, or different transformatons of image-based font formats. Systems that don't understand an extension ignore those files as though they are not there.
Fonts may also be stored in subdirectories, but in this case the "name" has slashes in it, so the services can just consider them normal file names.
Font files are found by a service taking the user-friendly name (X servers will have to extract a few fields from the ugly X name to get this) and tacking on each extension the service understands and checking if the file is there. There is no need to use readdir to get a specific named font. Services can assumme that once they see a font, that file will not be changed or disappear, although they may want to check the date stamp every now or then.
Services that need to search for fonts will have to recursively readdir the entire directory tree. They should be written so they don't do this on startup but instead delay it at least until the first font is requested. They should record the datestamp of the root directories and rerun the search if it has changed. Services are allowed to create their own cache files but they should create them in some other directory, as they may have read-only access to the font directories.
Multiple names for the same font (like "Ariel" or "helvetica" for "Helvetica") are done with symbolic links.
Yes it is quite likely that the first implementations will ignore each other's fonts. I expect they will gradually start to read each other, and that obsolete formats will disappear, and eventually there will be one file for each font.
Okay, the files should be of the form [name].[extension]. [name] is a user friendly name, ie something that a person of average intelligence may type, like "Helvetica". An example of a non-user-friendly name, which is not allowed under my design, is "adobe-helvetica-bold-normal-p".
[extension] is the user-unfriendly part and each font using service looks for a set of extensions it understands. Examples are "pfa", "ttf", and maybe "xfont.25.25" for an x bitmapped font that is designed for a pixel size of 25 vertically and 25 horizontally.
Just chop off nine fingers and one fingernail.
--G
I think that the whole packaging issue is quite a problem.
.deb format is played down.
I would also like to point out that one of the earlier threads on the "de facto" status of RPM in the standard was marked as a "(-1 Troll)". If people aren't open to this kinda of discussion, progress won't be made, and we might as well go back to bowining to the great satan of software.
I personally think REDHAT has a large investment in the automatic updating through their "redhat netowrk" and apt-get very much threatens that cash source. I think that is one of the reasons that the
And what major distrobution supports this?
Debian definately is the only one with FREE automatic upgrading.
same question as above.
What major distrobution supports this?
I'll give you the spec files, but that is an advantage for the author, how about for a user. Why should an end user care about this?
Yes apt-get has been made to work with rpm, but what distro has decided to set this up for their users to use it. Certainly not Redhat, they are trying to make money on the service (not that they shouldn't make money, I just quesiton if this is a good way).
I agree with your long run conclusion, and I agree that it will be hard. The most annoying thing about RPMS for me, is that it is ESPECIALLY hard to find RPM files to fill dependancies when you take the RPM from a third party source. (NOTE: RH network is not a solve for this... as it costs cash. Using an IS person to look things up is also a solution for this, but I didn't use it either as it also costs cash.)
Debian also may create some dependancy problems, but at least it tells me, so I don't spend forever looking for the file to make everything work.
I'm not against paying for things, but quesiton wheather this is a good way of going about things
It seems alot of companies are setting themselves up to use this method (ximian, nautilus, redhat, microsoft.) I am not against subscription service, but subscription updates, are questinoable as a method for making money, in my opinion.
I look forward to seeing what other services are started as subscription (but I only see this coming from ximian and nautilus, and I'm sure they will have differant systems, and not be on friendly terms.)
It would seem to me these companies would do better to offer subscription support and then use a common, open source, subscription service for added features (remote backup, remote CPU power).
The reason I see the open source business model (and the free software model) working is that 80% of most software projects spend 80% of their time in the support/update phase of a project.
IBM/Aurther Anderson/E&R/Deloit and Touch(or whatever it is) all know this. Micro$oft knows this, but wants to charge you incredible amounts of money for it.
I re-iterate, I do like redhat and some things they do. This rant makes me sound harder on them than I am.
yes...
de facto - In reality or fact; actually.
This debate wouldn't exist if it were in fact the standard.
He's not a dumbass,
De Facto means "in fact".
While De Facto can mean unofficially, it meaning has a connotation that would imply that it is more factually corret. (for example a De Facto governemt might not correspond with the legal government, but is IN FACT where the power lies) Why do programmers always overlook the connotatino of words?
I imagine there are lots of non-RPM users who would like to dispute this "fact".
If this is actualy true, that RPM's are "in fact" the standard, why is this debate occuring?
.debs now too.
.deb distro's, and it would cool some people's ire (including mine), if they would change the wording from "DeFacto", to "most prevalent".
Based on my experience, as I said above, RPM's USED to be alot more prevalent than they used to.
Maybe once upon a time they were the defacto standard, but alot of projects seem to be providing
Windows was once upon a time the "De Facto" operating system for PC's, I think you would agree that they are loosing this status, can't claim this completely any more. I believe RPM's fit in this category.
As for naming things after the distrobution, where did the name Redhat Package Manager come from?
Since it has been about a day, I've had some time to think about it. I guess I'll send in my comment asking that they, at least point out that if you make sure your RPM's works with alien it will help the
Now I just have to go fill out the form.
BTW to whoever it was that was trying to dismiss these comments by pointing out that we hadn't been part of the whole debate and what not... Why did they ask for public comments if they didn't want this type of conversation to take place?
Focus on the solution, not the problem!
(but I'll still be surprized if a new packaging system comes out that really helps everybody)
Debian, Libranet, Progeny, as well as two other distros that don't exist any more., use Debs and APT get, That's great, but OT. APT get isn't easier to use than RPMs, its easier to use than up2date, merely because there's no mirrors or vast quantities of unsupported packages. Which can be fixed pretty easily.
.deb, to give a full picture in the standard. Afterall, as they point out, there is no standard. Why not give a full picture of the situation instead of being one sided?
ok.. I'll accept some of thse facts
Mandrake and Connective also use APT, and Mandrake likely has more users than all the other distros mentioned here combined.
But does it work with RPM v3? (the one used in the document)
Every Red Hat machine can update packages with automatic dependencies.
As pointed out below, can you suggest or recommend? How? And do I have to pay to get this to happen with Redhat? (honest questions)
There is nothing specifically tying APT to Deb. However, there are far more than 4500 RPMs that are actively maintained, and far more users of RPM based distributions.
Agreed, if somebody had another distrobution that could do all the package-updating that debian can, I would listen. (As for the 4500, I can make alot of crappy Packages to inflate my package count number too)
All this is beside the point, my point is that the phrase "de Facto" should be "most prevalent", and it would do them some good to mention "alien" and
How would you feel if somebody said "Windows is the De Facto OS on the PC" and didn't mention anything about Linux/BSD? Especially in a document that was supposed to set a standard for the PC?
Why did they ask for public comments if they didn't want conversation like this to happen? Even if it is from people who haven't looked at the problem for as long?
"Stop shoooting your mouth off" is the call of a person who either dosen't want to debate, or dosen't have the knowledge to do so. You seem knowledgable, so I'm going to assume (and hope) that you simply are tired of the debate. If this is true.. that's fine.. don't participate.
Wow.. thats interesting.. Personally, I had heard of Debian before I'd heard of RedHat (yes I was using back then.. yes I started with slackware).
As I've pointed out elsewhere, what I would propose is replacing "de Facto" with "prevalent" (as that would not have the "corrective" connotation). It would take care of this kinda "who's older and bigger" war.
Mention a few of the other packaging formats (including deb) and point out that making sure your rpm works with alien can indeed make you even MORE compatable with more distros. (after all, interoperability is what this is all about, isn't it?)
Does the redhat network feel threatened by things like apt-get? (honest question.. I said that I thought that above, but I'd be curious to know what an actual person from the company would say.)
They should point this out in the document. :) )
Understanding why a standard is the standard is almost as important as the standard itself.
(if I say standard one more time... DOH.. too late
Is a standard always set by the majority?
Is Windows the standard PC Operating System?
I'll have to check that out.
The thing I'd point out is that after seeing some of the intent it is clear that some of my questions are inflamitory (this can be said without even looking at the FAQ yet), having looked at the standard I found no statemnet of intent in the introduction, and found words that had heavy negative connotation in the document wrt packaging.
If I'm representative of folk that are not part of the project, but interested in the issues, it would behove you to at least provide a statment of intent. This would show us dimwits, who haven't been paying attention, that one part of the community is not trying to pull something over on the other side.
With the recent tactics of MicroSoft, trying to drive a line down the middle between the Free Software types and the Open Source types, it is probably very important to get the politics right, as well as the standard itself.
So with rpm 3 or 4 I can get the full functionality of apt-get (recommends, suggests.. and all?) Also, somewhere somebody should explain that these RPMS can work with alien.
Up2date free for one machine.. as apposed to apt-get free for 0 to infinity machines... that's a tough choice.
As for the 4500, I was refering to the fact that you said there were more than 4500 RPM's. Half of them don't install easily is my experience (thus my comment about being able to make crappy packages to inflate my count too).
Ease of use should be just as heavily weighted as a determinig factor, as this is what keeps or looses beginnning end-users.
I agree, while they point out there is no standard, they do not back up their reasoning for using RPM as the supposedly "de facto" standard.
.debs than used to.
As RPM is the reason I originally left redhat to go to debian, I would suggest that they should either support their claim, or they shuold remove the suggestion.
In practicality, RPM used to be alot more dominant, I find that alot more projects are supporting
I think Redhat is trying to promote its "redhat network" as sees Debian's apt-get as a significant problem.
I normally do not like to talk about distribution being against distribution, but in this case it has already been done and I am just pointing it out.
I use Redhat in some cases and appreciate all that they do. I just see this as obvious manipulation.
1. a standard location for fonts
2. a standard lib that renders the fonts that
a. X Windows uses
b. ghostscript uses
c. anything else uses (StarOffice, Tex ?)
3. anti-alias support (yes, X4.0.2 has this, but you have to explicitly use it)
4. You don't have to do anything other than copy a font file to the aformentioned standard location to get it recognized by everything!
5. Maybe, an extensible font library, supporting some sort of plugin architecture for adding new font formats.
I've hated RPM since day one.
Getting a tarball and making it yourself is the best way to do it on Linux
The *BSD family's /usr/ports/ is a great idea and works great in practice. The source is brought in, dependancies as needed, and compiled for your box (See http://www.freebsd.org/ports/ for more info on that)
Trolling is a art,
What gets me is that the two formats being discussed are named after a particular distribution (DEBian and Redhat).
Indeed choosing one over the other would give substantial credibility of a distribution as being "the standard" distro.
load "linux",8,1
From dictionary.com -
There's no "supposedly" about it - RPM is the de facto standard.
And yes - .debs rock my world and yours. And if they hadn't named the fool things after the distribution, more Linux distros would probably have picked them up by now.
The idea is, Debian should just drop .deb packaging and catch up with the
ease, power and user base of RPM.
thats just it. i've used both and i would agree that rpm has a larger user base but i would dissagree with the power and ease assertations. apt-get is much more powerful and easy to use in my opinon. for this reason i think it should be given more consideration. if you do things based on sheer numbers then everyone should use microsoft since they have a larger market share.
use LaTeX? want an online reference manager that
-- john
i'm not shooting my mouth off. i didnt slander rpm's or redhat. i simply stated my preferences and concerns.
so what is the new packaging system? i wish they would have provided a link or some other information.
use LaTeX? want an online reference manager that
-- john
well i've played with rpm and apt-get. from the page
Currently the LSB does not officially specify a package format; however, the recommended package format is RPM (Version 3) with some restrictions listed below. RPM is the defacto standard on Linux and supported either directly, or indirectly by the widest number of distributions. The intent is to in the future replace this format with a new format currently being developed
i really think more consideration should be given to the debian system of package management. it appears both redhat and debian are contributors, but i would imagine redhat contributes a bit more. i really think this is going to hurt things.
use LaTeX? want an online reference manager that
-- john
...because those maintainers in a position of authority (mostly the Steering Committee) have been too busy getting 3.0 ready for release. Herb Sutter had contacted the GCC list but apparently got no reply.
The last releases, 2.95.x, as well as RH's snapshot-based spinoff of 2.96, all shipped with the old, nonstandard, noncompliant v2 C++ library, which has been mostly unmaintained for years.
Everybody's been working on the rewritten-from-scratch v3 C++ library, which has ISO compliance as its primary goal and criteria. If you get one of the nightly 3.0 build snapshot RPMS, you'll find that the new C++ library is the default.
When will 3.0 be released? Sooner, if you help.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
The Debian zealots are right. RPM does suck compared to dpkg. (Both have deficiencies, however). ... What's a stack?
------
I'm an assembly guru
How can you get a RPM to "Recommends:" or "Suggests:" other packages? I can't seem to find it in the manuals. ... What's a stack?
------
I'm an assembly guru
Your statement was that dpkg "is about as good as RPM". This is false, as dpkg is significantly more advanced. I'll flame people who post "facts" without researching them first, if you don't mind. ... What's a stack?
------
I'm an assembly guru
That this project doesn't go astray or become another one of the 10,546,673,132,895,345,923,566 neat sounding projects to bring the hopes of Linux users only to falter somewhere down the line due to ego's, vendor differences in opinion, lack of insight, etc.
Well not to be a troll or say something out of place to the Linux users out there, but I think at this point Corel can come off that page (you think) lets start things on the right foot with an up-to-date site.
Want Root?
Debians packaging system is .deb. Its about as good as RPM. Some people say Debian packages ae easier to create, others think RPM has much better package verification options.
APT...
* Is designed to cross platform and packaging system independepndent
* Is both, as of about half a year now.
* Currently popular on Debian and Progeny,also avaliable on Mandrake 8 (this distribution likely has a larger installed base than Debian) and Connectiva.
Compare Deb to RPM, and the difference isn;t that much. There ARE more RPMs about - yes, more than the 4500 deb packages. In case Debian users didn't realize this, their distribution only includes free software. Sometimes commercial software (shock-horror!) is the best tool for the job, and in most cases, Deb's don't exist.
LSB will go RPM. Its inevitable. And every single RPM based distro will have APT or APT like capabilities within a year.
IE: I need to install rpm of package foo. Get package foo, try to install. unmet dependancies, get dependancies, install them, get more unmet dependancies. bitch on irc.
Agreed 100%. But this isn't an RPM complaint and has very little to do with RPM versus Deb packaging formats. They're to do with add on tools and where software is hosted.
Automatic dependencies are already sorted out via up2date. What you need is a large repository of unsupported packages designed to work with your distribution.
I'd like to start something myself in this area. Anyone want to lend me a hand?
You still don't respond - APT isn't Debian specific and was designed to be independent of packaging systems.
Debian, Libranet, Progeny, as well as two other distros that don't exist any more., use Debs and APT get, That's great, but OT. APT get isn't easier to use than RPMs, its easier to use than up2date, merely because there's no mirrors or vast quantities of unsupported packages. Which can be fixed pretty easily.
Mandrake and Connective also use APT, and Mandrake likely has more users than all the other distros mentioned here combined.
Every Red Hat machine can update packages with automatic dependencies.
There is nothing specifically tying APT to Deb. However, there are far more than 4500 RPMs that are actively maintained, and far more users of RPM based distributions.
userland files, system utilities, and configuration data
Known by most peeple as the Linux operating system, OS being defined by most people as `the program that loads when I start my computer'.
shouldn't this really be called a "GNU Standard Base", or at the very least, "GNU/Linux Standard Base
No, IMO it should not, as there are many others contributors to this OS who put in effort other than the GNU project, and Richard Stallman has no right claiming to be the `maintainer' of the OS as if such a maintainer actually existed. Firstly that assumes the only software ones uses is the shell and GNU utilties. This is extremely uncommon, and ignores folk who who choose a different layer of abstraction (say, KDE, which is not produced by the FSF).
But does it work with RPM v3? (the one used in the document)
.deb. doesn't have).
:I was referring to :-). But yes, quality counts no matter what system is used.
Yes. RPM 3.05 can install all RPM 4.x packages - the main advantage of RPM 4 is transaction support in the RPM database (somethign which
As pointed out below, can you suggest or recommend?
Using up2date, a CLU / GUI app that comes with Red Hat since 6.2 (but is updated quite frequently itself)
And do I have to pay to get this to happen with Redhat?
For one machine, its free. For multiples, you should theoretically subscribe (ie pay, but you can simply create a new profile on the Red Hat Network. Or point the second machine at the firsts list of archives and freshen them.
As for the 4500, I can make alot of crappy Packages to inflate my package count number too)
Um, that's actually the number of maintained Debian packages
Windows is the De Facto OS on the PC" and didn't mention anything about Linux/BSD
Yes, popularity isn't the reason to adopt something, but when two packaging systems offer a very similar rnage of capabilities with no clear advantage, its a definite consideration.
I see no reference whatsoever to Linuxone! I always thought LinuxOne(TM) was working to become the highest rated supplier of Linux solutions based on packaging, support, and product capabilities in the global market
Ok, I'm being silly. I need more coffee
Feed the need: Digitaladdiction.net
Yes, well heaven forbid that we be INCLUSIVE...its better to be a linux-only-zealot and if they ain't running some version of the Linux kernel, it is garbage.
Embracing Solaris/BSD/the Linux layer on Windows would give a 100% effective coverage.
But, the LSB crowd doesn't see things that way.
If it was said on slashdot, it MUST be true!
I remember reading somewhere some time ago that Slackware boycotts this standard, but does anyone know why? I couldn't find anything about it in the FAQs on www.slackware.com.
-Karl
They all use it already - (except Debian (deb) w/recent derivatives (only Progeny is currently active, AFAIR - Corel has stopped, Stormix is broke) and Slackware (no real package system)).
Among the current users are Red Hat Linux, Mandrake, SuSE, Turbo, Caldera, Immunix, Trustix, Connectiva and all of the derivatives of Red Hat Linux.
All of the above has been around for some time, and the userbase of Red Hat Linux, Mandrake and SuSE is much bigger than Debian.
I started using Red Hat Linux in '95, and it wasn't the first release of RHL - Debian wasn't out with 1.0 (actually 1.1) at the time, and was insignificant: The big distro at the time was Slackware. The other major distros have also been around for some time - some spinoffs are a bit newer (like Connectiva and Mandrake).
Speaking of the other old ones: Caldera was Red Hat Linux with proprietary add-ons at that time - they had Looking Glass, a weird desktop thing. The oldtimers around here always wonder how Caldera, with so much money and many people at the time managed to become what they are (a company with revenue of about $1 million, spending $10 million to get there).
As for the packaging format: One of the main reasons for the LSB is to give a vendor/packager the possibility of creating one package and then have it run on "Linux". Specifying multiple package formats doesn't help to reach that goal... Note that being able to use it everywhere is important, so only a subset of RPM functionality can be used (so alien can convert to other package formats (well, .deb - .tgz isn't really sufficient) without loosing functionality required by the package). An example of excluded functionality is triggers.
4-1. ELF Special Sections
So sure there is a standard to put "special" elvens into, but what about the not so special elven?
All your [Linux Standard] bases are belong to us*
*us is defined as:
Including but not limited to Caldera/SCO, Debian, Mandrake, Red Hat, SuSE, and Trubolinux. IBM, Intel, Linuxcare, Metro Link, VA and others.
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
Debian, Libranet, Stormix, Progeny, Corel, and other distros support the deb package system and apt-get. Anyone who has actually used a Debian based distro on a regular basis will tell you that apt-get is far more powerful and easier to use than RPMs. It is easier to install software on a Debian distro than it is to install software on Windows 2000! In fact, installing software is so easy with apt-get, that you might think for a second that you were using a Mac.
Ideal slogan: All your Linux are Belong to Us!
Don't blame me - I voted for Howard Dean. http://dean2004.blogspot.com
The above is a little too convuluted ;-) Will this make development on Linux systems earlier, or is this just an effort to collectively index common linux libraries?
Link your binary application with the LSB's filter libraries found in /usr/lsb/lib to determine at compile time if your application is using only LSB defined APIs.
Link your binary application with the LSB /lib/ld-lsb.so.1 dynamic linker/loader.
Verify your binary application with the LSB's /usr/bin/lsbappchk tool to determine at runtime if your application is using only LSB defined APIs.
If people start writing their programs to comply to this binary compatibility will be something I would consider doing, instead of compiling from source. They guy down my hall who installed linux and asks me questions every time he trys to install software (since they all install differently) could leave me the heck alone. It would be good no matter how you look at it.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
I hadn't heard of this, it is a good idea. The only question is how well they promote the idea. Cause no good idea ever gets very far without some good promotion. So if you are interested in this getting paid attention to, please promote it.
Does it ever seem like the world will collapse from the weight of standards to you? It does to me.
Fragmentation if one thing that stands in the way of people accepting Linux as a desktop alternative - although there are sadly plenty of people who when they think of Linux think RedHat, as it's they're the vendor they've heard of.
<P>
If we can guarantee that our programs will run on any "compliant" system, that's surely a good thing. I'm troubled by the compliance tag, though. I'll have to read up and find out what <I>exactly</I> that means. Overall, this can't be bad.<P>
Tom.
Oh arse
Is the absence of C++ standards due to gcc not having a ISO C++ compliant release? I know that 3.0 is in the works and that Red Hat ships a snapshot of GCC in an attempt to get better libstdc++. Is this lack of a viable free option the reason for no C++ standardization?
I'm grabbing my copy of C/C++ User's Journal, April 2001, which had a Compiler Conformance check (see it online). They have always avoided rating compilers, but now that there is a standard, they decided there was now a somewhat objective means to judging a compiler - conformance to standards. They go on for about 5 pages, explaining the tests and giving justifications for testing. The folks who create the test suites get to comment, the folks who wrote the compiler get to comment, and it looks like everyone involved will work toward meeting the standard in the next release.
Gnu gcc 2.95.2 was tested, as well as Borland BCC 5.5, Microsoft's Visual C++ 6.0, Intel's C/C++ 4.5, as well as 6 others. While just about everyone else commented on the results, there was no spokeperson for gcc.
You'll have to go to the web-site for full results, but here's a few. Three test suites were used, from Dinkumware, Perennial, and Plum Hall. The compiler was tested as well as the library, and results were given as percentage compliance.
Borland
Dinkumware: library - 75%
Perennial: compiler - 63%, library - 67%
Plum Hall: compiler - 89%, library - 74%
Gnu C++
Dinkumware: not tested
Perennial: compiler - 98%, library - 41%
Plum Hall: compiler - 94%, library - 21%
IBM C++
Dinkumware: library - 99%
Perennial: compiler - 99%, library - 97%
Plum Hall: compiler - 95%, library - 85%
Intel
Dinkumware: not tested
Perennial: compiler - 96%, library - 72%
Plum Hall: compiler - 90%
Microsoft
Dinkumware: library - 84%
Perennial: compiler - 77%, library - 64%
Plum Hall: compiler - 83%, library - 74%
You can look up the other number if you so desire.
As you can see, as far as compliance goes, Gnu C++ is pretty good for a compiler, but is lacking in the library department. I find it interesting, and I'm sure the GNU C++ team is looking at the numbers, considering how important the library is to the standard (it really does make C++ more powerful).
Why not have the standard include specifications for multiple packages? When the system is installed, the user could select the default installer to use. Just make sure that the specification is easily extensible so that newer package formats can be added so that older systems won't be forced to upgrade.
science is a religion
Like it says above, it's an effort to standardise Linux distributions' layout, with an aim to ease the use of applications across distributions. It has a standard set of directories which should be used for things like config files and documentation.
--
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
the "open source" model will fail
I get really fed-up with all those people who keep screaming about how the Open Source model will fail. Look around you, its thriving not failing!
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10);'
Like, great if we get a standards base, but how is it going to be USED? Will RedHat, Suse, Debian, etc. offer us a bare-bones LSB install, without all the extras? Will people working on important projects offer a special implementation for people with LSB setups? Will it finally be feasible to have an InstallShield-like program for Linux? Will it be easy or a nightmare to go from an LSB install to one of several kinds of rigs (ie: a server box, an internet browsing box, a gamer's box, a development box, etc.)?
Also, how often do they forsee this base being updated? When new killer hardware comes out, how will this affect the LSB? Will the LSB be so concrete that a new killer ap coming along will shake it to the core and require a complete rebuilding? Or will the LSB be so abstract that it won't be really any use to anybody?
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
While binary compatability is great, one only has to look at shrink-wrapped Windows software to see that Linux is not ready for the average user (AKA "moron"). Take almost any application or piece of hardware and you will see Windows screenshots showing the installation and/or operation. When Linux has no predictable UI and innumerable potential configurations, it is impossible to produce instructions that all users can follow. We can look down on the average user all you want, but that's where the money is.
Work is primarily being done by the development community and the major Linux distributions including Caldera/SCO, Debian, Mandrake, Red Hat,SuSE, and Trubolinux. Further contributions have come from IBM, Intel,Linuxcare, Metro Link, VA and others.
Hmm, well it seems as though a few companies have done some development, however who do you think will be the first to adopt it into their base distrobution? What also comes to mind is package support. Right now it is said that it hasn't selected a package format but eludes to RPM. Does this mean that when others adopt the standard they will have/like to switch to RPM?
The only statement that cannot be questioned, is that every statement can be questioned.
All Your Linux Standard Base Are Belong To Us
Paizurishitetai desu ka?
It uses RPMS and ends with .0, what more do we need to know? I don't trust it, it'll probably load a vga message into lilo and screw the crap out of the mda video card in my server.
err... or is that redhat I am thinking of..
kenny
But I'm so used to counting in Base 10! I mean, I've got counting in binary and hexadecimal down pretty well, but .9? How the hell do you count in base .9?