[nSLUG] Why you are not seeing software ported to Linux
D G Teed
donald.teed at gmail.com
Wed Jun 22 22:30:57 ADT 2011
On Wed, Jun 22, 2011 at 8:38 PM, Ben Armstrong
<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. I remember EMC Networker not working until I installed
ia32-libs manually, and I thought also for a device driver once, but
I forget. But the point is, for a QA dude with some ISV, they
might not know the particular packages they would require in
a particular distro, or what it is called this year, and they
would need to do this uniquely for a bunch of distros. On other
platforms, they don't have to think about this as much. Even Direct X
is now a standard part of Windows now and game developers
don't have to worry about handling that. In QA, reducing variables
can reduce volumes of testing. If a QA guy doesn't have to
wonder whether the testing environment was set up right, that is
one more thing to make their task fly by more quickly.
> With a more standards based framework, these interventions
> would not be necessary.
Preaching to the choir. Take a look at Debian Policy lately? And the
> counterexamples you provide are people working *against* the system as
> it's designed to work, staunchly refusing to contribute to the
> community. What, exactly, are you asking us to do? Throw our free
> software principles out and fully embrace nVidia, bringing them into the
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.
> > The home brew approach of open source can be good. It
> > involves putting the user in control of their system and sometimes able
> > solve things in ways a vendor might block or make difficult
> > to cope with. There are lots of advantages. From the engineering
> > perspective there are also difficulties.
> So the answer is? Take away the user's control, prevent them from having
> choices, and make things more predictable for ISVs, and then we all win?
I'd like hardware that used to boot OK from last year's Redhat or Debian
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
I'd like netbsd to not bother putting out a multi-processor kernel if they
know it always
crashes on boot up. Those are examples of changes I would expect
if open source developers had a higher common standard than "I got it
working, hopefully it is useful for you too". That was very nice back
in 1993, or when Intel dragged their feet supporting centrino wireless
and NDIS wrapper appeared, but now it should be a process for the
large and well developed projects. I don't know if this mainly a QA issue.
I suspect it is impacted mostly by developer driven changes, including many
upstream from the Linux distros.
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.
The original purpose of my post was to see what others thought of that
blog posting and have some discussion around it. As I think I've mentioned,
I ran across it while looking up ABI, API and ISV mentioned in another
mailing list and I wondered how valid the opinions seemed to people here.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nSLUG