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

Ben Armstrong synrg at sanctuary.nslug.ns.ca
Wed Jun 22 14:05:12 ADT 2011


On 06/22/2011 11:04 AM, D G Teed wrote:
> On Wed, Jun 22, 2011 at 7:35 AM, Ben Armstrong
> <synrg at sanctuary.nslug.ns.ca <mailto:synrg at sanctuary.nslug.ns.ca>> wrote:
>     libc5 to libc6? You've *got* to be kidding ...
> 
> 
> He did say "and not alienate them".
> 
> Care to elaborate?  I'm not defending the blog, and
> parts of it are historical but I think there is
> something real about this perception from ISVs.

You know the first release of Debian replacing libc5 with libc6 was in
Debian 2.0 "Hamm" in 1998?  Debian even continued to include libc5 right
through Debian 3.1 "Sarge" which wasn't discontinued until 2008. This is
an example of "alienating" ISVs? Debian bends over backwards to continue
to remain compatible, e.g. through the 'oldlibs' section of the archive,
and with ia32-libs so that 32-bit binaries can continue to work on
64-bit systems.

The Linux kernel is another example: while the ABI does change over
time, with things constantly being added, they're quite conservative
about making changes that would remove old things. When they do, there's
usually just a smallish userspace around it that needs to be adjusted to
deal with the changes.

> Why can a Windows software product released in 1998 still work today?
> Why do Sun sparc binaries from ages ago still run today?

I have binaries on my oldest Debian system in /usr/local/bin dating back
to 1997 that still work today. I'm sure there are many other examples in
existence today.

But the world marches on. Things do change. And old software that used
to work in 1998 may *not* work today because of changes to the systems
it runs on. Certainly there is a drive in the Windows software-using
world to be on a constant upgrade treadmill. Is perfectly enduring ABI
compatibility for timespans exceeding a decade really the holy grail you
make it out to be?

> Why do companies like Dell and EMC create packages supported
> only in Suse and Redhat (can be made to work in Debian),
> while Debian has a bigger install base than Suse?

First, I suspect it's because partnering with a distribution that is a
corporate entity is easier than a volunteer-run project with a
decentralized command structure. Furthermore, Debian is in a different
position than other distributions, placing a higher value on free
software. Corporate entities like Redhat benefit from partnerships with
corporate ISVs in a way that is clearer than the benefit would be to
Debian. Naturally, Redhat will be able to allocate more resources to
deal with Dell and EMC, and so that makes them a more attractive target.

That being said, the Linux community is going above and beyond the call
of duty (i.e. nobody is paying any Debian maintainers to do this!) to
ensure that binaries from ISVs continue to work in successive releases
of the OS. Clearly that can't continue forever, as we don't have
unlimited resources to do it, but we do make a best effort to do this,
in spite of the fact that our primary goal is to ensure free software
(which can always be built again from source) continues to work on the
platform.

> Why does Blizzard have developer versions of some of
> their popular games which run within Linux, but they are
> afraid of the idea of releasing it, while they do have
> Mac OS support?

Nobody wants to be the first to do this. It's a risk. The Linux gamer
community is a very small market with uncertain returns compared to the
established markets.

> As long as there is only compatibility
> by moving everything forward, much of open source
> works like a very large home brew project, where the
> minimal goal is "I got it to work".  Of course projects
> very often exceed that, stating and achieving goals beyond
> the minimum, but in terms of a minimum standard common
> to all open source, this seems to be it.

That's a crazy comparison. There is a hell of a lot of crap proprietary
software out there written for proprietary platforms that barely passes
that minimum criteria. And *we* get blamed for being amateurish?

Your whole argument is based on a very one-sided article written by
Miguel at least six years ago (it's hard to say, since no date appears
on it, but it's at least after 2003, since that's the date for .NET
1.1). Nor do I trust his objectivity given the position he was in at
that time.

I can only speculate as to the reasons companies don't port more
software to Linux. I suspect it's due to a number of factors I've hinted
at above, but that's out of my field, as I am not an ISV deciding
whether or not to sell into the Linux market. You really want to know?
Don't speculate. Talk to them. What do they say their reasons are
*today*? And then critically evaluate their responses, as they may not
understand the issues fully and might just parrot back what pundits like
Miguel have written.

Ben



More information about the nSLUG mailing list