LSB Not Enough [LWN.net]

LSB Not Enough

Posted Sep 13, 2004 10:42 UTC (Mon) by hppnq (guest, #14462)
In reply to: LSB Not Enough by dlang
Parent article: Bruce Perens: the Linux colonel talks (vnunet)

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?

(Log in to post comments)

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)