Yes I think everyone has an opinion on this, nobody likes to see good stuff go downhill and go down the drain. But I left that aside.
I don't think about it cause I'm not ready to accept the likely loss of of even more good tech :) I haven't surrendered on MS with the Windows family so..
ESXi is sort of on a lifeline so it's not all a lost cause yet.
With the changes though the support for development with API docs etc by Broadcom could be a game changer - opening up the framework leading to FOSS/community tools and software being built would be exciting.
Imagine VMW but with third-parties fleshing out what is missing.
Windows is a poor place to do virtualization nowadays (for anything that's not enterprise/cloud)
-------------------------------------------
Original Message:
Sent: Jul 29, 2025 01:15 PM
From: Value Broadcom
Subject: VMWare Workstation 17.6 - Broken Software Updates mechanism (serious)
This is just the tip of the iceberg. After VMware was acquired by Broadcom, Workstation Pro became a joke. It's now full of bugs because we didn't pay for it. Just manually download the latest version from Broadcom's support website and hope it gets fixed someday.
Original Message:
Sent: Jul 20, 2025 04:35 AM
From: Ben Ryan
Subject: VMWare Workstation 17.6 - Broken Software Updates mechanism (serious)
Running 17.6.3 build-24583834on Win11x64
Seeing regular DNS queries issued from the host for FQDN "broadcom.com" - which return what looks like the SOA record
In the client, running the check for Software Updates errors out with "Disconnected - The update server could not be resolved. Check your Internet settings or contact your system administrator." That dialog says the update server is "https://softwareupdate.broadcom.com/cds"
Aha this is triggered by the fact that softwareupdate.broadcom.com. returns a Name Error - the hostname hasn't even been registered yet?!
I thought maybe there was a bug in the updates mechanism in this build, until I ran an nslookup for the updates server hostname :)
Guess I just saw windows doing name devolution on a non-existent fdqn
Obviously related to the changes Broadcom's making specifically with the vmware s/w update channels but it's not a good look.
The telemetry part is working fine, logs and packet dump say so anyway (funny they got the telemetry working fine)
Can anyone confirm?
ben