Slashdot Mirror
Linux Standard Base 1.1
Staili writes: "Zdnet is reporting that The Free Standards Group released version 1.1 of the Linux Standard Base (LSB) as well as the first version of the Linux Internationalization Initiative standard to deal with Linux language barriers."
Pardon me, as someone who uses linux, but is not a guru...isn't this the whole idea of "posix compatible"? seems redundant to me.
Tequila: It's not just for breakfast anymore!
I see all the major players are involved too.
so, how many of the major distros are/will be compliant ?
when will I be able to buy a book on administing an LSB 1.1 system ?
Here[wired.com] is an article on wired that i had jsut submitted before I saw this go up...its pretty good, lists some big players. =)
I SURVIVED THE GREAT SLASHDOT BLACKOUT OF 2002!
The LSB is, in my opinion, crucial for the adoption of linux by the average Joe. But who actually follows the LSB? We can create system guidelines all we want, but until they are widely followed, they aren't "standards."
they both give it their 'virtual blessing' accroding to an article on the register
How much does standardizing on RPM as the package format affect systems like Debian? From my understanding the whole apt (.deb) system has a lot of nice features that RPM doesn't... Not that it's a bad thing, I just wonder how much debate went into this particular aspect.
Derek
Don't Panic...
I mean, honestly, don't we already have POSIX? Isn't this what this is really all about? i.e getting a standard out that all unixes can use, with the reliability and scalability to boot?
I believe that linux has partial POSIX compatiblity, but if the kernal was 100% compatible, would we have this "group" of large companies wanting to add features to "ensure" compatibility?
From whatis.com
POSIX (Portable Operating System Interface) is a set of standard operating system interfaces based on the UNIX operating system. The need for standardization arose because enterprises using computers wanted to be able to develop programs that could be moved among different manufacturer's computer systems without having to be recoded. UNIX was selected as the basis for a standard
system interface partly because it was "manufacturer-neutral." However, several major versions of UNIX existed so there was a need to develop a common denominator system.
Informally, each standard in the POSIX set is defined by a decimal following the POSIX. Thus, POSIX.1 is the standard for an application program interface in the C language. POSIX.2 is the standard shell and utility interface (that is to say, the user's command interface with the operating system). These are the main two interfaces, but additional interfaces, such as POSIX.4 for thread management, have been developed or are being developed. The POSIX interfaces were developed under the auspices of the Institute of Electrical and Electronics Engineers (IEEE).
________________________
So basically, we have a standard, not just for Linux, but for all *NIX's (BSD, IRIX, Solaris, etc) And this geat consortum wants to make a new standard. Hmm, I hope it doesn't break the thousands of programs already out there. I mean, I could live with a re-compile for quite a bit, but this Linux consortum is honestly going to have to come up with something pretty convincing to show me that this compatibility is not going to be broken.
From the Linux Base website:
A lot has been said of late regarding the possibility that Linux will fragment into incompatible versions. Some of the speculation has been well reasoned, some not.
The least credible argument has been that Linux will fragment because UNIX did. This completely ignores the market dynamics that caused UNIX to fragment, and
consequently why these dynamics do not apply to Linux. UNIX was a means to an end, and the end was to sell unique hardware solutions. Linux is the means to a
completely different end - a free (as in free speech), reliable, scalable open source solution. Linux is, in a sense, an end unto itself.
_________________________________
Ok, I can get that, but UNIX (as long as it was POSIX compatible) never split up to the point that it was completely unusable across platforms(and I am talking about CLI, not window managers)
Blah Blah Blah.
A Linux distribution can consist of 90% software not covered by the LSB. Therefore, it makes no sense to discuss "administering an LSB system".
LSB is about minimum requirements for a distribution in order to make distributions more compatible, i.e. it's about deployment. If you distribution is LSB 1.1 compliant, then you should be able to install all software that only requires LSB 1.1. compliance. For a start, this will not cover ordinary GUI software.
In order to create a long-lasting standard, you cannot cover issues that are constantly changing or under development, so don't expect LSB to cover a whole distribution anytime soon. But LSB is an important step to make sure that distributions don't fork into something incompatible.
You are forgetting that the Linux which to
which you are referring is actually GNU/Linux.
Linus and Alan have nothing to do with the
GNU part (ok, they have something to do with it but not in this particular case). The LSB doesn't describe the API of
the kernel; it describes for example how
files are being layed out across the filesystem
- In Memoriam: Jeroen de Bruin (1972-2004), bye bro
you don't get it.........the structure of how the distro is layed out is not based on code (other than that of the installer) it is based on where the distrobution creaters what to put stuf, and how they want to link things, and how they want the directories layed out.....it is the structural placment of the programs......code is darwinian, but you need to have certain aspects remain the same.......the lattest stable glib, the latest stable KDE/Gnome, etc.....that is all...this will just put all the distrobutions at the same base at the same time......and the LSB will update as frequently as needed when a new stable library comes out.....
I am the Alpha and the Omega-3
well, maybe this won't happen on this release: since this is the .1 release instead of .0, it'll be mainly bug fixes; everyone knows .0 releases suck ass.
FreeBSD for the impatient.
ANYONE start using it! Preferably everyone.
Some people will say well what does this does to debian/apt. I say nothing. Apt is not dependant on using deb as evidenced by apt-rpm. Debian can adapt the Connectiva apt-rpm package and switch to rpm's rather easily (unless they are too pig headed). Also, does LSB compliance not allow you to use other packages as well as accepting RPM's?? That way debian can stick to debs for the short term, and switch to RPM's in the long term. Then at some point in the future, LSB can change the spec and require RPM only.
I would also like to see apt or some advanced package manager included in the spec as well. Apt kicks major booty and takes away the dependency hunt.
Gorkman
Would it actually be "GNU/RSB"?
In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.
As for the RPM part, I would assume it is because it is
almost a de-facto standard (sorry Debian people/deb-users).
The number of RPM users outnumbers by a fair margin the
number of deb users. Instead of driving all the RPM users and
RPM-based distros from all jumping into deb, they call for a smaller
number of users and distros to take up RPM.
Yes, I like virtually all other RPM users, have been in RPM-dependency
hell. This shouldn't be a problem inherent in RPM. Surely there is a way to
"apt-get" RPMs and handle their dependencies just as well as with apt-get
and deb?
Overall I like the spec. I'd like ANY standard spec, particularly for the filesystem /usr/bin instead of /usr/local/bin (or vis versa).
layout. I would like to know that no matter what distro I install I will ALWAYS find file x in
/etc or binary y in
In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.
I almost hate to do this but, I think Mandrake REALLY needs to start reading this and taking it into account. I've been using MDK for a few years now and I do really like the distro. Hell, infact, I'm burring the 8.2 beta2 right now. *BUT* one thing that makes me REALLY hate what they do is all this -mdk crap. Even something simply like the Kicker Menu icons are all stored in -mdk locations so no source that you use will get the icons right without you making symlins all over the place. And even when you DO make all the symlinks and copy stuff to MDK's locations, next time you install something, their RPM's will run "update-menus" and "fix" all their locations to their liking. THAT makes me not too happy.
/usrshare/applnk-mdk-simplified/.hidden/Configurat ion. Not the two big problems there. First eh mkd specifck location and then a HIDDEN dir on top of that.
For instance Mosfet's Liquid theme. He has a kcontrol module that he uses to control his theme. You can't have it on MDK if you don't copy his module to (something like, I forget):
It's this sort of thing that (my understand is) the LSB is supposed to help "prevent". I wish MDK would follow it. I think it would REALLY help the newbies if they did.
I'm not a prophet or a stone-age man,
I'm just a mortal with potential of a super man.
To notice that Mandrake, which is the most internationalized Linux distribution in the world, is not part of the li18nux initiative.
Also strange to notice that the logo used at li18nux website ressembles much to the one used for years at Mandrake's i18n main page! Anybody knows why Mdk is not part of the li18nux initiative?
They do NOT standardize on GNOME. GNOME is mentioned ONE time in the entire LSB-document, and that is as an example for a packagename ("lsb-gnome-gnumeric").
They DO however standardize on RPM, which is fine, because almost all distributions use it. Debian probably only have to make sure they support RPMs as well as debs, something they already do through "alien". RPM is also in the Debian-repository.
There is a sizable set of tools used in the construction of Debian that are tightly tied to .deb packages.
apt is only the start of the "advanced" aspect of package management; what's far more critical are the set of development tools, like lintian, debscripts, jablicator, deb-make, deb-helper, equivs, dpkg-dev, apt-move, and such.
Eliminating all of that would be like telling the Linux kernel developers that they have to stop using C, and write Linux in assembly language.
It's not simply apt-get that "eliminates the dependancy hunt;": in order for the set of packages to be kept coherent, so they're not merely a jumble of RPMs of dubious provenance strewn across the Internet, you need the development tools.
To move Debian to RPMs would require rewriting all those tools for RPM use. There's merit to such an idea; if there were coherent tools for dealing with the development of a complete RPM-based distribution, you'd doubtless get better stability. But that's a big task, and your non-recognition of the issue doesn't make it go away...
If you're not part of the solution, you're part of the precipitate.
Sounds to me like Debian is a little too tied to it's package format. And now it'll have to support 2 package formats to be LSB complient. In addition, none of the debian .deb packages can be considered LSB complient since they are not .rpm. In my opinion, too much time has been wasted on .deb, and anymore time wasted on it is time wasted. Going forward, packages HAVE TO BE .rpm to be standard and cross LSB compatible, which is a good thing.
-- these are only opinions and they might not be mine.
"Yes, I like virtually all other RPM users, have been in RPM-dependency hell. This shouldn't be a problem inherent in RPM. Surely there is a way to "apt-get" RPMs and handle their dependencies just as well as with apt-get and deb?"
Yes, there is. Apt can handle rpms as aptly as debs, as shown in Connectiva's apt-rpm. The thing people always seem to forget, though, is that, while apt is a wonderful tool, it's not the (only) thing that makes installation of packages on Debian so sweet. What makes apt really, really good is the blood, sweat and tears of the Debian package maintainers, who are amazing when it comes to handling dependencies in packages. Sure, the dependencies sometimes break in testing and unstable, but on the whole it works amazingly great.
:wq!
For RedHat, MandrakeSoft, Lycoris (Redmond Linux), Xandros and any other distro leader out they're to get involved to make Linux a better place for the average user. It would be nice to be able to click on a ONE link to download a program/driver off the net and not have search though this list. I'm sorry but it's time for a change... It's hard for every day people install programs and It's a pain for developers to repackage there binaries over for each distro. If you have time people check out Fiorina:
Linux not a threat to Microsoft on cnet. You'll it under January 30, 2002 but there Fiorina talks about how we are fighting Microsoft, but she saying what I been trying to tell my friends all this time.
We need to build a better desktop and stop bitching about Microsoft. We need to put our time into something better besides bitching about Microsoft because the only way we can beat them is to build something cleaner, faster, easier and better then what they have now. So MandrakeSoft, Lycoris and Xandros you want the to be the king of the desktop well you better to start looking that the LSB 1.1 because you are not going to get anywhere with your just putting the newest KDE, GNOME and X11 on a CD and calling it Linux 8.x. I can tell you one thing I had a friend that switch back to Windows because it was as hell to install programs and to get his hardware configure. I was helping him maintain his system, but when I got busy with doing work on the weekends trying to help my friend out on this website I couldn't be their to help him with his system. The sad thing is I'm very happy to see that he switch back to Windows, hell I been using Linux for 2 1/2 years( no duel booting for 1 1/2 year ) and been thinking about it myself. I been paying for games/software and supporting the companies out there but it's not doing any good if you got some open source bigots are going to warez sites or newgrounds for close source software for Linux that's not GPL or FREE. Flame or mod me down if you like, I'm just saying what's on my mind. I'm a programmer for a CBT company and I love programming, but I got bills to pay. In the end it's all about money and what's the next big thing.
From Zero to Hero... Starbuck Zero
If you were to actually read the standards document, the requirement is:
Distributions must provide a mechanism for installing applications in this packaging format with some restrictions listed below. [2]
And if you were to look for note [2] you would find that it reads:
[2] The distribution itself may use a different packaging format for its own packages, and of course it may use any available mechanism for installing the LSB-conformant packages.
The point of LSB is to allow third party applications to be portable across distributions. That does not mandate anything about how a distribution chooses to package the Linux kernel, GLIBC, or much of anything else that it itself chooses to package.
Indeed, nothing mandates that an LSB-compliant distribution even has its own packaging scheme. A distribution could have all the components required by LSB in all the right spots, and just plain put them there. No "packages;" just files.
If you're not part of the solution, you're part of the precipitate.
The ans wer is, by the way, that it doesn't affect Debian in any meaningful way.
Read the standard; it's not particularly painful to read.
A much more entertaining thing is to think about how this might affect folks using FreeBSD It is entirely possible that this standard allows FreeBSD, which is conspicuously not Linux as well as not based on RPM packaging, to nonetheless become a nicely "compliant" Linux Standard Base platform.
Heck, Microsoft might be able to modify the "Unix Emulation" environment they have running on Windows NT (it's sold as something; I don't recall the name...) become compliant with LSB
This wouldn't be any stranger than when Microsoft made Windows NT a "POSIX" platform, or when IBM got OS/390 certified as a Branded Unix (tm)
The notion that this creates some massive problem for Debian is just plain ignorant, and when the article links to the publicly-available-on-the-web standard, being so ignorant is quite inexcuable.
If you're not part of the solution, you're part of the precipitate.
You won't find one. There isn't one.
This actually has a really entertaining implication, namely that despite saying "Linux" a lot, the standard hasn't anything forcibly to do with Linux.
The notion that this standard has much of anything to do with the Linux kernel is desparately ignorant of a reading of the standard.
If you're not part of the solution, you're part of the precipitate.
I will no longer be able to design my software to install in /usr/local//bin/
if I wanted it included in a major distro?
Or does that mean that the distros will have to adapt the software to the standard?
ACK
For that matter, FreeBSD could comply with LSB without either:
Look at the standard; it specifies nothing about what OS kernel you are using.
Again, look at the standard. The set of package names to be managed by RPM, which runs on FreeBSD, is intentionally completely disjoint from any set of package names being managed "natively" by the distribution.
Careful reading of the standard shows that there is no requirement to be running Linux in order to conform with the standard. You could conceivably run some other kernel, like those from FreeBSD, NetBSD, Sun, SCO/Caldera. I'll bet it's at least theoretically possible that Windows NT with the "Unix emulation environment" could be made LSB-compliant.
If you're not part of the solution, you're part of the precipitate.
Okay, I'll bite...
:D
;D
"so there in the future when we finish our warp-capable ships, we can all speak the same language (which Star Trek has shown us is English)"
You mean you didn't see the episode of Deep Space Nine where the Universal Translator (UT) took a while to figure out a new language? Star Trek isn't standardised on English, we just hear the English feed from the UT, although everybody speaks their own language.
"they should go ahead and formalize a standard language, too - Eurenglish"
No, they already have a language, it's called Esperanto. Not many people use it. The EU has official languages, three of them: Engish, French and the language of the current presidency. German translations are also normal in respect to them being the biggest country.
"Besides, since English has been formed by absorbing other languages and terms from other languages"
So have most languages. English has common roots with most other western European languages.
"Besides, "foreign" languages are just like encryption, and everyone knows that encryption is only used by criminals...
Isn't English a '"foreign" language' to most foreigners... perhaps making you a criminal!
"On the other hand, maybe a link to translate the post into $USER_PREFERED_LANGUAGE would be helpful, with a preset for the language, and a selection during the posting screen. "
An excellent suggestion.
That's exactly what /usr/local is for - locally compiled software. On most GNU and GNUish software the author sets it up to install to /usr/local by default, but you can do ./configure --prefix=/usr if you're building a distro package.
I don't know what other distros are like about this (I've only ever used Mandrake and Debian, and I didn't get experienced enough with Mandrake to know any of the internals), but Debian source packages come in two parts - a tarfile of original, unmodified source, plus a .diff.gz file containing the changes ("Debianizations") the Debian package maintaniner made to make it fit in with Debian conventions (moving all documentation to /usr/share/doc/name-of-the-package, for instance). If the original author's makefile or other code doesn't conform to Debian conventions, the maintainer will change it so it does.
For a program like you describe where (presumably) /usr/local/bin is hard-coded somewhere, the diff would include replacing that with /usr/bin - you, as an "upstream" developer, can probably make this easier by defining PREFIX to /usr/local and always referring to "$PREFIX/bin" and so on.
Any linguist will tell you that English is a crappy language to standardize on.
Look at LSB mailing list, and see how many times Alan Cox has posted in just the last month. I count 23, myself.
Why? English's sounds aren't too hostile - the dental frictaves and affricates don't compare to the complexity of a tonal language, nor does it make distinctions on unusual properties, besides voiced/unvoiced. It's an Indo-European language, meaning more children learn a language in that language family than any other, and many people in many places already know it, a definite plus. On the downside would be the unusual spelling system, but it's survivable. Grammatically English is fairly normal, at least for an IE language. Where's the crappiness?
The ans wer is, by the way, that it doesn't affect Debian in any meaningful way.
I disagree.
* The standard does not require that Debian drop its own packaging scheme.
* The standard does not mandate the use of RPM packaging within the distribution.
The standard mandates that RPM is the preferred packaging system for people creating applications to run on Linux. Debian;s LSB support is based on the existence of Alien. I don't know too many Debian people who would trust alien to install large parts of their system.