|
Re^2: If you take me to task, at least provide an argument
by Ovid (Cardinal) on Dec 02, 2006 at 12:49 UTC
|
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.
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
|
|
|
|
|
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] |
|
|
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] |
|
|
|
|
Re^2: Getting Fed Up with ActiveState
by xdg (Monsignor) on Dec 04, 2006 at 06:21 UTC
|
| [reply] |
|
|
I think the word you were looking for is "Alpha"
I don't really understand why Strawberry perl is alpha. There's nothing alpha about the components that make up the Strawberry distro - namely dmake, MinGW, and MinGW-built Perl. Yet, somehow there's a (perceived) reason to label a pre-packaged distro of those components as being "alpha" ?
Calling it "alpha" casts, by association, unwarranted doubts (imo) upon the reliability of the components that make up the package.
Cheers,
Rob
| [reply] |