Re: the role of the LSB (was: On cadence and collaboration)
On Thu, Aug 06, 2009 at 08:52:10AM +0200, martin f krafft wrote:
> also sprach Pierre Habouzit <madcoder@madism.org> [2009.08.05.2333 +0200]:
> > But speaking from my experience as an employee of a software editor, I
> > can tell that the distribution diversity is a huge problem when it comes
> > to distributing our work. If your client use a Ubuntu LTS, a RHEL, a
> > SuSE or worst for some, some kind of home-brewed monster taken half from
> > a RHEL and custom packages (*sigh*) then you have as many builds to do,
> > regress-test and so on. When you target Windows or Solaris or MacosX,
> > you usually officially support the last two releases, and that's it (and
> > please, it's the same for "Linux" distributions, for RH you "have" to
> > support RH4.x and RH5.x if you want to be relevant).
>
> I think it's the job of something like the LSB to ensure a necessary
> baseline across distros on which vendors can build. Anyone gearing
> software at distro-specifics is committing the same fallacy as
> people writing HTML for Internet Exploder. And distros who are
> actively ignoring or superseeding the LSB are counter-productive.
You're comparing apples and oranges here, for HTML is a standard, and
theoretically, following the standard is enough (and even that is
probably -- and sadly -- a fallacy).
When it comes to the LSB, it doesn't say what happens when you're using
very specific bits of the Linux kernel or the GNU libc, and when you're
doing networking stuff for example, well, that matters a lot. That's
why LSB doesn't work for many vendors because of the very different
toolchains. You have to do regression tests for every single distro out
there, which many corporations cannot do, hence certify only for a
couple of distributions (and often only one: RHEL).
Anyways we're drifting away from the original point, so just let cut
that here.
> I just don't think it'll solve the vendors problem, nor eliminate
> all other problems relating to distro diversity. Heck, it might even
> create new problems, e.g. security issues as Julien suggested.
That's beside the point, if anyone thought I was saying that aiming to
synchronized freeze would solve the vendor problem, then I've probably
been ambiguous. I've never meant it.
I was merely explaining why the Distribution diversity is, in my
opinion, not something that one can call an _asset_. It's a variable
that you have to live with in the free software world. It has its upside
and its downsides, but it's neither an asset nor a defect.
I'm really sorry if I let people think that I'm advocating synced
freezes so that "LSB can be done right". It had never even crossed my
mind.
--
Intersec <http://www.intersec.com>
Pierre Habouzit <pierre.habouzit@intersec.com>
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie
Reply to: