In this issue

A new alpha release of Apache 2.0 hit the streets this week, 2.0.31, and a few issues were quickly unearthed: a compilation problem on Netware, and a bug where Apache will not run as a service on Windows. After being tested for road-worthiness on the live server at apache.org, some further minor problems were found and quickly fixed, with the group already looking towards making 2.0.32 a beta.

The support for enabling pthreads-based accept() serialization using the AcceptMutex configuration directive suffers from a serious problem on Solaris platforms, it was discovered this week. As the pthreads library was not being linked into the httpd executable, stub versions of the mutex functions are used from the C library, which resulted in no serialization being enforced. A fix was checked in, and discussion started about making a 1.3.24 release. In the meantime, administrators on Solaris using multiple Listen directives in conjunction with AcceptMutex pthread might consider using the default AcceptMutex instead.

This week a number of serious problems were found in various parts of the Oracle Application Server. Of particular note are a number of buffer overflows in an Apache module supplied by Oracle. However, all of the exploits or problems that were found are in Oracle extensions to Apache and do not affect Apache in any other situation. More details are available

After a highly successful conference last year (read about it in our special feature), O'Reilly is back and announcing the 4th annual Open Source Convention. The convention is a five-day event designed for programmers, developers, strategists, and technical staff involved in Open Source technology and its applications and is being held in July in San Diego. The theme this year is "Doing More with Less". O'Reilly are currently looking for people to give presentations and lead tutorials at the conference, and have details on how to submit a proposal.

I have some concerns about Apache 2.0's stability.

People have been working on the software for many months now, and users are awaiting its release (some patiently and some less so :-). Why is it taking so long?

The usual answer, and still the best one, is that it takes a while to produce quality software, and it won't be released until it's ready.

Another answer, however, is that the quality is taking so long to achieve because the codebase keeps getting destabilised. It seems as though basic underlying subsystems keep getting modified, frequently in a significant way, on a monthly if not weekly basis. Perturbations from these changes ripple through the rest of the server, and it often takes weeks for the last temblors to subside.

And rather than each developer working on its own pet area without affecting others, a great deal of many people's time seems to be getting spent on cleaning up after each other. Why? I'm not sure. This has always been a problem in the project, but it's currently at least an order of magnitude worse than it was a couple of years ago.

Some people will probably point to the possibility of personality conflicts and the effect of acrimonious debates on the development process. Yes, there are some antagonisms amongst the developers, but I personally don't think they're interfering with progress very much.

So what does it all mean? To me, it means that the foundation of Apache 2.0 hasn't settled to bedrock yet. It's going to include a lot of bells and whistles, and enhancements to features, performance, and scalability -- but IMHO there's still 'way too much churn at the most basic level for the package to be stable any time soon. And that worries me: the pressure to 'get a release out' may overpower the desire to 'do it right', and the result will be less than it could be -- and definitely less than it should be.

All IMHO, of course.

In this section we highlight some of the articles on the web that are of interest to Apache users.

This week we bring you a new series by Stas Bekman covering the Perl basics that you need to know when programming for mod_perl. Before that, here's an article entitled "Installation of mod_perl enabled Apache Without Superuser Privileges" which shows you how to install Perl modules and Apache under your home directory instead of system directories. You then need to set the PERL5LIB environment variable, or modify the @INC variable in your scripts to let Perl know where to look for the modules. It also tells you how to configure CPAN.pm to maintain your local repository.

"The Perl Basics You Need To Know (Part I)" covers global variables shared between packages, special Perl variables, and regular expressions that contain interpolated Perl variables. The second article continues with understanding warning messages by using the calls stack trace, solving the "my() Scoped Variable in Nested Subroutines" problem in six different ways, and exploring the very useful perldoc utility. Part III looks at the differences between global symbols and lexical symbols. It then explains about use(), require(), do(), %INC, and @INC. If you have attended Stas's regular "Getting started with mod_perl" talk, you may realise that some of the topics above can be found under the "Perl Reference" section. However, the articles here are the latest improved and revised version.

Don't understand what's .htaccess all about? Become an expert overnight by reading "Comprehensive guide to .htaccess" and ".htaccess - The Guide".