[nSLUG] Why you are not seeing software ported to Linux

Ben Armstrong synrg at sanctuary.nslug.ns.ca
Thu Jun 23 07:55:26 ADT 2011


On 06/22/2011 10:30 PM, D G Teed wrote:
> On Wed, Jun 22, 2011 at 8:38 PM, Ben Armstrong
> <synrg at sanctuary.nslug.ns.ca <mailto:synrg at sanctuary.nslug.ns.ca>> wrote:
> 
>     On 22/06/11 04:10 PM, D G Teed wrote:
>     > Unlike something like Solaris or Windows, in Linux
>     > you are expected to add another package to provide the library
>     > support, and then it works (e.g. ia32-libs).
> 
>     As a maintainer of an ISV's deb package of your 32-bit-only software for
>     amd64 you just make your package depend on ia32-libs. The user installs
>     your package and it "just works".
> 
> 
> OK, that would work for Debian packages, but not those coming in
> via alien.

Well, alien is a 'last resort' tool when an ISV hasn't seen fit to
provide a deb for your platform and the support community around the
distribution hasn't either. In a word: avoid.

> Perhaps both systems of developers have to make adjustments.
> ISVs have to adapt to the open source variability and work
> with different expectations than they would of Windows or Mac OS.
> The open source side has to resist making as many changes and breaking
> backward compatibility.  Why would grub change the partition numbering?
> Seems like something you'd want to avoid at any cost.  Are the grub
> folks an example of what you refer to as people working against the
> system?  I don't think I get your point about my examples.

I didn't tackle grub. Is that something an ISV is likely to care about?
It would be nice if we could stick to the topic instead of just
dribbling off on dozens of tributary issues that irritate you about
Linux but don't relate to the putative topic.

But nVidia *is* something an ISV may care about (e.g. if they're a game
developer contemplating a port to Linux). I acknowledge that graphics
drivers need more work, but the answer here is solid open source
support. We've busted our butts trying to get vendors on side, but
they're still uncooperative. What else can we do? We forge ahead the
best we can with the resources we have.

> I'd like hardware that used to boot OK from last year's Redhat or Debian
> version
> to continue to do so with this year's Redhat or Debian, unless
> there are reasons they are announcing end of support due to some
> hardware aspect.

I don't buy your "developers don't care" and "works for me" arguments. I
think everyone does their best given:

- they don't have unlimited resources to test on all possible hardware
combinations
- as each year goes by, older hardware gets harder and harder to support
- some hardware is poorly implemented and/or requires proprietary blobs;
this can cause problems for support in future releases, i.e. just
because a prior release worked doesn't *guarantee* that it will in the
next release, and breakage in a subsequent release isn't a clear cut
case of "QA failure"
- the maintainers for each distribution are limited by whatever upstream
(usually the kernel, Xorg, etc.) provides them, and are generally
reliant upon and responsive to users with old hardware presenting
problems that "fell through the cracks" in a release

> If improved ABI/API standards provide for less chaos, and
> this is what ISVs require, then I agree with at least part of their view.

I don't think improved ABI/API standards is causing the hardware issues
you cited.

Ben



More information about the nSLUG mailing list