VMware admits 'time bomb' rolled past quality control VMware’s CEO has blamed a chunk of leftover pre-release code for a bug that yesterday prevented virtual servers around the world from powering up when the clock hit 12 August. Despite the company carrying out quality assurance of its product, VMware failed to spot that it had released the leftover bit of time-bombed code …
It's easy to ensure this does not happen again.
just remove your crap DRM and *voila*.... Problem solved.
and these same companies want congress to grant them the ability to perform "self help" by allowing them to remotely disable anyone's software.
This release was only made available 2 weeks ago, Do you mean to say that all the companies affected by this had managed to complete full testing of this release in an environment which would not affect their live systems? Doesn't sound like it. Especially if those companies are running critical systems on ESX, then to be honest they are partly at fault. I'm sure they don't do it with Microsoft, so why with VMWare? The first rule in running systems like this is test, test, test and then test again. The testing may not have shown up the bug, but if they had spent more time on testing it, it would have shown up when the dates change.
Judging from Mr Maritz' letter, and discussion on the Communities page yesterday, it looks like it was regressed code, perhaps from the beta release. so we're talking about something that got regressed in by accident at some point before or at Update 2. Which means it:-
- predates Diane Greene's departure, and
- has nothing to do with DRM
It also means the whole thing was caused by perhaps one software engineer changing the wrong bit of code around, and that testing would always fail to spot it, unless the testing involved scanning code for beta time-stamps.
It must be safe to say that VMware will be making sure that all code is checked for this from now on!
"but anyone who runs a mission critical server in a VM is just asking for trouble"
Anyone who runs a mission critical server on bare metal that can't be immediately snapshotted and migrated to another piece of hardware is asking for trouble.
The screw up was nothing to do with VM, it could just as easily have happened in the OS or DB - and frequently has.
The best solution in my opinion is if future timebombs are limited to disabling only advanced features of the product, not basic functionality like powering on VM's.
It seems increasingly silly to limit things that much, because if users want a free hypervisor there's now ESXi, as well as VMware Server, plus Xen and MS.
VirtualConsole, vmotion etc. is VMware's value add, and I see why locking that down is fair.
For all those wondering:
Seems like they had troubles with 'kb2' after they had long time trouble with the usual 'kb' server.
Replacing 'kb2' with 'kb' in the failed URL brings you to the same page on the other server respectively.
http://kb2.vmware.com/kb/1006721.html
equals
http://kb.vmware.com/kb/1006721.html
But as of now both servers just started responding again.
DRM stands for Digital Rights Management. "Rights" as in those of the customer as well as the vendor - their right to use software/data that they've paid for in the face of others that would illegally gain access to it had those rights not been enforced.
Not that DRM has anything to do with this case, but slagging off DRM universally is not the correct approach.
Criticizing poorly implemented DRM that allows a vendor to abuse customers' rights is what we need to fight against.
I don't think Rob "bought into the industry propaganda", when he states:
"Criticizing poorly implemented DRM that allows a vendor to abuse customers' rights is what we need to fight against.".
The industry propaganda wanted (for a long time) to make us feel guilty for music that is not restricted, because "the artist" would be cheated that way. If he mentioned that DRM would be there to protect the income of the artist, THAT would be "buying into the industry propaganda"!
"I don't think DRM was an issue here, and I don't understand why folks think it is."
Here's a quick primer on DRM, then.
"Most likely the problem was the beta of U2 had an expiry of 12 Aug and some fool didn't remove that code during the final build."
Having "an expiry" on something you've licensed from someone is a restriction, or if you buy into "R == rights" then it's something which supposedly protects the "right" of the vendor to deny you use of the software. Consequently, the users experience DRM because those "rights" are being managed (or mismanaged) at their expense: you have the vendor telling you exactly which software to use at any given time with no flexibility or trust placed in you, the paying customer.
"That's all, move along."
To DRM 101 in your case, I guess.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
