Re^3: Getting Fed Up with ActiveState

[BrowserUk]

I don't necessarily think it should be an "author provides it or none at all" thing.

Agreed. But the motivation of the 'abandon ActiveState move' seems to be primarily driven by module authors who's modules are being flagged as 'unbuildable' by the automated AS process.

I think I can understand why AS do not fix the automated process. It's probably simply one of survival. They are (now again I think) as smallish company with limited pockets trying to survive. Any manual intervention into their automated process--which they provide free to the community with little possibility of return--would be a pure sink on their resources. They are already providing the storage, cpu and bandwidth.

I think that the premise that "they should do more" is flawed. Adding the need for personnel, to manually intervene, to the equation, could make the service and/or company go away completely! I also think that fostering the expectation that large volumes of win32 Perl (corporates and individual) users (as opposed to hackers) will abandon AS for a DIY build it yourself on every machine alternative is forlorn and pointless.

The moves in this direction, like strawberry perl, are motivated by the wish to make things easier for the Perl module developers--which by and large means non-win32 users--rather than the vast majority of win32 Perl users.

Making life easier for module writers to write, build & test their modules on win32 is a strong and good motivation. And it can only benefit win32 users also in the long term, by giving them access to a wider set of modules. But maybe the best solution would to not throw the baby out with the bath water.

If AS could provide a mechanism for allowing volunteer intervention to correct 'broken' automated builds might be one solution. Using CPAN to provide a central repository for binary distributions might be another. I realise that binary distributions can be bigger than a standard module, and that CPAN disk space is neither limitless and is also provided free to the community--and by many mirrors--by generous donations.

But then, there is an awful lot of cruft on CPAN now--stuff that hasn't been updated or downloaded for years if not decades--along with other stuff that probably shouldn't have ever made it up there in the first place.

Then again, I'm the wrong person to be having any of these thoughts--but I have them anyway.

[xdg]

I also think that fostering the expectation that large volumes of win32 Perl (corporates and individual) users (as opposed to hackers) will abandon AS for a DIY build it yourself on every machine alternative is forlorn and pointless.

Vanilla/Strawberry Perl are not "build it yourself". They are just packaged installers. Yes, it's volunteer labor. How does that differ from a Perl RPM or other package from any major Linux distribution? Or any packaged installer for Windows from other OSS projects?

motivated by the wish to make things easier for the Perl module developers--which by and large means non-win32 users--rather than the vast majority of win32 Perl users.

I think you have this backwards. It's motivated by Perl module developers who want to make things easier for the vast majority of Win32 Perl users by freeing them from the shackles of Perl 5.8.1 core modules mandated by the AS build process. The goal is to help users benefit from new or upgraded modules. Most users won't be bothered to try to figure it out a module that isn't available as a PPM could be installed anyway via CPAN -- if a PPM isn't available, they just won't use it.

If anything, it's making module authors' lives more difficult because of the greater number of modules getting scrutiny and bug reports on the Win32 platform. (c.f. Vanilla Perl Problem Modules) Tools like CPAN::Reporter are part of this -- increasing visibility of Win32 portability problems through CPAN Testers rather than leaving it relatively hidden inside a proprietary build system.

[BrowserUk]

... freeing them from the shackles ...

You have no concept of how corporates work. They love shackles. They invent shackles were there are none.

Do a supersearch of this place and look for all the posts that say variations on the theme of "I'm not allowed to install any modules" or "getting approval for the installation of a new module is a long and tiresome process".

If an IT department is going to distribute a Perl-based application to a couple of hundred user machines, the last thing they want to do is distribute a compiler, and mock-unix development platform to every machine also. Nor do they want to have to visit each machine individually and answer the same bunch of questions over and over in order to perform the installation.

And they sure as hell don't want to enable the user to pull random chunks of sourcecode from an open server (CPAN) and compile them locally.

They are just packaged installers.

Your concept of an 'installer' is bad also. When a corporate uses an MSI installation, it gets much more than just a bunch of files slapped onto the disk somewhere and then replicated to another part of disk leaving all the junk lying around.

A few of the benefits of using an MSI installation:

