Linux vs FreeBSD, vi vs emacs, MySQL vs PostgreSQL, your habit or favorite technology vs another’s. At the end of the day there is no winner, just a matter of preference for the task at hand. I learned C++ 13 years ago, I forgot most of my C++ knowledge 10 years ago, I discouraged the use of C++ in this period in between, and in the past year I’ve been re-learning C++ (mostly due to Drizzle). So what did I use after unlearning C++ 10 years ago? I wrote everything in C (and by everything I mean this was my performance programming language of choice). This worked quite well, but it’s an interesting evolution that I think is now coming full circle.

When I first started programming C, it was a bit clumsy, and I look back at my old code and cringe. I began to develop a certain programming style that can best be described as object-oriented C programming due to the conventions used. The structs, functions that operated on those structs, and …

It is striking how much harder it is to make money from open source than to write it in the first place. Open source development is a sophisticated and well-understood social activity. However, the economic model is often laughably primitive: "if you build it, they will come." That applies to the question of turning your open source project into a real job. More interestingly, it applies to the question of how to make open source projects as valuable as possible to the largest number of people. In this post I would like to propose an answer to both questions.

To illustrate open source sophistication, just look how easy it has become to start and manage projects. It is almost a cookie-cutter procedure. You pick one of a number of well known licenses, manage the code on SourceForge.net or Launchpad, communicate with the project …

I have been meaning to, for months, get working on the FederatedX storage engine. There are a lot of great features it has -- such as better support for transactions as well as some architectural changes, thanks to the work of Antony Curtis. It now is designed so that the connection is abstracted into a federated_io_ class. This allows you to be able to subclass different connection schemes/drivers. For instance, I have the code for Federated ODBC that I need to take the code from and port to a federated_io_odbc class.

FederatedX has been pulled into an older MariaDB repository (thanks Antony!) that I need to merge with the latest, as well as figure out how to get the test suite to load the plugable storage engine. I've tried to add 'INSTALL PLUGIN federated SONAME 'ha_federatedx.so'' to the test, but the server expects ha_federated.so to be in a particular file location. That needs to be solved. I looked at PBXT's test suite but …

There has been a lot of talk lately about the “Open Source Cloud.” What will it look like, who will be behind it, and can I use it now? These were hot topics at OSCON, and Stephen O’Grady had two excellent posts on them recently as well (one, two). As many other folks do, I see a few major drivers of this: the need for private clouds, the prevention of vendor lock-in (proprietary services), and open source hackers just wanting to be able to extend and fix the source code. Some layers of this open source cloud stack are further along than others, and I’m going to attempt to outline what I’ve found so far along with what I think is missing.

Virtual Machine …

1. It’s easy to screw up thread safety.
   If you’re trying to format something for output (e.g. leading zeros, only 1 decimal place or whatever… you know, format specifiers in printf) you are setting a property on the stream, not on what you’re converting. So if you have a thread running that sets a format, adds something to the stream, and then unsets the format, you cannot have another thread able to come in and do something to that stream. Look out for thread unsafe cout code.
2. You cannot use streams for any text that may need to be translated.
   gettext is what everybody uses. You cannot get a page into the manual before it tells you that translators may want to change the order of what you’re printing. This goes directly against stringstream.
3. You need …

Kristian Nielsen was just noticing that some valgrind issues have made it in to Drizzle's trunk. I just wanted to follow up and say that, as if we knew he was going to check, Brian and I spent much of yesterday (Friday) cleaning them all up.

We were merging in Jay's replication work and noticed a memory leak (not related to Jay's work - it was in another branch that was also being tested as part of the overall process) That brought us to the Valgrind situation.

There are a couple of remaining issues, one of which is on Stewart's plate for as soon as it's a reasonable time down in Australia. As soon as it's clean, we'll push those fixes along with Jay's replication work. Additionally, we're adding Valgrind to the set of things that a branch has to pass to be pushed into trunk. We honestly should have done this a while ago - but things happen. We're …

Kristian Nielsen was just noticing that some valgrind issues have made it in to Drizzle's trunk. I just wanted to follow up and say that, as if we knew he was going to check, Brian and I spent much of yesterday (Friday) cleaning them all up.

We were merging in Jay's replication work and noticed a memory leak (not related to Jay's work - it was in another branch that was also being tested as part of the overall process) That brought us to the Valgrind situation.

There are a couple of remaining issues, one of which is on Stewart's plate for as soon as it's a reasonable time down in Australia. As soon as it's clean, we'll push those fixes along with Jay's replication work. Additionally, we're adding Valgrind to the set of things that a branch has to pass to be pushed into trunk. We honestly should have done this a while ago - but things happen. We're …

Kristian Nielsen was just noticing that some valgrind issues have made it in to Drizzle's trunk. I just wanted to follow up and say that, as if we knew he was going to check, Brian and I spent much of yesterday (Friday) cleaning them all up.

We were merging in Jay's replication work and noticed a memory leak (not related to Jay's work - it was in another branch that was also being tested as part of the overall process) That brought us to the Valgrind situation.

There are a couple of remaining issues, one of which is on Stewart's plate for as soon as it's a reasonable time down in Australia. As soon as it's clean, we'll push those fixes along with Jay's replication work. Additionally, we're adding Valgrind to the set of things that a branch has to pass to be pushed into trunk. We honestly should have done this a while ago - but things happen. We're …

Like so many others, I got interested in the Drizzle project when it started. Some good ideas, lots of enthusiasm, and just pure GPL license, no "yes, we will take your work for free and sell proprietary licenses to it" SCA.

I even started contributing some development, fixing a number of Valgrind-detected bugs in Drizzle. I am proud that we kept the MySQL code 100% free of Valgrind errors, and wanted to help keep the same in Drizzle. So I debugged and fixed quite a few of the Valgrind-detected bugs that had crept in since forking from MySQL.

As I remember, I got down to two or three remaining or so. However, I it did discourage me somewhat to see how quickly these bugs had been allowed to enter the code. I remember one case where there was a Drizzle patch that had tried to simplify some field types. As I remember, the patch tried to simplify the code by eliminating some of multiple variants of string types. All well and good, but …

I’m going to be giving a talk at the PHP user group here in Portland, OR on August 11th. Details can be found here. If you’re in the Portland area please join the group and come check it out! This will be similar to the Boston MySQL Meetup group talk I gave earlier this month with Patrick, but with more focus on PHP.