[nSLUG] Why you are not seeing software ported to Linux
D G Teed
donald.teed at gmail.com
Thu Jun 23 12:14:50 ADT 2011
On Thu, Jun 23, 2011 at 7:55 AM, Ben Armstrong
<synrg at sanctuary.nslug.ns.ca>wrote:
> 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>>
> > 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
> > amd64 you just make your package depend on ia32-libs. The user
> > 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.
Avoid our enterprise backup solution? I think not, but anyway,
it works fine.
> I didn't tackle grub. Is that something an ISV is likely to care about?
Maybe VMware, EMC, Equallogic would care. I'm not sure.
> 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.
Good. I'm just drawing on experiences I've had where I could
imagine the challenge a 3rd party could be facing with trying
to make a solution for any Linux.
However, my thoughts are not specific to Debian, so you don't
need to be defensive about that. I think the cases I've
mentioned are mainly upstream issues.
> > 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
> - 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
I've had experiences demonstrating poor coding practise of
the elementary sort (e.g. test for a file before opening, or
catch the error when the file doesn't exist). There are times
they could be doing way better (don't worry, it wasn't Debian).
I'd call it minimal efforts to get it working and then
chalk up a success.
> > 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.
> OK, maybe not. I am speculating generally on where
additional control could have prevented recent BROKE issues I've seen.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nSLUG