This week there was an pretty important, but under reported announcement made concerning X. A few of the guys here at Red Hat (Kevin Martin, Soren Sandmann, Kristian Hogesberg and Mike Harris), Alan Coopersmith over at Sun, and Adam Jackson have been slogging away for the last few months to take the monolith that is X and break it apart into a more modular code base. This week they were able to announce RC1 of that modular release.

What does this mean for developers? This means that if you want to fix a problem in X you don't have to pull all of the code for X in order to fix that one problem. Instead you pull the component you want to work on and you can build against your installed X headers. This lowers the bar for individual developers to get involved with X. Hats off!

For doing X releases it also creates some interesting opportunities, assuming it's managed well. The fact that these pieces are all independent means that we can see a much faster rate of change in some parts of X while maintaining stability in those parts that are much more mature. The biggest opportunity here is in the driver world. Because X has pretty strong internal APIs and ABIs, it's possible that we can get to the point where we are doing driver development and releases independent of the larger X release. For a long time if you wanted support for your new card that you just bought at the store it's meant that you've had to wait for that huge monolithic X release to be done, on a multi-month or multi-year basis. Now we have the chance to do those software releases in sync with the release of new hardware availablility.

It also means that vendors who want to build drivers have a much easier time of doing that work without having to worry about the larger X release cycle. Of course, on the flip side, the support and testing matrix gets a lot larger. So there's some important decisions that need to be made in the X world about how to handle releases (should there be checkpoints where there is a large X release with a blessed set of components? Point releases just include updates for smaller sets of libraries where the larger set of source code remains untouched?) But these are questions that are a result of the new flexibility that has been created. So I'm happy to see them have to be answered. A symptom of success.

From the distributor's perspective, it means that we don't have to respin a few hundred megs of data and software in order to make a two line change. This means that release management and QA get a lot easier and in the commercial world that means lower cost to deliver working bits to customers. Everybody wins here.

If you see these guys you should thank them for taking the leadership role to make this possible. It's thankless work, but I think it's going to have a huge long-term impact on how X is developed and in the end will have a pretty signifigant, although indirect, positive impact on end users. Think about where we were a couple of years ago in the X world with XFree86 and the split that resulted in the move to x.org. We've come a long way.

There's an article in ZDNet talking about "PHP succeeding where Java isn't" but it's framed almost entirely in terms of technologies. However, they don't even mention what was probably the most important factor: the fact that PHP is free-as-in-speech. PHP got a free distribution system in the form of the various Linux vendors which is a huge factor in its rise to prominence. Java's licensing choice makes it impossible for it to tap this distribution method.

If you've installed a Linux system anytime in the last few years to use as a web server, PHP is just there. And it works. You don't have to futz around with downloading tarballs and setting up a Java-based web server or connector. All of a sudden, PHP becomes universal, available anywhere. As Linux has risen on the server side, so has PHP. The two are strongly linked.

Remember, it's LAMP, not LAMJ. Don't discount the distribution factor. It's huge. (Hint: just ask Netscape about its browser.)

Ruff!

For a very long time our desktop QA folks have been trying to figure out how to automate testing of entire apps, not just doing the piecemeal unit testing that often fails to find problems in an app itself. They weren't happy with most of the projects that were out there already, so they built their own. You can see what it can do today. I love the google example and the nautilus example is great.

Anyway, check out the main web site, download the code and let's start building out a solid test suite for our desktop. These guys did an amazing job over the last few months putting this together and we're quite proud of them. You should be, too.