When non ASCII names will finally work? (part 2)

no comment

CDBS usage statistics

Here is a fun little statistic for CDBS lovers and haters: Percent of packages (source, binary) using CDBS over time:

Sources-sid-main-2005-04        9.76    10.02
Sources-sid-main-2005-05        10.20   10.62
Sources-sid-main-2005-06        10.36   10.76
Sources-sid-main-2005-07        10.76   11.16
Sources-sid-main-2005-08        11.05   11.36
Sources-sid-main-2005-09        11.48   12.32
Sources-sid-main-2005-10        12.08   13.12
Sources-sid-main-2005-11        12.66   13.68
Sources-sid-main-2005-12        13.13   14.13
Sources-sid-main-2006-01        13.29   14.37
Sources-sid-main-2006-02        13.59   15.00
Sources-sid-main-2006-03        13.97   15.34
Sources-sid-main-2006-04        14.38   15.73
Sources-sid-main-2006-05        14.53   16.17
Sources-sid-main-2006-06        14.71   16.30
Sources-sid-main-2006-07        15.17   16.54
Sources-sid-main-2006-08        15.84   17.04
Sources-sid-main-2006-09        16.23   17.07
Sources-sid-main-2006-10        16.60   17.24
Sources-sid-main-2006-11        16.97   17.56
Sources-sid-main-2006-12        17.46   17.90
Sources-sid-main-2007-01        17.66   17.97
Sources-sid-main-2007-02        17.87   18.12
Sources-sid-main-2007-03        18.06   18.38
Sources-sid-main-2007-04        18.27   18.68
Sources-sid-main-2007-05        18.86   19.39
Sources-sid-main-2007-06        19.64   20.66
Sources-sid-main-2007-07        19.79   20.93
Sources-sid-main-2007-08        20.13   21.15
Sources-sid-main-2007-09        20.32   21.33
Sources-sid-main-2007-10        20.81   21.95
Sources-sid-main-2007-11        21.16   22.02
Sources-sid-main-2007-12        21.48   22.17
Sources-sid-main-2008-01        22.12   22.67

World domination in about 2020. :)

A Sporty PgCon?

Those who stuck around one or two days after PgCon last year in Ottawa might have noticed that there were a lot of runners in town. As it happens the Ottawa Race Weekend will take place again this year the Saturday and Sunday after the conference. They offer everything from a short walk up to a marathon. I am considering signing up for one of the races this year. If any fellow conference goers want to join up in a type of PostgreSQL team effort, feel free to contact me.

Problems with newer kernels

