By Tim O'Reilly

I've been working with Nat and Allison to plan the O'Reilly Radar Executive Briefing on Open Source at OSCON. I thought I'd share the focus of the program, and ask you, our readers, for further input.

There are three big buckets we're focusing on:

1. What role does open source play in the emerging Web 2.0 economy? What role should it play?
2. The challenges and opportunities as open source goes from a counter-cultural phenomenon to the mainstream of the computer industry.
3. Open source beyond software, including open source content and open source hardware.

I'll post more on each of these topics over the next couple of days. But to whet your appetite, I'll say that speakers on the first topic include Brad …

The other day I criticized MySQL for using somewhat cheap marketing tactics on Planet MySQL.

Obviously I’m a MySQL fan so instead of just criticizing I figured I’d offer some constructive ideas (a patch basically) to fix the problem.

Instead of preaching to the community they should become a leader in the MySQL blogosphere.

MySQL does a great job here at the source code level but they’re using marketing 1.0 tactics which just won’t work with sophisticated customers anymore.

They just don’t really participate in the blogosphere much and I think it’s hurting them. For example, Marten Mickos doesn’t appear to have a blog. Nor is there an …

Lumen software decided to choose (or re-choose) PostgreSQL over MySQL. On any given day, this news would not have caused so much as a stir in my throat. There are definitely some great reasons to choose PostgreSQL over MySQL or, for that matter, any RDBMS over another. But, one thing that really bothers me is when a decision is made to chose one over another with few valid or factually correct reasons.

No piece of software fits every use case. Ask a guy who is 6 foot 6 inches tall whether "one size fits all" really does. It doesn't. And, likewise, database management systems will never fit all needs. And I don't think they ever should.

How Did I Hear About This?

Matt Asay wrote a quick entry about the Lumen blog and …

Just found this wonderful summary of articles by Jeremy and wanted to give some of my thoughts on the topic.

First lets speak about death of the RAID. I think this is far from the case especially if you consider Software RAID here.

For many workloads you would like to get RAID just for the sake of BBU. As Jeremy mentioned RAID is cheap these days if you buy right one and can offer substantial improvement for write intense workload by safe write buffering and write merging.

Performance is another story. RAID is usually easiest way to get extra performance from your IO subsystem. Spreading the database among say 10 commodity boxes is often expensive for existing applications, even for new applications it will affect development time and complexity and it is well possible it might be no guys inside the company skilled enough …

Introduction

You've decided to obtain MySQL certification and that's great! Now it's a matter of how to go about it? You can go the traditional routes and take a class, or you can prepare on your own. I did the latter, and 2 exams later during MySQL Conference 2007, I passed the Certified MySQL Database Administrator (CMDBA) exams. I wanted to share my exam preparation experience, as I've never found this information in any other place. I took what I learned from how to study math and applied it to …

I remember once asking Marten Mickos to participate on a panel - "The Battle of the Databases" - for Linuxworld a year or two back. He declined. At the time, I was mildly annoyed at his sense of camaraderie - he didn't think it was productive to try to set MySQL against Ingres against PostgreSQL. A bit later, I can appreciate his stance. Yesterday I exchanged emails with Boris Kraft, founder of the Magnolia CMS project. I regularly exchange emails/IMs with Dries Buytaert, founder of Drupal. Both are competitors in one sense, but in reality we're focused on different opportunities.... READ MORE

So, I want to reduce data usage of a text field, by storing unique strings separated by a delimiter. So to do so I came up with this:

Given a table

CREATE TABLE `hmm` (
  `a` int(10) unsigned NOT NULL default '0',
  `b` text NOT NULL,
  `c` int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

INSERT INTO hmm VALUES (1, 'hmm8',1) ON DUPLICATE KEY UPDATE b = IF(FIND_IN_SET('hmm8', b)>0, b, CONCAT_WS(',',b, 'hmm8')), c = c+1;

SELECT * FROM hmm;
+---+--------------------------+---+
| a | b                        | c |
+---+--------------------------+---+
| 1 | hmm4,hmm5,hmm6,hmm7,hmm8 | 7 |
+---+--------------------------+---+

Let's break apart the INSERT statement, if column 'a' produces a duplicate ON DUPLICATE KEY UPDATE will issue an IF statement
…

Today, immediately after lunch, I got IO errors from my laptop hard drive (ironically while attempting a file system dump). Words to the affect of “oh gosh and bother” exiting my mouth and the decision was made to go get a new drive.

Well… one “shortcut” to the computer store later, have new HD (will travel).

Backup from previous night, xfsrestore here I come. And a good number of hours later… about 1.5million files restored.

I do wish file systems had REPEATABLE_READ though… that would be nice.

If you search for Sinhala, a large fraction of the links you'll see point to something written by Harshula "hash" Jayasuriya. Sinhala is a very, very old language, but it's not very well developed on computing platforms. Its script is most often represented in Unicode, but the default Unicode collation table (DUCET) doesn't order its words ("collate") properly. Thus, MySQL didn't order it properly.

To fix that, hash recently submitted a collation implementation to MySQL, based on the Sri Lanka Standards Institution's SLS1134-pt1 document. It seems to be right, judging from our tests, but I would be much more comfortable if it were exposed to more eyeballs. The collation is on its way into the mysql-5.2 tree, and should be …

I'm pleased to announce the release of DBD::mysql 4.005! This release contains various fixes, per Changelog:

• 
  
• Fixed mysql_warning issue < 4.1 (reminders, patches, help from ROAM, (issue 25713)
  
• makerealclean patch from ROAM (issue #25714)
  
• sqlstate cleanup patch from ROAM
  
• Replaced all references to dbis->debug to use DBIc_TRACE_LEVEL(imp_xxh)
  
• Fix to dbd_st_destroy - added back previously removed 'free everything' code which
  had been moved to dbd_st_finish, causing a crash upon freeing of bind values
  after all rows resulting from one execution of a query have been fetched. This meant
  that next attempt to execute the prepared statement would segfault. This
  work thanks to Rainer Weikusat!
  
• Removed all 'FindNewTable' calls in all tests. Just use 't1' for all tests to
  …