I understand your point, but just to play devil's advocate:
Dell must pick someone. I suppose they could offer both chips, but they don't want to confuse their customers, or their tech support personnel. Is whoever Dell picks the monopolist?
These conditions do not prevent a company from making use of any GPL software
I realize that. I like the GPL and I think it's a good license for a lot of software, even some code libraries.
I just think that it is counterintuitive that the licensing for MySQL is similar as if it was embedded in the application you're distributing. Most companies charge for the server and do not charge you to write applications for the server (or some products are always free of charge). MySQL is just the opposite: they give the server away for free and charge for writing applications.
I personally think that is confusing and counterintuitive. I also do not think that MySQL does a good job of clarifying that caveat. That is purely subjective, so I respect your disagreement. However, I think you may have missed my point which is what I'm trying to explain. I do not think it's a "myth" to be concerned about licensing which is counterintuitive to me.
I lose respect for any company that engages in lawsuits like this.
AMD has great products, and they are succeeding in the marketplace. A lawsuit just seems to come from jealousy. Why not spend their efforts competing with better products?
I know everyone is thinking about things like Intel's market control. But AMD is big enough to stand on its own feet and just keep going.
A nice, clear-cut lawsuit that acheives a real remedy can be healthy for a company, and is sometimes very necessary. But this type of litigious behavior can only corrupt. And that will destroy the innovation at AMD.
So you are saying that if I execute "tar -cf/dev/sa0/boot/kernel-2.6.14-gentoo-r5" and make a copy of the Linux kernel, which is GPL, onto another device, I have to track down all the contributors to the Linux kernel and get permission to do that?
(1) If you are copying files that you already have legally, and you are just incidently copying for basic functionality, it is likely fair use in which case you don't need a license. (2) The example you gave seemed to be pure GPL. Since you didn't make any derivative work with an incompatible license, I don't see a problem. (3) Legally speaking, if you copy something (aside from fair use), you need a license. Usually it is prominently displayed. If you are unsure about the license terms you have for a given piece of code, you need to track down the copyright holder and get a license.
Normally this whole process is simple because you just read one file that says "GPL" and it tells you the license for an entire application. Most of the time users merely use the application or perhaps copy it to other computers, and do not create derivative works. For this type of behavior they don't have anything to worry about under the GPL. The GPL is no-hassle when it comes to using and sharing programs.
However, the story is different for developers. Developers, like with any software, need to put themselves in a different frame of mind, about whose code they are using and what licenses that code is under. Developers invariably use code libraries, and for each one they know they need to acquire the correct rights. Let's say they plan to install it on 5 servers and 10 development machines, they need to acquire all 15 licenses for every code library they use developing the application.
The problem is that most people who are writing code that uses a separate database server view themselves as users of that database. If you write code that requires MySQL, you are a MySQL user. However, since the client libraries are GPL, those people are now (legally speaking) MySQL developers, since they are creating a derivative work of the MySQL product. And most people won't realize this until they are told by a MySQL sales rep that they need to pay up.
Of course this is not unique to the GPL. There are a lot of possible licenses for the client libraries that would cause this problem. However, by convention, client libraries are generally licensed under terms that do not create this problem. For example, BSD, LGPL, and many licenses used on the client libraries for commercial database products. MySQL breaks this convention.
And I'm not saying that it applies to every company. But it does apply to many situations that people may not realize. Most companies at least copy the application a few places around their company, for instance installing on a development machine and then the live server. Perhaps you can try to squeeze that into a legal situation. But it would be very easy to violate that if you aren't careful, which was my point.
Even commercial RDBMSs allow you the ability to link against the client libraries and distribute it. From a logical perspective, most people don't think of linking against client libraries as needing more licenses. But in the case of the GPL, it does. The GPL isn't normally used for client libraries (although it is used for code libraries).
The last time I checked, the overwhelming majority of companies on this planet are not software companies.
But many companies do copy code to one extent or another. If a company has some code under one license (perhaps that they purchased), it is likely incompatible wit the GPL and MySQL could enforce against them.
Making client libraries GPL is uncommon and certainly a caveat of using MySQL. It is not a myth. If you understand the implications and you're OK with it, that's fine.
My whole point is that most RDBMSs don't force you to make all of these sacrifices. If you want FTI you lose transactions (and a lot of other features), what kind of a sacrifice is that? Everyone says that MySQL is easy but to understand all of these tradeoffs is not easy at all.
Why not have MyISAM-table for text queries and link back to the main tables? Would give you an opportunity to choose which fields to add text data from before indexing too.
You could say the same thing about any data in a database at all. Transactions are useful on a table with a FTI just like on any other table.
Let's say that you want to make sure that a full text record does not exist without it's accompanying information (perhaps in a one to many relationship).
A text field doesn't seem at first like the typical bank account example that everyone uses to explain transactions. However, transactions are just as important for any data type.
If your application is designed for MySQL specificially without strict mode, then strict mode is not for you. It is more useful to people porting their applications from some other product to MySQL than to the existing MySQL user base.
But all the other databases seem to have mostly SQL standard syntax AND a large number of applications written for them.
MyISAM was never designed with transactions in mind. It performs its intended function excellently. Not all data is useful to keep in some kind of transaction context - take for example a table mapping UPC codes to product names and descriptions: it will never need to change in a transaction so having transactional overhead would be wasteful.
Yes, transactions are not required for every situation. I never said that they were. My point was that to achieve the advertised performance numbers that MySQL advocates give out, you have to sacrifice transactions. To get the advertised full text indexing you have to sacrifice performance.
Myth used to scare people away from opensource GPL code.
If your application links against the client library, it must adhere to the GPL. This is NOT a myth unless you know of an alternate client library.
MySQL is about choice... You can choose to use it or you can choose to use something else. You can choose to store your data in InnoDB, BerkeleyDB, Cluster, MyISAM, Memory, CSV
"Choices" is positive spin. Some might say that MySQL is all about sacrifices. Here are some examples:
(1) "MySQL has many applications written for it" * Not if you enable strict mode, or if you use storage engines that don't support the features you need. (2) "MySQL is optionally SQL compliant with strict mode" * Only if you want to forego 99% of the existing MySQL applications, and start fresh. (3) "MySQL has transactions" * Not in MyISAM, which means no full text indexing. (4) "MySQL is free" * Only if your application which links against the client library is also GPL. (5) "MySQL is fast" * Only if you use MyISAM, which means no transactions or many other features that aren't available in MyISAM.
I could go on. Anyone can talk about how MySQL has a feature, but you have to make sacrifices for those features. And I think many of those are bad, unnecessary sacrifices. MySQL implements features not to give their users choice, but to give MySQL AB a marketing advantage. Their advocates and salespeople will always say "yes" to all of those features above, but it's not until later that the customer realizes that they can't use the features together.
There are actually many differences. Full-text indexes (FTI) only work with MyISAM, for example.
If you change storage engines, you certainly need to examine all non-trivial MySQL code.
With MySQL, it's often hard to get all the features you want at one time. In the case of full text indexes, you can't also have transactions because only InnoDB has transactions.
can anyone point me somewhere which describes the deliniation of responsibilities between generic MySQL code and the storage engines?
Interesting question. However, MySQL does not completely abstract the storage engine. Different storage engines have different semantics at the higher levels. For instance, MyISAM does not support transactions, while InnoDB does.
My point was that the cat is out of the bag. Until we see the government try some funny stuff, let's not assume they will just because there is some incremental achievement in cryptography.
Why are we speculating here? We've had encryption for a long time now, and it's not going away. If the powers that be don't like this, wouldn't they not like GnuPG?
The poster made the political comment with absolutely no backing at all. I wouldn't be surprised if IBM was not allowed to export this to Iran, but again, nothing new. And you don't have much justification that Clinton would have tried to do anything.
How is that self-serving? I really have no interest in helping Nike.
And in economics, comparisons must be made. If Nike pays its workers more, it will employ fewer of them. So now you have some people making $4/day and some people standing in the unemployment line.
The main villian here is the governments in those countries that don't allow enough freedom and don't protect property. You might say Nike is an accomplice, since they probably need to bribe government officials constantly to be able to operate in those countries.
It's possible that he's using temp tables just to temporarily materialize a query result as part of a sequence of operations on the data. It's much better to use a view in that case, and PostgreSQL will optimize it to avoid uneccessary disk I/O.
And if he is using temp tables, it's still not obvious to me why they need to be vacuumed or analyzed.
Vacuum doesn't make too much sense for reporting, since there isn't any reason to have deletes/updates (at least no reason obvious to me). And analyze basically has two purposes: to allow PG to make a better plan, or if you want to use those statistics directly.
If you want the statistics to help make a better plan, that means PG needs to have several plans available. Perhaps if you're doing lots of joins, that may help. But the general use case for a temp table has just one option: sequential scan.
If you want to use the statistics directly, it seems to me better to just use aggregate functions. "ANALYZE" needs to scan the whole relation anyway, so why not use a precise query that gets exactly the information you want rather than whatever ANALYZE happened to collect?
You may have heard that PostgreSQL always needs to VACUUM/ANALYZE to be effective. That's partially true, but I think your temp tables may be a special case and not need VACUUM/ANALYZE at all.
First, do you want the statistics because PostgreSQL is choosing a bad plan without them, or do you use the statistics directly?
I'm having a little trouble understanding exactly what you want. It sounds like maybe you want something other than an elapsed time to trigger autovacuum on that one temp table so that the statistics are updated. But really, if there is any time lapse at all it seems like your application could not rely on the numbers without doing an explicit "ANALYZE" or "VACUUM ANALYZE".
Perhaps what you're looking for is up-to-date statistics of some kind. This has been discussed at length on the pgsql-hackers mailing list, primarily regarding the "count(*)" aggregate function. To do it in a transactionally up-to-date way requires triggers. If you want it to be automatic, certainly triggers are not for you since it's easier to do an "ANALYZE" than create a trigger. It could also be done with extensive locking.
The main problem is that the behavior you want can't be the default because it would cause performance problems for other applications. And you also say you don't want to do it explicitly.
Can you describe what you're trying to accomplish? Perhaps there is another way.
In particular, "optimizer that needs many hints" is a sign of the power of Oracle.
It's also a weakness. The plans should not be static because your data is not static. That means that when the data set changes, you need to re-optimize.
If they want to charge more for people who have more power, they really should charge per cycle.
But we all know that clock speed is not an accurate measure of processor speed. What they should really do is tie the pricing to benchmark results on Tom's Hardware.
I'll preface this comment by saying that I do not patronize Nike nor buy it's stock.
Neither Inonesia nor Vietnam are known for protecting private property. I think, rather than saying that Nike is exploiting the people of those countries, it would be more accurate to say that their government is oppressing them, and Nike is an accomplice.
If the people are there out of their own free will, that means no better alternatives exist. People who talk about "living wages" often never compare alternatives in the real world. Regardless of what someone arbitrarily declares a "living wage" to be does not mean that those people produce enough to justify such a wage. In other words, assuming that the people are there of their own free will, Nike is helping the people, who have only worse alternatives elsewhere.
However, the people do not really have their own free will there, since the government is oppressing those people. One could make a reasonable argument that Nike is hurting those people by propping up such a government.
We're often left with a difficult choice as a society. If we build industry in countries that oppress their people, we help the people (at least in the short term), and potentially create a more open society. On the flip side, it provides revenue to the government which is oppressive. We're facing this question most vividly in China right now, where the economy is opening but the freedom is not following.
So, I stand by my original point: If the government provides property protection to private citizens (including protection from the government itself), that promotes a robust, successful economy, including all of the infrastructure. And it does it much more quickly, efficiently, and effectively than foreign aid.
You called me a "cheap labor conservative", but that is not what I was even talking about. A lot of foreign investment is not just creating an export industry in the country. Much of that investment will go to local small & medium businesses which trade mostly within the country or with neighboring countries.
Moderation should be used to highlight relevent arguments and information in the discussion, and hide those that are irrelevent or factually incorrect.
Even if an argument is misguided, it's likely that many people hold that viewpoint. In that case, it's better to reply. Ideally, both the misguided argument and the reply would both be highly modded, and a 3rd party would notice both comments. The misguided comment actually presents a context in which you can make a more complete argument.
The first thing that Africa needs is functional governments. One of the most important things that a government can do is provide property protection. If property is protected from theft, extortion, vadalism, excessive taxation, &c., the country becomes a much more desirable target for foreign and domestic investment.
Foreign investment is orders of magnitude larger than foreign aid, and is spent much more efficiently. If we make a 3rd world country slightly more desirable for investment, it will help much more than any amount of aid. It will help everything, including infrastructure.
I understand that MySQL has consistency problems, due to a lack of type checking and so forth. I am not in any way endorsing MySQL.
I meant, does MySQL actually corrupt data so that MySQL itself cannot understand it? I use MySQL when I must, and I'd like to know if there are situations in which MySQL actually corrupts data.
now when you're talking million records or more, then oracle will "hog your resources" to ensure you get lightening quick responses while ensuring data integrity
You're implying that consuming many resources is required to ensure data integrity. It's not. Correct programming is required to ensure data integrity. "Hogging resources" (i.e. allocating lots of memory) is useful for acheiving better performance on a large database.
You also imply that a million records is a large database. It's not, unless of course each record is large. A million records can often fit entirely in RAM.
use MySQL and worry about your tables getting corrupted
Is data corruption on working hardware a real problem for MySQL?
[PostgreSQL's] autovacuum package also sucks ass
Constructive criticism, please. Autovacuum is useful to many people. If there's something about it that can be improved, let us all know.
With the very high clock rates currently in fashion, it is hard (perhaps impossible) to get the clock signal to propagate through the chip before too much of the cycle has elapsed.
Many applications require that write cache is flushed.
In his example, let's say it was a text editor. You change one letter in a document, and save it, it must sycnhronously write the sector to disk, to the actual physical media. Otherwise, if the system crashes, you lose it, and most people don't like that in a text editor.
Write cache at the disk level can be very bad. Databases may have no way of knowing that write cache is enabled, and tell you that your transaction is comitted when it's really not. Of course, battery-backed RAID controllers are safe, but the consumer level disks with write cache enabled can mean trouble.
Slashdot Mirror
I understand your point, but just to play devil's advocate:
Dell must pick someone. I suppose they could offer both chips, but they don't want to confuse their customers, or their tech support personnel. Is whoever Dell picks the monopolist?
These conditions do not prevent a company from making use of any GPL software
I realize that. I like the GPL and I think it's a good license for a lot of software, even some code libraries.
I just think that it is counterintuitive that the licensing for MySQL is similar as if it was embedded in the application you're distributing. Most companies charge for the server and do not charge you to write applications for the server (or some products are always free of charge). MySQL is just the opposite: they give the server away for free and charge for writing applications.
I personally think that is confusing and counterintuitive. I also do not think that MySQL does a good job of clarifying that caveat. That is purely subjective, so I respect your disagreement. However, I think you may have missed my point which is what I'm trying to explain. I do not think it's a "myth" to be concerned about licensing which is counterintuitive to me.
I lose respect for any company that engages in lawsuits like this.
AMD has great products, and they are succeeding in the marketplace. A lawsuit just seems to come from jealousy. Why not spend their efforts competing with better products?
I know everyone is thinking about things like Intel's market control. But AMD is big enough to stand on its own feet and just keep going.
A nice, clear-cut lawsuit that acheives a real remedy can be healthy for a company, and is sometimes very necessary. But this type of litigious behavior can only corrupt. And that will destroy the innovation at AMD.
So you are saying that if I execute "tar -cf /dev/sa0 /boot/kernel-2.6.14-gentoo-r5" and make a copy of the Linux kernel, which is GPL, onto another device, I have to track down all the contributors to the Linux kernel and get permission to do that?
(1) If you are copying files that you already have legally, and you are just incidently copying for basic functionality, it is likely fair use in which case you don't need a license.
(2) The example you gave seemed to be pure GPL. Since you didn't make any derivative work with an incompatible license, I don't see a problem.
(3) Legally speaking, if you copy something (aside from fair use), you need a license. Usually it is prominently displayed. If you are unsure about the license terms you have for a given piece of code, you need to track down the copyright holder and get a license.
Normally this whole process is simple because you just read one file that says "GPL" and it tells you the license for an entire application. Most of the time users merely use the application or perhaps copy it to other computers, and do not create derivative works. For this type of behavior they don't have anything to worry about under the GPL. The GPL is no-hassle when it comes to using and sharing programs.
However, the story is different for developers. Developers, like with any software, need to put themselves in a different frame of mind, about whose code they are using and what licenses that code is under. Developers invariably use code libraries, and for each one they know they need to acquire the correct rights. Let's say they plan to install it on 5 servers and 10 development machines, they need to acquire all 15 licenses for every code library they use developing the application.
The problem is that most people who are writing code that uses a separate database server view themselves as users of that database. If you write code that requires MySQL, you are a MySQL user. However, since the client libraries are GPL, those people are now (legally speaking) MySQL developers, since they are creating a derivative work of the MySQL product. And most people won't realize this until they are told by a MySQL sales rep that they need to pay up.
Of course this is not unique to the GPL. There are a lot of possible licenses for the client libraries that would cause this problem. However, by convention, client libraries are generally licensed under terms that do not create this problem. For example, BSD, LGPL, and many licenses used on the client libraries for commercial database products. MySQL breaks this convention.
If they copy it, they need a license.
Where in the GPL does it permit such copying?
And I'm not saying that it applies to every company. But it does apply to many situations that people may not realize. Most companies at least copy the application a few places around their company, for instance installing on a development machine and then the live server. Perhaps you can try to squeeze that into a legal situation. But it would be very easy to violate that if you aren't careful, which was my point.
Even commercial RDBMSs allow you the ability to link against the client libraries and distribute it. From a logical perspective, most people don't think of linking against client libraries as needing more licenses. But in the case of the GPL, it does. The GPL isn't normally used for client libraries (although it is used for code libraries).
The last time I checked, the overwhelming majority of companies on this planet are not software companies.
But many companies do copy code to one extent or another. If a company has some code under one license (perhaps that they purchased), it is likely incompatible wit the GPL and MySQL could enforce against them.
Making client libraries GPL is uncommon and certainly a caveat of using MySQL. It is not a myth. If you understand the implications and you're OK with it, that's fine.
My whole point is that most RDBMSs don't force you to make all of these sacrifices. If you want FTI you lose transactions (and a lot of other features), what kind of a sacrifice is that? Everyone says that MySQL is easy but to understand all of these tradeoffs is not easy at all.
Why not have MyISAM-table for text queries and link back to the main tables? Would give you an opportunity to choose which fields to add text data from before indexing too.
You could say the same thing about any data in a database at all. Transactions are useful on a table with a FTI just like on any other table.
Let's say that you want to make sure that a full text record does not exist without it's accompanying information (perhaps in a one to many relationship).
A text field doesn't seem at first like the typical bank account example that everyone uses to explain transactions. However, transactions are just as important for any data type.
If your application is designed for MySQL specificially without strict mode, then strict mode is not for you. It is more useful to people porting their applications from some other product to MySQL than to the existing MySQL user base.
But all the other databases seem to have mostly SQL standard syntax AND a large number of applications written for them.
MyISAM was never designed with transactions in mind. It performs its intended function excellently. Not all data is useful to keep in some kind of transaction context - take for example a table mapping UPC codes to product names and descriptions: it will never need to change in a transaction so having transactional overhead would be wasteful.
Yes, transactions are not required for every situation. I never said that they were. My point was that to achieve the advertised performance numbers that MySQL advocates give out, you have to sacrifice transactions. To get the advertised full text indexing you have to sacrifice performance.
Myth used to scare people away from opensource GPL code.
If your application links against the client library, it must adhere to the GPL. This is NOT a myth unless you know of an alternate client library.
MySQL is about choice... You can choose to use it or you can choose to use something else. You can choose to store your data in InnoDB, BerkeleyDB, Cluster, MyISAM, Memory, CSV
"Choices" is positive spin. Some might say that MySQL is all about sacrifices. Here are some examples:
(1) "MySQL has many applications written for it"
* Not if you enable strict mode, or if you use storage engines that don't support the features you need.
(2) "MySQL is optionally SQL compliant with strict mode"
* Only if you want to forego 99% of the existing MySQL applications, and start fresh.
(3) "MySQL has transactions"
* Not in MyISAM, which means no full text indexing.
(4) "MySQL is free"
* Only if your application which links against the client library is also GPL.
(5) "MySQL is fast"
* Only if you use MyISAM, which means no transactions or many other features that aren't available in MyISAM.
I could go on. Anyone can talk about how MySQL has a feature, but you have to make sacrifices for those features. And I think many of those are bad, unnecessary sacrifices. MySQL implements features not to give their users choice, but to give MySQL AB a marketing advantage. Their advocates and salespeople will always say "yes" to all of those features above, but it's not until later that the customer realizes that they can't use the features together.
There are actually many differences. Full-text indexes (FTI) only work with MyISAM, for example.
If you change storage engines, you certainly need to examine all non-trivial MySQL code.
With MySQL, it's often hard to get all the features you want at one time. In the case of full text indexes, you can't also have transactions because only InnoDB has transactions.
can anyone point me somewhere which describes the deliniation of responsibilities between generic MySQL code and the storage engines?
Interesting question. However, MySQL does not completely abstract the storage engine. Different storage engines have different semantics at the higher levels. For instance, MyISAM does not support transactions, while InnoDB does.
My point was that the cat is out of the bag. Until we see the government try some funny stuff, let's not assume they will just because there is some incremental achievement in cryptography.
Why are we speculating here? We've had encryption for a long time now, and it's not going away. If the powers that be don't like this, wouldn't they not like GnuPG?
The poster made the political comment with absolutely no backing at all. I wouldn't be surprised if IBM was not allowed to export this to Iran, but again, nothing new. And you don't have much justification that Clinton would have tried to do anything.
How is that self-serving? I really have no interest in helping Nike.
And in economics, comparisons must be made. If Nike pays its workers more, it will employ fewer of them. So now you have some people making $4/day and some people standing in the unemployment line.
The main villian here is the governments in those countries that don't allow enough freedom and don't protect property. You might say Nike is an accomplice, since they probably need to bribe government officials constantly to be able to operate in those countries.
It's possible that he's using temp tables just to temporarily materialize a query result as part of a sequence of operations on the data. It's much better to use a view in that case, and PostgreSQL will optimize it to avoid uneccessary disk I/O.
And if he is using temp tables, it's still not obvious to me why they need to be vacuumed or analyzed.
Vacuum doesn't make too much sense for reporting, since there isn't any reason to have deletes/updates (at least no reason obvious to me). And analyze basically has two purposes: to allow PG to make a better plan, or if you want to use those statistics directly.
If you want the statistics to help make a better plan, that means PG needs to have several plans available. Perhaps if you're doing lots of joins, that may help. But the general use case for a temp table has just one option: sequential scan.
If you want to use the statistics directly, it seems to me better to just use aggregate functions. "ANALYZE" needs to scan the whole relation anyway, so why not use a precise query that gets exactly the information you want rather than whatever ANALYZE happened to collect?
You may have heard that PostgreSQL always needs to VACUUM/ANALYZE to be effective. That's partially true, but I think your temp tables may be a special case and not need VACUUM/ANALYZE at all.
There are a few issues here.
First, do you want the statistics because PostgreSQL is choosing a bad plan without them, or do you use the statistics directly?
I'm having a little trouble understanding exactly what you want. It sounds like maybe you want something other than an elapsed time to trigger autovacuum on that one temp table so that the statistics are updated. But really, if there is any time lapse at all it seems like your application could not rely on the numbers without doing an explicit "ANALYZE" or "VACUUM ANALYZE".
Perhaps what you're looking for is up-to-date statistics of some kind. This has been discussed at length on the pgsql-hackers mailing list, primarily regarding the "count(*)" aggregate function. To do it in a transactionally up-to-date way requires triggers. If you want it to be automatic, certainly triggers are not for you since it's easier to do an "ANALYZE" than create a trigger. It could also be done with extensive locking.
The main problem is that the behavior you want can't be the default because it would cause performance problems for other applications. And you also say you don't want to do it explicitly.
Can you describe what you're trying to accomplish? Perhaps there is another way.
In particular, "optimizer that needs many hints" is a sign of the power of Oracle.
It's also a weakness. The plans should not be static because your data is not static. That means that when the data set changes, you need to re-optimize.
If they want to charge more for people who have more power, they really should charge per cycle.
But we all know that clock speed is not an accurate measure of processor speed. What they should really do is tie the pricing to benchmark results on Tom's Hardware.
I'll preface this comment by saying that I do not patronize Nike nor buy it's stock.
Neither Inonesia nor Vietnam are known for protecting private property. I think, rather than saying that Nike is exploiting the people of those countries, it would be more accurate to say that their government is oppressing them, and Nike is an accomplice.
If the people are there out of their own free will, that means no better alternatives exist. People who talk about "living wages" often never compare alternatives in the real world. Regardless of what someone arbitrarily declares a "living wage" to be does not mean that those people produce enough to justify such a wage. In other words, assuming that the people are there of their own free will, Nike is helping the people, who have only worse alternatives elsewhere.
However, the people do not really have their own free will there, since the government is oppressing those people. One could make a reasonable argument that Nike is hurting those people by propping up such a government.
We're often left with a difficult choice as a society. If we build industry in countries that oppress their people, we help the people (at least in the short term), and potentially create a more open society. On the flip side, it provides revenue to the government which is oppressive. We're facing this question most vividly in China right now, where the economy is opening but the freedom is not following.
So, I stand by my original point: If the government provides property protection to private citizens (including protection from the government itself), that promotes a robust, successful economy, including all of the infrastructure. And it does it much more quickly, efficiently, and effectively than foreign aid.
You called me a "cheap labor conservative", but that is not what I was even talking about. A lot of foreign investment is not just creating an export industry in the country. Much of that investment will go to local small & medium businesses which trade mostly within the country or with neighboring countries.
I disagree.
Moderation should be used to highlight relevent arguments and information in the discussion, and hide those that are irrelevent or factually incorrect.
Even if an argument is misguided, it's likely that many people hold that viewpoint. In that case, it's better to reply. Ideally, both the misguided argument and the reply would both be highly modded, and a 3rd party would notice both comments. The misguided comment actually presents a context in which you can make a more complete argument.
The first thing that Africa needs is functional governments. One of the most important things that a government can do is provide property protection. If property is protected from theft, extortion, vadalism, excessive taxation, &c., the country becomes a much more desirable target for foreign and domestic investment.
Foreign investment is orders of magnitude larger than foreign aid, and is spent much more efficiently. If we make a 3rd world country slightly more desirable for investment, it will help much more than any amount of aid. It will help everything, including infrastructure.
I understand that MySQL has consistency problems, due to a lack of type checking and so forth. I am not in any way endorsing MySQL.
I meant, does MySQL actually corrupt data so that MySQL itself cannot understand it? I use MySQL when I must, and I'd like to know if there are situations in which MySQL actually corrupts data.
now when you're talking million records or more, then oracle will "hog your resources" to ensure you get lightening quick responses while ensuring data integrity
You're implying that consuming many resources is required to ensure data integrity. It's not. Correct programming is required to ensure data integrity. "Hogging resources" (i.e. allocating lots of memory) is useful for acheiving better performance on a large database.
You also imply that a million records is a large database. It's not, unless of course each record is large. A million records can often fit entirely in RAM.
use MySQL and worry about your tables getting corrupted
Is data corruption on working hardware a real problem for MySQL?
[PostgreSQL's] autovacuum package also sucks ass
Constructive criticism, please. Autovacuum is useful to many people. If there's something about it that can be improved, let us all know.
With the very high clock rates currently in fashion, it is hard (perhaps impossible) to get the clock signal to propagate through the chip before too much of the cycle has elapsed.
Then how does it work?
Many applications require that write cache is flushed.
In his example, let's say it was a text editor. You change one letter in a document, and save it, it must sycnhronously write the sector to disk, to the actual physical media. Otherwise, if the system crashes, you lose it, and most people don't like that in a text editor.
Write cache at the disk level can be very bad. Databases may have no way of knowing that write cache is enabled, and tell you that your transaction is comitted when it's really not. Of course, battery-backed RAID controllers are safe, but the consumer level disks with write cache enabled can mean trouble.