Will LSB 4 Standardize Linux? (InternetNews)

That makes little sense.  Distros can be certified LSB4 compliant, and they can offer
meta-packages to pull in any libraries necessary for LSB4 compliance if they are not in the
default install.

This isn't meant to help users directly.  As Joe notes, no software vendor will claim to run
on any old LSB4-certified system.

However, ISVs who code to LSB4 -- i.e., rely only on what's documented to be present in LSB4
-- will find porting to any LSB4 system will be easier than what they have to do now.
Typically, now, they have to build release packages on some ancient version of Red Hat, and
then rely on forward link compatibility to run on new Red Hats, and everywhere else too.

With any luck this means they can rely on newer OS features than they previously had access
to.  E.g. does LSB have futex?

If this works out, users will benefit by having a wider and possibly more modern choice of
targets certified by the ISVs, because it will be cheaper for the ISVs to port and certify.
ISVs benefit by being able to sell into shops that run distros they hadn't previously been able
to afford to support.

Anyway that's the theory.

Perhaps one direction would be to have ISV's use a "LSB distro" against which they can test
their packages.  If it works on the LSB edition, it should work against any other GNU/Linux
distribution also certified to meet the LSB.

However, I doubt that the distributors will agree easily about the minimal content for such a
distribution.  These days, such an idea may even be moot if the QA process can test against VM
images of Debian Stable, Ubuntu LTS, SUSE and Red Hat Enterprise (it's not like there's
licensing costs...).

K3n.

The same thing that makes life hard in Linux for ISVs and proprietary software makers to
support Linux is the same things that make it hard for open source developers and users to use
Linux.


For example:

I like games. I want to play around with video games and I want to play around with making
simple games. It's something enjoyable and fun to do.

Unless, of course, your running Linux. 

Then it's a huge PITA. Language bindings, boost, Python, various libs and all that are used in
all sorts of games or game engines. Very complex levels of dependencies and compiling versions
for your own distribution are very very difficult.

No distribution will support everything you need and even if they do the build-time options
are probably not going to be correct and probably not the correct versions either. 

I have spent _days_ trying to get this or that to compile and to install. Over and over again
I've tried to do this with all sorts of things with Crystalspace or Ogre3D and all of that. 

All of these are open source projects, all of these have developers that use and are fans of
Linux and come from Linux oriented backgrounds.

You know what I would have to do to get it to work in Windows?

Download a EXE and run it. At worst, 2 or three.

That's all. 

Days and days of struggling with Linux and dependencies and hell and failing at it, vs
spending 10 minutes to download a executable. 

(And, of course, that isn't counting the low-quality of Linux 3D drivers which usually end up
thwarting me even after I get everything built.)

So you know most of their users are not going to use Linux, they are going to use Windows.

I've even thought about dual booting Windows just so I can play with open source software.

-----------------------------

Distributions work by simply brute forcing the software into submission. They spend hundreds
of man-hours compiling, testing, and bug hunting. That's how it works and it's the only way it
works.. Through simply massive amounts of time and effort. 


And not only that but it's all duplicated. 

The same amount of work that is required to get Debian's high quality packages still needs to
be entirely duplicated for Suse, Redhat, Fedora, Ubuntu, Mandriva, etc. etc.

The only reason Ubuntu works as well as it does is because of the massive amount of personal
effort Debian developers put into making Debian packages work, and even then because Ubuntu
doesn't care so much about package compatibility they screw things up so that their 'stable'
system is consistently buggier then Debian's 'testing'.

There is very little logical reason for this! Why, if Debian does things well and Fedora does
things well and Redhat does things well... Why on earth is Suse or Ubuntu developers forced to
recreate all of that on their own?

Even if they use Fedora's scripts and packages as the basis for things they use it's still a
huge PITA to _port_ it over to Ubuntu and all sorts of variables inflict all sorts of bugs and
broken behavior on end users.

And, again, the only way to fix it is just a massive amount of _DUPLICATE_ effort on the part
of every Linux distribution developer out there.


They are all using the same programs, similar scripts, similar versions, same everything. The
only difference is that they have to compile the software and build it into packages.

-------------------------


IMO one of the most important things that Linux distributions can do now is work together to
eliminate needless distinctions between them. 

LSB is probably a good start, but it's probably not nearly enough.

"Standardisation is a good thing, but the end goal should be to respond to the requests of
distros, rather than making distros bypassable via write-for-LSB-run-anywhere."

I look at it a bit different. In any system, there are places where disagreement is important,
because choice is needed. There are also many areas where using multiple approaches is silly
or trivial - best to pick one and run with it. 

A standard like LSB should be a way to sort between the two. Stuff that's really common gets
rolled into a standard, distro-unique stays unique. 
Then app developers can use LSB to cover the 80% common, and focus
on distro-specific goop. Likewise distros can split effort between maintaining the commons and
keeping their identity-specific bits. 

ABI stability might be a priority for an organisation such as LF which is a consortium of
proprietary software developers.  For free software projects, it might be quite justified that
this wasn't a priority (it can be good, but just not a top priority).

The lack of C++ ABIs is a pain in the neck, but it is not something I would like to blame on
the GCC people.  The C++ standard is both complex and itself instable, and producing a stable
ABI for it (let alone one compatible with other compilers) is no mean task.  The easiest way
to deal with the problem that I know of is to wrap the ABI in something else (i.e. all exports
are extern "C", or on Windows COM is popular for the purpose).

nail's head says ouch.

> Oh, you mean you're talking about closed-source ISVs? Why didn't you say so?

The LSB has always been about making it easier closed-source for ISVs to package their
applications for GNU/Linux distributions. If you don't care about them, you're better off
ignoring LSB discussions altogether.