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."
Linus and Alan Cox aren't mentioned. Surely having the distros agreeing is one thing but if Linus and Alan change things within the kernel this would render the LSB pointless.
Windows manages to have some compatibility between 95/98/2000/XP because the control all of the OS, the distros don't control the kernel.
Interesting to see how often LSB has to be updated to keep up with the kernel.
An Eye for an Eye will make the whole world blind - Gandhi
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.
I installed it and it took over my computer! But then again, I should have known better.
After all, everyone knows that All your Linux Standard Base are belong to us.
------
Today's Top Deals
Okay, I may be the only one on the short bus today, but I simply don't see the value in the details of the document. It seems to be very vague and incomplete. For instance, under filesystem, in which the question of where to put things is something that many people think about at some point. It makes three references to some special files in /dev. And for shell it just says to use a posix compliant one, well no shit sherlock. I'm personally not impressed by making rpm the standard packet format since in my 7 years of linux usage I haven't ever used a distro that used rpm. Like I said, maybe I'm missing the big picture here.
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.
As far as standardization goes, is there any word as to when gcc will be able to compile ANSI C++ standard code? As in: using namespace std; and fun jazz like that. Or, contrariwise, is no one planning to do that with gcc as borland can already? Just asking to know, not trolling, honest.
Call it what it is
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
The LSB standardizes on RPM and GNOME. That's going to sit well with the apt and KDE zealots.
The problem with this LSB thing is, it's too controlled by redhat. Redhat has been one of the biggest problems in putting things in the wrong place and using dumb formats.
If LSB is going to work, they're going to have to start doing things right, instead of how they feel like. Of course LSB can't really be bad, the worst that could happen is just redhat joining it, but I'm afraid that's about all that will happen.
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
This is so needed. Just following a HOWTO doc can be gruelsome, at least for persons who truly needs them (the newbies), due to incompabilities in, for instance, the substructure of /etc, locations of different config files, which may be a hassle to find on your own in the often bloated directory-structures, etc.
/&#!"# dependency issues that comes with far too many installs of software not especially (re)packaged for your distribution.
IMHO, anything that causes more conformity between distros is A Good Thing, though I am sure many would not agree with me. Hopefuly something will be done about the
"Everyone who believes in telekinesis, raise my hand..." - James Randi
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?
EVERYTHING should be in UNICODE dammit! *EVERYTHING*: Sources, texts, executables. That is the only way for completely transparent i18n. I'm tired of having to configure/recompile every single application to display greek characters and then accept greek characters properly.
Looking for people to chat about multicopters, coding, music. skype: gtsiros
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.
... c'est que nous devrions decider sur une langue universelle. Alors, nous n'aurions pas besoin de standardiser sur les distro de linux.
Au fait, maintenant que j'y pense, est-il offensif de faire des postes en une autre langue ici sur slashdot, ou est-ce que nous sommes standardise sur une langue ici?
Juste mes 2 centimes....
Wow! This must be a PERSONAL letter, just for me!
Also, someone should tell Mandrake that a standard UNIX/printer tab is 8 spaces.
You can already install most rpms with the alien tool. So this LSB thing will probably help alien coders a lot.
My point is that dpkg can be used for Debian.
And rpm for addon software.
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.
While the standard does narrow RPM to a subset of commands. The set of commands seems too large, and the syntax of the commands is ambiguous. Should the commands always allow all GNU options or could a subset (like busybox) be sufficient.
.so.
The required command syntax should be complete spelled out, so you could write a portable rpm. If the command set was known, you could write rpm such that it is independent of system tools and does not require the root user to use --root option. This could be good for embedded systems.
rpm and busybox could share a
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.
It appears to me that this is also defining a binary standard. For example, Posix standards ensure that a particular header file will include a symbol definition, but they don't specify exactly what that symbol's value must be. This works fine for a source code level standard, but could potentially require recompiling from source for each distribution. /dev for specific devices, etc.
Further, if I'm reading it right, this will standardize things like specific names in
OTOH, I don't have a feel for how often binary incompatibility issues actually show up in practice. I've hit some minor problems with ncurses.h, but that was across different o/s's (aix vrs linux). I'd be very interested in other developer's experiences.
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.
Which Linux distros are the most conformant, or most closest to conformance with the LSB?
I've seen comments that Mandrake is the most internationalised. Is this true. How do other distros such as Debian compare?
On the issue of internationalisation, how is that accomplished from a programming perspective? Most of my development work occurs under Windows, where it is very easy to switch between single byte, multi byte and Unicode at compile time (based on TCHAR definitions). It is also very easy to switch resource DLLs. How is this achieved under Linux? And, does Linux make use of code pages, or something similar when it's not using Unicode?
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.
The things behind dpkg and all of that sure, they are nice, but how are they all that really different from RPM? I agree that I may not be totally clued in about all aspects of apt, dpkg and all of the other stuff Debian uses, but to say that it's so tied to a packaging format??? Debian is no more tied to it then Redhat is tied to RPM. If they are, then the Debian project made a major mistake!
Debian's primary advantage is that its packages are consistent. When you select a package, it comes with a very specific set of dependencies. That, and the fact that Debian is the source of the vast majority of .deb packages (especially the sort of "core" packages likely to come up in a dependency), mean they can get away with a lot of splitting up components, compiling platform-independent bits once and binaries many times (Debian isn't just an i386 distro like many others), shared libraries that get shared properly, and all sorts of other consistency stuff. Where a release-focused distro might concentrate on making all the packages in version 9.2 (say) work together nicely and consistently, Debian does a pretty good job of keeping all the packages consistent, all the time. (OK, so it doesn't always work 100% on 'unstable', but if you wanted stability you wouldn't be running that version anyway).
Maybe now is the time for Debian to actually form a company or form a different way of making the decisions instead of democracy.
The democracy/meritocracy structure is exactly what Debian is about - it's run by a non-profit org. called Software in the Public Interest. They don't exist to make a profit, or to make themselves popular - they exist to make a distribution of good software freely available.
Maybe they need to modify the DFSG to be more lienient?
And that would help how?
If it's free (free as in DFSG), it goes in 'main' and goes on the official CDs. If it's free as in DFSG but requires non-free software (like a GPLed "helper" application for PGP for instance), it goes in 'contrib'. If it's not free-as-in-DFSG (this includes shareware and closed-source freeware), it goes in 'non-free' - contrib and non-free are easily available over ftp or as the last CD in the set. If it's not in non-free, either nobody's tried packaging it, or Debian aren't sure if it would even be legal for them to distribute it.
Again, things like the DFSG are why Debian exists.
I don't know, but there has to be someone who is going to draw a line in the sand and get the volunteers in action and get Woody released (and with a 2.4 kernel as well...).
It looks like it'll be installed with a 2.2 kernel by default, and a 2.4 kernel as an option (fairly easy to install thanks to the magic of apt/dpkg - install, reboot, Lilo offers you a choice of kernel). Woody already includes precompiled 2.4.17 kernels for 386, Pentium, 686 (PPro/P2/P3/Celeron), K6 and K7 (Athlon/Duron), and that's just the i386 builds.
OTOH, if Debian was a company, where would all those volunteers be? Probably starting their own distro or doing Linux from Scratch.
PHB's and Joe Sixpacks like hearing and seeing commercials like Mandrake Linux is compliant (it isn't but) with the LSB which means no matter where you buy or download your software it will work!
This is why volunteer efforts like Debian have a niche. They don't like hearing and seeing commercials, they like giving people a stable OS. They're not trying to make a profit, which is why they can get away with doing what they feel is The Right Thing.
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.
Wishful thinking that you can get all the *linux
distributions to agree on one standard. You
might as well hope everyone packs up and just
run RedHat, the market leader.
There's already a standard..it's called RedHat!
( sorry debian, no lead core developers means you are losers anyways)
* Caldera Inc * Compaq * Corel Corporation * The Debian Project * Enhanced Software Technologies, Inc. * Hewlett Packard (sponsor) * IBM (sponsor) * Linuxcare * Linux for PowerPC * MandrakeSoft * Metro Link, Inc. * Olliance * The Open Group * Oracle * SGI * Turbolinux Inc. * Red Hat Software * Software in the Public Interest, Inc. * SuSE GmbH * The USENIX Association * VA Linux * WGS Inc
I see someone keeps his 6th grade creative writing assignments around...
Imagine a Beowolf Cluster of THESE!!!
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.
Speaking of which, don't you have some masturbation to do now? After that's done you can go back to crying in your parents basement.
- Anonymous Commander ][, esq.