[PLUG] LAMP Platform Updating Problems

Kenneth B. Hill ken at scottshill.com
Thu May 31 16:37:30 UTC 2007


On May 30, 2007, at 10:00 PM, Derek Loree wrote:

> On Wed, 2007-05-30 at 11:27 -0700, Kenneth B. Hill wrote:
>> I have a been leading a development project of a database app that is
>> built on a LAMP-variant platform (it uses Gentoo Linux, Apache,
>> PostgreSQL AND PHP) along with some CPAN perl modules and MapServer.
>> We seem to have problems with updates to the individual LAMP tools
>> not working with the other LAMP tools. For example, if we update
>> Apache with a security update, then we experience with features in
>> the app not working in a perl mod or PHP etc.
>>
>> I recently got back from a business trip, and I sat next to someone
>> on the airplane that does LAMP database application development. I
>> shared with him this experience, and he agreed with me that this is
>> an underlying problem with developing in a LAMP environment/platform.
>> This results in increasing our labor/time costs in maintaining the
>> infrastructure of the application. I would like to hear other
>> experiences with this issue - if any.
>
> I have found that there are two distinct types of problems.  One is
> caused by the Linux distribution package maintainers, the other is
> caused by the program/language developers.  The changes in packages  
> are
> usually the settings used to compile the packages (this can lead to
> dependency changes).  These can usually be solved by downloading the
> package source and re-making the package (or download the program  
> source
> and recompile the program).  This can lead to a DIY Linux system,  
> which
> has its own benefits and drawbacks.
>
> The developers of programs/languages have varying attitudes about
> backward compatibility.  The range is from "we don't care" to "we  
> will,
> at all cost, maintain backward compatibility".
>
> It may be easier to look at the likely problems with the different
> parts.
>
> I've never had a problem updating database servers, though I have read
> about them.  PostgreSQL does an extremely good job of maintaining
> backward compatibility.  MySQL tries hard, but has a higher problem
> rate.
>
> Apache does a very good job of maintaining backward compatibility,
> though they did make sacrifices to create a better product --
> particularly in the jump to Apache2.  The problems that do arise are
> usually caused by the linux distribution's change in features that are
> compiled in by default.  This is the most likely reason to go to a DIY
> system.
>
> PERL is somewhere between MySQL and Apache.  If you use strictly
> pre-packaged modules, you should be OK; however, there are a lot of
> chefs stirring this pot, so YMMV.   Thoroughly test your own code  
> before
> upgrading.
>
> PHP is a version nightmare.  They really don't make any attempt to
> maintain backward compatibility, the compatibility that is there is  
> only
> because the PHP developers couldn't find an excuse to change it.
> Distributions like Debian and RH are essential for maintaining pre- 
> built
> packages (including libraries) and the version dependencies.  For your
> own code, lots and lots of testing is required before attempting an
> upgrade.  Better yet, start from scratch with the new version.  Code
> that is written for multiple versions is BLOATED because of this
> attitude.
>
> Some people just don't upgrade because of this.
>
> Hope this helps.
>
> -- 
> Derek Loree
>
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>

Derek,

I can confirm your comment about PHP being a version nightmare. When  
we test an update to PHP on a QA box/server and then deploy the  
update to the Production box/server, we still experience problems/new- 
bugs in the application. My development team refers to these problems  
as "regression bugs", and these "regression bugs" are what's driving  
up our operating costs (e.g., we perform a update to the LAMP tools,  
and the application we developed breaks). I don't have nearly as much  
of this problem with my Windows platform web applications. Maybe that  
is the trade-off with using LAMP versus Windows; one pays the license  
fee for the server OS, SQL Server database, IIS, etc. and one gets a  
little bit more reliable platform??? This has been a very interesting  
experience for me in realizing total ownership/operations cost (TOC)  
with open-source software.

-Ken



More information about the PLUG mailing list