from the we-pay-this-fine-and-we-may-or-may-not-have-done-anything dept.
SEC Charges VMware with Misleading Investors by Obscuring Financial Performance:
The Securities and Exchange Commission (SEC) said on Monday it has charged cloud computing company VMware Inc. with misleading investors by obscuring its financial performance.
The company was charged with misleading investors about its order backlog management practices, which the agency said enabled it to push revenue into future quarters by delaying product deliveries to customers, thereby concealing the company's slowing performance relative to its projections.
Without admitting or denying the findings in the SEC's order, VMware consented to a cease-and-desist order and will pay an $8 million penalty, the SEC said. VMware confirmed in a statement of its own that it reached a settlement with the SEC and agreed to pay the penalty without admitting or denying the SEC's findings.
[...] "The SEC Staff has confirmed that it does not intend to recommend enforcement action against any current or former VMware officers or other member of management in connection with the investigation, and this settlement concludes the matter," VMware said in its statement on Monday.
See also: Broadcom to Acquire VMware in Massive $61B Deal
Related Stories
Broadcom to acquire VMware in massive $61B deal – TechCrunch:
Sometimes when there is smoke, there is actually fire. Such was the case with the rumors of Broadcom's interest in VMware this past weekend. It turns out that fire was burning hot, and today, Broadcom announced it is acquiring VMware in a massive $61 billion deal.
The deal is a combination of cash and stock, with Broadcom assuming $8 billion in VMware debt.
With VMware, Broadcom gets more than the core virtualization, which the company was built on. It also gets other pieces it acquired along the way to diversify, like Heptio for containerization, and Pivotal, which helps provide support services for companies transitioning to modern technology. At the same time it bought Pivotal, it also acquired security company Carbon Black.
That touches upon a lot of technology, but it begs the question, where does it all fit with Broadcom (which has spent a fair amount of money in recent years buying up a couple of key software pieces prior to today's announcement)?
[...] VMware CEO Raghu Raghuram put the typical positive spin on the deal about the two companies being better together. "Combining our assets and talented team with Broadcom's existing enterprise software portfolio, all housed under the VMware brand, creates a remarkable enterprise software player," he said in a statement, referring to those two other pieces Broadcom already owns.
Also reported at:
Previously: Broadcom in Talks to Buy Cloud Computing Firm VMWare
(Score: 2, Touché) by darkpixel on Tuesday September 20 2022, @12:03AM (8 children)
Who uses VMWare crap?
Oh...right...it's all the point-and-click "systems administrators" out there who don't know how to use qemu or bhyve because it isn't pointy-clicky enough.
(Score: 2, Insightful) by vux984 on Tuesday September 20 2022, @01:26AM (7 children)
Do you really choose your enterprise virtualization platform based on it missing features, lacking tooling options, and having less enterprise support? If so, you aren't trying hard enough. If so, surely, there is something even less complete, with even fewer tools, and worse documentation out there?? Maybe that runs on Amiga for extra points?
:p
(Score: 4, Interesting) by darkpixel on Tuesday September 20 2022, @01:46AM (4 children)
What lack of features? I've been virtualizing stuff in the enterprise for nearly 20 years now. The one time someone insisted on VMWare it ended up being a $140,000 mess that nearly bankrupted the company.
What lack of tools? Snapshots? Failover? Or do you really wish there was an open source portal that was difficult to navigate just to purchase a license to use your virtualization product?
That's funny. I forgot there's a class of "administrators" who are so incompetent at doing their job that they have to convince their employer to hire more support people to back them up all the while calling it "enterprise support". What does your employer pay you for? To be their VMWare sales rep?
I currently run virtualization systems in the healthcare space to the tune of ~140 hypervisors across ~30 different companies. We don't use Windows or VSphere to do it. I've watched with a slight twinge of sadness as competitors have been infected by cryptolocker and a decent number have been fined and a handful have gone out of business.
The competitors all hired IT bros who claimed they new how to do "enterprise" IT things...but they didn't. The only thing they had figured out, was that if you don't actually know how to do your IT job, you just contract everything out. Basically glorified $80k/year sales reps for lots of companies (including VMware).
You don't need an $80k/year point-and-click moron who tells you to buy $150k/year in software. It's cheaper to hire the $100k/year guy who knows how to use all the tools at his disposal.
(Score: 2) by vux984 on Tuesday September 20 2022, @07:36PM (3 children)
Thanks, that's what i was going for.
Really, you bring them up constantly; its hard to beleive you forgot about them.
I honestly don't have much experience with vmware beyond the desktop edition and even that was years ago -- is it really that bad? I do have experience with Citrix Xenserver and HyperV, along with docker/kubernetes clusters. I agree with your position that hiring a good admin for a few bucks more makes sense, but as I see it, vmware is just another tool, and I can hire a guy who knows how to use it. And they'll be easier to replace when they move on too, especially if they moves on suddenly.
(Score: 2) by darkpixel on Tuesday September 20 2022, @08:27PM (2 children)
Sure. It is just another tool, and you can hire all sorts of people who claim to know how to use it.
But if your hiring requirements are "need someone who knows vSphere", either you have an existing problem that needs to be supported, or your requirements are wrong.
Once upon a time I had a company try to recruit me as their first developer hire for a new product they wanted to develop.
After we got to talking, they flat-out said "we have this Python web app that basically works, but we want to re-write it in Visual Basic .NET". I asked why that was a requirement, and they said "the CEO knows and likes Visual Basic .NET".
I declined and told them that I thought VB.NET was the wrong language and platform for an app they thought would end up being on the scale of Facebook and that if the CEO likes and knows VB.NET, he should develop it.
(I can read VB, and had written some VB code decades ago, but it's not even on my resume.)
I'm sure they got a ton of other applicants who all knew VB.NET and were happy to waste time and effort on it.
It's been about 8 years since that interview--and I know a few people in other areas of that company, and they've all told me the same thing: They tried to build the app, it took years, and it never took off because of licensing costs, inability to scale, crashes, etc... Customers were still using the old Python app and paying for it... then the dev team decided to nuke the old Python app and force customers to switch to the new VB.NET powered site. That year the company lost nearly $4,000,000 in contracts as customers cancelled.
Don't set arbitrary and stupid requirements.
If a company chooses VMware, ConnectWise, or Windows as a solution to a problem, chances are they've made a lot of other dumb decisions and I'm not interested in working for/with them.
(Score: 2) by vux984 on Tuesday September 20 2022, @08:53PM (1 child)
One of my clients builds windows software because nobody would buy their medical devices if it didn't work with windows. Another uses windows because the lathes they use, use windows. Another uses windows because the point of sale system is windows, and the point of sale system is some industry specific thing with all kinds of b2b integration with key partners and vendors. They switch to something else, they're at such a huge disadvantage relative to their competitors they may as well just close shop. They use Windows servers because it REALLY doesn't make sense to use anything else.
Another client, runs a B2B cloud platform, and that's all built on linux servers, well ... linux docker containers running on kubernetes; but even that has windows kicking around because some of the software they develop is client side integrations with the cloud platform that must run on windows.
I like *nix as much as the next person here, and there are some businesses that can (and should) exit windows, but there's a multitude more that can't and shouldn't.
vmware ... I honestly don't know where exactly there is a business case for it vs other options. I do see lots of cases where hyperV makes a lot of sense though. You mentioned running 140 hypervisors accross 30 companies; for example; and in a small business that is already running windows on 20 or 100 clients, and it already has and needs some windows admin skills; then if they also need a few servers, and it makes sense to deploy a few hypervisors for them, then hyperV really does makes a lot of sense vs deploying a whole different platform just for 3 or 4 systems that will require a completely different set of admins/skills to even do the day-to-day management.
connectwise -- that came out of the blue here; you must really hate it. I don't have an opinion of it, but if you are raging against the whole remote-managment/monitoring/Asset tracking/device health monitoring, category I can't really agree. Especially at the 'small/medium business' category, where you just can't economically in-source all the skills for all the technologies you use.
(Score: 2) by darkpixel on Tuesday September 20 2022, @09:41PM
That's simply not true. The FDA approval process is the same regardless of using Windows or Linux.
"Vendor lock-in" or "Product X is required to do our job but the developers are completely incompetent and can't build cross-platform software" are perfectly valid, non-arbitrary reasons to use Windows.
I used to do some work for a client that had 50-year-old machines that communicated over serial to a "special" Windows 2000 box using some proprietary ISA card...and that machine was tied into Exchange 2003 as part of their business process. 100% developer incompetence...but that was the situation.
Newer versions of Exchange wouldn't work and there was no support for using alternate mail platforms. Something to do with OLE Embedded objects and strange arcane databases. Anyways, this client would lose millions of dollars per day if this box was down. They arrived at their solution because the cost of modernizing everything was on the order of several hundred million dollars. It's 2022. They're still running Exchange 2003 to this day. They pay Microsoft a hefty chunk of change each year to keep patching Exchange 2003 when timezones change. It's way cheaper than hundreds of millions of dollars.
For that one client that went the VMware route, it was about centralizing an app/database used by 35 offices and accessing it via RDP. They had a requirement of five-nines of uptime during business hours.
The cost was somewhere on the order of ~$150,000 in software/licensing/support and a yearly cost of ~$35k for the rack space, cooling, generator power, an "enterprise" contract/tech who "knew" VMware, etc...
We replaced the entire solution with about $20k in hardware (new servers, UPS units, and ditching Linksys switches) and had 3 years with zero downtime during business hours. Then they scrapped their centralization effort because they were moving from one software package to another and the app/database was completely unfamiliar to staff and didn't work very well. Another Windows-only developer that refused to use anything other than MSSQL with a .NET Framework front-end. But I digress.
You are correct, sir. I was at a company that decided to start using ConnectWise. It cost them around $50k to get it set up and running. They had a promise from ConnectWise that they had 3 months to try it, and if they didn't like it, they would refund the money.
The CEO loved it because he could build add-ons in .NET and it had a MSSQL backend. In the first two months I sent over 200 screenshots of the app crashing and several e-mails from customers saying they hated it. The CEO ignored it.
That was almost 20 years ago. I left the company a long, long time ago. About a year ago a bunch of their customers called me and switched. I finally figured out why. In 2021 they were still tied into Exchange 2008, the crappy SQL 2005 backend, and a Windows 2008 server. They didn't pay for upgrades and maintenance because it was "too expensive" (tens of thousands per year), and their server finally got compromised. Big win for me.
Sure--I completely agree. I've worked with companies before who have said "we aren't going to use you because we want all our IT knowledge to be in-house". One of them ended up trying to implement in-house what my company does. In less than a year, they were calling me in a panic because their staff had figured out just enough to deploy stuff to production, but when their first hard drive died in a server, they didn't know the commands to replace it.
The point is, you don't need to in-source every last IT thing, you just need a company that knows how to do it while not charging you an arm and a leg.
I manage approximately 140 hypervisors, 400 VMs, 80 routers, about 500 switches/WAPs, 600 phones, 3,400 desktop machines at 90 locations. I do it with a team of three people thanks to proper engineering, automation, and actually solving problems instead of doing the quickest possible fix to get the customer off the phone in order to keep my "support staff body count" low. Oh, and I don't hire support staff at minimum wage. I find competent people and pay them well.
It's a huge problem in IT. The thought process seems to be "let's hire a few guys, charge clients $500/office/mo for remote support, backups, patching, etc....and then cut corners and have long hold times so we can milk as much money out of this as possible, and recommend products like Datto that give us kickbacks or discounts so the customer can't find it cheaper elsewhere".
(Score: 4, Interesting) by jb on Tuesday September 20 2022, @04:12AM (1 child)
In the order you asked: yes; not sure what you mean by that; and yes.
"Missing features" is a big advantage: it's well known that the more complex a system grows to become, the less reliable it becomes, the less secure it becomes and the more compromises get made that ensure that it's never the best at any specific thing it does (one cannot "be all things to all men" and nor can any software system, at least not efficiently & productively).
"Less enterprise support" is also a good thing: if your computing department don't know how to support it themselves, there are only two possible causes: either the vendor is hiding important information from you (which should result in automatic disqualification) or you've hired incompetent computing personnel (so replace them). When "enterprise support" is available, some sneaky salesman might end up conning your (non-technical) senior management into buying it, thereby making it near impossible for the computing department to do their jobs without relying on an external single point of failure (and who gets the blame when that risk eventuates? Certainly not the C-suite who insisted against all reason on creating that SPoF in the first place...).
The only thing that's worse than a lack of documentation is documentation that's just plain wrong (like most of the junk one can find on third party "help" sites). In documentation, quality is far more important than quantity. For example, on this topic, it's hard to fault the quality of the vmd(8/amd64), ldomd(8/sparc64) etc. man pages ... and in the rare circumstances of coming up against a new bug, of course there's no substitute for having access to the source.
Given that m68k did not do branch prediction, it'd probably be a far saner architecture for virtualisation than amd64, if only it had survived to the present day & evolved at a similar rate to other second-tier archs (e.g. sparc or mips). Plus its instruction set made m68k assembly far easier to read (and write!) than i386/amd64. Great shame it did not survive.
(Score: 2) by vux984 on Tuesday September 20 2022, @08:30PM
Unless it's missing something you need to use, or have to work harder to get around.
That's a false dilemma. The mere availability of enterprise support doesn't mean your IT people must be incompetent. By that logic, if you deploy Red Hat for years, and then decide to subscribe to RHEL, you lose all your skills to problem solve anything yourself? How does that work?
If your computing department don't know how to support themselves at all then you are doing it wrong, but if they are totally self reliant down to the point where they are reading the source code to investigate rare obscure bugs... then guess what... you are still doing it wrong.
If you have incompetent non-technical management who fall for sneaky sales pitches for company destroying solutions, you are doomed anyway.
If a "system administrator" is doing anything useful by reading source, then you are probably wasting him on "system admin". If you've got someone doing system admin: (Planning / Deploying / running / monitoring / maintaining systems, backups, hardware/software/firmware updates, etc) and he's reading man pages and source code to resolve tricky issues, and he's actually any good at it ... then congratulations you've hired a mechanical engineer to do the janitors job. Don't get me wrong, mechanical engineers make fantastic janitors... but if you've got a mechanical engineer on staff, do you really want him wasting his time doing the janitors job?