Massive VMware Bug Shuts Systems Down
mattmarlowe writes "Imagine if Red Hat released a version of Linux, and after it was deployed, customers noticed that any processes with a start date of today would refuse to run? Well, that's what happened to VMware — a company that wants nearly all server applications running in virtual machines within a matter of years." Supposedly a fix will be available ... in 36 hours.
I don't get license management measures in software that is only going to be used by major corporations.
If someone wants to run virtual machines at home or in a small business, they're likely going to be more than satisfied with VMWare Virtual Server (formerly GSX) and wouldn't even consider the much more complex ESX.
In a major corporation, fear of massive fines and prosecution is enough to stop them from pirating your software. Hardware dongles, software license managers and the like only hurt your paying customers.
I'm a big tall mofo.
I stick to virtualbox. I'm not going to pretend I've audited the source code, but if I need to, I can.
Say YES to freedom.
Do you even lift?
These aren't the 'roids you're looking for.
There probably is no "fix" they are just waiting for the problem to go away
I can just see the programmers reaction when he sees the bug report.
"so the process wont start if it has todays date? hmm.." he then proceeds to set the target date for tomorrow and takes the day off
But the real bug is license enforcement in the first place. Why would you run the risk of making your business depend on the whims of someone else's IP policies and enforcement?
Now, I'm somewhat realistic. I know that there isn't (yet) an adequate replacement for every piece of closed proprietary software out there. But for my own business (admittedly small) I am building with nothing but GPL/BSD/Apache license code. And it is working. I don't trust closed code. Of course my software will have bugs, some of them serious. But I won't have stuff shutting down because of "license" issues. Why do people go quietly into enforced licenses? Why do people accept remote kill switches on their servers? Why doesn't this strike everyone as a crazy thing to do?
Ah, see, another reason why free software always is better
Taxation is legalized theft, no more, no less.
VMWare licenses for ESX server cost something like $5k apiece. My company uses VMWare and I don't quite get it. We pay for expensive blade hardware ($8k each for those, not to mention the chasis), then we pay $5k per virtual server. And for what? Adding virtualization overhead to the runtime cost.
Meanwhile, in articles like this, people are showing how to run many applications and different versions within a single container. A single node in the cluster can run any application. There are always busy, keeping the hardware fully utilized. Isn't that the promise of utility computing? Rack up a bunch of cheaper (but not cheap/shoddy) servers and let your cluster go to town.
So, my question is, why are we (as an industry) embracing virtualization when apps written for a smart container (like OSGi) give the same benefits without all the additional co$t and runtime overhead?
...Says it all, I think. Perhaps you should reconsider the ramifications of making your business critically dependent on software that contains code specifically design to make it stop working.
Consider this: to a proprietary vendor the only safe failure mode for "license management code" is one where everything stops.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Maybe stable support then. Each time I try adding a usb device virtualbox throws up it's hands and gives me an error.
....... Thus ends my attempt at wit or whatever
I've been weighing up whether to migrate from VMware Server for our limited set of operations and move to ESXi and then ESX. This has made up my mind now. I'd rather wait for the hype of virtualisation to really settle down, use it in a pretty limited capacity and then run more stuff on technology and a host system that gets it right - KVM and Linux. I don't care too much about waiting, because as far as I'm concerned this just isn't acceptable. Many organisations will be brought to their knees by something like this, and over something that is totally unnecessary as well. I could understand pretty much any other issue, but not this. Sorry VMware.
I was thinking about the very problem of trusting your compiler, and the only thing I could come up with is building one from an open assembler.
I built gcc (1.4) with a C interpreter. It was slow as hell (and we did it mainly to stress-test the interpreter), but when I fed the source of gcc to the result, it did what I expected--built a system the same as the one that regular gcc built.
But the simple fact of the matter is that a little common sense should reveal that the whole notion is impossible in the real world. At the time Thompson wrote, there was, basically, one C compiler and one version of login, and neither one changed very much, so it was at least theoretically possible for a fairly simple program to recognize them. The sources to gcc have changed too much over the years to be recognizable to anything less than a hard-AI system, i.e., something that doesn't exist (and if it did, you'd notice, since it would take hours to compile even the simplest app). Toss in drastically different compilers from vendors like Sun, IBM, Intel and HP, and the whole thing becomes even more ridiculous. But if you really want to check, write your compiler in another language (one that doesn't compile to assembler, like Java or Python).