LSB Not Enough [LWN.net]

LSB Not Enough

Posted Sep 13, 2004 5:19 UTC (Mon) by dlang (✭ supporter ✭, #313)
In reply to: LSB Not Enough by bojan
Parent article: Bruce Perens: the Linux colonel talks (vnunet)

you guys must be deliberatly trying to misunderstand the problem

the problem is with companies that are not writing open source code, they are not writing infrastructure catagory programs, theya re writing programs for specific tasks and want to continue doing so.

they are willing to support 'Linux' but are not willing to support 20 different flavors of 'Linux'. while we all know that 90% or more of things will work just fine with no effort across all the different flavors, that's not good enough, they have to KNOW that their software will work and they don't want to have to run it through QA 20 times to prove that it will work (and when you have redhat doing non-standard stuff it's very easy to get software that requires non-trivial changes between distros)

if there was a good standard that would let the software function everywhere then this issue could fade away, unfortunantly the LSB takes so long to standardise and covers so little that in practice it's not good enough (I buy software from a company that currently supports 4+ distros and they ignore the LSB becouse it wouldn't help them at all, their management couldn't be sure that someone didn't accidently use a non LSB piece so they still wuld have to test it on every distro)

the problem of commercial software only working on some distros IS a real limitation right now. and now that you can't get a supported OS to run the software on without substantial per-seat licenses it makes it harder to get linux into new places

and once a company buys into the 'enterprise distro' they tend to want to run it everywhere becouse it is expensive in terms of support people to run multiple distros

(Log in to post comments)

LSB Not Enough

Posted Sep 13, 2004 10:42 UTC (Mon) by hppnq (guest, #14462) [Link]

The problem does not seem to exist when it comes to porting apps to proprietary Unix systems, so I fail to see why the Linux case would be exceptionally difficult.

I agree that the LSB has not (yet) brought us the standards base we were hoping for. Smart software vendors that want to make their software run on Linux platforms will want to take a good, hard look at their own configuration methods and probably make use of, for instance, autoconf. Just like they would in other cases, by the way.

Could you hand me the list of "20 different flavours", or were you just trying to make the problem look bigger than it is?

LSB Not Enough

Posted Sep 14, 2004 0:31 UTC (Tue) by koide (guest, #22687) [Link]

Because each Linux flavor is comparable to a single proprietary Unix (AFAIK there're no different flavors of solaris, hp/ux, etc.). So supporting Linux is supporting each different distro, and there're certainly more than 20.

Thinking on widely used ones you might get to 5 or 6 instead of 20, but the problem is still far from trivial for not trivial systems, especially when you're focused on users which won't be happy compiling each part of the system.

A good approach for this issue might be to install in a specific, non standard location while LSB is LNSB, such as Sun's jre (/usr/java), though this doesn't solve library naming issues, so you end up with duplicate libraries (see OpenEV or FGS).

You might ask, why not use RPM/apt/whatever? Because then the maintenance cost is huge (updating each part of the system, and tracking each distro specific change, which happens in between versions of the same distro). You can use your package format of choice once you've built the tree in an independant way, of course, but that's against the spirit of packages, I'd say.

LSB Not Enough

Posted Sep 14, 2004 8:05 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

each distro is different enough to be a seperate flavor, and frequently each release of a distro is enough different from previous releases to count as a seperate flavor. with commercial Unix vendors there is less variation between different releases then there is between different linux distro releases (so binaries compiled for Solaris 2.6 still work on Solaris 10, but try to take a binary compiled for RedHat 7 and make it work on Fedora Core2)

it's the same problem as supporting multiple Unix vendors and the software companies don't support all variations on Unix, they support a small handful of them, and in Linux they only support a small handful as well (mostly RedHat releases historicly)

One problem that Linux has along these lines is that it changes faster then the competeing OS's do. that makes the newer linux systems far better, but it makes it harder for the software vendor (even if they only support a single distro)