Stuart Herbert | Gentoo

I’ve just done an upgrade of a web box from Apache 2.0.x to Apache 2.2.8, using Portage 2.1.4.4. Somehow, Apache got built after the modules (PHP, Subversion, etc etc) were upgraded - and not before. This left Apache completely unable to start, because the modules had been linked against Apache 2.0. Grrr.

Gentoo’s new Apache 2.2.8 default config also left behind the mod_ssl config file from Apache 2.0 (for some reason, instead of updating this file, Apache 2.2.8 comes with a mod_ssl file with a different name)

Also had problems with /usr/lib/apache2/logs not existing, and with Apache’s Listen directive being hidden away inside the default vhost, instead of in the main config file where it belongs.

All in all, took me a couple of hours to dig through everything and sort it out. It’s not like Gentoo’s Apache team to fsck things up as badly as this; I hope this isn’t a sign of things to come, or else I’ll fork these packages and maintain them myself.

Here is a link to the LWN article about allow_url_fopen that Robin was referring to. This link works for non-LWN subscribers too.

(Although, why do you need a link for non-subscribers? You’re subscribed to the Linux world’s finest news site already, right? )

https://forums.gentoo.org/viewtopic-t-504541.html

ChrisWhite has pointed us all at a great write-up about success with Gentoo on production web servers, including numbers on the time taken, savings over using CentOS, and on downtime caused by Gentoo problems.

Chris, you’re completely missing the point about objects and PHP.

Classes and inheritence are not new to PHP 5; PHP has had these for many many years now. PHP 5 brings with it new features, such as interfaces, class constants, and access controls (although it’s still got a ways to go to catch up with both Python and Ruby). It also changes the semantics of objects; in PHP 4, objects are passed by copy, but in PHP 5, objects are passed by handle.

You can - and plenty of folks do - write object-oriented code in PHP 4 just fine.

PHP’s runtime behaviour - that each page starts afresh - is one of PHP’s killer features. You’ve obviously got no idea about just what a difference it makes. Every time your script runs, you’re guaranteed to start with a clean slate. The only state you have to worry about is the state you’ve stored for yourself. This simplicity makes it almost trivial to create deterministic code, without which you cannot produce high-quality code.

Managing state between pages is very straight forward in PHP. If the state matters only for the user’s current visit, put it in the session. If you need state to persist between visits, or it is information that other visitors need, put it in a persistent datastore (such as a database). Use a local cache (files on disk, memcached) to reduce the amount of time you have to get state from the persistent datastore. That’s the PHP way.

Folks who follow design patterns religiously are missing the point. They’re not hard and fast rules (that way lies Java, and its hideous and pointless complexity); they’re guidelines, meant to make you think about the natural structures that arise in your code. They’re not meant to be a cult. Anyone tells you different, they haven’t read enough Suzuki. When all you have is a hammer (or a set of design patterns), everything starts to look like a nail.

And that’s the beauty of PHP over many of the other tools that you have. If you want to write a system that’s entirely object-oriented, you can. But you don’t have to. You can create and use objects where they make sense, and you can continue to use global functions where they make sense. PHP’s neutral philosophy gives you the freedom to just get on with it, and do what’s right for your needs, your skills, and your tastes.

I’ve just added an ebuild for activeCollab to the Gentoo Web-Apps overlay, in the experimental branch.

activeCollab is shaping up to be an open-source alternative to 37 Signals’ Basecamp, written in PHP instead of Rails.

Enjoy!

Santos, the thing to remember about activeCollab is that it’s starting from the position of being a free clone of / alternative to Basecamp, the simplistic project management tool from the folks behind Rails.

Customers love Basecamp. It has a very clean user interface that doesn’t scare off folks who aren’t all that comfortable using computers. This is really its strong point; it allows you to engage those customers you’d normally spend hours on the phone with instead.

But, for project managers, the downsides quickly add up. In the office, many of our developers describe Basecamp as a just another bulletin board. The lack of structured data makes Basecamp easy to start using, but when you need to run off a progress report, maintain central action plans, or manage risks and issues, the lack of structured data starts to bite. Oh, and you currently can’t get all your data out of Basecamp either, which puts a bit of a dent into your business continuity planning. (To be fair, you can get a lot of it out, but the process isn’t a one-click solution atm).

