TheReg owes you and PIR a personal apology for saying you guys were "sloppy." The fact that the article went ahead full speed isn't so bothersome, it was the aspersions cast by TheReg, then not recalled that seems to be truly unprofessional here. Their correction is still incorrect, just less insultingly so.
What bothers me about the article was that whoever wrote it clearly called into question the quality of service being provided by PIR, but in the correction posted, there is no apology for this insult against the good folks at PIR.
It doesn't matter if they were insulting bill gates or mother theresa, when the truth came to light, the correction should have contained a contrite apology to PIR for the slur. There was none, just a bit of backpedalling about how internic is having issues with.net.
Funny thing, we didn't get a sentence about how sloppy internic is for having problems with.net.
Or even a sentence about how sloppy The Reg is, which could have been used to humorous poke fun at themselves while giving PIR the apology they still deserve.
When they thought the problem was.org, before checkig any actual facts, they said this about them:
"Which it is all very sloppy and doesn't exactly encourage confidence in the company that now runs the.org domain - Public Interest Registry."
when they published their "correction" http://theregister.co.uk/content/6/30764.html they said this about verisign / NSI:
"VeriSign's crsnic Whois servers are having trouble. There was some problem with.net addresses at the weekend. It has therefore concentrated on getting them up and running first rather than.org since it runs.net domains and not.org domains."
First of all they didn't mention how "sloppy" this was of verisign, and how this incident should "shake our faith" in their ability to administer domain names.
Second off, they're still wrong. Verisign doesn't RUN the whois servers for.org,.org does.
I do believe there are at least as many errors in the correction as in the original article, which is to say, a lot.
The reason MySQL is easy is that it never complains when you do something stupid, it just does it.
Convert a column type filled with dates from text to date / time type, and MySQL will put 0000-00-00 for each date it can't figure out.
If it can't figure out any dates, they all get set to that.
Since even innodb tables can survive such a change, all your original dates are gone.
On the other hand, in a real database, you'd get errors, complaints, all kinds of guff from the database as it refused to do something that stupid.
That is only one of dozens of examples of MySQL doing things "wrong" from the point of view of reliable, coherent data, and not bothering to tell you.
If I use interbase or pgsql and don't need the features, I just don't use them. But when I need the extra features of a real database, I don't have to switch from MySQL to another database if I already started with one.
Apparently, we're all dumb as lamp posts and can't bother to read the part of the whois query on our boxes that says this whois server only handles.net and.com
We're going to go back to school, we should be ready to post articles worth reading in a few short years, til then, there's always the BBC, eh?
No matter how long it was on the front page, this article sullied the reputation of the.org folks, and they deserve an apology and a retraction.
Unless, of course, the Reg doesn't take responsibility for what it publishes. Like a lot of so called "news" sites out there. Heck, even slashdot posts retractions once in a blue moon or two.
I'd like to point out I talked to the author of INNOdb tables, and he assured me that innodb tables use a "double write MVCC" mechanism to assure the D part of ACID. So, the only part MySQL is still missing is check constraints to be ACID.
My thing against benchmarking is that MySQL wins hands down on simple insert / delete against almost every serious database out there. It just flies. Unfortunately, I do a lot of
select enum from table except (select enum from table2) kinda stuff, and mysql just can't do it.
The part about maintaining two databases is valid, but only so far. the biggest cost of running Oracle are license fees and maintenance. MySQL doesnt' really need a whole lot of maintenance, since it's more or less self maintaining, and any one of the PERL or PHP developers can run myisamcheck when they need to.
If you can get rid of half your oracle licenses, then the usage of MySQL makes sense, if it doesn't help you get rid of licensing / support contracts, then I guess Oracle is still the way to go.
But really, there are TONs of shops out there running Oracle for content management type stuff that are just tossing money into the toilet.
Actually, I really do like MySQL. I just don't like to benchmark it against Postgresql in the role of "datastore for a web site" without looking elsewhere.
It may be hard to believe, but you can do more with a database than build a web site:-)
MySQL is a great backend data store for web sites. However, it is NOT ACID compliant, and shouldn't be compared against an ACID compliant database.
Postgresql uses Write ahead logging, and you can pull the power plug on the machine in the middle of 1000 concurrent transactions and the database will lose NONE of your data.
That doesn't come free. MySQL has no approximationg of it. If the OS fails to complete a write to a block, MySQL has no write ahead log or what not to to fix the data with. You've got a corrupted record with half the data in it, and that's that.
MySQL doesn't do constraints, so for every check contraint I put into a Postgresql based application, I have to write one in PHP or Perl or what not for MySQL. But you've got a possibility of race conditions for certain constraints, so MySQL cannot approximate Postgresql in that situation.
There are MANY other issues brought up by MySQL, but it only gets the A and I from ACID. It lacks proper constraints and just inserts a default value when you insert a NULL into a NOT NULL field! That in no way qualifies for use of the C in ACID. It has no write ahead logging, so it can't qualify for the D, since power failure can result in it having incompletely written records that can't be recovered.
It's not so much MySQL I hate, I really don't. It's the marketing they do. The MySQL people shout out they have ACID when they don't. Adding innodb tables alone isn't enough to qualify as ACID compliant. Heck, even the Postgresql guys didn't claim the D part until just over a year ago, and that required a HUGE chunk of code for write ahead logging.
While the Postgresql core developers quietly make one of the nicest databases in the world, the MySQL crew basically lies about the capabilities of their database.
There are plenty of people using Oracle in a situation that probably should be using MySQL. I can think of at least three examples in my own company where I've told the folks doing the work that they'd be better off with MySQL, because they're basically batch processing in Oracle, not using any constraints, foreign keys, or transactions.
So no, I don't hate it. But I do wish people would stop spouting misinformed garbage about it's capabilities. It's a great partner for Postgresql. Postgresql handles the critical data you can't afford to lose or get wrong, MySQL handles content management. But the MySQL crew continue to try and rule the world, and in the long run, that's actually bad for open source, because the worst thing we can do is give someone a first experience with an Open Source database that can't do what it promised to do, and then they reckon all open source databases are like MySQL, overselling themselves.
From an earlier interview, which was pulled because of it's containing an admission of guilt:
"Finally. Somebody raised a possible problem that you yourselves distribute the infringing code under the GPL licence. Do you see that as a problem from your point of view? No we do not, because you do not have an infringement issue when you are providing customers with products that have your intellectual property in them. OK, but Linux has a kernel which isn't yours. Are you saying that there are changes to the kernel? We have concerns and issues even with areas of the kernel. So you are saying that you are happy distributing the kernel because the offending code belongs to you anyway, as I understand it? Yes."
I.e. these guys don't have clue 1 what the GPL actually says. Unfortunately for them, failure to comprehend a license does not relieve you of your responsibilities under said license.
No, the guy before you is right. SCO probably could say "we didn't know it was there." However, the second they realized it was there, it was their duty to cease distribution and demand removal of whatever code was offending.
If they knowing distributed a linux distribution while it had SCO IP protected portions in it, then their argument becomes much weaker.
Interestingly, an interview that had a marketroid from SCO saying they weren't worried about distribution because they owned the IP rights was yanked within 12 hours of publication. I quoted part of it in a talk back on linuxtoday. Basically, it was an admission that they had been knowingly distributing linux with the infringing code.
At this point, SCO has scuttled their own boat with no help from the outside. Admitting they KNEW the code was there and kept distributing it means they have little recourse now.
How do you benchmark a ferrari and a freight train?
MySQL is missing so many key features that benchmarking MySQL against Postgresql is useless.
How fast is MySQL when it has check constraints on data? No one knows, since it doesn't have them.
How fast is MySQL when you use a complex sub select? No one knows, it can't do more than a few common cases yet.
How fast is MySQL when you use stored procedures? Triggers? custom data types? Unions?
None of those things are there. WHEN MySQL gets around to having most of the features a REAL database has, then you can benchmark it, until then, any benchmark is going to unfairly favor MySQL because MySQL is fast because it is missing most of the features it needs to compete, and it never errors out, even when it should.
It's a data store, not a database. The SQL it supports is so small a subset of SQL92 as to be useless for any but the most simple content management applications.
When it meets most of the SQL99 or 03 standards, we'll talk. Til then, you're tilting at windmills when you compare MySQL to any other database. Heck, even Foxpro is a better database than MySQL.
1: IBM finds that the code added, if any, came from Caldera, forcing SCO to sue themselves.
2: IBM, in discovery, demands a receives the source to SCO's flavors of Unix and finds evidence that SCO stole GPL'd source code to put into unixware / openserver. Sco is forced to release the whole shebang under the GPL.
Oh, and another thing about MySQL is that when it does what would usually be classified as "the wrong thing" it never tells you. Not even a warning.
Create two tables, one innodb, the other myisam. Run a transaction against both of them. roll it back halfway through.
MySQL doesn't tell you that you can't run a transaction on a MyISAM table, it doesn't tell you it didn't roll back the MyISAM table, in fact, it happily acts like it got the whole thing right, and rolled it back. Except the changes you made to the myisam table are still there.
MySQL is a data store with a minimal SQL front end written by people who DO NOT UNDERSTAND the issues of database design in a high load / high transaction environment. To paraphrase the manual, data consistency and what not are the job of the database, they are the job of your code. god help you if you make a mistake because MySQL isn't going to catch any of them.
Let's see, 3 years ago, you tried Postgresql. It took 10 whole minutes to load your data, so it must just suck at everything else. Never mind that there's been like 4 major revisions put out (think Mysql 3 to 4 to 5 to 6 to 7).
If Postgresql was corrupted, it was likely running on a hard drive with bad sectors or in a machine with bad memory. The fact that MySQL doesn't tax your machine as hard makes it more likely that postgresql will show these errors.
I've been running Postgresql for 4 years, and have NEVER had a table get corrupted, NEVER had it lose data, and NEVER had it crash.
Your experience with it, i.e. virtually none, disqualifies you from stating it sucks.
MySQL is NOT A SQL database. It's missing so many features it's hard to make a list and not have it be as long as your arm.
Here are a few: No constraints (however, it will accept them during table creation, then promptly ignore them!) Allows you to put NULL into not null columns, and just inserts either the default or 0 or '' or 0000-00-00. Foreign keys, now that they finally have them, don't support cascading, which makes them about worthless.
Let's make it clear, if Postgresql was a shitty as you're saying, the.info and.org domains would not be running on it. How many TLDs run on MySQL by the way? 0.
"And the Devil Will Drag You Under" by Jack Chalker "Waiting for the Galactic Bus" by Parke Godwin "Dark Star" by Alan Dean foster "The Damned" trilogy by Alan Dean Foster
I didn't say I RUN it async, I said I tested it async.
besides, you have no earthly idea what that server was used for.
If it was a giant collection point for data feeds from a mainframe with 5000 people hitting it for ODBC feeds to slurp into Excel, it's quite a sane setup.
So, yet another example of an idiot posting AC who has NO real world experience.
The 2 minute wait to post, by the way, sucks nuts, and the person who implemented it should have their head smacked against a wall. Yes, you know who you are...
Actually, according to the report, they used a hardware RAID controller. Note that on fast hardware (i.e. 8 CPU xeon machines) Linux's kernel RAID is often faster than hardware RAID.
The real killer was that they left atime on in linux, while turning it off in Windows. that's just playing dirty.
Interesting point. I find that there are several views when it comes to OS databases.
One is that since most open source databases lack some feature, they will never replace any Oracle servers. Most of the people who believe this also believe that Oracle servers are always used in high parallel load transactional systems that have to be up 24/7 and never go down. While plenty of sites that need that use oracle, it is not inversely always true. Many places put Oracle online because it's what their developers know and love, not because it's the best fit for the problem.
The next view is that Open Source databases are ready to replace Oracle right now, everywhere. While there are plenty of places using Oracle that could switch to Pgsql/MySQL/Firebire right now, there are plenty more that couldn't dream of it. It's all about what you're doing with your database that defines which ones you can use.
The final view is the right tool for the job view. These folks are rare. They're actually loaded test datasets into various database engines, read up on how each db's locking mechanism works, examined each to see where the best fit is.
People relying on the first two views are treating computer science like a religion instead of a science.
Slashdot Mirror
Then, of course, the article I suggested should be published by IT Analysis, and then blindly published by TheReg. Seems fitting. :-)
TheReg owes you and PIR a personal apology for saying you guys were "sloppy." The fact that the article went ahead full speed isn't so bothersome, it was the aspersions cast by TheReg, then not recalled that seems to be truly unprofessional here. Their correction is still incorrect, just less insultingly so.
What bothers me about the article was that whoever wrote it clearly called into question the quality of service being provided by PIR, but in the correction posted, there is no apology for this insult against the good folks at PIR.
.net.
.net.
It doesn't matter if they were insulting bill gates or mother theresa, when the truth came to light, the correction should have contained a contrite apology to PIR for the slur. There was none, just a bit of backpedalling about how internic is having issues with
Funny thing, we didn't get a sentence about how sloppy internic is for having problems with
Or even a sentence about how sloppy The Reg is, which could have been used to humorous poke fun at themselves while giving PIR the apology they still deserve.
When they thought the problem was .org, before checkig any actual facts, they said this about them:
.org domain - Public Interest Registry."
.net addresses at the weekend. It has therefore concentrated on getting them up and running first rather than .org since it runs .net domains and not .org domains."
.org, .org does.
"Which it is all very sloppy and doesn't exactly encourage confidence in the company that now runs the
when they published their "correction" http://theregister.co.uk/content/6/30764.html they said this about verisign / NSI:
"VeriSign's crsnic Whois servers are having trouble. There was some problem with
First of all they didn't mention how "sloppy" this was of verisign, and how this incident should "shake our faith" in their ability to administer domain names.
Second off, they're still wrong. Verisign doesn't RUN the whois servers for
I do believe there are at least as many errors in the correction as in the original article, which is to say, a lot.
The reason MySQL is easy is that it never complains when you do something stupid, it just does it.
Convert a column type filled with dates from text to date / time type, and MySQL will put 0000-00-00 for each date it can't figure out.
If it can't figure out any dates, they all get set to that.
Since even innodb tables can survive such a change, all your original dates are gone.
On the other hand, in a real database, you'd get errors, complaints, all kinds of guff from the database as it refused to do something that stupid.
That is only one of dozens of examples of MySQL doing things "wrong" from the point of view of reliable, coherent data, and not bothering to tell you.
If I use interbase or pgsql and don't need the features, I just don't use them. But when I need the extra features of a real database, I don't have to switch from MySQL to another database if I already started with one.
Apparently, we're all dumb as lamp posts and can't bother to read the part of the whois query on our boxes that says this whois server only handles .net and .com
We're going to go back to school, we should be ready to post articles worth reading in a few short years, til then, there's always the BBC, eh?
No matter how long it was on the front page, this article sullied the reputation of the .org folks, and they deserve an apology and a retraction.
Unless, of course, the Reg doesn't take responsibility for what it publishes. Like a lot of so called "news" sites out there. Heck, even slashdot posts retractions once in a blue moon or two.
I'd like to point out I talked to the author of INNOdb tables, and he assured me that innodb tables use a "double write MVCC" mechanism to assure the D part of ACID. So, the only part MySQL is still missing is check constraints to be ACID.
My thing against benchmarking is that MySQL wins hands down on simple insert / delete against almost every serious database out there. It just flies. Unfortunately, I do a lot of
select enum from table except (select enum from table2) kinda stuff, and mysql just can't do it.
The part about maintaining two databases is valid, but only so far. the biggest cost of running Oracle are license fees and maintenance. MySQL doesnt' really need a whole lot of maintenance, since it's more or less self maintaining, and any one of the PERL or PHP developers can run myisamcheck when they need to.
If you can get rid of half your oracle licenses, then the usage of MySQL makes sense, if it doesn't help you get rid of licensing / support contracts, then I guess Oracle is still the way to go.
But really, there are TONs of shops out there running Oracle for content management type stuff that are just tossing money into the toilet.
Yes, you're right. He should get out his source distribution of Windows and whip out a solution right away.
He has the source to Windows right? Like everyone else?
What else can he do but complain?
Actually, I really do like MySQL. I just don't like to benchmark it against Postgresql in the role of "datastore for a web site" without looking elsewhere.
:-)
It may be hard to believe, but you can do more with a database than build a web site
MySQL is a great backend data store for web sites. However, it is NOT ACID compliant, and shouldn't be compared against an ACID compliant database.
Postgresql uses Write ahead logging, and you can pull the power plug on the machine in the middle of 1000 concurrent transactions and the database will lose NONE of your data.
That doesn't come free. MySQL has no approximationg of it. If the OS fails to complete a write to a block, MySQL has no write ahead log or what not to to fix the data with. You've got a corrupted record with half the data in it, and that's that.
MySQL doesn't do constraints, so for every check contraint I put into a Postgresql based application, I have to write one in PHP or Perl or what not for MySQL. But you've got a possibility of race conditions for certain constraints, so MySQL cannot approximate Postgresql in that situation.
There are MANY other issues brought up by MySQL, but it only gets the A and I from ACID. It lacks proper constraints and just inserts a default value when you insert a NULL into a NOT NULL field! That in no way qualifies for use of the C in ACID. It has no write ahead logging, so it can't qualify for the D, since power failure can result in it having incompletely written records that can't be recovered.
It's not so much MySQL I hate, I really don't. It's the marketing they do. The MySQL people shout out they have ACID when they don't. Adding innodb tables alone isn't enough to qualify as ACID compliant. Heck, even the Postgresql guys didn't claim the D part until just over a year ago, and that required a HUGE chunk of code for write ahead logging.
While the Postgresql core developers quietly make one of the nicest databases in the world, the MySQL crew basically lies about the capabilities of their database.
There are plenty of people using Oracle in a situation that probably should be using MySQL. I can think of at least three examples in my own company where I've told the folks doing the work that they'd be better off with MySQL, because they're basically batch processing in Oracle, not using any constraints, foreign keys, or transactions.
So no, I don't hate it. But I do wish people would stop spouting misinformed garbage about it's capabilities. It's a great partner for Postgresql. Postgresql handles the critical data you can't afford to lose or get wrong, MySQL handles content management. But the MySQL crew continue to try and rule the world, and in the long run, that's actually bad for open source, because the worst thing we can do is give someone a first experience with an Open Source database that can't do what it promised to do, and then they reckon all open source databases are like MySQL, overselling themselves.
From an earlier interview, which was pulled because of it's containing an admission of guilt:
- 05 -12-010-26-IN-CD-LL-0026
"Finally. Somebody raised a possible problem that you yourselves distribute the infringing code under the GPL licence. Do you see that as a problem from your point of view?
No we do not, because you do not have an infringement issue when you are providing customers with products that have your intellectual property in them.
OK, but Linux has a kernel which isn't yours. Are you saying that there are changes to the kernel?
We have concerns and issues even with areas of the kernel.
So you are saying that you are happy distributing the kernel because the offending code belongs to you anyway, as I understand it?
Yes."
I.e. these guys don't have clue 1 what the GPL actually says. Unfortunately for them, failure to comprehend a license does not relieve you of your responsibilities under said license.
http://linuxtoday.com/news_story.php3?ltsn=2003
No, the guy before you is right. SCO probably could say "we didn't know it was there." However, the second they realized it was there, it was their duty to cease distribution and demand removal of whatever code was offending.
If they knowing distributed a linux distribution while it had SCO IP protected portions in it, then their argument becomes much weaker.
Interestingly, an interview that had a marketroid from SCO saying they weren't worried about distribution because they owned the IP rights was yanked within 12 hours of publication. I quoted part of it in a talk back on linuxtoday. Basically, it was an admission that they had been knowingly distributing linux with the infringing code.
At this point, SCO has scuttled their own boat with no help from the outside. Admitting they KNEW the code was there and kept distributing it means they have little recourse now.
How do you benchmark a ferrari and a freight train?
MySQL is missing so many key features that benchmarking MySQL against Postgresql is useless.
How fast is MySQL when it has check constraints on data? No one knows, since it doesn't have them.
How fast is MySQL when you use a complex sub select? No one knows, it can't do more than a few common cases yet.
How fast is MySQL when you use stored procedures? Triggers? custom data types? Unions?
None of those things are there. WHEN MySQL gets around to having most of the features a REAL database has, then you can benchmark it, until then, any benchmark is going to unfairly favor MySQL because MySQL is fast because it is missing most of the features it needs to compete, and it never errors out, even when it should.
It's a data store, not a database. The SQL it supports is so small a subset of SQL92 as to be useless for any but the most simple content management applications.
When it meets most of the SQL99 or 03 standards, we'll talk. Til then, you're tilting at windmills when you compare MySQL to any other database. Heck, even Foxpro is a better database than MySQL.
Interesting. and, if SCO is found to have a case with no Merit, would they then owe the linux developers for their lost development time?
1: IBM finds that the code added, if any, came from Caldera, forcing SCO to sue themselves.
2: IBM, in discovery, demands a receives the source to SCO's flavors of Unix and finds evidence that SCO stole GPL'd source code to put into unixware / openserver. Sco is forced to release the whole shebang under the GPL.
And, it looks like it's run by the same sloppy crew as their legal team:
Apache/1.3.14 (Unix) mod_ssl/2.7.1 OpenSSL/0.9.6 PHP/4.0.3pl1 on Linux
I believe there are remote root exploits for each of those packages listed.
Oh, and another thing about MySQL is that when it does what would usually be classified as "the wrong thing" it never tells you. Not even a warning.
Create two tables, one innodb, the other myisam. Run a transaction against both of them. roll it back halfway through.
MySQL doesn't tell you that you can't run a transaction on a MyISAM table, it doesn't tell you it didn't roll back the MyISAM table, in fact, it happily acts like it got the whole thing right, and rolled it back. Except the changes you made to the myisam table are still there.
MySQL is a data store with a minimal SQL front end written by people who DO NOT UNDERSTAND the issues of database design in a high load / high transaction environment. To paraphrase the manual, data consistency and what not are the job of the database, they are the job of your code. god help you if you make a mistake because MySQL isn't going to catch any of them.
Let's see, 3 years ago, you tried Postgresql. It took 10 whole minutes to load your data, so it must just suck at everything else. Never mind that there's been like 4 major revisions put out (think Mysql 3 to 4 to 5 to 6 to 7).
.info and .org domains would not be running on it. How many TLDs run on MySQL by the way? 0.
If Postgresql was corrupted, it was likely running on a hard drive with bad sectors or in a machine with bad memory. The fact that MySQL doesn't tax your machine as hard makes it more likely that postgresql will show these errors.
I've been running Postgresql for 4 years, and have NEVER had a table get corrupted, NEVER had it lose data, and NEVER had it crash.
Your experience with it, i.e. virtually none, disqualifies you from stating it sucks.
MySQL is NOT A SQL database. It's missing so many features it's hard to make a list and not have it be as long as your arm.
Here are a few: No constraints (however, it will accept them during table creation, then promptly ignore them!) Allows you to put NULL into not null columns, and just inserts either the default or 0 or '' or 0000-00-00. Foreign keys, now that they finally have them, don't support cascading, which makes them about worthless.
Let's make it clear, if Postgresql was a shitty as you're saying, the
"And the Devil Will Drag You Under" by Jack Chalker
"Waiting for the Galactic Bus" by Parke Godwin
"Dark Star" by Alan Dean foster
"The Damned" trilogy by Alan Dean Foster
I didn't say I RUN it async, I said I tested it async.
besides, you have no earthly idea what that server was used for.
If it was a giant collection point for data feeds from a mainframe with 5000 people hitting it for ODBC feeds to slurp into Excel, it's quite a sane setup.
So, yet another example of an idiot posting AC who has NO real world experience.
The 2 minute wait to post, by the way, sucks nuts, and the person who implemented it should have their head smacked against a wall. Yes, you know who you are...
Actually, according to the report, they used a hardware RAID controller. Note that on fast hardware (i.e. 8 CPU xeon machines) Linux's kernel RAID is often faster than hardware RAID.
The real killer was that they left atime on in linux, while turning it off in Windows. that's just playing dirty.
In testing the Postgresql database, I've seen improvements of 100% when using noatime, async
Interesting point. I find that there are several views when it comes to OS databases.
One is that since most open source databases lack some feature, they will never replace any Oracle servers. Most of the people who believe this also believe that Oracle servers are always used in high parallel load transactional systems that have to be up 24/7 and never go down. While plenty of sites that need that use oracle, it is not inversely always true. Many places put Oracle online because it's what their developers know and love, not because it's the best fit for the problem.
The next view is that Open Source databases are ready to replace Oracle right now, everywhere. While there are plenty of places using Oracle that could switch to Pgsql/MySQL/Firebire right now, there are plenty more that couldn't dream of it. It's all about what you're doing with your database that defines which ones you can use.
The final view is the right tool for the job view. These folks are rare. They're actually loaded test datasets into various database engines, read up on how each db's locking mechanism works, examined each to see where the best fit is.
People relying on the first two views are treating computer science like a religion instead of a science.
Squid with a simple custom redirector works nicely.