This recent article from the Builder.com.au website shows exactly how simple it is to get a LAMP server up and running on your Ubuntu installation.

I can't tell you how many times I have been asked what is the fastest, easiest way to install a LAMP (Linux Apache, MySQL, PHP) server on Ubuntu. Well, I guess it's time I just post it here for everyone to enjoy.

You're just two apt-get calls and a few various commands away from pulling in an Apache 2 web server and a PHP5 module that has MySQL support already built in. Set the password for the MySQL installation and you're all set to go.

In a new post today Stuart Herbert asks the question "is it possible to secure a shared server with PHP and FastCGI installed on it?" His answer follows...

The challenge with securing a shared hosting server is how to secure the website from attack both from the outside and from the inside. PHP has built-in features to help, but ultimately it's the wrong place to address the problem. [...] Before we can look at performance, the first question is: how exactly do we get PHP and FastCGI running as different users on the one web server in the first place?

He follows through on this, giving a little mini-tutorial on getting the environment installed on an Apache web server. He includes some benchmarks on the difference between using the Apache 1.3.x series and Apache 2 (generated using the ab benchmarking tool).

Lorna Mitchell has posted the last part of her development process towards creating a sample REST server in PHP:

This is part 3 of my article about writing a restful service server. If you haven't already, you might like to read part 1 (covering the core library and grabbing the information we need from the incoming request) and part 2 (covering the service handler itself) before reading this section. This part covers the Response object that I used to return the data to the user in the correct format.

She show how she created the object to push the response back out to the client with an output() method that displays the XML response in a manually generated format.

Lorna Mitchell has posted the second part of her series detailing her REST server development project (part one is here).

This is part 2 of my rest service writing article. In part 1 we saw the library which holds the functionality we will be using, and we also handled the incoming request and captured all the data we'll be using.

In this second part she gets into the details behind the handle() method of the class. It splits the URL into its parts and, based on the action requested, hands it off to the right method and calls the output() method to return to the user. Some error handling is also included (with custom exceptions).

In a new post to the ThinkPHP blog today there's a look at combining Comet with PHP to make a simple method for the client to talk back to the server outside the usual methods.

If a couple of users have opened the application there are already some hundred or thousand requests per second. The outcome of this is a big load for your server and a highly increased traffic - your server will in a senseless way be overloaded. In conclusion, our problem is the enormous amount of polling without knowing whether the server really wants to send a new push. Let's turn the initial situation around. And we get the solution to our problem: Comet.

With Coment, the model changes and the request is "cached" on the server-side automatically in a single Comet instance. Coordinate this with another recommendation of theirs, a PHP socket server, and you can do some pretty interesting things.

Lorna Mitchell has started a three part series on her blog detailing the process she went through to develop a REST server in PHP.

I recently had reason to write a REST server in PHP, which was very interesting. There aren't a whole lot of resources on this topic around so I thought I'd write an outline of what I did. There is quite a lot to it so I'm publishing in multiple sections - this is part 1, which covers the central functionality and handling the incoming request.

In this first part she talks about the wrapper class she developed and includes some sample code that does the initial handling of the request (reading from php://input and passing it off to a handle() method to the taken care of).

Harun Yayli mentions some updates to his memcache.php project (providing statistics on the optimization your site is gaining from using the memcached extension).

Your good comments from all over the world about memcache.php is amazing. Thank you all! I've recently received a contribution from Michael Gauthier. I took the liberty to tweak a bit and now memcache.php can flush individual server (no flush all servers yet).

The latest version of the file can be downloaded here and some sample output can be seen here.

On the Zend Developer Zone there's a new article that looks to answer the question in its title - "Why should I care what server my application is running on?" (by Eddo Rotman)

Imagine this - you develop an application on your machine and then, when you come to deploy it to the production server, all of a sudden, you encounter various errors and failures. Or maybe, when you decide to switch your hosting provider, your application stops behaving the way it should. How about this -... one day, out of the blue (well, out of your IT manager's whim) your application just misbehaves. Sounds familiar?

Times like can never be completely avoided (yes, there'll always be bugs) but you can take some steps to help prevent most of the major failing points. He points out some of the key configuration directives to watch out for, differences in some functions' responses based on the OS, and the differences in character sets between a unix-based and Windows based environment (like rn versus just n).

A pretty cool project in PHP - Memproxy is a caching proxy "server" that uses memcached for storing the cache. This project uses PHP scripts to handle caching using memcache.

The server uses memcached to store the information and automatically manages things like TTL, custom headers and is "application agnostic" all wrapped up in a small codebase with minimal dependencies.

Brian Moon has announced the release of the latest version of his memproxy tool that uses memcache to create a "server" to save the proxy information.

I put server in quotes because it is really just a PHP script that handles the caching and talking to the application servers. Apache and other HTTP servers already do a good job talking HTTP to a vast myriad of clients. I did not see any reason to reinvent the wheel.

Features of this new version include a TTL for the cached data, minimal dependencies for the application to use and a small code base consisting of two files. It also handles HTTP 1.1 requests, is transparent and applows pages to dynamically be specifically added and removed from the cache.

You can download this latest version from the project's page on the Google Code website.