In this context, ActiveCollab’s current behaviour makes perfect sense. You don’t want everyone and anyone being able to sign up by themselves, and suddenly be able to see what your project plans are. I’m sure your defense and public-sector customers would just love that! (Or any of your customers, come to think of it )

But I hope the ActiveCollab folks read your blog entry. One of my personal pet peeves about Basecamp is that it’s a stand-alone island. It’s not integrated with anything (including other products from 37 Signals); and there’s nothing causes confusion on projects like duplcation. It’d be great to see ActiveCollab provide a plugin architecture, so that folks can add stuff like wikis, bug trackers and more. Being able to mix & match features, so that it be tailored to what each organisation wants, would be a killer feature imho.

Oh, and if you want to be able to “just” install trac and use it, without having to mess about with dependencies or anything else, you should be using Gentoo

I’ve been playing about with using PDO to work with mysql. Something’s not quite right in there, and it’s resulting in a segfault when I run some local unit tests.

I’m not all that hot on PHP’s internals; I only tend to go digging in there when work needs a runkit bug diagnosing and fixing. But I’m pretty sure that what I’m seeing needs some TLC.

PDO objects themselves are created and destroyed when I’d expect them to be, as the objects go out of scope. The problem is that the PDOStatement objects aren’t doing the same. According to gdb, PDOStatement objects are only getting cleaned up when php_request_shutdown() runs; never before.

Surely we should be seeing PDOStatement objects being destroyed before their corresponding PDO object? The segfault is happening because php_mysql_stmt_dtor() is calling mysql_more_results() after the PDO object has been destroyed. We’re passing garbage data into the mysql client library … which chokes and segfaults as a result.

I think there’s two bugs here. The first problem is that PDOStatement objects appear to be persisting even though they’ve gone out of scope. php_pdo_stmt_delref() only gets called during php_request_shutdown(), never before. That doesn’t seem right to me. Why aren’t PDOStatements being destroyed when they go out of scope?

The second problem is that PDO objects are being destroyed before their corresponding PDOStatement objects. I couldn’t find (or, most likely, I didn’t recognise it any code that handles reference counting between PDO and PDOStatement objects. Maybe I’ve got it wrong, but I’d expect PDOStatement objects to add/subtract the corresponding PDO object’s reference counter, to ensure that PDO objects don’t get destroyed until all of their PDOStatement objects have been destroyed.

Anyone else got an opinion on this?

Kristi and I have just come back from the lovely town of Skien, Norway, attending the php|vikinger event organised by Zak Geant. It’s the first time I’ve attended an event like this, and I thought that Zak did a good job of running the unconference with the mighty power of Thor.

It was great to meet Sebastian for the first time, and to pick his brains about PHPUnit test suites. I confess I spent most of the weekend hacking away on my tests, rather than actively joining in the sessions; I now have unit tests for most of my Datastore PHP library. Need to track down and fix a PDO segfault, but otherwise it’s getting to the point where it’s actually useful. I hadn’t seen Hartmut’s PECL_Gen package before; I’m looking forward to when it can throw exceptions back into PHP (grin).

If you’ve never been to Norway before, it’s well worth the trip … especially if (like me) you’re used to how dirty and grey the UK can be. Don’t worry if you don’t know enough Norwegian. I think we met just the one person who didn’t speak English, and we’re pretty sure they were tourists too!

I’ve disabled write access to the Gentoo PHP Overlay for the moment. We’re moving the site to the new Gentoo Overlays box soon.

I’ll announce the new address once everything is up and running.

I’ve agreed to take on the job of building the ebuilds for Drupal 4.7 for the Gentoo web-apps team.

One of the nice features of Drupal 4.7 is that each of the nearly 200 optional modules comes with its own installation script. In theory, this will make it possible for Gentoo to provide a separate ebuild for each module, allowing site owners to mix and match modules to suit their individual needs.

Hopefully, I’ll get some experimental ebuilds into the webapps overlay shortly.