It has become apparent to me that the Linux kernels in Debian testing and unstable (2.6.2x) have all kinds of problems compared to the one in stable (2.6.18), especially when it comes to working with virtualization. I have been trouble booting newer kernels as guest systems in VirtualBox (bug #434723) and QEMU (and bug #449085). There is some chatter in the Gentoo forums to the same effect. I have also had trouble compiling the host system kernel modules of VMPlayer and VirtualBox with newer kernels. If your job requires regular juggling of virtual machines and operating systems, this creates big problems. Plus my UMTS card stopped working (bug #433750), also confirmed by Gentoo chatter. :) I have also tried to build pure upstream kernels myself, but they have the same problems. So my advice to those running Debian post-stable is to stick to kernel 2.6.18 from stable if you are seeing funny issues.

Configuration files with Git

A while ago I put the configuration files in my home directory (.bashrc, .psqlrc, etc.) into a Subversion repository so I could keep track of what I changed and distribute the changes to different machines. This worked well, but the choice of Subversion created a number of shortcomings: It was difficult to work with unconnected hosts (no local commits), it is difficult to make changes that apply only to some machines (branches, changesets?), and you need a separate directory for the repository.

Now I have converted this to Git, which appears to address these problems. The repository information is entirely contained in the .git directory in the top level of the working tree. I haven't transferred the tree to a different host yet, so that will be next week's project.

Now I'll go ahead and commit the .gitconfig file into the GIT repository. :)

Version control unmaddened

PostgreSQL is the only project I'm involved in that uses CVS. Most other places now use Subversion, Bazaar, or something else. That's fine, but it's really annoying to continously type in the wrong tool when you switch back and forth.

So today I fixed this problem. I wrote this little shell script I call vcs:

#!/bin/sh



if [ -d CVS ]; then

       cvs "$@"

       exit $?

fi



if [ -d .svn ]; then

       svn "$@"

       exit $?

fi



dir=$(pwd)



while [ -n "$dir" ] && [ "$dir" != / ]; do

       if [ -d "$dir/.bzr" ]; then

               bzr "$@"

               exit $?

       fi



       dir=$(dirname "$dir")

done



exit 77

This can be extended in obvious ways.

Put this in your path, and then you can use vcs for everything.

But somehow, cvs is really easy to type, or maybe your fingers are wired to svn or something else. So add to this a couple of shell functions like this:

bzr() { vcs "$@" || { [ $? -eq 77 ] && command bzr "$@"; }; }

cvs() { vcs "$@" || { [ $? -eq 77 ] && command cvs "$@"; }; }

svn() { vcs "$@" || { [ $? -eq 77 ] && command svn "$@"; }; }

Now you can type cvs update or whatever your brain or fingers prefer and it will do the right thing.

EnterpriseDB and the Professional Grade

I was naturally confused when I read about EnterpriseDB announcing the First-Ever Professional-Grade PostgreSQL Distribution for Linux. I would have thought that at least Great Bridge, Red Hat, and Pervasive would have prior claim to that title, and there are surely others who might fit this category but don't make so much noise about it.

So that needed to be cleared up. I went to download their "EnterpriseDB Postgres" package, versioned 824-linux-x32-b1. (Is that beta 1?) This unpacks to a setup_x86.bin file. I recalled my bumpy experience with the installer of EnterpriseDB proper, but this one seems to work quite a bit better. It's the same Java-type installer, for what it's worth, but this one actually ran to the end without error at the first attempt. Somehow it even installed all the software with the proper library dependencies for my Debian system, including the dreaded libssl issue, so that was really a relief.

The installation contains PostgreSQL, Slony-I, PostGIS, pgAdmin, phpPgAdmin, JDBC and ODBC drivers, Apache, and PHP, each in current versions. The default installation goes to /opt/edb-postgres/8.2/, but you can change that. The entire installation is owned by the postgres user, so no points for security.

The installation layout looks like this:

$ ls -l /opt/edb-postgres/8.2/8.2.4
total 56
drwxrwxr-x 15 postgres root 4096 2007-08-08 11:13 apache/
drwxrwxr-x 2 postgres root 4096 2007-08-08 11:14 bin/
drwxrwxr-x 3 postgres root 4096 2007-08-08 11:13 doc/
-rwxrwxr-x 1 postgres root 369 2007-08-08 11:13 env.55434*
drwxrwxr-x 2 postgres root 4096 2007-08-08 11:13 etc/
drwxrwxr-x 6 postgres root 4096 2007-08-08 11:13 include/
drwxrwxr-x 2 postgres root 4096 2007-08-08 11:14 install_logs/
drwxrwxr-x 2 postgres root 4096 2007-08-08 11:13 jdbc/
drwxrwxr-x 3 postgres root 4096 2007-08-08 11:14 lib/
drwxrwxr-x 7 postgres root 4096 2007-08-08 11:13 pgadmin3/
drwxrwxr-x 6 postgres root 4096 2007-08-08 11:13 php/
-rwxrwxr-x 1 postgres root 214 2007-08-08 11:13 postgres.env*
drwxrwxr-x 5 postgres root 4096 2007-08-08 11:13 share/
drwxrwxr-x 6 postgres root 4096 2007-08-08 11:13 utils/

This was clearly designed by a Windows engineer who never heard of a Linux file system hierarchy standard.

How is this actually works out is that there is a bin/psql which is a shell script that sets PATH and LD_LIBRARY_PATH and then calls bin/psql.bin which is the actual binary. Unfortunately, this shell wrapper neglects to set the right TCP port (which I configured in the installer as 55434, the default offer was 5433), so just calling psql without options doesn't connect. I'm not sure whether it is intentional that way.

But all the programs seem to generally work. Even pgAdmin has no problems with libraries or whatnot. phpPgAdmin is available at http://localhost:8080/. The default database contains a few sample tables that I seem to recall to have seen in the EnterpriseDB installer as well. All in all it's a normal PostgreSQL installation with a crazy installation layout. There is also an init script based on the one you find in the PostgreSQL source code distribution. A vacuum cron job or autovacuum is not configured, and the postgresql.conf file isn't tuned.

Now what makes this "professional grade"? The installation uses insecure permissions, nobody knows how to upgrade these things, nobody knows whether there will be security updates for the integrated Apache and PHP components, there is no integration into log rotation, log checking, or other system services, the setup isn't tuned or configured, no vacuum, nobody has access to the source code of the installer, so you don't know what's in there and can't fix it yourself.

It remains to be explained why this is any more useful than whatever your local apt or yum installs.