but very little sense to compare either of those products with Oracle;
It makes a lot of sense, especially if you're deciding between Oracle and a cheaper alternative. Many people bought Oracle when it was the only DB that could get the job done for them, but PostgreSQL has come a long way since that time.
Absolutely anyone getting ready to make their next payment to Oracle should be comparing Oracle with PostgreSQL to make sure Oracle is really a wise investment.
How is it justice to pay someone for damage that didn't happen? Sounds more like a lottery to me: "Alright, good thing I bought that crappy software, Cha-Ching!".
That seems like a strange argument. You seem to be saying that the president shouldn't do it, and the combination of the president and the Senate is still not enough because they can be controlled by the same party sometimes. I'm assuming you don't expect the judiciary to replenish themselves, so that leaves basically two options:
(1) The House has input (2) The people have input
Both of those are very political options, and I think that's bad for an independent judiciary. If you get the House or the people involved, judges will have to campaign like a president. It will make a mockery out of the Rule of Law and the Separation of Powers, because it will no longer matter what Congress does. A judge will run on a platform of some type, like "I will overturn Roe v. Wade" or "I will expand Roe v. Wade". Why should Congress bother passing laws if we're just going to elect judges that can dictate policy without following the legislative process?
Re-use is possible though, the best examples are the Java and.Net libraries which are very good.
You can view a standard library as an example of code reuse, but I think there is a fine line between "code reuse" and a language with a rich vocabulary.
Java is a minimalist language, so many of the simple functions are implemented as libraries. That's not "good" or "bad", it's just a design decision. However, perl has a built-in regex processor, while Java has a library. Is java reusing code better than perl in that example? No: they both just provide some basic services to the programmer in different ways.
The article didn't say anything about a non-compete clause. There should have been one, and if there is, it's actionable, and if not, it's not actionable.
Non compete clauses are basically OK as long as: (1) They are not overly broad; (2) You still have avenues for a similar level of employment; and (3) It's not for an unreasonable duration
OR they pay you a huge severance in one way or another to compensate for your unemployability.
I know it doesn't have to be GPL, but it has to be GPL compatible (which most of those licenses are anyway) or one of the special exceptions (like php).
As for the "freeloaders" comment, let me remind you that you included in that group a commercial software developer who just wants to add MySQL support to their application among (perhaps) other database drivers.
You may consider those people freeloaders, but most developers would be surprised by that and consider it a disadvantage to adding support for MySQL. Consider that most commercial database engines have less restrictive licenses on their client libraries, specifically to allow developers freedom to include support for their database.
It's a bit like saying that anyone who writes a commercial application that can operate on linux is freeloading.
By default under copyright law, you have absolutely no right to distribute the MySQL client library.
MySQL grants you this privilege under the condition that the derivitive work is OSS. Linked executables are generally considered to be "derivitive works", and so is basically anything that is dependent upon the copyrighted work.
The problem is that the client library is GPL, not LGPL as one might expect.
That means that any application that you distribute that can access a MySQL database must be linked against the MySQL library, which is GPL, forcing your application to be GPL.
Most people don't consider adding MySQL support to their application to be "distributing MySQL".
TSearch2 is a full text search module for PostgreSQL that has been available for a long time. It's stable and not in beta.
What's wrong with modules? They're great. It means that you can upgrade TSearch2 or some other module without waiting for the next release of PostgreSQL. It's not difficult at all to install the modules, just copy some files and run a SQL file.
I think that PostgreSQL making use of it's extensibility by forcing some functionality out into modules was very successful from a technological standpoint, a release process standpoint, and a user's standpoint. However, it certainly was a marketing failure. Now everyone thinks PostgreSQL is missing those features. PostgreSQL has never been known for it's marketing abilities.
It's about incentives. What's the incentive for a small, private ISP to start censoring content? After all, there are a million other small, private ISPs that customers can switch to if there is a problem.
However, if the government provides access, then it is very hard for small, private ISPs to exist, because they have to compete against a price of $0.
That means, when the censors come to power, they already control all of the internet access. And they can say things like "internet access is a privilege not a right". And then install checkpoints.
Can't you just open the big file in a spreadsheet, determine the column headings, and then use scripts from that point on? So what if the spreadsheet doesn't read past 64k lines or whatever.
It sounds like your requirements are actually quite simple, you just want to quickly format the first few hundred lines to get an idea about the data. Maybe even just use "head big_file.csv >/tmp/header.csv" and then import it.
And also, if this is all preliminary analysis anyway, what's wrong with beta software?
Perhaps MS Access or OOo Base is right for you? They should be able to seamlessly import and view a few hundred thousand lines, without requiring you to know about the data in advance.
You make a lot of good points, however I wasn't really posting about the issues behind the topic of the article, I was posting because the article seemed to mislead more than inform.
My primary point was that a computer is not a source, and "some scientists" are not a source. There is a kind of "web of trust" of reputations among sources. To circumvent that and use nameless sources allows you to report whatever you want, which is exactly why the reporters do that. They want to make a sensationalist story, and they don't want to bother checking up on their sources, so they just use sources without names, like "a weather model" or "some scientists".
Anyway, I think we're in agreement there.
As far as the other points you made, basically I think this:
(1) There are many people concerned about the rise of C02 and CH3 from human activity. Whether they're right or wrong, it at least warrants caution about our output of those gasses.
(2) Statement #1 is highly political, and everybody (no matter what political party) is trying to use it to control the actions of others. Some want some foriegn nation to have power over the U.S., and vice-versa.
(3) The "solutions" to #1 range from a "let's wait and see" to "let's grind the economy to a halt". Unfortunately, there's no evidence to suggest exactly how far we should go to limit C02/CH3 production. When making economic decisions, we really need a cost/benefit analysis, but we have no way to make one. However, it seems reasonable to take some steps to reduce the human impact on the atmosphere.
What I want to know is why don't the media practice "equal time" during the daily weather forecast.
There are some situations in very specific geographical areas where a local forecaster is more effective than the bigger weather outfits. This might be the case in a narrow valley where the weather patterns are very different from nearby areas. However, aside from that, there aren't really any reliable forecasters that consistantly disagree. However, aside from that, I would be surprised to find many reliable dissenting opinions.
However, they neglected to give any information about the assumptions that the computer model is using.
It's not informative to use a computer model as a definitive source. They should give a few basic principles upon which the model is based, and let the reader decide. They don't say which computer model, or who extrapolated the data, or anything.
The reader is left with the impression that the prediction is irrefutable because "a computer said it".
I think this goes back to that "bad science reporting" article a little while ago.
Computer models need assumptions. What assumptions are used to model the loss of artic ice by 2070? A computer isn't magically smarter than people, it just calculates using the numbers a human gives it.
I'll give an example: Let's say it's 60 degrees F when you wake up, and 75 degrees F by 2pm. A computer model might say that we're all going to be cooked in a week.
A computer is not a scientific source to be cited in a news article. The alternative, however, is a little bit less exciting to print. What they really mean to say is that "If assumptions X, Y, and Z remain true, then [horrible thing] will happen by [really soon].".
Not only that, but "some scientists now believe"?! Of course "some scientists" will believe almost anything. You can find scientists that think the Earth is 5000 years old. What matters is a consensus among reputable, peer-reviewed scientists.
It's really hard for me to believe that every application that touches the database is as rock-solid as the release of a database server. And when you have different groups working on different projects, one group will always have to wonder "maybe that other group put in some inconsistent data?".
Then, presumably, each developer would have access to a spec detailing how the data in the database should look. And every new application you need to accommodate might change that spec. It's easy to have the database handle that spec, so why not just let the database do it? That way you don't have a million versions of a spec floating around and hope that every application adheres 100% all the time, for every query.
And transaction id wraparound is far worse than OID wraparound.
Just to clarify, in 8.1 there is integrated autovacuum, and also it detects a possible xid wraparound. The problem is basically eliminated. If you really try to push 8.1 forever without vacuuming, it will start issuing warnings, and eventually errors. Then when you finally vacuum, everything is fine.
I hope Postgres solves this problem (along with the OID wrap thingy) once and for all
8.1 is in beta, and as I understand it, both those issues are solved. There's integrated autovacuum which uses statistics to determine the best times to vacuum automatically. And OIDs are now not used by default, so wraparound shouldn't happen by accident. There's not much reason to use OIDs on purpose, either.
international support
What's wrong with PostgreSQL's international support?
easier/more integrated full-text indexing
I happen to like tsearch2. I think the main thing that PostgreSQL should do is have better support for "packages" so that it is easy to install a 3rd party project like tsearch2. I think the fact that PostgreSQL doesn't integrate every last feature into the backend is a strength. It's very extensible, I just think they need to make it a little easier to install 3rd party packages.
more efficient TEXT and BYTEA
What's inefficient about them? TEXT is compressed by default. The only thing I would change is allow you to directly access an arbitrary offset of a bytea field.
parallel queries
What do you mean by that? PostgreSQL has great concurrent access performance as-is. Are you talking about the 1 CPU per query issue?
When I have 10 apps inserting data into my database, I'm sure they're doing it right because those applications have been tested, and ere written by competent programmers.
What about when you have 9 live applications, and the 10th is in testing phase? If it inserts bad data, it could screw up the other 9 applications.
And the answer is NOT more application code. That requires an enormous amount of redundant code. If every application does it's own consistancy checking (both coming from and going to the database), you're virtually talking about reimplementing a database product in an application library. And all that code needs it's own testing and has it's own performance problems. And that code can be highly dependent on the physical structure of data, and usually requires massive restructuring when the data schema changes to accomodate application #11.
Why not just let the database give you an error if you violate a constraint? It's simple, and it tells you exactly where and what the problem is without affecting other applications. Plus, making schema changes is no big deal because you can easily use views to make sure that old applications are supported.
The difference is, that PostgreSQL is in no way dependent upon EnterpriseDB; whereas MySQL is entirely dependent upon MySQL AB.
PostgreSQL has survived, and even accelerated development, through numerous companies and individuals with varying degrees of involvement.
SCO has a track record of making huge problems for companies that they work with. If they make huge problems for MySQL AB, the MySQL product is in serious danger, and so are all the customers. MySQL is actively involving SCO, and possibly risking a lot. We don't know, but anyone who uses MySQL has a legitimate reason to worry.
If SCO makes huge problems for EnterpriseDB, that's unfortunate, but does not risk the PostgreSQL product.
At a time like this, I'm happy that my company uses PostgreSQL, which is not controlled by any one company.
PostgreSQL vacuum is a good thing
When did that become a myth? Autovacuum has been touted for a couple releases now, and in 8.1 it's integrated into the backend. Users no longer have to worry about it at all (although like many performance parameters, it's still tunable to a degree).
The division between disk and filesystem is also artificial.
The extra layer of abstraction is valuable to people who use it. If you want or need to change the on disk layout and you use a filesystem, you have to change all the applications that access that data. With an RDBMS you can make changes without changing existing applications.
There are many technologies that are abstrations on top of abstrations. Every extra abstraction has a cost and a benefit. If the benefit is small to you, forget it. However, I value the benefits of an RDBMS highly for many applications (though not all), and so I use it.
Slashdot Mirror
What you want is PLJava, which is released and functional code:
s play.php
http://gborg.postgresql.org/project/pljava/projdi
PLJ was more like a first try, and I don't think it's being maintained.
that might be true of v7.3 - when using postgresql 7.1 it was clearly not as easy to work with as MSSQL 2000.
7.3?! That was two versions ago, PostgreSQL is on 8.0 right now. In fact, 8.1 is in beta and almost released.
And 7.1 is even less relevent to this discussion.
Ok, I'll tell you.
PostgreSQL has shipped with python as a stored procedure language since... well, a couple years back anyway. It was available in v7.2 I know.
PostgreSQL is *very* extensible.
but very little sense to compare either of those products with Oracle;
It makes a lot of sense, especially if you're deciding between Oracle and a cheaper alternative. Many people bought Oracle when it was the only DB that could get the job done for them, but PostgreSQL has come a long way since that time.
Absolutely anyone getting ready to make their next payment to Oracle should be comparing Oracle with PostgreSQL to make sure Oracle is really a wise investment.
How is it justice to pay someone for damage that didn't happen? Sounds more like a lottery to me: "Alright, good thing I bought that crappy software, Cha-Ching!".
That seems like a strange argument. You seem to be saying that the president shouldn't do it, and the combination of the president and the Senate is still not enough because they can be controlled by the same party sometimes. I'm assuming you don't expect the judiciary to replenish themselves, so that leaves basically two options:
(1) The House has input
(2) The people have input
Both of those are very political options, and I think that's bad for an independent judiciary. If you get the House or the people involved, judges will have to campaign like a president. It will make a mockery out of the Rule of Law and the Separation of Powers, because it will no longer matter what Congress does. A judge will run on a platform of some type, like "I will overturn Roe v. Wade" or "I will expand Roe v. Wade". Why should Congress bother passing laws if we're just going to elect judges that can dictate policy without following the legislative process?
Re-use is possible though, the best examples are the Java and .Net libraries which are very good.
You can view a standard library as an example of code reuse, but I think there is a fine line between "code reuse" and a language with a rich vocabulary.
Java is a minimalist language, so many of the simple functions are implemented as libraries. That's not "good" or "bad", it's just a design decision. However, perl has a built-in regex processor, while Java has a library. Is java reusing code better than perl in that example? No: they both just provide some basic services to the programmer in different ways.
I think that's what non-compete clauses are for.
The article didn't say anything about a non-compete clause. There should have been one, and if there is, it's actionable, and if not, it's not actionable.
Non compete clauses are basically OK as long as:
(1) They are not overly broad;
(2) You still have avenues for a similar level of employment; and
(3) It's not for an unreasonable duration
OR they pay you a huge severance in one way or another to compensate for your unemployability.
I know it doesn't have to be GPL, but it has to be GPL compatible (which most of those licenses are anyway) or one of the special exceptions (like php).
As for the "freeloaders" comment, let me remind you that you included in that group a commercial software developer who just wants to add MySQL support to their application among (perhaps) other database drivers.
You may consider those people freeloaders, but most developers would be surprised by that and consider it a disadvantage to adding support for MySQL. Consider that most commercial database engines have less restrictive licenses on their client libraries, specifically to allow developers freedom to include support for their database.
It's a bit like saying that anyone who writes a commercial application that can operate on linux is freeloading.
By default under copyright law, you have absolutely no right to distribute the MySQL client library.
MySQL grants you this privilege under the condition that the derivitive work is OSS. Linked executables are generally considered to be "derivitive works", and so is basically anything that is dependent upon the copyrighted work.
You contradicted yourself. First you say:
If you write a recepie organizer that uses MySQL, then you need to do nothing.
Then you say:
Generaly, if you want to use and distribute MySQL client libraries, you also need to release whaterver is yours as GPL.
If you write an application that merely uses MySQL, you don't have the ability to distribute that application without the source.
If you do want to distribute, MySQL is GPL
The problem is that the client library is GPL, not LGPL as one might expect.
That means that any application that you distribute that can access a MySQL database must be linked against the MySQL library, which is GPL, forcing your application to be GPL.
Most people don't consider adding MySQL support to their application to be "distributing MySQL".
TSearch2 is a full text search module for PostgreSQL that has been available for a long time. It's stable and not in beta.
What's wrong with modules? They're great. It means that you can upgrade TSearch2 or some other module without waiting for the next release of PostgreSQL. It's not difficult at all to install the modules, just copy some files and run a SQL file.
I think that PostgreSQL making use of it's extensibility by forcing some functionality out into modules was very successful from a technological standpoint, a release process standpoint, and a user's standpoint. However, it certainly was a marketing failure. Now everyone thinks PostgreSQL is missing those features. PostgreSQL has never been known for it's marketing abilities.
It's about incentives. What's the incentive for a small, private ISP to start censoring content? After all, there are a million other small, private ISPs that customers can switch to if there is a problem.
However, if the government provides access, then it is very hard for small, private ISPs to exist, because they have to compete against a price of $0.
That means, when the censors come to power, they already control all of the internet access. And they can say things like "internet access is a privilege not a right". And then install checkpoints.
Can't you just open the big file in a spreadsheet, determine the column headings, and then use scripts from that point on? So what if the spreadsheet doesn't read past 64k lines or whatever.
/tmp/header.csv" and then import it.
It sounds like your requirements are actually quite simple, you just want to quickly format the first few hundred lines to get an idea about the data. Maybe even just use "head big_file.csv >
And also, if this is all preliminary analysis anyway, what's wrong with beta software?
Perhaps MS Access or OOo Base is right for you? They should be able to seamlessly import and view a few hundred thousand lines, without requiring you to know about the data in advance.
You make a lot of good points, however I wasn't really posting about the issues behind the topic of the article, I was posting because the article seemed to mislead more than inform.
My primary point was that a computer is not a source, and "some scientists" are not a source. There is a kind of "web of trust" of reputations among sources. To circumvent that and use nameless sources allows you to report whatever you want, which is exactly why the reporters do that. They want to make a sensationalist story, and they don't want to bother checking up on their sources, so they just use sources without names, like "a weather model" or "some scientists".
Anyway, I think we're in agreement there.
As far as the other points you made, basically I think this:
(1) There are many people concerned about the rise of C02 and CH3 from human activity. Whether they're right or wrong, it at least warrants caution about our output of those gasses.
(2) Statement #1 is highly political, and everybody (no matter what political party) is trying to use it to control the actions of others. Some want some foriegn nation to have power over the U.S., and vice-versa.
(3) The "solutions" to #1 range from a "let's wait and see" to "let's grind the economy to a halt". Unfortunately, there's no evidence to suggest exactly how far we should go to limit C02/CH3 production. When making economic decisions, we really need a cost/benefit analysis, but we have no way to make one. However, it seems reasonable to take some steps to reduce the human impact on the atmosphere.
What I want to know is why don't the media practice "equal time" during the daily weather forecast.
There are some situations in very specific geographical areas where a local forecaster is more effective than the bigger weather outfits. This might be the case in a narrow valley where the weather patterns are very different from nearby areas. However, aside from that, there aren't really any reliable forecasters that consistantly disagree. However, aside from that, I would be surprised to find many reliable dissenting opinions.
I didn't say computer models aren't useful.
However, they neglected to give any information about the assumptions that the computer model is using.
It's not informative to use a computer model as a definitive source. They should give a few basic principles upon which the model is based, and let the reader decide. They don't say which computer model, or who extrapolated the data, or anything.
The reader is left with the impression that the prediction is irrefutable because "a computer said it".
I think this goes back to that "bad science reporting" article a little while ago.
Computer models need assumptions. What assumptions are used to model the loss of artic ice by 2070? A computer isn't magically smarter than people, it just calculates using the numbers a human gives it.
I'll give an example: Let's say it's 60 degrees F when you wake up, and 75 degrees F by 2pm. A computer model might say that we're all going to be cooked in a week.
A computer is not a scientific source to be cited in a news article. The alternative, however, is a little bit less exciting to print. What they really mean to say is that "If assumptions X, Y, and Z remain true, then [horrible thing] will happen by [really soon].".
Not only that, but "some scientists now believe"?! Of course "some scientists" will believe almost anything. You can find scientists that think the Earth is 5000 years old. What matters is a consensus among reputable, peer-reviewed scientists.
It's really hard for me to believe that every application that touches the database is as rock-solid as the release of a database server. And when you have different groups working on different projects, one group will always have to wonder "maybe that other group put in some inconsistent data?".
Then, presumably, each developer would have access to a spec detailing how the data in the database should look. And every new application you need to accommodate might change that spec. It's easy to have the database handle that spec, so why not just let the database do it? That way you don't have a million versions of a spec floating around and hope that every application adheres 100% all the time, for every query.
And transaction id wraparound is far worse than OID wraparound.
Just to clarify, in 8.1 there is integrated autovacuum, and also it detects a possible xid wraparound. The problem is basically eliminated. If you really try to push 8.1 forever without vacuuming, it will start issuing warnings, and eventually errors. Then when you finally vacuum, everything is fine.
I hope Postgres solves this problem (along with the OID wrap thingy) once and for all
8.1 is in beta, and as I understand it, both those issues are solved. There's integrated autovacuum which uses statistics to determine the best times to vacuum automatically. And OIDs are now not used by default, so wraparound shouldn't happen by accident. There's not much reason to use OIDs on purpose, either.
international support
What's wrong with PostgreSQL's international support?
easier/more integrated full-text indexing
I happen to like tsearch2. I think the main thing that PostgreSQL should do is have better support for "packages" so that it is easy to install a 3rd party project like tsearch2. I think the fact that PostgreSQL doesn't integrate every last feature into the backend is a strength. It's very extensible, I just think they need to make it a little easier to install 3rd party packages.
more efficient TEXT and BYTEA
What's inefficient about them? TEXT is compressed by default. The only thing I would change is allow you to directly access an arbitrary offset of a bytea field.
parallel queries
What do you mean by that? PostgreSQL has great concurrent access performance as-is. Are you talking about the 1 CPU per query issue?
When I have 10 apps inserting data into my database, I'm sure they're doing it right because those applications have been tested, and ere written by competent programmers.
What about when you have 9 live applications, and the 10th is in testing phase? If it inserts bad data, it could screw up the other 9 applications.
And the answer is NOT more application code. That requires an enormous amount of redundant code. If every application does it's own consistancy checking (both coming from and going to the database), you're virtually talking about reimplementing a database product in an application library. And all that code needs it's own testing and has it's own performance problems. And that code can be highly dependent on the physical structure of data, and usually requires massive restructuring when the data schema changes to accomodate application #11.
Why not just let the database give you an error if you violate a constraint? It's simple, and it tells you exactly where and what the problem is without affecting other applications. Plus, making schema changes is no big deal because you can easily use views to make sure that old applications are supported.
What is the difference?
The difference is, that PostgreSQL is in no way dependent upon EnterpriseDB; whereas MySQL is entirely dependent upon MySQL AB.
PostgreSQL has survived, and even accelerated development, through numerous companies and individuals with varying degrees of involvement.
SCO has a track record of making huge problems for companies that they work with. If they make huge problems for MySQL AB, the MySQL product is in serious danger, and so are all the customers. MySQL is actively involving SCO, and possibly risking a lot. We don't know, but anyone who uses MySQL has a legitimate reason to worry.
If SCO makes huge problems for EnterpriseDB, that's unfortunate, but does not risk the PostgreSQL product.
At a time like this, I'm happy that my company uses PostgreSQL, which is not controlled by any one company.
PostgreSQL vacuum is a good thing
When did that become a myth? Autovacuum has been touted for a couple releases now, and in 8.1 it's integrated into the backend. Users no longer have to worry about it at all (although like many performance parameters, it's still tunable to a degree).
The division between disk and filesystem is also artificial.
The extra layer of abstraction is valuable to people who use it. If you want or need to change the on disk layout and you use a filesystem, you have to change all the applications that access that data. With an RDBMS you can make changes without changing existing applications.
There are many technologies that are abstrations on top of abstrations. Every extra abstraction has a cost and a benefit. If the benefit is small to you, forget it. However, I value the benefits of an RDBMS highly for many applications (though not all), and so I use it.