So here you go… may I present Blake's CentOS LAMP Server Guide, single-page edition, and the perhaps friendlier multi-page edition.

The guide covers the basics of building up a CentOS box to use as a remotely-administered LAMP server, including installation and configuration of PHP, Apache and MySQL. Other goodies are in there too, like mail server setup with Postfix/Postgrey/Dovecot. Keep in mind this guide was written from my point of view, and contains the ways that I like to do things. I keep my basic LAMP stuff pretty slim for maximum performance, so you'll see some installations from source in there to help keep things tight.

Let me know if the guide is useful! I'm hoping to get Google to pick it up and get some comments going on the various ways people set up their own LAMP boxes.

In the meantime, I noticed a new article over at Sitepoint about the upcoming PHP 5.3 release, slated for later this year. Apparently some new features which were originally scheduled for PHP 6 are now included in 5.3, including Late Static Binding, and Namespaces!

While I can't get too excited about Namespaces, I know there are people out there that will love the fact that they will finally be arriving to PHP-land. By its very nature a lot of PHP projects are small, and you can usually get along fine without Namespaces on a small project. But with larger PHP sites and applications like Facebook becoming more commonplace, Namespaces are bound to come in exceedingly useful for some people.

On a more personal-project level, I find Late Static Binding to be much more exciting. The examples given in the Sitepoint article are very thorough so I won't reprint them here, but the quick summary is that if you have a function in a Parent class that uses the self:: operator, you can't call that function from the perspective of a Child class, as self:: always references the class it is in (ie. the Parent). Late Static Binding will give PHP developers a new reference called static:: which changes that; it will resolve to the static class at runtime (ie. the Child). This will allow for a much more intuitive extensions of parent classes in object-oriented PHP!

Good stuff, you should check it out.

Dubious literary merits of top-ten lists aside, I thought I'd re-post the list here. Then I thought I'd make fun of it and finish with a life lesson about how cheerleading for a technology is rarely worth the effort, unless you're getting personal kickbacks.

10 Reasons Why PHP is better than ASP

1. PHP.NET the greatest API resource known to MAN
2. If you have a problem, someone will have already implemented a solution in PHP for you
3. Syntax is better, closer to C, C++, and Java. Unlike VB where anything goes.
4. To run ASP you need IIS on windows, which is not free, for PHP however you need linux and apache which are FREE!!
5. Great built in support for ftp, email, graphics package GD2 and also MySQL (also FREE).
6. PHP will run on Unix, Linux, Solaris and Windows. ASP is mainly only Windows associated but you can use it on linux with additional modules installed.
7. PHP code is much faster, ASP is developed on the COM based architecture, this is an overhead for the server.
8. mod_rewrite, need I say more.
9. Advanced Perl-compatible regular expression functions and loads of built in support for regular expressions on the whole.
10. Greater control over error handling, and more detailed error messages.

My god! It's full of assumptions with no real data backing the arguments whatsoever! I am absoultely SHOCKED to find something like that on the internet!

Sarcasm aside, I think the author was just trying to say how happy he was with PHP. I can't fault him for that. Letterman has shown us that sometimes you have to really stretch to fill out a top ten list too, so I'll cut him some slack there. He probably just wrote down a bunch of stuff that his overall PHP programming environment did better than his old ASP one. But if you're going to promote something at the expense of something else, you should try to have your arguments straight. So let's burn it down:

1. PHP.NET the greatest API resource known to MAN

I like the php.net site as much as the next PHP programmer, but I'm going to go with Kip here and say, "Nobody can know that, Napoleon." I'll agree that the PHP site offers much better reference than anything I can find for classic ASP, but it's a bit of hyperbole to say it's the greatest API resource ever. It's a decent point, and I award honors for enthusiasm, but it's not really a concrete reason as to why the PHP language is better than the ASP language.

2. If you have a problem, someone will have already implemented a solution in PHP for you

That's not a reason why PHP is better than ASP. That might be a reason why the PHP community is better than the ASP community, but it says nothing for the language itself. All this can tell us is that there are likely more PHP users than ASP users. By this logic, C and C++ are 'better' than PHP.

3. Syntax is better, closer to C, C++, and Java. Unlike VB where anything goes.

Half-point for this one. If we're talking classic ASP, PHP is certainly more palatable, at least to me. But syntax is a subjective topic (which is why some people still use Perl. Hah! Low blow.) PHP isn't a walk in the park either though. One of PHP's downsides is that the core functions were put together a bit willy-nilly (some string function start with "str_", while some are just "str"), so often a programmer has to go to the documentation just to find out a function name. And keep in mind that at the time classic ASP was being compared to PHP, it was PHP 3 that most people were using. Go back to that baby and find out just how much better the newer PHP versions are!

4. To run ASP you need IIS on windows, which is not free, for PHP however you need linux and apache which are FREE!!

A for effort, D for results. If you were really using classic ASP without using Windows (IIS is free with Windows), then how about Apache::ASP? It's been around since 1998, eight years before this guy's post. This would be an argument for the cost-effectiveness of a language, not for how good the language is.

5. Great built in support for ftp, email, graphics package GD2 and also MySQL (also FREE).