• Restores original computer state upon installation failure: Windows Installer keeps track of all changes made to the system during the application installation process. If the installation fails, Windows Installer can restore, or roll back, the system to its initial state.
• Helps prevent certain forms of inter-application conflicts: Windows Installer enforces installation rules that help to prevent conflicts with shared resources between existing applications. Such conflicts can be caused when an install operation makes updates to a dynamic link library (.dll) shared by an existing application, or when an operation deletes a dynamic link library shared by another application.
• Reliably removes existing programs: Windows Installer can reliably uninstall any program it previously installed. It removes all the associated registry entries and application files, except for those shared by other installed software. You can uninstall an application at any time after a successful installation. (Removal should not be confused with rollback, which restores a computer to its initial state when an installation failure has occurred.)
• Diagnoses and repairs corrupted applications: An application can query Windows Installer to determine whether an installed application has missing or corrupted files. If any are detected, Windows Installer repairs the application by recopying only those files found to be missing or corrupted.
• Supports on-demand installation of application features: Windows Installer can be instructed to initially install a minimal subset of an application. Later, additional components can be automatically installed the first time the user accesses features that require those components. This is known as advertising. For example, Windows Installer could install Microsoft Word with a minimal set of features. The first time the user tried to access a mail merge function (not included with the original installation), Windows Installer would automatically install the mail merge component. Similarly, Windows Installer can also purge components that go unused in an application. For example, Windows Installer could be configured to remove the mail merge component if it goes unused for 60 days.
• Supports unattended application installation: Installation packages can be configured to require no installation process interaction from the user. During the installation process, Windows Installer can query the computer for desktop attributes, including determining whether any applications were previously installed by Windows Installer.

And this doesn't even to begin to list all the security aspects. Like installing Perl on a machine such that only users who are members of a particular group can use it, in hot-desk environments where any employee can sit down at any machine and log on, but each user has different priviledges. Using an MSI, installing an application so that an non-authorised user won't even be able to see it is trivial.

Remote installs. I built a system for the remote installation and maintanence of application software on 40,000 desktops and portables located in dozens of separate sites distributed across an entire country. Any employee could walk into any site, sit at any desk and log on and his user profile (down to his choice of fonts and desktop colours--which is a legal requirement for visually impaired employees) was loaded onto the machine automatically. And if he attempted to use an application that had never been installed on that particular machine before, it was installed for him as he waited. When he logged off and the next user sat down to use it, it was a legal requirement that the next user would never be able to see anything that the previous user had been doing. There are 23 divisions within the company (actually a government department), and it is a legal requirement that all their work must be kept separate.

Using MSIs in this type of environment is a delight, because it knows and understands about the security setup; roaming profiles; domain based networking; and all the other bits and pieces that are need to make this work.

Trying to set this up with a 'installer', based around an emulation of an OS that has none of these concepts, would simply be impossible.

[xdg]

You have no concept of how corporates work. They love shackles.

That must be why they prefer Java to Perl. :-)

Trust me -- I understand corporates quite well. But one can always dream.

... variations on the theme of "I'm not allowed to install any modules" ...

Non-sequitur. If they're not allowed to install modules, it's all irrelevant. If they are allowed to install modules, then they might wish to use PPMs that rely upon core modules written since 2003. Moreover, even those using the latest release of ActiveState -- with up-to-date core modules -- can't get AS-built PPM's unless those PPM's build cleanly against the first 58x release. They have the dependencies -- just the build farm doesn't.

Side note -- one way AS could probably resolve this conundrum is to keep a separate build-farm and PPM repository for the first 58x release and the latest 58x release. Or just keep a separate build-farm and repository for each 58x minor release.

Your concept of an 'installer' is bad also. When a corporate uses an MSI installation...

That's a known issue. If you look at the roadmap for Vanilla Perl, switching to an MSI installer has been on the list for a while.

I built a system...

I'm very impressed. Are you at all interested in applying your experience to help instead of just pointing out shortcomings? I'm serious here -- not trying to be snide -- you clearly have thought a lot about this and have tremendous practical experience with MSI's and I freely admit I don't. I know we'll need experts to get it right.