On Thu, Aug 06, 2009 at 08:52:10AM +0200, martin f krafft wrote: > also sprach Pierre Habouzit <madco...@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.habou...@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 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
