I still read the site every so often, but it's gone from one of my main sites that I read religiously to one that I forget about for a week or two.
The level of the articles don't even warrant skimming the summary in most cases, let alone reading the comments or actually commenting myself. Part of it is that my interests have diverged and part of it is that Slashdot has seriously lost any edge it ever had.
I can see why they feel the need to freshen up the design -- and it's not like it's ever been strong on a design front -- but the beta is atrocious and once I can't avoid it I doubt I'll ever be back. Slashdot may have outlasted Digg but I suspect it will share the same fate.
From what I've read (including BengalsUF's comments, which seem to be the only authoritative source for the case), it sounds to me like Mr. Childs was taking extreme security precautions.
It's been mentioned several times that the network devices were configured to not store their configs in NVRAM or to wipe the configs if password recovery was used. I personally think that is a bit much, but I could see people I've worked with over the years arguing for this in order to prevent the configs from being retrieved by an attacker (and then analyzed and used to attack the rest of the network).
So once you've gone that far, you have to have a way to legitimately store and reload the configs when the inevitable failure occurs or an update is required. But if you just put the configs in CVS somewhere, then that becomes the security hole people can attack. So encrypting them and requiring multi-factor authentication to access makes a certain amount of sense.
As I said, I think it's going a bit far, but if you really really really want to ensure security of a critical piece of infrastructure, that's one way to do it. The way Mr. Childs went about it didn't scale beyond him (another common failing in small environments where the team size = 1), and maybe was too limiting to really be practical, but I don't necessarily think it equates to a matter of ensuring job security as has been claimed.
Video games aren't like other forms of entertainment. Paul McCartney's old albums are regularly updated for new mediums (tapes, CDs, etc.) and are fundamentally comparable to new albums made today minus some audible differences in production.
A video game made in 1988 may still be great, but there are much higher barriers to it finding a modern audience:
1. It may be difficult to run on modern systems (or at least require a level of knowledge -- e.g. what is ScummVM -- that makes it harder to access than a modern game for the uninitiated).
2. It may be so dated from a graphics, interface, or gameplay mechanics perspective that someone coming to it fresh will not enjoy it.
3. It may not even be possible to legally acquire; unlike movies and music, where old releases are often available alongside new releases, old games disappear from shelves.
Sure, there are exceptions. GOG.com, ScummVM, buying something on Ebay. But you have to already have an interest in exploring or revisiting older games.
Game designers are celebrities within their field, not within society. Paul McCartney is a celebrity because of his musical contributions, but he also is immediately recognizable to millions of people who may have never heard his music. Richard Garriott is a celebrity only to people who know his work -- which, as mentioned, has not continued to be relevant in recent gaming history.
And that in a nutshell is why someone as important to early gaming history as Richard Garriott was may not roll off the tip of someone's tongue today.
He also hasn't made a noteable game since 1997 (or 1999 if you consider Ultima IX noteable), at best 11 years ago. While I instantly know who Lord British is, he is far from a household name to someone who was 3 when Ultima Online launched.
I think it's conceivable that the world's population could have its quality of life raised across the board so that there are not people living in abject poverty who are literally starving to death, although it would be quite difficult and especially problematic to do so without causing the abject poor and working poor to effectively combine (meaning a reduction in quality of life for those presently at the low end of the scale but above the very bottom).
However, raising the quality of life so that literally no one has anything to lose (as you put it) doesn't seem practical. If everyone is a millionaire, then that will be the new poverty as the value of things will adjust accordingly based on their scarcity as already happens.
Put another way, someone will always have more than you in one way or another. More possessions, more political power, more social influence. If you feel that this is unbearable (as in someone who is legally permitted to obtain an abortion) or that you have no power to change this within the system (as with a tyrant suppressing political freedom) then people of a particular disposition will gravitate towards terrorism as a means to achieve their goals. Not to mention those who possess a strong enough dislike for another group of people based on religion, ethnicity, or other factors that their mere existence is offensive to you, which is even more difficult to solve as there is no middle ground.
Your records belong to you. You can request them (and depending on the hospital / doctor's office, they may claim you can only receive copies or that they will only send them directly to your new healthcare provider) at any time and take them with you.
The long and short of it is that a lot of these devices have pretty poor performance, and can get away with it because they're used on 1.5mbps lines. However, there are some out there that are decent.
Of course, there's the build-it-yourself approach with m0n0wall or pfSense or something else. With a spare PC laying around you'll likely get reasonable performance, although electricity usage is quite a bit higher than an appliance.
I agree that all of those things could be of value, but I still contend that even if someone was willing, the average employee doesn't have access to that kind of data.
It's not so much that I don't believe ANYONE would steal from their former employers but that EVERYONE would do so as the article is practically saying (50% is absurdly high).
I'm sure that some people do try to profit from illicitly obtained information from their past employers; I've heard a few stories here and there about people getting busted. But there is simply no way that 50% of everyone in the workforce is doing this for a few simple reasons:
1. Risk - I think everyone is aware that the damage to your career and professional reputation would be catastrophic if you were caught, not to mention the legal ramifications.
2. Ethics - Yes, people do have them. Maybe not everyone is the pinnacle of ethical behavior, but that doesn't mean every other person you see at the office is just waiting to mug you and steal your wallet in the parking lot.
3. Nothing to steal - The majority of employees just don't have access to proprietary information that is actually of value outside the company. Sure, I could tell a future employer about my company's HR policies or give them an org chart. That might be very slightly useful, but certainly isn't going to get me hired or land me millions. I could also give them all of the company's internally developed code, but it would be of little use without all of the institutional knowledge, expertise and essentially the entire original company to go along with it.
4. Employers are liable as well - Take the case of the people who tried to sell some of Coke's trade secrets to Pepsi. They were refused, and Pepsi informed the police. They know that they would be liable for the illegal behavior as well, and want no part of it. Now not every employer operates above board, but it's a risky game to try to sell information to someone who may not even want to buy it.
I was under the impression that the bridge had to go through Yerba Buena not to serve the island population (who are only there because the bridge makes it convenient I imagine), but because the bay is too deep and without a firm bedrock to otherwise locate the middle section of the bridge securely.
Possibly that was only a concern when it was originally built, but regardless, you would essentially need to route it in the same path as otherwise you'd need a new landing point on the Oakland side and there's Alameda in the way.
There are four bridges running east/west over the bay, it just happens that there is only one in this particular (useful) location. Also, given that the Bay Bridge has to connect to Yerba Buena island, there's not really a lot of room for another one right next to it. So there is redundancy, but you have to deal with the physical realities of the area.
That's a completely valid option, but I'm leery of MySQL replication due to prior experiences. When it works it's fine, it just has a few issues that I've had crop up. Keep in mind, if your official backup copy is coming from the slave, you have to make absolutely sure that the data is really in sync and up-to-date.
That means using tools like mk-table-checksum and mk-heartbeat from Maatkit. If you're not using them (or comparable things), then your data could be silently corrupted or out of date which would invalidate your backup. Note that seconds_behind_master from MySQL is kind of a joke for verifying that your slave is up-to-date.
My other beef with MySQL slaves is that they, by design, can only write in a single thread whereas the master can use all of its cores to do this. So even with two identical systems, the master may be fine at load and the slave may totally choke. People also have a habit of purchasing underpowered slaves, because "they don't do anything", forgetting that they still do 100% of the write load from the master, even if nothing else uses the host. Buying larger hardware just to keep up with the master for a once-an-hour backup feels dirty to me, but it is what it is.
Yes, but as I mentioned, this is not necessary specifically only with InnoDB. Because it writes to disk atomically, you will get a valid point-in-time copy of the database simply by taking a filesystem snapshot; no read lock required, which means the application can continue operating from the user's perspective.
The problem with a read lock is that, if done on a master DB, you will impact the production service that uses the database. Depending on the workload, this could take a minute or even longer, which is usually not acceptable.
However, there's another problem: MySQL performance degrades significantly on LVM when a snapshot is active. So even though the database continues operating as usual, performance will not be the same (and perhaps not at all adequate) during the backup period -- especially considering that you're doing extra disk I/O to get the data copied off.
So, I prefer to use xtrabackup these days. This presumes that you have no MyISAM tables though; otherwise you're back to mysqldump or taking a read lock or some other less desirable method.
One other point: if you backup with filesystem snapshots (of the raw DB files), then you have to restore the entire database during a restore. Maybe this is fine and maybe it's a huge headache.
There are a million ways to backup MySQL (and other DB's), and it really comes down to what kind of downtime you can tolerate during your backup. I generally want to back up very frequently, without impacting the service, and avoiding replication (and all of the headaches involved in that -- see the existence of tools like mk-table-sync for an idea of what can go wrong) if possible. If you don't have those requirements, then mysqldump or mylvmbackup or something else are totally valid options.
That is actually the accepted practice for backing up InnoDB databases with MySQL. Of course, you take a filesystem snapshot to get a point-in-time in-use copy of the database files; backing up the real filesystem wouldn't work due to the time shift of the data while you're backing up.
You do have to recover the files upon restoration (I would usually run the recover after the backup finished, since time is of the essence when you need to do a restore), but by not having to take a read lock or halt MySQL, you avoid a service interruption or having to replicate out your data just to backup (which could be problematic in itself, what if the slave server is not in sync?).
Of course, this works because of the way that storage engine functions on disk. You can't do this with MyISAM tables or you'll be in a world of hurt. There are also online backup tools readily available, which are the superior solution now in my opinion.
They would have to perform an act with the express intent of causing terror and fear in the general populace, also typically involving idealogical goals (check) and targeting civilians with violence (not check).
I don't think that knocking down a single AM radio tower qualifies, although it is certainly vandalism, destruction of property and other things.
I mean, if I destroyed everyone's wifi devices in my building with a hammer, I'm crazy and have destroyed property in a criminal manner. But am I a terrorist?
I also prefer organic milk for different reasons (I think it tastes better, and it's expiration date is usually way further out than regular), although I suspect the main differentiator may be that organic milk is almost always ultra-pasteurized as opposed to regular pasteurization which is the norm for regular milk.
Bugatti Automobiles SAS is a subsidiary of Volkswagen, and is actually a new company founded in 2000. As far as I'm aware, none of the former Bugatti companies were ever associated with GM; even if they were, a subsidiary can certainly make cars distinct from its parent company if the corporate structure permits.
Yeah, I'm not sure what this particular site requires. I do know from prior professional experience that the 'second site' was always a very tough sell (and actually, of the places I've worked, only Yahoo was good about that sort of thing).
It's more than just the hardware too, it's the processes in place to ensure that there are very seriously no dependencies on one site. For instance, maybe you deploy everything simultaneously to both sites, you buy equal hardware in both places, you do BCP failover tests regularly to ensure the second site works as expected, and so forth.
But where do you build new packages? Where is your source control repository? Not being able to use your normal workflow can be almost as bad as a public outage, and can lead to one as well.
In this case, maybe the guy could just slap something together, but even so the amount of effort to do what you're talking about would probably take a few days to iron out. You lose a lot of time right off the bat just figuring out what happened and whether or not you are going to be seeing your equipment again anytime soon. Plus some things are just out of your control; getting a DSL or cable hookup with a static IP, if you didn't already have one, can literally take weeks.
A lot of places are not prepared for a complete site loss. They may be very redundant within the site, with multiple hosts and backups and redundant power / AC / networking, but not have a single piece of equipment not located at that colocation center.
Consider that even if they did have off-site backups (which are really the bare minimum, although a lot of small operations overlook it anyway), they probably don't physically possess any equipment to run it on or have an agreement with another colocation center to put that equipment in.
So right now they need to put an order in with Dell and Cisco and whoever to get duplicate equipment (that they probably don't have a budget for), find another colo on short notice, wait for the equipment to arrive (1-2 weeks), do the physical installation work, and then restore all of their systems types from backups that may or may not represent the complete bare metal system image.
Most disaster recovery plans only account for disasters within a finite period of time (the power goes out for a few hours) or for partial losses (you lose 2 of 4 web servers), because redundancy is the most expensive part of any computer deployment.
Re:Selling an open-source software business?
on
Locating the Real MySQL
·
· Score: 4, Informative
For the database server itself, there is no difference between MySQL Community Edition and MySQL Enterprise Edition besides the release schedule. The community edition (aka the regular one everyone uses) has been pared down to 4 releases a year, which are cherry picked from the enterprise releases.
However, the source is completely available for the enterprise releases, and you are able to compile and install them yourself. This is what Percona is doing, for instance (plus some other patches).
With that said, MySQL has other software that comes along with the enterprise edition that is not open sourced to my knowledge. A query analyzer, monitoring, and other goodies. Personally I prefer to find their equivalents in the open source world, but I'm sure some people buy and use these packages.
Slashdot Mirror
I still read the site every so often, but it's gone from one of my main sites that I read religiously to one that I forget about for a week or two.
The level of the articles don't even warrant skimming the summary in most cases, let alone reading the comments or actually commenting myself. Part of it is that my interests have diverged and part of it is that Slashdot has seriously lost any edge it ever had.
I can see why they feel the need to freshen up the design -- and it's not like it's ever been strong on a design front -- but the beta is atrocious and once I can't avoid it I doubt I'll ever be back. Slashdot may have outlasted Digg but I suspect it will share the same fate.
That's correct, only two digits are left. Also I never post anymore and barely read the site anymore.
From what I've read (including BengalsUF's comments, which seem to be the only authoritative source for the case), it sounds to me like Mr. Childs was taking extreme security precautions.
It's been mentioned several times that the network devices were configured to not store their configs in NVRAM or to wipe the configs if password recovery was used. I personally think that is a bit much, but I could see people I've worked with over the years arguing for this in order to prevent the configs from being retrieved by an attacker (and then analyzed and used to attack the rest of the network).
So once you've gone that far, you have to have a way to legitimately store and reload the configs when the inevitable failure occurs or an update is required. But if you just put the configs in CVS somewhere, then that becomes the security hole people can attack. So encrypting them and requiring multi-factor authentication to access makes a certain amount of sense.
As I said, I think it's going a bit far, but if you really really really want to ensure security of a critical piece of infrastructure, that's one way to do it. The way Mr. Childs went about it didn't scale beyond him (another common failing in small environments where the team size = 1), and maybe was too limiting to really be practical, but I don't necessarily think it equates to a matter of ensuring job security as has been claimed.
Video games aren't like other forms of entertainment. Paul McCartney's old albums are regularly updated for new mediums (tapes, CDs, etc.) and are fundamentally comparable to new albums made today minus some audible differences in production.
A video game made in 1988 may still be great, but there are much higher barriers to it finding a modern audience:
1. It may be difficult to run on modern systems (or at least require a level of knowledge -- e.g. what is ScummVM -- that makes it harder to access than a modern game for the uninitiated).
2. It may be so dated from a graphics, interface, or gameplay mechanics perspective that someone coming to it fresh will not enjoy it.
3. It may not even be possible to legally acquire; unlike movies and music, where old releases are often available alongside new releases, old games disappear from shelves.
Sure, there are exceptions. GOG.com, ScummVM, buying something on Ebay. But you have to already have an interest in exploring or revisiting older games.
Game designers are celebrities within their field, not within society. Paul McCartney is a celebrity because of his musical contributions, but he also is immediately recognizable to millions of people who may have never heard his music. Richard Garriott is a celebrity only to people who know his work -- which, as mentioned, has not continued to be relevant in recent gaming history.
And that in a nutshell is why someone as important to early gaming history as Richard Garriott was may not roll off the tip of someone's tongue today.
He also hasn't made a noteable game since 1997 (or 1999 if you consider Ultima IX noteable), at best 11 years ago. While I instantly know who Lord British is, he is far from a household name to someone who was 3 when Ultima Online launched.
That's right, it's happened to you: you got old.
I was going to say "Surprise! It's always orange" but then I actually checked before posting and was shocked to see that it's yellow.
It's also intensely stupid.
I think it's conceivable that the world's population could have its quality of life raised across the board so that there are not people living in abject poverty who are literally starving to death, although it would be quite difficult and especially problematic to do so without causing the abject poor and working poor to effectively combine (meaning a reduction in quality of life for those presently at the low end of the scale but above the very bottom).
However, raising the quality of life so that literally no one has anything to lose (as you put it) doesn't seem practical. If everyone is a millionaire, then that will be the new poverty as the value of things will adjust accordingly based on their scarcity as already happens.
Put another way, someone will always have more than you in one way or another. More possessions, more political power, more social influence. If you feel that this is unbearable (as in someone who is legally permitted to obtain an abortion) or that you have no power to change this within the system (as with a tyrant suppressing political freedom) then people of a particular disposition will gravitate towards terrorism as a means to achieve their goals. Not to mention those who possess a strong enough dislike for another group of people based on religion, ethnicity, or other factors that their mere existence is offensive to you, which is even more difficult to solve as there is no middle ground.
Your records belong to you. You can request them (and depending on the hospital / doctor's office, they may claim you can only receive copies or that they will only send them directly to your new healthcare provider) at any time and take them with you.
My ISP links to http://www.smallnetbuilder.com/component/option,com_chart/Itemid,189/ which has throughput numbers for common home routers.
The long and short of it is that a lot of these devices have pretty poor performance, and can get away with it because they're used on 1.5mbps lines. However, there are some out there that are decent.
Of course, there's the build-it-yourself approach with m0n0wall or pfSense or something else. With a spare PC laying around you'll likely get reasonable performance, although electricity usage is quite a bit higher than an appliance.
You may be disappointed in the results: http://en.wikipedia.org/wiki/List_of_United_States_extradition_treaties
I guess The Spanish Prisoner lied to us.
I agree that all of those things could be of value, but I still contend that even if someone was willing, the average employee doesn't have access to that kind of data.
It's not so much that I don't believe ANYONE would steal from their former employers but that EVERYONE would do so as the article is practically saying (50% is absurdly high).
Yep, that's me. I even put it on my resume once as a joke (I had one empty line to fill).
I'm sure that some people do try to profit from illicitly obtained information from their past employers; I've heard a few stories here and there about people getting busted. But there is simply no way that 50% of everyone in the workforce is doing this for a few simple reasons:
1. Risk - I think everyone is aware that the damage to your career and professional reputation would be catastrophic if you were caught, not to mention the legal ramifications.
2. Ethics - Yes, people do have them. Maybe not everyone is the pinnacle of ethical behavior, but that doesn't mean every other person you see at the office is just waiting to mug you and steal your wallet in the parking lot.
3. Nothing to steal - The majority of employees just don't have access to proprietary information that is actually of value outside the company. Sure, I could tell a future employer about my company's HR policies or give them an org chart. That might be very slightly useful, but certainly isn't going to get me hired or land me millions. I could also give them all of the company's internally developed code, but it would be of little use without all of the institutional knowledge, expertise and essentially the entire original company to go along with it.
4. Employers are liable as well - Take the case of the people who tried to sell some of Coke's trade secrets to Pepsi. They were refused, and Pepsi informed the police. They know that they would be liable for the illegal behavior as well, and want no part of it. Now not every employer operates above board, but it's a risky game to try to sell information to someone who may not even want to buy it.
So in summary: bullshit.
I was under the impression that the bridge had to go through Yerba Buena not to serve the island population (who are only there because the bridge makes it convenient I imagine), but because the bay is too deep and without a firm bedrock to otherwise locate the middle section of the bridge securely.
Possibly that was only a concern when it was originally built, but regardless, you would essentially need to route it in the same path as otherwise you'd need a new landing point on the Oakland side and there's Alameda in the way.
There are four bridges running east/west over the bay, it just happens that there is only one in this particular (useful) location. Also, given that the Bay Bridge has to connect to Yerba Buena island, there's not really a lot of room for another one right next to it. So there is redundancy, but you have to deal with the physical realities of the area.
That's a completely valid option, but I'm leery of MySQL replication due to prior experiences. When it works it's fine, it just has a few issues that I've had crop up. Keep in mind, if your official backup copy is coming from the slave, you have to make absolutely sure that the data is really in sync and up-to-date.
That means using tools like mk-table-checksum and mk-heartbeat from Maatkit. If you're not using them (or comparable things), then your data could be silently corrupted or out of date which would invalidate your backup. Note that seconds_behind_master from MySQL is kind of a joke for verifying that your slave is up-to-date.
My other beef with MySQL slaves is that they, by design, can only write in a single thread whereas the master can use all of its cores to do this. So even with two identical systems, the master may be fine at load and the slave may totally choke. People also have a habit of purchasing underpowered slaves, because "they don't do anything", forgetting that they still do 100% of the write load from the master, even if nothing else uses the host. Buying larger hardware just to keep up with the master for a once-an-hour backup feels dirty to me, but it is what it is.
Yes, but as I mentioned, this is not necessary specifically only with InnoDB. Because it writes to disk atomically, you will get a valid point-in-time copy of the database simply by taking a filesystem snapshot; no read lock required, which means the application can continue operating from the user's perspective.
The problem with a read lock is that, if done on a master DB, you will impact the production service that uses the database. Depending on the workload, this could take a minute or even longer, which is usually not acceptable.
However, there's another problem: MySQL performance degrades significantly on LVM when a snapshot is active. So even though the database continues operating as usual, performance will not be the same (and perhaps not at all adequate) during the backup period -- especially considering that you're doing extra disk I/O to get the data copied off.
So, I prefer to use xtrabackup these days. This presumes that you have no MyISAM tables though; otherwise you're back to mysqldump or taking a read lock or some other less desirable method.
One other point: if you backup with filesystem snapshots (of the raw DB files), then you have to restore the entire database during a restore. Maybe this is fine and maybe it's a huge headache.
There are a million ways to backup MySQL (and other DB's), and it really comes down to what kind of downtime you can tolerate during your backup. I generally want to back up very frequently, without impacting the service, and avoiding replication (and all of the headaches involved in that -- see the existence of tools like mk-table-sync for an idea of what can go wrong) if possible. If you don't have those requirements, then mysqldump or mylvmbackup or something else are totally valid options.
That is actually the accepted practice for backing up InnoDB databases with MySQL. Of course, you take a filesystem snapshot to get a point-in-time in-use copy of the database files; backing up the real filesystem wouldn't work due to the time shift of the data while you're backing up.
You do have to recover the files upon restoration (I would usually run the recover after the backup finished, since time is of the essence when you need to do a restore), but by not having to take a read lock or halt MySQL, you avoid a service interruption or having to replicate out your data just to backup (which could be problematic in itself, what if the slave server is not in sync?).
Of course, this works because of the way that storage engine functions on disk. You can't do this with MyISAM tables or you'll be in a world of hurt. There are also online backup tools readily available, which are the superior solution now in my opinion.
They would have to perform an act with the express intent of causing terror and fear in the general populace, also typically involving idealogical goals (check) and targeting civilians with violence (not check).
I don't think that knocking down a single AM radio tower qualifies, although it is certainly vandalism, destruction of property and other things.
I mean, if I destroyed everyone's wifi devices in my building with a hammer, I'm crazy and have destroyed property in a criminal manner. But am I a terrorist?
I am gonna squeeze on that animal and drink whatever comes out!
I also prefer organic milk for different reasons (I think it tastes better, and it's expiration date is usually way further out than regular), although I suspect the main differentiator may be that organic milk is almost always ultra-pasteurized as opposed to regular pasteurization which is the norm for regular milk.
Bugatti Automobiles SAS is a subsidiary of Volkswagen, and is actually a new company founded in 2000. As far as I'm aware, none of the former Bugatti companies were ever associated with GM; even if they were, a subsidiary can certainly make cars distinct from its parent company if the corporate structure permits.
Yeah, I'm not sure what this particular site requires. I do know from prior professional experience that the 'second site' was always a very tough sell (and actually, of the places I've worked, only Yahoo was good about that sort of thing).
It's more than just the hardware too, it's the processes in place to ensure that there are very seriously no dependencies on one site. For instance, maybe you deploy everything simultaneously to both sites, you buy equal hardware in both places, you do BCP failover tests regularly to ensure the second site works as expected, and so forth.
But where do you build new packages? Where is your source control repository? Not being able to use your normal workflow can be almost as bad as a public outage, and can lead to one as well.
In this case, maybe the guy could just slap something together, but even so the amount of effort to do what you're talking about would probably take a few days to iron out. You lose a lot of time right off the bat just figuring out what happened and whether or not you are going to be seeing your equipment again anytime soon. Plus some things are just out of your control; getting a DSL or cable hookup with a static IP, if you didn't already have one, can literally take weeks.
A lot of places are not prepared for a complete site loss. They may be very redundant within the site, with multiple hosts and backups and redundant power / AC / networking, but not have a single piece of equipment not located at that colocation center.
Consider that even if they did have off-site backups (which are really the bare minimum, although a lot of small operations overlook it anyway), they probably don't physically possess any equipment to run it on or have an agreement with another colocation center to put that equipment in.
So right now they need to put an order in with Dell and Cisco and whoever to get duplicate equipment (that they probably don't have a budget for), find another colo on short notice, wait for the equipment to arrive (1-2 weeks), do the physical installation work, and then restore all of their systems types from backups that may or may not represent the complete bare metal system image.
Most disaster recovery plans only account for disasters within a finite period of time (the power goes out for a few hours) or for partial losses (you lose 2 of 4 web servers), because redundancy is the most expensive part of any computer deployment.
For the database server itself, there is no difference between MySQL Community Edition and MySQL Enterprise Edition besides the release schedule. The community edition (aka the regular one everyone uses) has been pared down to 4 releases a year, which are cherry picked from the enterprise releases.
However, the source is completely available for the enterprise releases, and you are able to compile and install them yourself. This is what Percona is doing, for instance (plus some other patches).
With that said, MySQL has other software that comes along with the enterprise edition that is not open sourced to my knowledge. A query analyzer, monitoring, and other goodies. Personally I prefer to find their equivalents in the open source world, but I'm sure some people buy and use these packages.