Four Linux Vendors Agree On An LSB Implemenation 245
An anonymous reader submits a link to this story at Linuxlookup.com which says that "Connectiva, Mandrakesoft, Progeny and Turbolinux today announce the creation of a common implementation of the LSB 2.0 which will serve as the base for future products. The project, called 'Linux Core Consortium' (LCC), is backed by Linux supporters such as Computer Associates, HP, Novell, Red Hat, Sun, OSDL, and the Free Standards Group."
Article Short on details (Score:5, Interesting)
Will this include glibc standardization?
rpm vs. deb (Score:4, Interesting)
Supported by Novell?? (Score:4, Interesting)
The Reference Unix (Score:5, Interesting)
Re:Networking! (Score:3, Interesting)
Since most of the packages are same accross all distributions, it's in no big distribution's interest (short-term interest) to be compatible with smaller distributions as that enables user mobility.
So if you're RH you don't want to see some good X program being directly installable on SuSE - if SuSE is slightly cheaper (or god forbid free), why would users of application X stay with RH (all other factors being equal)?
The pressure to standardize Linux to some meaningful extent will come from
a) Smaller distributions (like Debian, Turbolinux, etc.)
b) Software and hardware vendors trying to keep SuSE and RH in check (Oracle, Sun, etc.).
Novell has a range of non-OS software which can make money (like directory server, etc.) whereas RH's portfolio in my view is limited to their OS. Linux standardization will hurt RH the most as it will make distribution type almost irrelevant.
My guess is that RH is there just for the sake of it.
Here's the list of orgs behind LSB.
http://www.freestandards.org/modules.php?na
Long-term, standards will of course increase acceptance of Linux, but by then selling OS support will become commodity.
Look how Sun's stuff got certified recently ("Open Standards") - they'll keep kicking that chair under Red Hat...
http://www.opengroup.org/lsb/cert/cert_pr
Re:Finally (Score:3, Interesting)
i think there should be a abstraction of paths and config files so you can create a binary installer that works on every distribution but where the files really go to is depending on the distribution
this wold make it possible to log into a suse machine, start a special shell and see all config file like they would be on a debian machine at least from the location viewpoint
Re:Isn't that why we have an LSB (Score:2, Interesting)
LSB is absolutely critical to taking on Windows, and needed to be updated. There cannot be dozens of packages that have to be maintained by those of us writing software for Linux. This makes the user experience bad for people who aren't computer science majors and can't work configure, GNU C, etc.
Installing a program from binaries should be the single simplest thing a user ever has to do. It should be simple and consistant across all distributions. An individual distribution may have a "better way of doing it" (dpkg vs rpm, etc.), but the user experience needs to be consistent, and there needs to be a set of features, libraries, etc. that package maintainers can write to to be able to say:
"Click here to install the GNU/Linux LSB 2 package"
Windows has been to this point for a long time. You don't see a lot of programs saying "click here for Windows 95, click here for NT." There are programs that do, just not many. Even in the Windows 3.1 to 95 transition, you saw a lot more programs that used Win32s and just shipped a 95 version than that shipped both versions.
GNU/Linux needs to get there. Diversity is fine, version numbering is confusing across the board. The kernel version is usually stated on the box or on the information on the website. Versions of other pieces aren't commonly reported.
Being able to say "LSB 2.0" and being able to have a LSB 2.0 package that installs on all LSB 2.0 plaftorms is absolutely critical.
From a developer standpoint, the most attractive alternative is to use Java or ECMA