I don't buy this. Almost nothing happened on Jan 1, 2000. If the problem was real and really deserved the effort we put into it, we should have seen at least 0.01% of the events not get fixed. I would expect that well-funded entities like governments would be hit least hard and people out in the third world that had one ancient computer running some piece of equipment to be hit at like a 10% rate. The reality was that almost nothing happened anywhere. "We fixed it" just doesn't make sense.
Microsoft's current recommended platform for business development is ".Net"..Net desktop application can be simply copied to a folder and run. However, the stuff that makes applications easy to support is where the problem lies. For example, to properly log to the Application log in a way that can be searched and filtered, you need to add an event log source to the system. This can be done on the first instance of a logged event, but then the user would need elevated rights. So, we make installers that create the log source on install. No sane Windows developer has put anything they wrote in the system32 folder for the last twenty years. Another note is that.Net applications use a config file that resides in the same directory as the application by default.
I'm so happy to hear someone else say this. Some of the worst code I've seen in my life was 100% up to the "coding standards" it was written under.
I've seen many examples of development teams that write the most unmaintainable heaps of crap, but they are very good at variable naming conventions. I my opinion, elaborate variable naming standards should only be established after getting the basics covered. Instead of berating the new guy for not using some stupid prefix, get on him for poor commenting or source control practices. My biggest personal pet peeve is people who don't understand what they are checking in. I constantly get temp files, unrelated and abandoned attempted fixes, bread crumbs debugging, and irrelevant config changes checked in with whatever the developer was actually trying to check in.
Actually, I think the reason he thought it was hard to read was the loop termination condition. "ss" is vague and it is not trivial to arrive at the conclusion that this loop runs until ss is a null reference (for a non-C programmer). Had the loop termination been written as "ss == NULL", then it would have been easy to read. In my experience, C programmers tend to value terseness over readability. The ultimate example of this paradigm is Perl, which we all know can be a nightmare to maintain.
In my opinion, if that for loop were only a few lines long, the naming would be acceptable. If the loop were 100 lines long, I'd ask for a more descriptive variable name. I use "for(i=0; i<something; i++)" all the time, if it is a very small loop and the usage is obvious.
As for...
The culture he's been inculcated in is one in which you never have to understand how a linked list is actually implemented, because you just use a library for it.
... I prefer to think that in OOP systems, we hide the implementation of the loop not to pretect our fragile brains, but to not bind the code that uses the list to a specific list implementation. I like being able to switch between ArrayList, HashTable, SortedList, List<Stuff>, and Dictionary without breaking my iteration code.
RAID is taught in about a half hour of an introductory system admin class. The Wikipedia entry for RAID has more content than most classes. If the "complexity" of RAID overwhelms you, then please don't be a professional sysadmin. As for quick return from downtime, that is what backup is for. RAID is for online redundancy, meaning that your system won't fail in the first place if you have a component failure. Using RAID for anything else is likely to be less than successful.
Also, RAID is transparent to the file system. If you can list the directories of both drives independently, then you probably aren't using RAID correctly, even software RAID. The only way to see them both is to break the RAID array, at which point a comparison of the two becomes irrelevant.
Back to my original point. The original poster is asking for advice on how to protect his data and the availability of his services. Following your advice to avoid RAID because it is unneeded complexity would be a horrible mistake.
So..... you misinterpreted what RAID does (hint: it doesn't replace backups), misimplemented it and had problems. Therefore, you conclude that RAID is an unreliable technology that causes more problems than it solves, and you made your own similar solution that is simple, but only solves some of the problems that RAID solves.
I've never known anyone to have files disappear and reappear due to RAID problems. We have over 100 RAID arrays in our department running right now and have never seen this. The company as a whole has tens of thousands of RAID arrays and, as far as I know, we don't have this problem anywhere.
With the iLO advanced license, you can SSH into the management port and map remote CD images over http. It is much faster than using a client side mapping.
Blades are best if you are an organization that buys more than a handful of servers each year. The fact that the enclosures will be obsolete after this, or maybe the next, generation of servers turns out not to matter much. It is very easy to move a blade server between enclusures in the same rack. Just power it down, move its VirtualConnect profile to another slot in the same domain (usually a racks worth the enclosures), move the blade, and turn it back on. All of the WWNs and MAC addresses move with the blade. So, as you move from c-class blades to whatever is the next generation, just move a few servers to empty an enclosure and replace it with a new enclosure. Early in the lifespan as the number of c-class blade servers is growing there is no problem. Late in the lifespan when the number of c-class servers is shrinking, there is a very organized path to consolidating the server into a small number of enclosures.
The need to bring down all of the blades in an enclosure would be very rare. Every part of the enclosure except the midplane is redundant. Even firmware upgrades can be done without taking the system down. If you do have a need to service the midplane, it's easy to migrate the servers, one at a time, to another enclosure. If you have a disaster, it's easy to move the servers to any other enclosure and bring them up.
A DMCA exemption request has been filed for jailbreaking iPhones and will be reviewed soon. A more explicit request for an exemption for unlocking has also been filed. See here: http://www.eff.org/cases/2009-dmca-rulemaking
So, if German society is okay with forgetting such things, why make a law that makes it illegal to remind them? It seems inconsistent that a society that allows people to move on with their lives needs to protect people from a society that may hold their past against them. The German society that created this law surely is a German society that would hire an ex-convict as long as they have served their time.
I wonder if there isn't an interesting history behind this law. Like, perhaps, it was passed to allow WW-II era leaders to continue to lead a public life without embarrassment. Or, maybe, it is a way to make official pardons more effective by sheilding the pardoned from public backlash. Both of these sound like they are not in the best interestes of the German people. I'd like to hear from anyone who knows the real background of this law.
I can't agree more, especially for data. I take great care in source controlling database and I would never dream of auto-building a deployment package.
Myself and all of the developers don't have access to the database schemas in the dev environment with our normal accounts. I have a SubVersion hook script that runs all checkins to the database schema files on the dev DB. If the script errors, the commit is rejected. This guarantees that the only way to get changes into the database is to put those changes in source control. Even with this level of control, every once in a while someone checks in a drop-create script on a table, or does similar nonsense. Of course we have to recover the database from a backup, but the script is now forever in source control. If I blindly turned the commits into a deployment script, there would be a lot of these things. So, I have a custom tool that allows me to find all of the changed files in the database schema code in a range of revisions, allows me to choose and reorder them, and it generates a deployment script. Sometimes the script needs hand tweaking.
The process goes like this --
1. Work on dev server, get all unit tests to pass.
2. Create deployment script. Deploy to test server, do unit tests again.
3. Give deployment script (and app changes) to QA. They run them on the Stage server and do user acceptance testing.
4. If all is well, both the final code and the deployment process have been verified, roll out to production.
I'm also a big fan of using test data in test, not production data (for new development, bug fixing often requires production data). I can put far more taxing scenarios in than the users ever will. Production data rarely tests the edge cases. I also have an issue in my production environment that all work begun on a given day is closed out by the end of the day. So, my nightly backups rarely have any variety of data in them.
I don't see any value in automating the process any farther, but I do automate the heck out of compiled code and content deployment. The best tool depends on the environment. I currently use WiX to package up static deployables as MSI packages as I do mostly Windows development.
Or an HTTPS form that accepts your credit card number, then mails it back to you in a confirmation message 20 seconds later. I had that happen to me once.
I also know of more than one site that accepts credit cards numbers and them has the site email the order requests, card number and all, to the reseller for processing. It's amazing how many people don't see a problem with it.
I was a TEM operator about twenty years ago. We didn't have any special floor and the vacuum was drawn with an Edwards High Vacuum roughing pump that plugged into the wall and the final vacuum (10E-7 torr) was drawn with the internal diffusion pump. It was a Hitachi 600AB that could do about 100,000X magnification, but we only used it to about 4,000X or so for our purposes. This was a two ton, seven foot tall scope. We didn't use it for high magnification, but for x-ray diffraction crystallography and EDS identification of elemental composition. We also has a Phillips SEM. I'm sure we paid far less than $60,000 for it -- we bought it used. Even the TEM, which we bought brand new, was only about four times as expensive as the TM-1000. However, neither of these scopes could ever be used in most homes due to power requirements and their sheer size.
I think the big deal here is that this one (the TM-1000) fits on a table top, weighs 200 pounds, and doesn't require liquid nitrogen. BTW, the EDS detector available for this unit is pretty lame and is only able to detect elements from sodium up.
BTW, to make a div or span into a control, just add runat="server" and id attributes to them. They work just fine that way and fully encode HTML all by themselves.
As for data binding -- use textboxes for input, they refuse to accept tags. Then you don't have the problem of encoding the data on the way out. As for the label, although it doesn't HTML encode, I can't think of too many cases where I would display user submitted data in a label. It seems like a rare issue to me.
I also don't like to use declarative binding in my ASP/Net apps. For me the.aspx file has only presentation, no binding logic. The code behind page has UI logic including binding. All other code goes into the business or data layer class libraries.
I just tried it with ASP.Net 2.0. A TextBox, HTMLInputText, div, and span control all escaped HTML properly. A Label did not properly escape the Text property. I can't think of very many situations where you would use user supplied values for label text, that a span wouldn't be more appropriate for. By default TextBoxes don't allow HTML to be submitted at all. BTW, ASP.Net 2.0 is four years old.
Do you think that for the past 50 years auto engineers have forgotten to account for something hitting the engine dead on? Modern cars get run straight into metal support beams all the time and their engines manage to not intrude on the passenger compartment. How would a Bel Air engine do more damage than a nearly immovable object? The left front collision was chosen because it is the standard "very dangerous and also very likely" collision mode. If head on collisions were the cause of more traffic deaths, then it would be the standard test and would have been in the video.
I'll bet if they dropped the Bel Air directly on the roof of the Malibu (headlights first, not flat), the Malibu driver would have died. Sure, there are situations that wouldn't favor the Malibu. But, a 2009 Malibu driver is more likely to sleep in his own bed tonight then a 1957 Bel Air driver.
About 10 years ago, a guy in a Chevy Suburban rear-ended my Pontiac Grand Am. His steel front grill was totalled and my plastic rear bumper just popped out after the accident with some minor paint scratches. Your one experience doesn't mean that bigger vehicles are safer or that they take less damage in an accident. If you value your life, buy a car rated well by the IIHS and get collision insurance on it. Going your own way and feeling safer because a car is bigger or "stouter" is foolishness that will get you killed. The collision insurance will eliminate the urge to buy a car that will get through a crash with less damage to itself rather than a car that will allow less damage to be inflicted on you.
But why break pattern? An inline four would be smaller and machanically simpler than a V-4. Also, if you need a small engine and your class has essentially no rules, then not running a turbo sounds like a bone-headed move to me. The turbo Hayabusa was offered as an example of how it could be done for $25,000 by any idiot off the street. But if you want to fab it yourself, 1.5 liters and a 16-valve, short stroke, turbo inline four is still the tried and true way to get 500HP in a small package.
You didn't read the article. This is exactly the research that was done to come to the conclusion that cooked food allowed us more free time. Humans on a raw food diet were one subject -- they tend to be undernourished even when they seems to have an adequate calorie intake. To verify this, studies were done on humans who had their small intestines removed (the intestines were removed before the study due to unrelated medical complications). These humans allowed the researches to see that significantly less nutrition is extracted from uncooked food in the human stomach than is extracted from cooked food. The difference was huge; a human would need to eat nearly twice as much uncooked fod to get the same nutrition as from cooked food.
A 3 liter engine making 500HP is not under a terrible amount of stress. My streetbike makes 200HP at the rear wheel and diplaces 1.4 liters. This thing is only making 16% more power per liter than mine and I run on pump gas and have put 20 thousand trouble-free miles it.
If I were on the team for the motorcycle, I would have recommended a turbo Hayabusa motor. You can easily get 500 or 600 horsepower without any risk of engine problems and fit it in a much smaller footprint than their custom engine.
I've got bad news for you... SQL 2005 isn't going to fix anything. SQL 2005 is better than 2000, but you are having problems that are either related to your application (deadlocks) or your hardware (server load). If you simply upgrade from 2000 to 2005 without changing the code to take advantage of any new features of 2005, then the situation will not change. The SAN may actually create a new bottleneck at the HBA.
I'm still new at this, so maybe I'm doing something wrong. But, I found that if I put something from iTunes and sync it to my iPhone, then it will sync with my copy of iTunes at work. However, for my non-iTunes music, it won't sync. Apple's approach to DRM seems to be -- "If people complain about the inconvenience of DRM'd music, we'll simply make non DRM'd music even less convenient". My iPhone is my first, and probably my last, Apple product I ever buy.
I was also amazed that my iPhone doesn't act like a flash drive when you hook it up with a USB cable. What kind of control freak company made this thing? Oh wait... never mind. Even jailbreaking it doesn't really fix this issue.
Microsoft has already lost over a billion dollars from their previous patent lawsuits. It doesn't seem to have prompted them to support patent reform yet. I would guess they would need to be hit for at least 20 billion to change their minds.
Here's something to think about... you lost a single controller and it was an event that required a vendor to be on site. BackBlaze's system is redundant enough that ten controllers failing isn't a big deal. So, you pay for the support that your system needs, they designed the support need out of the system.
Slashdot Mirror
I don't buy this. Almost nothing happened on Jan 1, 2000. If the problem was real and really deserved the effort we put into it, we should have seen at least 0.01% of the events not get fixed. I would expect that well-funded entities like governments would be hit least hard and people out in the third world that had one ancient computer running some piece of equipment to be hit at like a 10% rate. The reality was that almost nothing happened anywhere. "We fixed it" just doesn't make sense.
Microsoft's current recommended platform for business development is ".Net". .Net desktop application can be simply copied to a folder and run. However, the stuff that makes applications easy to support is where the problem lies. For example, to properly log to the Application log in a way that can be searched and filtered, you need to add an event log source to the system. This can be done on the first instance of a logged event, but then the user would need elevated rights. So, we make installers that create the log source on install. No sane Windows developer has put anything they wrote in the system32 folder for the last twenty years. Another note is that .Net applications use a config file that resides in the same directory as the application by default.
I'm so happy to hear someone else say this. Some of the worst code I've seen in my life was 100% up to the "coding standards" it was written under.
I've seen many examples of development teams that write the most unmaintainable heaps of crap, but they are very good at variable naming conventions. I my opinion, elaborate variable naming standards should only be established after getting the basics covered. Instead of berating the new guy for not using some stupid prefix, get on him for poor commenting or source control practices. My biggest personal pet peeve is people who don't understand what they are checking in. I constantly get temp files, unrelated and abandoned attempted fixes, bread crumbs debugging, and irrelevant config changes checked in with whatever the developer was actually trying to check in.
In my opinion, if that for loop were only a few lines long, the naming would be acceptable. If the loop were 100 lines long, I'd ask for a more descriptive variable name. I use "for(i=0; i<something; i++)" all the time, if it is a very small loop and the usage is obvious.
As for...
The culture he's been inculcated in is one in which you never have to understand how a linked list is actually implemented, because you just use a library for it.
... I prefer to think that in OOP systems, we hide the implementation of the loop not to pretect our fragile brains, but to not bind the code that uses the list to a specific list implementation. I like being able to switch between ArrayList, HashTable, SortedList, List<Stuff>, and Dictionary without breaking my iteration code.
RAID is taught in about a half hour of an introductory system admin class. The Wikipedia entry for RAID has more content than most classes. If the "complexity" of RAID overwhelms you, then please don't be a professional sysadmin. As for quick return from downtime, that is what backup is for. RAID is for online redundancy, meaning that your system won't fail in the first place if you have a component failure. Using RAID for anything else is likely to be less than successful.
Also, RAID is transparent to the file system. If you can list the directories of both drives independently, then you probably aren't using RAID correctly, even software RAID. The only way to see them both is to break the RAID array, at which point a comparison of the two becomes irrelevant.
Back to my original point. The original poster is asking for advice on how to protect his data and the availability of his services. Following your advice to avoid RAID because it is unneeded complexity would be a horrible mistake.
So..... you misinterpreted what RAID does (hint: it doesn't replace backups), misimplemented it and had problems. Therefore, you conclude that RAID is an unreliable technology that causes more problems than it solves, and you made your own similar solution that is simple, but only solves some of the problems that RAID solves.
I've never known anyone to have files disappear and reappear due to RAID problems. We have over 100 RAID arrays in our department running right now and have never seen this. The company as a whole has tens of thousands of RAID arrays and, as far as I know, we don't have this problem anywhere.
With the iLO advanced license, you can SSH into the management port and map remote CD images over http. It is much faster than using a client side mapping.
Blades are best if you are an organization that buys more than a handful of servers each year. The fact that the enclosures will be obsolete after this, or maybe the next, generation of servers turns out not to matter much. It is very easy to move a blade server between enclusures in the same rack. Just power it down, move its VirtualConnect profile to another slot in the same domain (usually a racks worth the enclosures), move the blade, and turn it back on. All of the WWNs and MAC addresses move with the blade. So, as you move from c-class blades to whatever is the next generation, just move a few servers to empty an enclosure and replace it with a new enclosure. Early in the lifespan as the number of c-class blade servers is growing there is no problem. Late in the lifespan when the number of c-class servers is shrinking, there is a very organized path to consolidating the server into a small number of enclosures.
The need to bring down all of the blades in an enclosure would be very rare. Every part of the enclosure except the midplane is redundant. Even firmware upgrades can be done without taking the system down. If you do have a need to service the midplane, it's easy to migrate the servers, one at a time, to another enclosure. If you have a disaster, it's easy to move the servers to any other enclosure and bring them up.
I think this is already an exemption under the DMCA. See here: http://www.copyright.gov/1201/2006/index.html
A DMCA exemption request has been filed for jailbreaking iPhones and will be reviewed soon. A more explicit request for an exemption for unlocking has also been filed. See here: http://www.eff.org/cases/2009-dmca-rulemaking
So, if German society is okay with forgetting such things, why make a law that makes it illegal to remind them? It seems inconsistent that a society that allows people to move on with their lives needs to protect people from a society that may hold their past against them. The German society that created this law surely is a German society that would hire an ex-convict as long as they have served their time.
I wonder if there isn't an interesting history behind this law. Like, perhaps, it was passed to allow WW-II era leaders to continue to lead a public life without embarrassment. Or, maybe, it is a way to make official pardons more effective by sheilding the pardoned from public backlash. Both of these sound like they are not in the best interestes of the German people. I'd like to hear from anyone who knows the real background of this law.
I can't agree more, especially for data. I take great care in source controlling database and I would never dream of auto-building a deployment package.
Myself and all of the developers don't have access to the database schemas in the dev environment with our normal accounts. I have a SubVersion hook script that runs all checkins to the database schema files on the dev DB. If the script errors, the commit is rejected. This guarantees that the only way to get changes into the database is to put those changes in source control. Even with this level of control, every once in a while someone checks in a drop-create script on a table, or does similar nonsense. Of course we have to recover the database from a backup, but the script is now forever in source control. If I blindly turned the commits into a deployment script, there would be a lot of these things. So, I have a custom tool that allows me to find all of the changed files in the database schema code in a range of revisions, allows me to choose and reorder them, and it generates a deployment script. Sometimes the script needs hand tweaking.
The process goes like this --
1. Work on dev server, get all unit tests to pass.
2. Create deployment script. Deploy to test server, do unit tests again.
3. Give deployment script (and app changes) to QA. They run them on the Stage server and do user acceptance testing.
4. If all is well, both the final code and the deployment process have been verified, roll out to production.
I'm also a big fan of using test data in test, not production data (for new development, bug fixing often requires production data). I can put far more taxing scenarios in than the users ever will. Production data rarely tests the edge cases. I also have an issue in my production environment that all work begun on a given day is closed out by the end of the day. So, my nightly backups rarely have any variety of data in them.
I don't see any value in automating the process any farther, but I do automate the heck out of compiled code and content deployment. The best tool depends on the environment. I currently use WiX to package up static deployables as MSI packages as I do mostly Windows development.
Or an HTTPS form that accepts your credit card number, then mails it back to you in a confirmation message 20 seconds later. I had that happen to me once.
I also know of more than one site that accepts credit cards numbers and them has the site email the order requests, card number and all, to the reseller for processing. It's amazing how many people don't see a problem with it.
I was a TEM operator about twenty years ago. We didn't have any special floor and the vacuum was drawn with an Edwards High Vacuum roughing pump that plugged into the wall and the final vacuum (10E-7 torr) was drawn with the internal diffusion pump. It was a Hitachi 600AB that could do about 100,000X magnification, but we only used it to about 4,000X or so for our purposes. This was a two ton, seven foot tall scope. We didn't use it for high magnification, but for x-ray diffraction crystallography and EDS identification of elemental composition. We also has a Phillips SEM. I'm sure we paid far less than $60,000 for it -- we bought it used. Even the TEM, which we bought brand new, was only about four times as expensive as the TM-1000. However, neither of these scopes could ever be used in most homes due to power requirements and their sheer size.
I think the big deal here is that this one (the TM-1000) fits on a table top, weighs 200 pounds, and doesn't require liquid nitrogen. BTW, the EDS detector available for this unit is pretty lame and is only able to detect elements from sodium up.
BTW, to make a div or span into a control, just add runat="server" and id attributes to them. They work just fine that way and fully encode HTML all by themselves.
.aspx file has only presentation, no binding logic. The code behind page has UI logic including binding. All other code goes into the business or data layer class libraries.
As for data binding -- use textboxes for input, they refuse to accept tags. Then you don't have the problem of encoding the data on the way out. As for the label, although it doesn't HTML encode, I can't think of too many cases where I would display user submitted data in a label. It seems like a rare issue to me.
I also don't like to use declarative binding in my ASP/Net apps. For me the
I just tried it with ASP.Net 2.0. A TextBox, HTMLInputText, div, and span control all escaped HTML properly. A Label did not properly escape the Text property. I can't think of very many situations where you would use user supplied values for label text, that a span wouldn't be more appropriate for. By default TextBoxes don't allow HTML to be submitted at all. BTW, ASP.Net 2.0 is four years old.
Do you think that for the past 50 years auto engineers have forgotten to account for something hitting the engine dead on? Modern cars get run straight into metal support beams all the time and their engines manage to not intrude on the passenger compartment. How would a Bel Air engine do more damage than a nearly immovable object? The left front collision was chosen because it is the standard "very dangerous and also very likely" collision mode. If head on collisions were the cause of more traffic deaths, then it would be the standard test and would have been in the video.
I'll bet if they dropped the Bel Air directly on the roof of the Malibu (headlights first, not flat), the Malibu driver would have died. Sure, there are situations that wouldn't favor the Malibu. But, a 2009 Malibu driver is more likely to sleep in his own bed tonight then a 1957 Bel Air driver.
About 10 years ago, a guy in a Chevy Suburban rear-ended my Pontiac Grand Am. His steel front grill was totalled and my plastic rear bumper just popped out after the accident with some minor paint scratches. Your one experience doesn't mean that bigger vehicles are safer or that they take less damage in an accident. If you value your life, buy a car rated well by the IIHS and get collision insurance on it. Going your own way and feeling safer because a car is bigger or "stouter" is foolishness that will get you killed. The collision insurance will eliminate the urge to buy a car that will get through a crash with less damage to itself rather than a car that will allow less damage to be inflicted on you.
But why break pattern? An inline four would be smaller and machanically simpler than a V-4. Also, if you need a small engine and your class has essentially no rules, then not running a turbo sounds like a bone-headed move to me. The turbo Hayabusa was offered as an example of how it could be done for $25,000 by any idiot off the street. But if you want to fab it yourself, 1.5 liters and a 16-valve, short stroke, turbo inline four is still the tried and true way to get 500HP in a small package.
You didn't read the article. This is exactly the research that was done to come to the conclusion that cooked food allowed us more free time. Humans on a raw food diet were one subject -- they tend to be undernourished even when they seems to have an adequate calorie intake. To verify this, studies were done on humans who had their small intestines removed (the intestines were removed before the study due to unrelated medical complications). These humans allowed the researches to see that significantly less nutrition is extracted from uncooked food in the human stomach than is extracted from cooked food. The difference was huge; a human would need to eat nearly twice as much uncooked fod to get the same nutrition as from cooked food.
A 3 liter engine making 500HP is not under a terrible amount of stress. My streetbike makes 200HP at the rear wheel and diplaces 1.4 liters. This thing is only making 16% more power per liter than mine and I run on pump gas and have put 20 thousand trouble-free miles it.
If I were on the team for the motorcycle, I would have recommended a turbo Hayabusa motor. You can easily get 500 or 600 horsepower without any risk of engine problems and fit it in a much smaller footprint than their custom engine.
Then this would be the record for you...
http://thekneeslider.com/archives/2005/09/09/hayabusa-sets-speed-record/
This is the fastest I've seen from a street-legal motorcycle.
Microsoft fixed the licening issue on Oct 1, 2006.
http://www.microsoft.com/windowsserver2003/evaluation/news/bulletins/datacenterhighavail.mspx
They specifically mention VMware ESX in the Microsoft article.
I've got bad news for you... SQL 2005 isn't going to fix anything. SQL 2005 is better than 2000, but you are having problems that are either related to your application (deadlocks) or your hardware (server load). If you simply upgrade from 2000 to 2005 without changing the code to take advantage of any new features of 2005, then the situation will not change. The SAN may actually create a new bottleneck at the HBA.
I'm still new at this, so maybe I'm doing something wrong. But, I found that if I put something from iTunes and sync it to my iPhone, then it will sync with my copy of iTunes at work. However, for my non-iTunes music, it won't sync. Apple's approach to DRM seems to be -- "If people complain about the inconvenience of DRM'd music, we'll simply make non DRM'd music even less convenient". My iPhone is my first, and probably my last, Apple product I ever buy.
I was also amazed that my iPhone doesn't act like a flash drive when you hook it up with a USB cable. What kind of control freak company made this thing? Oh wait... never mind. Even jailbreaking it doesn't really fix this issue.
Microsoft has already lost over a billion dollars from their previous patent lawsuits. It doesn't seem to have prompted them to support patent reform yet. I would guess they would need to be hit for at least 20 billion to change their minds.
Here's something to think about... you lost a single controller and it was an event that required a vendor to be on site. BackBlaze's system is redundant enough that ten controllers failing isn't a big deal. So, you pay for the support that your system needs, they designed the support need out of the system.