Our favorite anti-open source article, "Winning the Linux Wars", suggested that Microsoft partners should be "Playing the R&D card" by emphasizing that "Microsoft invests north of $6 billion a year on R&D. There is nobody in the Linux world that does that."

Well, Merck (MRK) invests about $4 billion a year in R&D. Bristol-Meyers (BMY) $669 million. Eli Lilly & Co. (LLY) $2.7 billion. Pfizer (PFE) $1.8 billion. Sanofi-Aventis (SNY) a whopping $10.2 billion, or nearly half of its $20.5 billion in revenues. Together, that's about $19.5 billion a year in research and development.

Apparently, though, that's not enough. This Friday (January 20, 2006), The Wall Street Journal's "Science Journal" ran article entitled "In Switch, Scientists Share Data to Develop useful Drug Therapies" which pointed …

It's LCA time again, in the opinion of people like Ramsus and Linus among the best conferences in the world. It's the conference put on by LinuxAustralia, but this year it's held in Dunedin (New Zealand) at the University of Otago.

Brian Aker (MySQL Director of Architecture) will be there too (courtesy of the MySQL community department), as will Stewart Smith (MySQL Cluster developer - also serving on the board of Linux Australia).

We were fortunate enough to all be accepted for talks in the program. Great!
It should be lots of fun, I've been to Adelaide (2004) and Brisbane (2002) also. Note that it is a yearly event, I …

Ronald brings up an interesting point about compatibility between MySQL versions.

While some of the options are a bit harder to automatically fall back (Views/triggers/stored procedures), it's worth noting the compatibility feature that was introduced in the mysqldump bundled with 4.1:

mysqldump --compatible=name

from the help output:
Change the dump to be compatible with a given mode. By default tables are dumped in a format optimized for MySQL. Legal modes are: ansi, mysql323, mysql40, postgresql, oracle, mssql, db2, maxdb, no_key_options, no_table_options, no_field_options. One can use several modes separated by commas. Note: Requires MySQL server version 4.1.0 or higher. This option is ignored with earlier server versions.

Why oh why would you want to do this. Well it my case, I’ve committed to developing a web application using MySQL 5 features, knowing that I had to upgrade my production server from 4.0

Well as part of doing this, I hit a stumbling block. My current production web server runs RedHat 7.3, and even with all the latest rpm updates, it does not have glib 2.3 which is required for MySQL 5. I’m no guru, but trying to upgrade from Redhat 7.3 to 9, to at least get these rpm is not an easy process. I’m not confident to try to compile glib 2.3 and all it’s dependancies on a production server, nor is it possible to recompile MySQL down (I suspect not). All just too many variables. It appears the time has come to scrap it and work with a more current RedHat Enterprise Linux version. Down side, the 25 web sites are not going to be too happy.

Anyway, as an interim to at least move forward as much as possible I dowgraded the provided …

A couple days ago, a mistake caused a key-value table to generate new keys for duplicate values when there should have been a unique constraint on key. This affected the stat gathering table (stats for one value are now associated with many keys) and I have to clean up the data -- while preserving the stats that have already been generated. In trying to do this, I think I found a bug in replication .... an UPDATE statement that aggregates the data produces different results on my replication slave. I've submitted a formal bug report along with SQL to duplicate the error here. I'm curious if anyone else has encountered this bug, or knows of a way to achieve the result that I want without breaking replication.

Here's a description of the test case:

Two tables store key-value pairs (in the example, `color` and `animal`), and `a_to_c` stores a relationship …

Wouldn't you know it just a few weeks after I bought my father a Mac for Christmas, Steve Jobs beats his previous target dates by announcing and shipping Intel-based Macs at MacExpo last week. I don't think my father is enough of a power user to notice the difference, but for most Mac heads, the new Intel-based Macs are nothing but good news. 

Not only do a lot of the MySQL developers and the open source community in general use and love the Mac, it seems to be an increasingly popular platform among our customers.  In our most recent user survey over the holidays, Mac OS/X users accounted for about 12% of respondents. This is an increase over the last year, and …

Wouldn't you know it just a few weeks after I bought my father a Mac for Christmas, Steve Jobs beats his previous target dates by announcing and shipping Intel-based Macs at MacExpo last week. I don't think my father is enough of a power user to notice the difference, but for most Mac heads, the new Intel-based Macs are nothing but good news. 

Not only do a lot of the MySQL developers and the open source community in general use and love the Mac, it seems to be an increasingly popular platform among our customers.  In our most recent user survey over the holidays, Mac OS/X users accounted for about 12% of respondents. This is an increase over the last year, and …

There's an interesting editorial in InfoWorld about SQL Server where Sean McCown, a noted SQL Server author, says that only "tree huggers" would use an open source database. Maybe he should have checked with the IT staff at InfoWorld since they run MySQL and the LAMP stack extensively in InfoWorld's operations.  In fact InfoWorld's former CTO Chad Dickerson, frequently wrote about their use of MySQL and other open source products. Or maybe Chad really is a tree hugger. 

Maybe Alcatel, Cardinal Health, the Census Bureau, CNet, Evite, Friendser, The Gap, Google, Lufthansa, Macy's, Nasa, Nokia, Orbitz, Sabre, Sony, Suzuki, Tellme Networks, TicketMaster and eight million other MySQL users are all tree huggers.  Hell, we're being over-run by tree huggers.  Ok, Craigslist is a customer too, and they probably are tree …

When I suggested MySQL had a big part to play in the X of AJAX it was more of a case throwing ideas into the ether than any solid or contrived plan. My initial thoughts were simply to allow the web server to talk directly with MySQL and return the XML needed for a give select statement. The goal was to avoid the normal middle stage of using some sort of scripting to accept the statement, call a standard MySQL select and process this into an XML format. Something along the lines of MySQL being an XML factory where you pass the select and MySQL directly passes back the XML.

Some great ideas have been suggested, mainly around using --xml to format the output directly from the command line, which would interact with Apache by a module. I've been able to knock up a Perl program which is capable of doing this but it's raised more concerns than solid answers.

When I looked at this more closely the immediate thing was how …

I’m not there yet with compiling MySQL Workbench from the previously released 1.0.0-alpha source for linux. I’d like to think I’m getting closer but not really certain. I’m getting good response to my Bug Report #16604 from MySQL Staff. Seems I work at it during the day, update, and then next morning there is some more info, but still doesn’t cut the cheese, as it just moves me to next error.

So in my last edition, I got an error and installed a lua product (which was the right one), but I didn’t do a configure again, just a compile. I bet that’s a C/C++ 101 lesson. Also as per request, added Java options consistent with my environment. So:


$ cd /src/mysql-workbench-1.0.0/mysql-gui-common/
$ ./configure --enable-grt --enable-canvas --with-java-ldflags="-L/opt/j2sdk1.4.2_10/jre/lib/i386/client/ -ljvm"
./configure: line …