Ok (I used to think the same way), but you are losing a number of things:
1) The ability to mathematically define valid data in the RDBMS so your code only has to worry about security implications of data validation 2) The ability to separate out the SQL from your code so it is not generally included inline in every one of your object classes.
Pretty much every bug in software can be reduced to a data state bug or a data flow bug. Using the RDBMS properly can eliminate most or all of the former.
I will tell you why we selected PostgreSQL to be the only RDBMS supported by LedgerSMB.
The basic issue is that RDBMS's are often used as light-weight information stores, but they are designed to be powerful math engines which can simplify application development immensely if properly used. You can do some of this using just ANSI SQL, but often you run into limitations which are best solved by using stored procedures basically as named queries.
The math engine aspects allow us to look at valid data states as a problem which is checked outside the flow of execution of the program, as is security. We can do this because the data is mathematically defined independent of the application flow.
With a few exceptions, LedgerSMB is going to a one-language-per-file model where HTML, CSS, Javascript, Perl, and SQL are all separated out into different files. This allows for a simpler, easy to follow model.
I write serious business applications. I have done serious work with MySQL, Firebird, and PostgreSQL. In general, I would say that PostgreSQL is the best of the three.
Now, contrary to your opinion, PostgreSQL is actually quite successful It is just not as visible because it has not historically been as good at the super-simple website app stuff. However, I would not trust any money-tracking applications (not even a shopping cart) to MySQL.
Actually, there are several cases where you may think that MySQL has foreign keys when it doesn't. So the support of foreign keys is not entirely complete.
If innodb is not installed, you get a MyISAM table without the foriegn key enforcement and not even a warning is given on table creation (you do get a warning when you insert, but the application is unlikely to be watching).
CREATE TABLE table2 (
id int autoincrement primary key,
foreign_id int references table1(id),
test text ) type=innodb;
CREATE TABLE table2 (
id int autoincrement primary key,
foreign_id int,
test text,
FOREIGN KEY foreign_id REFERENCES table1(id) ) type=innodb;
In one of the above examples (won't say which one;-) ), you don't get foreign key enforcement. No warning. just no enforcement.
Yes, MySQL has foriegn keys. It doesn't have them 100% but it does have them.
PostgreSQL is BSD licensed, MySQL is GPL licensed.
But aside from that, it is unlikely that Google's code contributions go beyond general performance benefits, management of large numbers of systems, and maybe full text search.
PostgreSQL 8.3 already will have a great, mature full text search capability, is far easier to manage in large environments, and can handle more complex loads than MySQL can. So I don;t think that there is likely to be a lot of useful ideas which could be transplanted.
Finally, the architecture of the programs are entirely different. MySQL uses a single process, multithreading model (which has lead to nteresting cases where a thread can cause the entire service to stop working!) while PostgreSQL uses a forking process model.
Note that JET is used by Access to store relational data, but it is also used by Exchange to store nonrelational data. There is no SQL support in JET. It is not like SQLite so much as like BDB.
I think we can all say that MySQL is pretty crappy at being an RDBMS, compared to PostgreSQL or even Firebird.
However at the time Google was evaluating versions, PostgreSQL's performance wasn't so great. It was a pain to use and develop for, and backups had a tendency of being dumped in the wrong order so the data could not properly be restored. (I have been using PostgreSQL primarily since 6.5.)
Firebird? It wasn't even around yet. Sure there was Interbase, but it was not open source.
And Google didn't need transactions scalable security management, or anything else where MySQL gets fundamentally failing grades. So what did they do? They chose what was the best database at the time as their needs required.
Today, PostgreSQL is a far better database (will continue to be even after the infusion of Google code since Google obviously isn't using it for anything where a real RDBMS is required), so I would think that if a startup like Google were starting today, a different choice might have been made. But for the time it was made, it wasn't a bad choice.
PostgreSQL used to be a pain to work with. hard to use, and had somewhat interesting problems with things like restoring backups. It is now extremely robust, solid, powerful, and has great performance.
MySQL is a good database where all you need is a simple interface to try to store data and where you dont care that much if what you get out isn't exactly what you put in. This means simple CMS needs, and simple storage needs. Google would fit that profile.
However, as an RDBMS, MySQL sucks badly. Yeah, that is like saying that a PC sucks as a mainframe, but...
I certainly wouldnt want to be anywhere near a large positron beam hitting electrons. They don't explode... Instead you get a number of things happening:
1) Positron + electron = 2 gamma rays/ 2) A missing electron (meaning free radical, and/or an electrical current).
So basically, a positron destroys an electron and creates two ionizing photons.
So think of this less as an explosion and more as a giant light-bulb spewing gamma rays. Cool, but you want to be somewhere else.
Note that the current ideas for positronic rocket engines involve ablating material via the gamma rays.
The Linux community must get away from trying to be Ford or GM (Genetically Modified?). Linux offers POWER! No apologies POWER! It ain't for your gran'ma. I beg your pardon?
My grandma was programming computers (in Fortran) since before I was born. If she was still alive, you bet she would like Linux.
There are a lot of people of any generation who feel intimidated by computers, but I will tell you that most of the senior citizens of my customer base are sufficiently intelligent for this not to be a problem. I would suggest that you limit your comments to those about your own grandma and leave the rest of us out of it:-)
So whether you agree that Comcast should be able to make a small profit on wiretaps, they are providing an additional layer of checks and balances to our government. No. The government provides the checks, which add to Comcast's balances (and hence balance sheet). Until the NSA sends in the hammer squads;-)
Honestly, I agree with the practice of charging the government for these sorts of things though. It is better that they charge law enforcement than that they pass the cost on to the customers.
I think there is an interesting misconception about true community-developed software such as Linux. It will remain open because that is the best way to compete. Look at PostgreSQL for example. They even use a BSD-style license and everyone that has tried to offer a closed version of it has failed unless it is a niche market that the PostgreSQL community doesn't really want to be in anyway.
1) Seeds do not retain vitality for 20 years. 2) New varieties will contain new patents, thus preventing you from doing that regarding a variety that is about to move into the public domain. 3) Accidental cross-polination would still be patent infringement.
Aside from trade secret law which applies to every industry, hybrids have *no* intellectual property protections beyond the possibility of plant patents which only apply to asexual reproduction (and hence seeds are non-patentable).
I have actually watched the apple, rose, and stonefruit industries for a while. Those areas have a lot of plant patents, but the patents have a shorter lifespan than the plant's genetics so, strains fall back into the public domain fairly quickly. Of my 20-some-odd rose bushes, only 2 are patent protected. None of my three fruit trees are.
As for grains and vegetables, you do have a number of hybrids, but there is also a resurgeant heirloom vegetable industry (at least for the local-targetting agricultural businesses including garden centers). Heirloom varieties are great because the seeds *can* be reused. The problem with GMO's is that you have the possibility of inadvertant patent infringement by doing so and thus you have the evisceration of the last remaining checks and balances agaisnt the huge suppliers to agriculture (such as Monsanto).
If you read the article carefully, you will note that it doesn't contradict what I wrote.
1) Pharmaceuticals are the product of articial processes. While it would be nice to have international treaties which would provide royalites to countries where the original plant was used, that is very different than patenting the plant itself, especially in the context of food production.
2) The Impatiens variety they were discussing (Spellbound) would actually be grown by cuttings. Hence we are talking about a clone which is asexually reproduced, and there is no downstream restrictions on gardners doing their own crossbreeding.
So while there are social equity issues that need to be dealt with, this doesn't even approach the danger that genetic engineering poses to the world's food and plant supply.
BTW last spring I was shopping for rose bushes when I found what looked like a nice attractive Rugosa hybrid. I passed up buying it because it was patented, and rugoses are sufficiently invasive that one would be *very* tempted to dig up rhyzomes (which would be illegal if you let them grow or give to friends).
Aside from the fact that this would almost certainly be patent misuse....
A larger real concern has to do with farmers in third world countries. The goverments will be pressed into granting identical patent rights as exist in the US, and will be unable to do a lot about it. Then the foreign corporation basically uses this to take a percentage of what was once purely domestic trade out of the country. This is *very bad* for the developing world.
BTW, there is not, and has never been, a global shortage of food production. Most famines are caused by trade disruption (mostly things like civil wars), not natural causes. There is no need to try to address a mythical looming global food shortage except through working to stabilize the global population (through things like building schools).
is that normal plant patents (at least in the US) only cover grafting, budding, cuttings, and other forms of asexual reproduction. Basically you can't patent a natural genetic variant you discover and then prevent people from using it as breeding stock.
Hence you can buy a patented rose bush, breed it with another patented rose bush, and be the exclusive patent holder of the offspring (or decide to let the offspring be patent free). This is a big check on the power of plant patents
This changes with GMOs. With GMO's, offspring which carry the artifical genetic structure are subject to the control of the patent holder. This means that farmers now have a great deal more to worry about in terms of being sued for intellectual property violations simply by growing their own seed crops. This is a large deal because it effectively decommoditizes the food crop industry and turns it into something much more similar to the proprietary software industry....
Slashdot Mirror
Slony-I is probably your best answer. Pg-pool might do as well, especially if you use it along with Slony.
Ok (I used to think the same way), but you are losing a number of things:
1) The ability to mathematically define valid data in the RDBMS so your code only has to worry about security implications of data validation
2) The ability to separate out the SQL from your code so it is not generally included inline in every one of your object classes.
Pretty much every bug in software can be reduced to a data state bug or a data flow bug. Using the RDBMS properly can eliminate most or all of the former.
I will tell you why we selected PostgreSQL to be the only RDBMS supported by LedgerSMB.
The basic issue is that RDBMS's are often used as light-weight information stores, but they are designed to be powerful math engines which can simplify application development immensely if properly used. You can do some of this using just ANSI SQL, but often you run into limitations which are best solved by using stored procedures basically as named queries.
The math engine aspects allow us to look at valid data states as a problem which is checked outside the flow of execution of the program, as is security. We can do this because the data is mathematically defined independent of the application flow.
With a few exceptions, LedgerSMB is going to a one-language-per-file model where HTML, CSS, Javascript, Perl, and SQL are all separated out into different files. This allows for a simpler, easy to follow model.
Slony, Pg-pool, and a number of other Free addons provide different approaches to this issue.
It allows you to access MySQL from within PostgreSQL. You can also access anything else you can reach via Perl's DBI interface.
I write serious business applications. I have done serious work with MySQL, Firebird, and PostgreSQL. In general, I would say that PostgreSQL is the best of the three.
Now, contrary to your opinion, PostgreSQL is actually quite successful It is just not as visible because it has not historically been as good at the super-simple website app stuff. However, I would not trust any money-tracking applications (not even a shopping cart) to MySQL.
So have I. I have even written published papers introducing MySQL. And Lurker is right on pretty much all his points.
Now, all software has gotchas, but MySQL's ones are unusually severe.
I would also point out that once you have done serious work with a *real* RDBMS, you will tend to get frustrated when you have to go back to MySQL.
Actually, there are several cases where you may think that MySQL has foreign keys when it doesn't. So the support of foreign keys is not entirely complete.
;-) ), you don't get foreign key enforcement. No warning. just no enforcement.
If innodb is not installed, you get a MyISAM table without the foriegn key enforcement and not even a warning is given on table creation (you do get a warning when you insert, but the application is unlikely to be watching).
CREATE TABLE table2 (
id int autoincrement primary key,
foreign_id int references table1(id),
test text
) type=innodb;
CREATE TABLE table2 (
id int autoincrement primary key,
foreign_id int,
test text,
FOREIGN KEY foreign_id REFERENCES table1(id)
) type=innodb;
In one of the above examples (won't say which one
Yes, MySQL has foriegn keys. It doesn't have them 100% but it does have them.
PostgreSQL is BSD licensed, MySQL is GPL licensed.
But aside from that, it is unlikely that Google's code contributions go beyond general performance benefits, management of large numbers of systems, and maybe full text search.
PostgreSQL 8.3 already will have a great, mature full text search capability, is far easier to manage in large environments, and can handle more complex loads than MySQL can. So I don;t think that there is likely to be a lot of useful ideas which could be transplanted.
Finally, the architecture of the programs are entirely different. MySQL uses a single process, multithreading model (which has lead to nteresting cases where a thread can cause the entire service to stop working!) while PostgreSQL uses a forking process model.
THe two are fundamentally different.
Note that JET is used by Access to store relational data, but it is also used by Exchange to store nonrelational data. There is no SQL support in JET. It is not like SQLite so much as like BDB.
I think we can all say that MySQL is pretty crappy at being an RDBMS, compared to PostgreSQL or even Firebird.
However at the time Google was evaluating versions, PostgreSQL's performance wasn't so great. It was a pain to use and develop for, and backups had a tendency of being dumped in the wrong order so the data could not properly be restored. (I have been using PostgreSQL primarily since 6.5.)
Firebird? It wasn't even around yet. Sure there was Interbase, but it was not open source.
And Google didn't need transactions scalable security management, or anything else where MySQL gets fundamentally failing grades. So what did they do? They chose what was the best database at the time as their needs required.
Today, PostgreSQL is a far better database (will continue to be even after the infusion of Google code since Google obviously isn't using it for anything where a real RDBMS is required), so I would think that if a startup like Google were starting today, a different choice might have been made. But for the time it was made, it wasn't a bad choice.
I actually at least partially disagree with you.
PostgreSQL used to be a pain to work with. hard to use, and had somewhat interesting problems with things like restoring backups. It is now extremely robust, solid, powerful, and has great performance.
MySQL is a good database where all you need is a simple interface to try to store data and where you dont care that much if what you get out isn't exactly what you put in. This means simple CMS needs, and simple storage needs. Google would fit that profile.
However, as an RDBMS, MySQL sucks badly. Yeah, that is like saying that a PC sucks as a mainframe, but...
I certainly wouldnt want to be anywhere near a large positron beam hitting electrons. They don't explode... Instead you get a number of things happening:
1) Positron + electron = 2 gamma rays/
2) A missing electron (meaning free radical, and/or an electrical current).
So basically, a positron destroys an electron and creates two ionizing photons.
So think of this less as an explosion and more as a giant light-bulb spewing gamma rays. Cool, but you want to be somewhere else.
Note that the current ideas for positronic rocket engines involve ablating material via the gamma rays.
My grandma was programming computers (in Fortran) since before I was born. If she was still alive, you bet she would like Linux.
There are a lot of people of any generation who feel intimidated by computers, but I will tell you that most of the senior citizens of my customer base are sufficiently intelligent for this not to be a problem. I would suggest that you limit your comments to those about your own grandma and leave the rest of us out of it
Honestly, I agree with the practice of charging the government for these sorts of things though. It is better that they charge law enforcement than that they pass the cost on to the customers.
I think there is an interesting misconception about true community-developed software such as Linux. It will remain open because that is the best way to compete. Look at PostgreSQL for example. They even use a BSD-style license and everyone that has tried to offer a closed version of it has failed unless it is a niche market that the PostgreSQL community doesn't really want to be in anyway.
1) Seeds do not retain vitality for 20 years.
2) New varieties will contain new patents, thus preventing you from doing that regarding a variety that is about to move into the public domain.
3) Accidental cross-polination would still be patent infringement.
Not really.
Aside from trade secret law which applies to every industry, hybrids have *no* intellectual property protections beyond the possibility of plant patents which only apply to asexual reproduction (and hence seeds are non-patentable).
I have actually watched the apple, rose, and stonefruit industries for a while. Those areas have a lot of plant patents, but the patents have a shorter lifespan than the plant's genetics so, strains fall back into the public domain fairly quickly. Of my 20-some-odd rose bushes, only 2 are patent protected. None of my three fruit trees are.
As for grains and vegetables, you do have a number of hybrids, but there is also a resurgeant heirloom vegetable industry (at least for the local-targetting agricultural businesses including garden centers). Heirloom varieties are great because the seeds *can* be reused. The problem with GMO's is that you have the possibility of inadvertant patent infringement by doing so and thus you have the evisceration of the last remaining checks and balances agaisnt the huge suppliers to agriculture (such as Monsanto).
If you read the article carefully, you will note that it doesn't contradict what I wrote.
1) Pharmaceuticals are the product of articial processes. While it would be nice to have international treaties which would provide royalites to countries where the original plant was used, that is very different than patenting the plant itself, especially in the context of food production.
2) The Impatiens variety they were discussing (Spellbound) would actually be grown by cuttings. Hence we are talking about a clone which is asexually reproduced, and there is no downstream restrictions on gardners doing their own crossbreeding.
So while there are social equity issues that need to be dealt with, this doesn't even approach the danger that genetic engineering poses to the world's food and plant supply.
BTW last spring I was shopping for rose bushes when I found what looked like a nice attractive Rugosa hybrid. I passed up buying it because it was patented, and rugoses are sufficiently invasive that one would be *very* tempted to dig up rhyzomes (which would be illegal if you let them grow or give to friends).
Aside from the fact that this would almost certainly be patent misuse....
A larger real concern has to do with farmers in third world countries. The goverments will be pressed into granting identical patent rights as exist in the US, and will be unable to do a lot about it. Then the foreign corporation basically uses this to take a percentage of what was once purely domestic trade out of the country. This is *very bad* for the developing world.
BTW, there is not, and has never been, a global shortage of food production. Most famines are caused by trade disruption (mostly things like civil wars), not natural causes. There is no need to try to address a mythical looming global food shortage except through working to stabilize the global population (through things like building schools).
is that normal plant patents (at least in the US) only cover grafting, budding, cuttings, and other forms of asexual reproduction. Basically you can't patent a natural genetic variant you discover and then prevent people from using it as breeding stock.
Hence you can buy a patented rose bush, breed it with another patented rose bush, and be the exclusive patent holder of the offspring (or decide to let the offspring be patent free). This is a big check on the power of plant patents
This changes with GMOs. With GMO's, offspring which carry the artifical genetic structure are subject to the control of the patent holder. This means that farmers now have a great deal more to worry about in terms of being sued for intellectual property violations simply by growing their own seed crops. This is a large deal because it effectively decommoditizes the food crop industry and turns it into something much more similar to the proprietary software industry....
is that what was once a commodity market (food) could become an intellectual property driven market.
Piracy will include growing unauthorized crops. This is not good for anyone except for companies like Monsanto.
They say to the (wo)man with the hammer, "Everything looks like a nail!"
RMS's post about invariant sections:
http://lists.debian.org/debian-legal/2003/08/msg00807.html
Bushnell's post that got him in trouble:
http://lists.debian.org/debian-legal/2003/09/msg00707.html
Bushnell's email relating to his resignation:
http://softwarelibero.it/pipermail/discussioni/2003-November/008465.html
OpenKiosk client is the same way. But that is not what I am talking about.
In both cases, the Linux client is both Free and Open Source on Linux and neither Free nor Open Source on Windows.