On a deployment I’m currently working on, I’ve seen two different cases of proprietary software use leading to both madness and sadness, which are just so typical that I can’t resist to tell you. Keep in mind, for the rest of this reading, that the whole platform is running under Solaris 10 x86-64.
The first case is a data quality management software that we will keep anonymous. The editor promised before the deployment began that they had a version of the software for the operating system that we would be using. Well, it turned out they do have a Solaris version… for sparc, and a x86-64 version… for Linux. No Solaris x86-64 version, and no way to get a rebuild in a timely fashion.
The second case is a content management software that we will keep anonymous. It comes in the form of a java web application and a java application container. Part of integrating this software involves a proprietary plugin for Apache HTTPd that acts as a mix of mod_proxy_balancer, mod_disk_cache, and htcacheclean, as well as a cache invalidator.
Originally, the java web application was supposed to be installed within a JBoss Application Server instead of the editor provided container, and Apache HTTPd would reverse proxy requests to the JBoss server. This means we already had an Apache HTTPd in place (latest version ; 2.2.11 at the time), and since we have x86-64 processors, it was built as a 64-bits binary.
Contrary to the first case, this time, we had a Solaris x86 binary. Yes, you read correctly: x86 ; 32-bits only.
After going through the pain of rebuilding Apache HTTPd in 32-bits (there are various reasons why we don’t use sunfreeware software), it turned out the module was a 2.0 ABI module not compatible with the 2.2 ABI. It also turned out there was a 2.2 ABI version of the module for Solaris… sparc.
It finally worked after another build of Apache HTTPd, a 2.0.63 release, this time.
The more you get used to free software, the more these kind of things get frustrating.
Both comments and pings are currently closed.