OSNews

LAMP is PHP land and there is no equivalent to .NET on the server.



I work on both LAMP and .NET professionally and it's not my decision to "throw out" anything. I also know what the hell I am talking about since I deal with this problem throughout the year.

Here is an example:

Zencart (one of the top shopping carts)
Zen Cart v1.5.0

Minimum server requirements:

PHP 5.2.14 or higher, or PHP 5.3.5 or higher.
Apache 2.x or newer (Specifically the latest PCI Compliant version)

PHP 5.2.14 came out in 2010. Why should a shopping cart be dependent on the latest version of PHP and a specific series of a web server? Why is there an Apache dependency? What if I don't want to use Apache?

This is the norm in Linuxland. Everyone builds against latest since there isn't anything like .NET to maintain backwards compatibility. The standard strategy is to get latest and tell anyone who has software dependent on PHP or MySQL N-1 to f themselves. I know this first hand since I've had to fix a lot of PHP code that had dependency breaks or was version abandoned by the developer.



Well you don't know much about LAMP development then. What developers would like to use and what they build against for business reasons are two entirely different things. CENT/RHEL is the standard for web servers and going outside it increases the conflict risk. That means higher support costs.

Again don't get defensive since all these annoying dependencies benefit Linux when it comes to web servers. It creates inertia and discourages stepping outside the norm.

ze_jerkface,

"Well you don't know much about LAMP development then. What developers would like to use and what they build against for business reasons are two entirely different things. CENT/RHEL is the standard for web servers and going outside it increases the conflict risk. That means higher support costs."

I think Soulbender would already agree with your complaints about PHP, as do I. But you are exaggerating the difficulty of using alternate linux distros for the server. It's practically plug and play no matter which distro you use. Also, I haven't had much trouble replacing apache with alternates like lighttp either, just because it's not officially supported doesn't mean it doesn't work.

I'm not saying we should step outside of "supported" installations willy nilly, but if there is a good reason to then it's certainly feasible.

You answered your own question in your example: PCI Compliance. I'm dealing with this exact issue with a client right now. I've almost convinced her to leave Zen Cart behind for a sane solution, but she has a love/hate relationship with it; she loves the power and flexibility, but loathes the compliance issues. If it weren't for the PCI Compliance nightmare, I'd be content to support her Zen Cart instance, but it's making us both pull our hair out.

The OP talked about PHP/Perl/Python.



OH MY GOD! You found an application with some stringent requirements. Wow, good thing there are no .NET apps out there that require a specific .Net or IIS version....


...wait. Does it depend on the latest version or 5.2 and 5.3?



Have you actually tried using it with something else? We have FPM these days and I'm still to find a PHP app that ran with mod_php and not fpm. Maybe zencart is horribly written and won't work outside mod_php but that's a developer problem, not a PHP one.
Also Apache 2.x or later is not a specific version and if you're still using Apache 1.x you have bigger problems.



In other words, a developer problem and not a PHP problem.


Yeah, sure I don't. Personal attack already? Argument not going well?



That's an imaginary risk. In terms of web development the differences between RHEL/CNT and, say, Ubuntu Server or SuSE aren't significant.

And why are you using an old version of PHP. PHP developers maintain 2 branches (5.4, 5.3) of their software. For each one they do a point release every month or 2 to fix issues (being security most of the time). So having an old (and probably vulnerable) version exposed to the outside world is not very wise.

What you need to do if you use a Linux distribution that is release based, raise the voice and ask them to provide point releases instead of "backporting" bug fixes which usually came late, if they came after all.

Edited 2012-11-27 15:30 UTC

Maybe RHEL is the standard in Linux servers, but their long term release is not the best choice for all the packages that form the RHEL distribution. Yes, a LTS Kernel/Core packages mean a stable system, but why I want backported patches to all the web apps it provides. They don't even trust that system on their own servers. For example, check in RHEL/CENTOS repository which version of Bugzilla they have available for install. I'm sure they don't have the last one, which in fact is the one currently running on their own bug tracking server.
https://bugzilla.redhat.com/

Also (and sorry if I get you down of that cloud), (1) Developers test against the upstream packages, that's why a package said it requires at least X.Y version, and (2) Who told you upstream developers user RHEL in the first place. They usually use more lean and clean distributions (the lest fat, the better).

Edited 2012-11-27 19:51 UTC