|
in reply to Re: Getting Fed Up with ActiveState
in thread Getting Fed Up with ActiveState
I noticed that with the exception of my Strawberry Perl reference, you didn't address a single point I made. Instead, you tell how friendly ActiveState has been (and I do agree on this point) and you then attack me. This is not productive. I listed very concrete issues and linked to the evidence.
Since AS can't support core module upgrades, users cannot use modules which require those (but see next paragraph). Since AS apparently doesn't fall back to Makefile.PL if the Build.PL has problems, users cannot use those modules. And when we have modules which have all tests pass but are still listed as failing, I, as a module author, have no way out.
Yes, I can tell users how to find other PPM repositories or tell them how to install a compiler and find nmake, but when I have thousands of dedicated servers, this becomes a support nightmare, drives up costs, and ensures that my company has to spend more more working around problems in a build process we don't control instead of providing more features for our customers. This costs our company money.
These are issues that ActiveState has known about for years. For a small company, they've done great things for the Perl community and I don't want to disparage that, but when one of the fundamental needs of a particular open-source product is not met, it becomes a stumbling block and toolchains must not fail if it can be avoided. The more difficult a toolchain is to work with, the more likely someone is to choose different tools. I've emailed ActiveState in the past about related problems and Adam Kennedy has communicated with them for over a year on this, to no avail. Even a quick search on Google has led me to a number of similar horror stories. I also know of at least one module author who no longer worries about Windows because of how painful things are. How this could possibly serve the needs of the Perl community, I don't know.
|
Re^3: If you take me to task, at least provide an argument
by chromatic (Archbishop) on Dec 02, 2006 at 20:03 UTC
|
I also know of at least one module author who no longer worries about Windows because of how painful things are.
I certainly don't. If Windows users care to provide me patches or advice to fix problems, I'm very grateful, but I that's happened only a couple of times in the past four years.
| [reply] |
|
|
| [reply] |
|
|
If overload doesn't work on any platform you run, I'm sure p5p would welcome your bug report. Otherwise, I'm not sure what you mean. Are you suggesting that I deliberately break Windows support in my code?
| [reply] |
|
|
|
|
|
Re^3: If you take me to task, at least provide an argument
by vkon (Curate) on Dec 02, 2006 at 19:24 UTC
|
I admit that I quickly become too aggressive to your responce...Actually, sorry, I should have more concrete points on the matter.
Please excuse me for my tone.
But when you met some difficulty/bug, far more productive is to correctly work with misbehaviour, but driving people away from AS is counterproductive.
You say some bug costs you money. But isn't *every* bug cost money, more or less?
Finding a way around bugs costs human attention, which turns out to be money in the end.
My example - my PocketPC throws away my internet browser, so I need to reload via mobile network some pages again, and again, so this cost me money spent on trafic.
Okay, calming down once again :) let me notice that value of binaries produced by ActiveState is not only exact versions of binaries, but this entire support of several languages together makes even more added value. (I mean new alternative of perl/Tk feature ActiveTcl, which is a big step forward)
Returning to your original question, there was similar problem in Perl core itself, longly discussed in p5p.
There was an error for module searching algorithm. If you have module in the core, but then install it from CPAN, then you get both versions on disk, but actually used version is wrong one.
Very old and very serious problem, and I even suspect you faced namely this problem.
what to do in the realm of thousands of frustrated users? Switch to python?
In my opinion calm discussion with p5p and with AS (which are sometimes are same people) is the best option.
Best regards,
Vadim.
PS Thanks for constructive reply, and please forgive my yet other ramblings, which a hopelly not such aggressive this time :) | [reply] |
Re^3: If you take me to task, at least provide an argument
by syphilis (Archbishop) on Dec 02, 2006 at 13:48 UTC
|
Since AS can't support core module upgrades, users cannot use modules which require those
But AS perl can (and does) support core module upgrades. Any user with a compiler (either a free/commercial M$ compiler, or the freely available MinGW compiler) can upgrade core modules on ActivePerl. If that's not happening, then I think you should blame the user ... not ActiveState.
I think it's up to the user to overcome the PPM shortcomings. It's not a difficult task.
Cheers,
Rob | [reply] |
|
|
Forgive me for repeating myself:
Yes, I can tell users how to find other PPM repositories or tell them how to install a compiler and find nmake, but when I have thousands of dedicated servers, this becomes a support nightmare, drives up costs, and ensures that my company has to spend more more working around problems in a build process we don't control instead of providing more features for our customers. This costs our company money.
Complexity management is one of the most severe problems with software today and I fear that many technical people simply do not understand it. I didn't and had to have it beaten into my head repeatedly over the years. It's very easy to get wrong and every time we try to pass a problem onto users, we add another layer of complexity they have to deal with.
Even when we give users crystal clear instructions which are difficult to get wrong, they will get those instructions wrong. Even if it's only one percent of users (and for installing compilers, it will be greater than that), imagine what happens when you have thousands of users.
| [reply] |
|
|
C:\> ppm repo add trouchelle http://trouchelle.com/perl/ppm/
C:\> ppm repo add bribes http://www.bribes.org/perl/ppm/
C:\> ppm repo add uwinnipeg http://theoryx5.uwinnipeg.ca/ppms/
might help an accident-prone user?
Also along these lines, if you want to provide a package that demands a non-trivial set of prerequisites, one possibility is to make a
bundled zip archive of all the ppm packages, which then can be installed, in principle, from a batch file - see
http://theoryx5.uwinnipeg.ca/ppms/bundles/ for some
examples.
| [reply]
[d/l] |
|
|
Even when we give users crystal clear instructions which are difficult to get wrong, they will get those instructions wrong
Yeah ... I can sympathise ... but really, if you want to make money out of morons, then you have to be prepared to accept the fact that they're ... umm ... morons.
But it's unfair to go blaming ActiveState for not being able to come up with a moron-proof system. Strawberry Perl (which I've starting advocating, btw) is not a solution to this problem ... those morons are still going to have to learn how to invoke a compiler.
(I apologise for the use of the word of "moron" ... I shouldn't do that. Just because one doesn't know how to use a compiler doesn't mean that one is a "moron" ... there was a time when I didn't know how to use a compiler ... but then .......... :-)
Cheers,
Rob
| [reply] |
|
|
