http://www.perlmonks.org?node_id=587370


in reply to Re: Getting Fed Up with ActiveState
in thread Getting Fed Up with ActiveState

Partly the reason this stuff can't be fixed is that it can't be fixed.

I spent a YEAR trying to get my modules (most of which need refaddr via deps) supported in the PPM build system, to no available.

I even spoke to them IN PERSON, was assured something would be worked out, and eventually got to the position at the end of the day that some of the technical bugs in the PPM system CAN'T be fixed due to commercial reasons.

Likewise, they can't bundle GCC with Perl like Vanilla/Strawberry does due to licensing conflicts, with those licenses there for commercial reasons.

So after a year of trying, I simply concluded that depsite their previous good works, which I appreciate, ActiveState has now reached the point of damaging Perl. That's nothing against the individuals involved, just that ActivePerl appears to me to have worked itself into a commercial and legal position that is untenable.

And so I decided to, like the internet, route around it and just make a "normal" Win32 Perl distribution that removed the commercial constraints and did things the way I was used to having them on Unix.

And the end result after the help of dozens of awesome volunteers was Strawberry.

Replies are listed 'Best First'.
Re^3: Getting Fed Up with ActiveState
by demerphq (Chancellor) on Dec 02, 2006 at 14:46 UTC

    most of which need refaddr via deps

    Thing I dont get about this is that I can see a couple of work arounds for this problem that would be pretty easy to do. For instance before you use any dependencies you use Scalar::Util then check if refaddr is available and if not then you simply create your own Scalar::Util::refaddr().

    But I guess I'm glad you didnt find a solution as the Milkshake-Perls are a real bonus. More competition in the marketplace is a good thing. :-)

    ActiveState has now reached the point of damaging Perl

    I'll just add that I think that this is extreme. They do lots of stuff for the perl community, maintain some of its most important modules, and provide for free services that are very valuable to the community. I think they should be respected for that.

    ---
    $world=~s/war/peace/g

Re^3: Getting Fed Up with ActiveState
by syphilis (Archbishop) on Dec 02, 2006 at 10:03 UTC
    ActiveState has now reached the point of damaging Perl

    Interesting notion ... I doubt that ActiveState would wish to damage Perl. If they are being forced to do so, then perhaps that's an indictment of the legalities involved (as opposed to an indictment of the course of action that ActiveState have chosen to pursue).

    Basically, I'm just wondering whether you should instead be asserting that "the law has reached the point of damaging perl". (I'm not a lawyer, so I can't give an answer ... and if I were a lawyer, then my answer would probably be biased :-)

    Cheers,
    Rob
Re^3: Getting Fed Up with ActiveState
by BrowserUk (Patriarch) on Dec 02, 2006 at 11:48 UTC
    Likewise, they can't bundle GCC with Perl ...

    Can't? Or don't want to? You do realise that there is a difference don't you?

    I don't want them to bundle GCC with their distributiom, and I'm bloody sure that a large number of their corporate clients don't just 'not want them to', but would abandon them and Perl if they did.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      I'm bloody sure that a large number of their corporate clients don't just 'not want them to', but would abandon them and Perl if they did

      Maaaan ... much as I love you - that's not an astute assertion to make.

      ActivePerl already supports MinGW's gcc compiler. One can use either that compiler, or an MS compiler, with ActivePerl - and that state of affairs would not change if AS distributed MinGW's gcc with their ActivePerl builds.

      If the corporate clients did not wish to use the gcc compiler that was being (hypothetically) shipped with ActivePerl, then they would simply ignore its presence and proceed with "business as normal".

      Cheers,
      Rob
        If the corporate clients did not wish to use the gcc compiler that was being (hypothetically) shipped with ActivePerl, then they would simply ignore its presence and proceed with "business as normal".

        Aaah but ..., would their security policies allow that? I know of (having worked for them) many corporates that simply wouldn't consider distributing a compiler--anyone's compiler--to their general purpose workstations. Full stop. It would not be allowed to happen.

        So, unless AS produced two distributions, one with and one without, these corporates and government departments alike, would cease distributing Perl to workstations.

        Likewise, even in their IT departments where the developers workstation image routinely incorporates development tools, distributing a second C compiler is likely to produce conflicts--libraries, header trees et al--and that could break their existing, carefully tested toolset. You doubt this? See Re: Re(2): Usage of tools for an example of the extremes many corporates go to ensure standardised toolsets. This is not uncommon.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.