[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