Proprietary Sybase DBI/DBD module
Joel Bernstein
joel at fysh.org
Wed Oct 31 20:00:34 GMT 2012
On 31 October 2012 20:34, DAVID HODGKINSON <davehodg at gmail.com> wrote:
>
> On 31 Oct 2012, at 17:53, Joel Bernstein <joel at fysh.org> wrote:
>
>> On 31 October 2012 18:42, DAVID HODGKINSON <davehodg at gmail.com> wrote:
>>> On 31 Oct 2012, at 17:33, Jason Clifford <jason at ukfsn.org> wrote:
>>>> The DBD will be normal perl however it will require a client lib which
>>>> will be a binary only distribution.
>>> And hilarity ensued.
>>
>> I don't see why, that's how all the other commercial RDBMS DBDs
>> work... What's so funny?
>
> So may distros, so little time.
>
> How widely can a single .so be spread across different kernels,
> libcs and so on?
[snip heavy-handed but surprisingly well-researched example of the
issues with binary-only closed-source code]
I see what you mean. I'm not aware of any interface to another
commercial DBMS that doesn't exhibit this issue (perhaps barring the
execrable FreeTDS). It's still better to have modules on the CPAN
which require commercial libs than to have most of your dependencies
installable from CPAN but some that have to be fetched from a
commercial repo, isn't it?
> So sparse linux support.
Given the use cases for commercially-supported software that's not
uncommon. By locking people down to long-term-support Linux distros
(RHEL and their ilk) you have some modicum of trust in the platform
and the versions of stuff available on it. Think what would be
involved in supporting Oracle or Sybase on Debian unstable, for
example.
Not to be snarky but the answer here seems to be "yes, and what's your point?"
/joel
More information about the london.pm
mailing list