Re: Proprietary Sybase DBI/DBD module
On Thu, 2012-11-01 at 01:10 +, Anthony Lucas wrote: But, why on earth would this go into a standard perl distribution? It doesn't sound very standard OR widely distributable. Had the request genuinely been to get their particularly DBD into the standard Perl distribution I'd agree but I think it's clear now that what was really being asked was for details on what is the standard way to distribute such a module within the Perl ecosystem. That's a very different proposition. I'm no fan of non-free software however the fact is that some people will use this product, and other similarly non-free ones, and those people will be content with the distribution requirements. So long as the companies offering it comply with the license terms of those whose software they build upon what is the problem?
Re: Proprietary Sybase DBI/DBD module
From: Joel Bernstein j...@fysh.org Chris Jack chris_j...@msn.com wrote: Sybase will be releasing to CPAN but they're still finishing off work/testing etc. What's the question then? The original question was how to get it into standard distributions. Dave Cross answered this. When I asked at the SAP/Sybase conference, the presenter, when I asked, said it would get released to CPAN sometime (but it's possible the presenter didn't know). Finding out how to get it into standard distributions doesn't require the code to be immediately available on CPAN. The driver is currently available at http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc01694.1570/doc/html/car1311374855236.html Niche is a point in time concept. SAP buying Sybase was a significant coupe for both companies. SAP competes head to head with Oracle in applications yet had been beholden to Oracle for its database. This had lead to all the complications you would expect. SAP is now pouring bucket loads of money into development of Sybase. years ago, I was pessimistic that Sybase was going to become another hard to sell legacy skill on my CV (anyone remember SQLPlus: now there's a legacy database skill...). Now, I'm not so sure. SAP is targeting Sybase as being the number commercial database in the world. They were able to add some credibility to that aim with statistics about the number of sites now migrating from Oracle to Sybase. But who knows. That sounds pretty niche to me - a database I used to use a bit in the past which is now basically used to support a certain big app. Not seeing anybody migrating TO Sybase, are you? SAP quoted 800 sites in the last year migrating from Oracle to Sybase. Sybase is currently the 4th biggest commercial database (http://itknowledgeexchange.techtarget.com/eye-on-oracle/oracle-the-clear-leader-in-24-billion-rdbms-market/), but it's the 47.9% growth in 2011 (compared to under 20% for everyone else) that makes me think that there's life (and opportunity) in remaining in the Sybase camp. Sybase scrwed itself (IMHO) 10 years back by being very slow to come to the row level locking party. So software like SAP (at the time) that required row level locking had no alternative than to look to vendors like Oracle. Oracle then stole a march on Sybase again by coming out with a grid computing solution: not enought CPU - just add another box. Sybase is now playing catch up and with the resource of SAP behind it. It is also very prepared to compete on price. DB2, SQLServer and Teradata are in slightly different markets (IMHO): so really Sybase is primarily competing against Oracle. Ooops: I meant SQLBase (although SQLPlus is kind of ironically funny: if there's a database tool that should qualify as legacy, SQLPlus would be it). Finally, please, please, please fix your mailer, the quoting/attribution in that was impressively broken and it took me minutes just to -read- your reply. Apologies: I use hotmail and it looks fine when I send it. I usually switch to Plain Text - but on this occasion I had left it on Rich Text. The problem is in the list's conversion software. I doubt either Hotmail or List software is going to change anytime soon - so I will try to be careful. From: PostgreSQL and SQLite are both excellent open source databases that are still actively developed. True, but they don't even appear on the radar for market share. From: DAVID HODGKINSON daveh...@gmail.com Can you define proprietary please? All I meant was Sybase was writing it itself. They've put a lot of effort into improving performance/functionality. It will be shipped with .so files? See link above. Regards Chris
Re: Proprietary Sybase DBI/DBD module
Quoting Chris Jack chris_j...@msn.com: From: [attribution appears to be missing] PostgreSQL and SQLite are both excellent open source databases that are still actively developed. True, but they don't even appear on the radar for market share. Really? What about all those Android devices using SQLite for pretty much all their data storage? Dave...
Re: Proprietary Sybase DBI/DBD module
On 30 Oct 2012, at 18:02, Uri Guttman u...@stemsystems.com wrote: On 10/30/2012 01:35 PM, DAVID HODGKINSON wrote: Chris, Can you define proprietary please? It will be shipped with .so files? The source will be there but the license says we can't change it? it seems pretty obvious to me. the sybase people have written a new driver which is being released in binary only form (hence proprietary) Talking with Chris last night, that may not be the case. and also they have written a DBD for it which they will (or have) put on cpan. as usual the DBD will be open source and free. i would expect the binary lib to downloadable but useless without a sybase server which is commercial. There's a free, limited version available. I've used it to develop against in the past. the confusion is from not clearly describing the binary lib vs the perl/cpan DBD module as separate entities. This is true.
Re: Proprietary Sybase DBI/DBD module
On Wed, 2012-10-31 at 17:21 +, DAVID HODGKINSON wrote: it seems pretty obvious to me. the sybase people have written a new driver which is being released in binary only form (hence proprietary) Talking with Chris last night, that may not be the case. I also spoke with him last night and today he has posted a link to some docs for it. The DBD will be normal perl however it will require a client lib which will be a binary only distribution.
Re: Proprietary Sybase DBI/DBD module
On 31 Oct 2012, at 17:33, Jason Clifford ja...@ukfsn.org wrote: On Wed, 2012-10-31 at 17:21 +, DAVID HODGKINSON wrote: it seems pretty obvious to me. the sybase people have written a new driver which is being released in binary only form (hence proprietary) Talking with Chris last night, that may not be the case. I also spoke with him last night and today he has posted a link to some docs for it. The DBD will be normal perl however it will require a client lib which will be a binary only distribution. And hilarity ensued.
Re: Proprietary Sybase DBI/DBD module
On 31 October 2012 18:42, DAVID HODGKINSON daveh...@gmail.com wrote: On 31 Oct 2012, at 17:33, Jason Clifford ja...@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? /joel
Re: Proprietary Sybase DBI/DBD module
On 31 Oct 2012, at 17:53, Joel Bernstein j...@fysh.org wrote: On 31 October 2012 18:42, DAVID HODGKINSON daveh...@gmail.com wrote: On 31 Oct 2012, at 17:33, Jason Clifford ja...@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? Even VMWare ships source for their drivers so they can be compiled for each flavour of kernel. OK, from that linked page, the requirements are: • Adaptive Server Enterprise – version 15.7 or later. • Open Client and Open Server – version 15.7 or later. • Perl – version 5.14.0 or 5.14.1. • DBD::SybaseASE driver – no specific version requirements. • CT-Library – (CT-Lib API) version 15.7. • Perl DBI – version 1.616. And this leads to: Red Hat EL 5.0 (AMD64/EM64T) Certified view more Red Hat EL 5.0 (IBM POWER) Certified view more Red Hat EL 6.0 (AMD64/EM64T) Certified view more Red Hat EL 6.0 (IBM POWER) Certified view more SuSE SLES 11 (AMD64/EM64T) Certified view more SuSE SLES 11 (IBM POWER) Certified view more And a few Unixes according to http://certification.sybase.com/ucr/productResult.do. So sparse linux support.
Re: Proprietary Sybase DBI/DBD module
On 31 October 2012 20:34, DAVID HODGKINSON daveh...@gmail.com wrote: On 31 Oct 2012, at 17:53, Joel Bernstein j...@fysh.org wrote: On 31 October 2012 18:42, DAVID HODGKINSON daveh...@gmail.com wrote: On 31 Oct 2012, at 17:33, Jason Clifford ja...@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
Re: Proprietary Sybase DBI/DBD module
On 31 Oct 2012, at 20:00, Joel Bernstein j...@fysh.org wrote: Not to be snarky but the answer here seems to be yes, and what's your point? Companies that make you buy their software (limited, free, development version notwithstanding, limiting the *client* systems you use out of what, fear that you might use their software more widely?
Re: Proprietary Sybase DBI/DBD module
On 31 Oct 2012, at 20:40, DAVID HODGKINSON wrote: On 31 Oct 2012, at 20:00, Joel Bernstein j...@fysh.org wrote: Not to be snarky but the answer here seems to be yes, and what's your point? Companies that make you buy their software (limited, free, development version notwithstanding, limiting the *client* systems you use out of what, fear that you might use their software more widely? But do consider, loss of brand value/reputation as they can't properly test the client on every platform and one of their brand components is stability/reliability? And I suspect most people deploying Sybase are going to tailor the OS/distro around it. G.
Re: Proprietary Sybase DBI/DBD module
But, why on earth would this go into a standard perl distribution? It doesn't sound very standard OR widely distributable. You can't have it both ways... No one is trying to be unwelcoming, It's just that we're getting 2 conflicting messages here. -Original Message- From: Greg McCarroll g...@mccarroll.org.uk Sender: london.pm-boun...@london.pm.org Date: Wed, 31 Oct 2012 23:00:45 To: London.pm Perl M\[ou\]ngerslondon.pm@london.pm.org Reply-To: London.pm Perl M\[ou\]ngers london.pm@london.pm.org Subject: Re: Proprietary Sybase DBI/DBD module On 31 Oct 2012, at 20:40, DAVID HODGKINSON wrote: On 31 Oct 2012, at 20:00, Joel Bernstein j...@fysh.org wrote: Not to be snarky but the answer here seems to be yes, and what's your point? Companies that make you buy their software (limited, free, development version notwithstanding, limiting the *client* systems you use out of what, fear that you might use their software more widely? But do consider, loss of brand value/reputation as they can't properly test the client on every platform and one of their brand components is stability/reliability? And I suspect most people deploying Sybase are going to tailor the OS/distro around it. G.
Re: Proprietary Sybase DBI/DBD module
From: Dave Cross d...@dave.org.uk Well, there's only one standard Perl distribution[1]. And that doesn't include any DBD modules. It doesn't even include DBI. There are a number of distributions that include modules beyond the standard set. Offhand I can think of ActivePerl[2], Strawberry Perl[3] and DWIM Perl[4]. Some of these include DBI and DBD modules but (as far as I know) they only include DBD::mysql - as it's still by far the most popular database. None of them include DBD::Sybase, so the chance of getting them to include an alternative Sybase DBD would seem to be tiny. Thanks this is helpful. Popular is a slightly arbitrary concept: see http://db-engines.com/en/blog_post/1 for instance. Not that I'm saying that's correct simply that you choose your own definition of popular. I will grant you that mysql has the most downloads of any open source database. Obviously mysql is a database - but it's really not in the same market as Oracle, DB2, Sybase etc. IMHO mysql got itself scrwed for all time when it was acquired by Oracle. How better to control what features get added to a low end competitor. At the same time, you're dissuading development on other open source databases by having something with already good functionality. There are, however, a couple of alternatives that you can consider. Firstly, for a module to be considered real to most Perl programmers, it needs to be on CPAN. The PAUSE FAQ[5] is still (as far as I know) the best guide for getting a module onto CPAN. Sybase will be releasing to CPAN but they're still finishing off work/testing etc. Secondly, you could consider making pre-packaged versions of the module available for various platforms. For example, an RPM for Red Hat systems or a .deb for Debian/Ubuntu. You could try to get it into the standard package repositories for these systems but the niche nature of Sybase use is likely to count against you here. Niche is a point in time concept. SAP buying Sybase was a significant coupe for both companies. SAP competes head to head with Oracle in applications yet had been beholden to Oracle for its database. This had lead to all the complications you would expect. SAP is now pouring bucket loads of money into development of Sybase. 3 years ago, I was pessimistic that Sybase was going to become another hard to sell legacy skill on my CV (anyone remember SQLPlus: now there's a legacy database skill...). Now, I'm not so sure. SAP is targeting Sybase as being the number 2 commercial database in the world. They were able to add some credibility to that aim with statistics about the number of sites now migrating from Oracle to Sybase. But who knows. From: Jason Clifford ja...@ukfsn.org So long as it being proprietary does not prevent this model of distribution that's all you need to do. Thanks for your response too. It's only proprietary in the sense that it is written/maintained by SAP/Sybase. They're also releasing similar module for Python, PDP, and so on. They'll all be free and available in the standard locations like CPAN. RegardsChris
Re: Proprietary Sybase DBI/DBD module
On 30 October 2012 17:32, Chris Jack chris_j...@msn.com wrote: [ oh god, my eyes. please fix your mailer / quoting / attribution. please. please. i'm begging. ] There are, however, a couple of alternatives that you can consider. Firstly, for a module to be considered real to most Perl programmers, it needs to be on CPAN. The PAUSE FAQ[5] is still (as far as I know) the best guide for getting a module onto CPAN. Sybase will be releasing to CPAN but they're still finishing off work/testing etc. What's the question then? You seemed to be suggesting they wanted to distribute it without putting it on CPAN. If they'll put it on CPAN, it's a non-issue, just like Every Other Perl Module. If they stick it on CPAN they can still do more work on it (and they get other people to test it, too). CPAN releases should be regular, not one-off. And if it's not finished/tested enough for CPAN, why are you asking how to get it into Perl core? Your question doesn't really make any sense now. You could try to get it into the standard package repositories for these systems but the niche nature of Sybase use is likely to count against you here. Niche is a point in time concept. SAP buying Sybase was a significant coupe for both companies. SAP competes head to head with Oracle in applications yet had been beholden to Oracle for its database. This had lead to all the complications you would expect. SAP is now pouring bucket loads of money into development of Sybase. 3 years ago, I was pessimistic that Sybase was going to become another hard to sell legacy skill on my CV (anyone remember SQLPlus: now there's a legacy database skill...). Now, I'm not so sure. SAP is targeting Sybase as being the number 2 commercial database in the world. They were able to add some credibility to that aim with statistics about the number of sites now migrating from Oracle to Sybase. But who knows. That sounds pretty niche to me - a database I used to use a bit in the past which is now basically used to support a certain big app. Not seeing anybody migrating TO Sybase, are you? And I'm not sure why you think SQL*Plus is a legacy skill, isn't it still the standard command-line client for Oracle? From: Jason Clifford ja...@ukfsn.org So long as it being proprietary does not prevent this model of distribution that's all you need to do. Thanks for your response too. It's only proprietary in the sense that it is written/maintained by SAP/Sybase. They're also releasing similar module for Python, PDP, and so on. They'll all be free and available in the standard locations like CPAN. RegardsChris Then what is your question? I don't get it. Did you actually just want to say heads up guys, Sybase might actually be vaguely usable from Perl without FreeTDS sometime soon? Because that would've been a better and less contentious message to send. Finally, please, please, please fix your mailer, the quoting/attribution in that was impressively broken and it took me minutes just to -read- your reply. /joel
Re: Proprietary Sybase DBI/DBD module
On 30 Oct 2012, at 16:32, Chris Jack wrote: [...] IMHO mysql got itself scrwed for all time when it was acquired by Oracle. How better to control what features get added to a low end competitor. At the same time, you're dissuading development on other open source databases by having something with already good functionality. PostgreSQL and SQLite are both excellent open source databases that are still actively developed.
Re: Proprietary Sybase DBI/DBD module
Chris, Can you define proprietary please? It will be shipped with .so files? The source will be there but the license says we can't change it? Anything else? Dave
Re: Proprietary Sybase DBI/DBD module
On 10/30/2012 01:35 PM, DAVID HODGKINSON wrote: Chris, Can you define proprietary please? It will be shipped with .so files? The source will be there but the license says we can't change it? it seems pretty obvious to me. the sybase people have written a new driver which is being released in binary only form (hence proprietary) and also they have written a DBD for it which they will (or have) put on cpan. as usual the DBD will be open source and free. i would expect the binary lib to downloadable but useless without a sybase server which is commercial. the confusion is from not clearly describing the binary lib vs the perl/cpan DBD module as separate entities. uri
Re: Proprietary Sybase DBI/DBD module
Quoting Chris Jack chris_j...@msn.com: I'm just back from speaking at the Las Vegas SAP/Sybase conference (on a somewhat Perl related topic too!). One of the (other) interesting talks was about a new proprietary Sybase ASE DBI/DBD module for Perl (to be called DBD::SybaseASE from memory). They were a little short on specifics, but it sounds like it will answer a number of concerns with the current non-proprietary DBD::Sybase - for instance with performance of bulk loading. I asked what was being done about getting it into standard perl distributions, and the presenter didn't know. Hence my question: can anyone send me/post information or a link about how to get a new module into standard Perl distributions (and maybe also a list of the major perl distributions). Well, there's only one standard Perl distribution[1]. And that doesn't include any DBD modules. It doesn't even include DBI. There are a number of distributions that include modules beyond the standard set. Offhand I can think of ActivePerl[2], Strawberry Perl[3] and DWIM Perl[4]. Some of these include DBI and DBD modules but (as far as I know) they only include DBD::mysql - as it's still by far the most popular database. None of them include DBD::Sybase, so the chance of getting them to include an alternative Sybase DBD would seem to be tiny. There are, however, a couple of alternatives that you can consider. Firstly, for a module to be considered real to most Perl programmers, it needs to be on CPAN. The PAUSE FAQ[5] is still (as far as I know) the best guide for getting a module onto CPAN. Secondly, you could consider making pre-packaged versions of the module available for various platforms. For example, an RPM for Red Hat systems or a .deb for Debian/Ubuntu. You could try to get it into the standard package repositories for these systems but the niche nature of Sybase use is likely to count against you here. Does that help at all? Let us know if you have any further questions. Cheers, Dave... [1] https://metacpan.org/release/perl [2] http://www.activestate.com/activeperl [3] http://strawberryperl.com/ [4] http://dwimperl.com/ [5] http://www.cpan.org/modules/04pause.html
Re: Proprietary Sybase DBI/DBD module
On Mon, 2012-10-29 at 14:07 +, Chris Jack wrote: I'm just back from speaking at the Las Vegas SAP/Sybase conference (on a somewhat Perl related topic too!). One of the (other) interesting talks was about a new proprietary Sybase ASE DBI/DBD module for Perl (to be called DBD::SybaseASE from memory). They were a little short on specifics, but it sounds like it will answer a number of concerns with the current non-proprietary DBD::Sybase - for instance with performance of bulk loading. I asked what was being done about getting it into standard perl distributions, and the presenter didn't know. Hence my question: can anyone send me/post information or a link about how to get a new module into standard Perl distributions (and maybe also a list of the major perl distributions). RegardsChris Do you know what the license terms for redistribution of this module are? Ideally you simply upload the module to CPAN and, optionally, advise the producers of Strawberry Perl and ActiveState that it is available so they can package it up for their users. So long as it being proprietary does not prevent this model of distribution that's all you need to do. Jason Clifford