I agree with this. PHP comes with a much better set of default functionality than classic ASP.

6. PHP will run on Unix, Linux, Solaris and Windows. ASP is mainly only Windows associated but you can use it on linux with additional modules installed.

I can only offer a rebuttal here from the point of view where both PHP and ASP are being used to serve web pages, and in this case his point isn't a real argument. To serve PHP web pages, you need to install a PHP module for your web server (the typical install), or a web server that handles PHP natively (none exist that I'm aware of). To serve ASP web pages, you need to install an ASP module for your web server (Apache::ASP), or a web server that handles it natively (IIS, UltiDev Cassini*). It's the same thing in either case: you have to install or modify a web server to serve pages for your chosen language. This is really a platform consideration, not a language consideration. You can't make this comparison for standalone PHP (such as the CLI) either… it would be like saying C is better than PHP because I can make desktop apps with C. You're comparing different tools in that case.

7. PHP code is much faster, ASP is developed on the COM based architecture, this is an overhead for the server.

Likely, but debatable. PHP is an interpreted language, which means that your web server has to load in the interpreter and all the required libraries each time it uses PHP. Just like a web server would have to load in the COM libraries each time it wanted to serve some ASP. So… got any benchmarks? Because my dad is faster than your dad.

8. mod_rewrite, need I say more.

This is a junk point and quite irrelevant. mod_rewrite is a feature of Apache, not PHP. If you don't like the features of IIS, use something else. Did I mention Apache::ASP yet?

9. Advanced Perl-compatible regular expression functions and loads of built in support for regular expressions on the whole.

Huh? I admit, I've never done any classic ASP regexp work, but a simple Google search resulted in this article on VBScript regexps. Looks pretty much like the standard "advanced" Perl regexps to me. I can get behind the "built-in support" aspect of the comment, as it looks like you might have had to write your own ereg_replace-style functions, but it doesn't look like ASP is lacking anything in the regexp-engine department.

10. Greater control over error handling, and more detailed error messages.

Disagree. PHP didn't get decent error handling until PHP 5, by which time classic ASP had been replaced by ASP.NET, so you'd want to compare those instead. Building an error-handling structure in PHP back then would have been about the same amount of effort as building one for a classic ASP application.

So, in summary, newsgroup arguments suck. Why would someone post a year-old argument about to a newsgroup that's not even on topic (classic ASP is not ASP.NET)? Whatever the reason, the resulting flamewar on the newsgroup is proof for one of my favourite sayings: "Think of just how stupid the everyday median person is… and then realize that half of them are stupider than that." Average newsgroup poster's intellect aside, cheerleading PHP in this kind of way generally just leads to all the nay-sayers pointing out how crappy most of the PHP code out there is, and PHP is still fighting this kind of image. If you were writing a professional application, some of these points might be useful in an overall comparison of system architectures, but as far as distinct language differences go it's a pretty fluffy list.

PHP is my favourite language. I personally would never use classic ASP over PHP for a web project, but that's not because of any significant language difference, claimed or real. None of the points in this guys list prove anything about either language, and are really just unsubstantiated ponderings on his own personal experience. That's fine, as long as you don't draw any conclusive results from it! I'm sure the guy just wanted to express his new-found satisfaction and personal appreciation for PHP in a catchy form, which is great. Have hammer, everything looks like nail, etc. However, judging by the ridiculous newsgroup activity, the author would have been much better off writing something like "I like PHP better than classic ASP because setting up a complex search-engine friendly PHP application using Apache and mod_rewrite is easier and more cost-effective than setting up a similar ASP application using IIS". His points would support that statement much better, and I would agree with him wholeheartedly!

So as it's a new year, and this is a new blog, it's totally inappropriate that I start things off with a death announcement. In case you hadn't heard, PHP 4 is done, finished, kaput. And thank Zeus! Only one more major version to go until Magic Quotes are but a painful memory. Don't get me wrong… PHP 4 has kept me employed in various ventures over the last 7 years, but Magic Quotes are a pain in the ass if you don't know what you're doing, and I sure didn't for a long time. Seven years… oh, the memories. I remember the first PHP app I worked on, years ago, in the glorious dot-com summer days of 2001. It was a bulletin board (dare I name it? yes, of course) called vBulletin, and the damn thing didn't even have any indexes on its MySQL tables when I was tasked with fixing a particular installation at the little start-up I worked for at the time.

Anyhow, the PHP folk'll be dragging out security releases until the end of August '08, and after that you'll need to have your apps in shape. Check out the migration guide. There's so many compelling reasons to upgrade to PHP 5 that I won't even get into it here. The upgrade process is generally pretty painless, unless you happen to work at my current job where someone decided to change $this to a null reference in some of the key application classes.

Even though I'm the PHP guy of this two-bit operation, keep in mind that I actually like .Net, especially for non-web application programming, of which I've done practically none. One time I thought I might be applying for a .Net job though, so I started a small non-web project to get my hands dirty. I didn't get very far, but I did end up with a desktop app that did a good job of displaying a picture of a rather awesome cold baby seal. However, although I like .Net, I fear change, and I am solidly behind PHP as a web development tool.