Just the mere fact that you need to be aware that you're backing up a specific RDBMS makes it more complicated than backing up your photo collection.
It's not tricky as some problems, but if you don't read the manual, you're probably not going to get it right. And most people don't read the manual, so I tell them it's tricky so that they are aware that they might not be safe. If they care, then they usually would rather pay a high hourly rate than read the manual.
Replication is essentially mirroring, but via the database instead of on the disk/controller level.
"Replication" simply means that you keep two copies of the same data somewhere, somehow. There are many different ways to do this, and there are many reasons you might want to do this.
That's why replication is not a "checkbox" kind of feature. It's a set of many features, and to choose the right combination (that is, to make the right trade-offs), you need to look at the system as a whole.
These people were doing one kind of replication -- mirroring at the physical level. That did not guard them against overwrites at all (whether malicious, programmer error, or administrator error).
It's not, however, public education that's the problem.
If public "education" passes illiterate people along until they end up with a diploma, then yes, it is a problem with public education.
If you graduate from the 6th grade, that should mean something. If you can't do it, you should be held back and given the opportunity to make it up. If you're violent you give up the opportunity and you get kicked out of regular school.
Education is not expensive. Babysitting, dealing with thugs and coddling apathy are expensive.
Why do you say that? Making an effective release of any platform is no easy task.
It seems easy with the exponential growth that Rails saw in the past, because you don't have to care about the existing users. Just break everything, whenever you want, there are plenty of new users. You don't care if a library has bugs in it, because users are starting from scratch, so they'll just be happy it does anything at all.
Now, with adoption growing at some more reasonable pace, they'll need to satisfy existing users. If they don't, nobody will use the new version, and the old version will stick around. Then they have to maintain two frameworks, and they have a mess. Half the libraries work on the old version and are broken on the new version, and vice versa.
I'm not saying they can't do it. It may go just fine, and I hope it does. But if you only see the benefits, and you don't see the costs (or dangers), you are better off blind.
If you have difficulty imagining a bad release and its impact on a project, look at MySQL and the 5.1 "GA" release. Or Vista.
by no means should this even remotely count towards conviction as that mosquito could have come from almost anywhere
Huh? It's called "circumstantial evidence".
1. Car was stolen. 2. They identified someone who was not the owner, and associated him with the car.
There could be a million completely reasonable stories about how it arrived there, so it's not "proof beyond a reasonable doubt". However, it is real evidence, and the jury can weigh it along with everything else.
Similarly, if you find a murder weapon in someone's car, they might not have done it. Maybe they are being framed. Maybe it was stolen, used, and put back. However, that's for the jury to sort out.
What is the business case where one may justify using MySQL and paying for it?
Someone writes an industry-specific application, and they don't know much or care much about databases. A business needs an industry-specific application, and there's not much competition around, so they pick the MySQL-backed app.
Neither company cares about the $500 price tag (or whatever it is) for MySQL, so they just buy it. It may or may not be necessary, depending on how the app is packaged and distributed, but it's close enough, and they probably like the idea of support anyway.
I am in no way advocating this situation. The purchaser of the app probably does care very much about their data, and will have problems with an app written by people who know nothing about data management.
If you don't see the advantages of centralized data management, you probably have never needed to get the answer to an interesting business question before.
Developers are usually only interested in pushing data into a database, or perhaps regurgitating it later. But the data is being stored for a reason: so that business people can make useful inferences from the facts collected throughout the enterprise.
Until schools start offering Software Engineering majors, people that see themselves as programmers will invariably end up in CS majors, wondering how any of their classes are going to help them code a game, or design a piece of enterprise software.
Those people are looking for vocational school, and end up at a university.
The reason is mostly due to social status. Graduating from a university carries a higher social status than graduating from a vocational school. But is that any reason to turn a university into a vocational school and keep calling it a university?
Teaching a functional language to somebody without any experience of imperative constructs may turn out to be easier.
That may be true. However, I suspect that it's still better to learn an imperative language first.
You go through the experience of imperative programming, and seeing a variety of OOP languages. Right when you think you know everything, then you get hit with a functional language.
I think that process may be better than learning functional programming first, and then realizing that most professional (and amateur) programming is imperative. In that case, you're likely to be disillusioned with functional programming, and forget it.
Strange that you say that, because I've always considered most human directions to be far more declarative than imperative.
For instance, "go to the store and buy milk". If you were to try to reduce that to imperative instructions, it would be a nightmare. In fact, nobody has done it, because it's so hard to describe in terms of the myriad possible states and branches.
Along the way, you do all kinds of optimization, too. If there's traffic on the main street, you might take side streets. If one checkout line is longer, you might choose the shorter one. If one brand is on sale, you might buy that one.
I would like to point out that the current release is not something that can be said to be fault of Sun. The decisions to do a GA release was solely been made by the MySQL management in Sun. The only thing Sun can be blamed of is to not start fixing the MySQL development organization soon enough to ensure that things like this can't happen.
What should Sun have done to make this release better? By the time Sun purchased MySQL, it was already way behind the release schedule, and had serious problems. Should they have delayed it further and made it a 5-year gap between GA releases?
Also, releasing with known bugs is a known problem for MySQL anyway. The only reason it's news now is because:
* They took 3 years to do a release, over a year in RC phase, and it's still got major problems.
* People can't believe that MySQL still hasn't stabilized their product.
I fail to see why I must buy Christmas junk to support those who don't.
I still fail to see how consumption is good for the economy. I have read more than a couple economic books, and I'm familiar with some of Keynes' ideas.
The only thing even close that sounds plausible to me is that high consumer spending provides a temporary boost to the economy with higher long-term costs.
Quite simply, if you can produce $1M worth of consumer goods or $1M worth of capital (i.e. tractors or something), won't it always be best for the economy in the long term to produce the capital (assuming people aren't starving or something)? The capital sticks around, and can be used to produce more consumer goods in the future, whereas consumer goods just get used and now they're gone.
It is quite likely that the people who jump all over proprietary software that has a poor quality release are not the same people as the one's who are defending MySQL
A very valid point.
If I try MySQL and it chokes on my database, all I am out is my time.
And someone's data.
Not only that, it's the deception involved. They are calling it GA when it's anything but.
It's like if you ask me for directions, and I send you in the wrong direction and make it sound like I know what I'm talking about. You would probably begin to have a low opinion of me when you are even more hopelessly lost and maybe out of gas. But hey, it's free!
Instead of cursing every product with which a writer has had bad experiences, the key to reducing grief is to remain aware of the likely risks and rewards of each approach.
We can be as relativistic as we want, as though every system is a snowflake with it's own beauty, but in the real world, sometimes value judgments are useful.
For instance, if you design a truck and I design a car, we can both respect each others' designs, and differ on opinion. You might prefer towing capacity, and market that benefit to construction workers and farmers. I might market the fuel economy and handling to commuters.
If someone designs a car that sometimes explodes when it rains and the steering wheel in the trunk, it's a bad design, period.
What happens if KDE crashes and burns? You revert to a working version, or pick up some other desktop environment. If you're a novice, maybe you are in trouble. A desktop carries very little state -- and even less important state -- so switching back and forth doesn't cost much.
The costs of the scary problems Monty mentions could be arbitrarily high. If you lose data, or an application goes down, or you produce a wrong result and then base a decision on that wrong result, that can be very expensive.
Slashdot Mirror
Just the mere fact that you need to be aware that you're backing up a specific RDBMS makes it more complicated than backing up your photo collection.
It's not tricky as some problems, but if you don't read the manual, you're probably not going to get it right. And most people don't read the manual, so I tell them it's tricky so that they are aware that they might not be safe. If they care, then they usually would rather pay a high hourly rate than read the manual.
Replication is essentially mirroring, but via the database instead of on the disk/controller level.
"Replication" simply means that you keep two copies of the same data somewhere, somehow. There are many different ways to do this, and there are many reasons you might want to do this.
That's why replication is not a "checkbox" kind of feature. It's a set of many features, and to choose the right combination (that is, to make the right trade-offs), you need to look at the system as a whole.
These people were doing one kind of replication -- mirroring at the physical level. That did not guard them against overwrites at all (whether malicious, programmer error, or administrator error).
It's not, however, public education that's the problem.
If public "education" passes illiterate people along until they end up with a diploma, then yes, it is a problem with public education.
If you graduate from the 6th grade, that should mean something. If you can't do it, you should be held back and given the opportunity to make it up. If you're violent you give up the opportunity and you get kicked out of regular school.
Education is not expensive. Babysitting, dealing with thugs and coddling apathy are expensive.
Why do you say that? Making an effective release of any platform is no easy task.
It seems easy with the exponential growth that Rails saw in the past, because you don't have to care about the existing users. Just break everything, whenever you want, there are plenty of new users. You don't care if a library has bugs in it, because users are starting from scratch, so they'll just be happy it does anything at all.
Now, with adoption growing at some more reasonable pace, they'll need to satisfy existing users. If they don't, nobody will use the new version, and the old version will stick around. Then they have to maintain two frameworks, and they have a mess. Half the libraries work on the old version and are broken on the new version, and vice versa.
I'm not saying they can't do it. It may go just fine, and I hope it does. But if you only see the benefits, and you don't see the costs (or dangers), you are better off blind.
If you have difficulty imagining a bad release and its impact on a project, look at MySQL and the 5.1 "GA" release. Or Vista.
by no means should this even remotely count towards conviction as that mosquito could have come from almost anywhere
Huh? It's called "circumstantial evidence".
1. Car was stolen.
2. They identified someone who was not the owner, and associated him with the car.
There could be a million completely reasonable stories about how it arrived there, so it's not "proof beyond a reasonable doubt". However, it is real evidence, and the jury can weigh it along with everything else.
Similarly, if you find a murder weapon in someone's car, they might not have done it. Maybe they are being framed. Maybe it was stolen, used, and put back. However, that's for the jury to sort out.
What is the business case where one may justify using MySQL and paying for it?
Someone writes an industry-specific application, and they don't know much or care much about databases. A business needs an industry-specific application, and there's not much competition around, so they pick the MySQL-backed app.
Neither company cares about the $500 price tag (or whatever it is) for MySQL, so they just buy it. It may or may not be necessary, depending on how the app is packaged and distributed, but it's close enough, and they probably like the idea of support anyway.
I am in no way advocating this situation. The purchaser of the app probably does care very much about their data, and will have problems with an app written by people who know nothing about data management.
That was probably a joke. But I have had to report out of both Access and MySQL databases, and Access was much better.
The SQL dialect in Access is more consistent, closer to the standard, and richer than MySQL's SQL dialect.
Access is slow, and annoying in some other ways, and certainly would not be my first choice, but I would not rule it out.
If you don't see the advantages of centralized data management, you probably have never needed to get the answer to an interesting business question before.
Developers are usually only interested in pushing data into a database, or perhaps regurgitating it later. But the data is being stored for a reason: so that business people can make useful inferences from the facts collected throughout the enterprise.
Until schools start offering Software Engineering majors, people that see themselves as programmers will invariably end up in CS majors, wondering how any of their classes are going to help them code a game, or design a piece of enterprise software.
Those people are looking for vocational school, and end up at a university.
The reason is mostly due to social status. Graduating from a university carries a higher social status than graduating from a vocational school. But is that any reason to turn a university into a vocational school and keep calling it a university?
Teaching a functional language to somebody without any experience of imperative constructs may turn out to be easier.
That may be true. However, I suspect that it's still better to learn an imperative language first.
You go through the experience of imperative programming, and seeing a variety of OOP languages. Right when you think you know everything, then you get hit with a functional language.
I think that process may be better than learning functional programming first, and then realizing that most professional (and amateur) programming is imperative. In that case, you're likely to be disillusioned with functional programming, and forget it.
Strange that you say that, because I've always considered most human directions to be far more declarative than imperative.
For instance, "go to the store and buy milk". If you were to try to reduce that to imperative instructions, it would be a nightmare. In fact, nobody has done it, because it's so hard to describe in terms of the myriad possible states and branches.
Along the way, you do all kinds of optimization, too. If there's traffic on the main street, you might take side streets. If one checkout line is longer, you might choose the shorter one. If one brand is on sale, you might buy that one.
We should not punish Open Source for being Open Source.
But we should criticize it when they unleash bugs onto an unsuspecting public by mislabeling it "GA".
You're way off base. Here's what Monty said:
What should Sun have done to make this release better? By the time Sun purchased MySQL, it was already way behind the release schedule, and had serious problems. Should they have delayed it further and made it a 5-year gap between GA releases?
Also, releasing with known bugs is a known problem for MySQL anyway. The only reason it's news now is because:
* They took 3 years to do a release, over a year in RC phase, and it's still got major problems.
* People can't believe that MySQL still hasn't stabilized their product.
Some projects have a better reputation than others -- but I agree. If it doesn't actually work yet, call it an alpha, or don't release at all.
Then question how the GDP number was arrived at, not the usefulness of the GDP metric itself.
When it's so easy to game the numbers, why not redefine the numbers?
Because the original numbers are valuable metrics, even if imperfect.
If you want to come up with a new metric, don't use a word that already has a precise meaning. It's flat-out deceptive.
I fail to see why I must buy Christmas junk to support those who don't.
I still fail to see how consumption is good for the economy. I have read more than a couple economic books, and I'm familiar with some of Keynes' ideas.
The only thing even close that sounds plausible to me is that high consumer spending provides a temporary boost to the economy with higher long-term costs.
Quite simply, if you can produce $1M worth of consumer goods or $1M worth of capital (i.e. tractors or something), won't it always be best for the economy in the long term to produce the capital (assuming people aren't starving or something)? The capital sticks around, and can be used to produce more consumer goods in the future, whereas consumer goods just get used and now they're gone.
And every time the word recession was asked far beyond a year ago, the only answer was "not yet" and they kept hoping things would get better.
If you read the article, you'll see that the authors concluded that we've been in a recession by redefining the word "recession".
They aren't looking at new, better data; and they don't have any new, amazing insight. They are just looser with their terms of doom and gloom.
It is quite likely that the people who jump all over proprietary software that has a poor quality release are not the same people as the one's who are defending MySQL
A very valid point.
If I try MySQL and it chokes on my database, all I am out is my time.
And someone's data.
Not only that, it's the deception involved. They are calling it GA when it's anything but.
It's like if you ask me for directions, and I send you in the wrong direction and make it sound like I know what I'm talking about. You would probably begin to have a low opinion of me when you are even more hopelessly lost and maybe out of gas. But hey, it's free!
Instead of cursing every product with which a writer has had bad experiences, the key to reducing grief is to remain aware of the likely risks and rewards of each approach.
We can be as relativistic as we want, as though every system is a snowflake with it's own beauty, but in the real world, sometimes value judgments are useful.
For instance, if you design a truck and I design a car, we can both respect each others' designs, and differ on opinion. You might prefer towing capacity, and market that benefit to construction workers and farmers. I might market the fuel economy and handling to commuters.
If someone designs a car that sometimes explodes when it rains and the steering wheel in the trunk, it's a bad design, period.
You're comparing a GUI desktop to a DBMS.
What happens if KDE crashes and burns? You revert to a working version, or pick up some other desktop environment. If you're a novice, maybe you are in trouble. A desktop carries very little state -- and even less important state -- so switching back and forth doesn't cost much.
The costs of the scary problems Monty mentions could be arbitrarily high. If you lose data, or an application goes down, or you produce a wrong result and then base a decision on that wrong result, that can be very expensive.
I think the difference is that a lot of open source projects operate on a release-early-release-often philosophy
Huh? This took MySQL 3 years. Over one year in RC stage alone.
And, yet, it still has major bugs.
With Postgres, it took me upwards of 20 minutes when it should have taken much less time.
If you mention the issue, who knows? Maybe it will be fixed.
Usability or documentation issues are not always obvious to the developers...
When partitioning and master/master replication fully arrive it will be an incredible option.
By arrive do you mean "GA" or "actually works"?
As Ryan said there is no such thing as bug free software...
Some of the bugs in Monty's list are pretty scary.
Your standards for a DBMS are different than mine.