Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Why doesn't vmware upstream these patches? #266

Open
bogardon opened this issue Jul 29, 2024 · 5 comments
Open

[Question] Why doesn't vmware upstream these patches? #266

bogardon opened this issue Jul 29, 2024 · 5 comments

Comments

@bogardon
Copy link

vmware/broadcom are still releasing new vmware versions for linux, but why don't they also patch their modules so it compiles on recent kernels? it seems weird that we're all relying on @mkubecek (god bless) to patch things time and time again.

what is the most recent kernel that vmware actually supports?

apologies if this has been answered before.

@Manfred-Knick
Copy link

Manfred-Knick commented Aug 2, 2024

VMware has never ever committed to anything like "the most recent (vanilla) kernel supported".

"Supported host operating systems ..." :
https://knowledge.broadcom.com/external/article?legacyId=80807

For 17.5, evaluating the above list against www.kernel.org, I result into --> LTE 6.1 .

@robertstrom
Copy link

So how is it that VMware Workstation on Windows never seems to break through all of the monthly patching (of Windows) that happens in between releases of Workstation. Surely there are changes to the Windows kernel. Why does it almost always break on Linux, but not on Windows? Same with VMware Fusion. I have never seen it break like it does on Linux.

@Manfred-Knick
Copy link

Manfred-Knick commented Aug 2, 2024

Please, comprehend that VMware is primarily interested in making money by selling to commercial customers,
exploiting co-operation with their Enterprise Partners. +++ FULL STOP +++

I suggest viewing VMware Workstation (and, formerly, Player) as supplemental to their expensive Enterprise solutions,
providing some support for rather matured versions of open-source-distributions
as exceptions supplemental to their respective enterprise counterparts.

With Microsoft as their outstanding Partner,
their development departments will receive heavy-weighted assistance and advanced information support -
which surely will not be disclosed to open-source projects: Heaven forbid!

Expecting benevolent permanent renewed support
. - for open-source,
. - for every new kernel version,
. - for every common-or-garden distribution
from VMware is simply naive.
Such a commitment has never ever been granted: Perish the thought!

Much could be spared if this reality could finally be allowed to sink in.

Last not least, it is not only my personal impression that Broadcom seems primarily interested
in enhancing the revenue out of their purchase.

ERGO:

Lots of us have been grateful for Michal Kubeček's mature patches against respective recent kernels.

The current massive hi-jacking of this repository with hundreds of half-baked mee-too-posts is not helpful at all:
#239 (comment) .

I myself definitely refrain from deploying "solutions" not finally approved by an experienced kernel developer,
particularly for productive use.

EDIT:
Furthermore, for me, the late XZ backdoor debacle will persist as a strong reminder ...
In 1135 a.C., although being warned by Laokoon ("quidquid id est, timeo Danaos et dona ferentes"),
Trojans chose to learn that the hard way ...

@rakotomandimby
Copy link

@robertstrom , it is because Microsoft is more carrying about backward compatibility than the Linux kernel. One will always find an exception to what I just wrote, but community driven software can brake backward compatibility without notice. Windows cannot do that as freely as Linux.

@Manfred-Knick
Copy link

With all due respect: This proposition is misleading, at least, to put it mildly.

.- Linux kernel guarantees stability for its external programming API

. - -> Linus Torvalds: "We don't break user space!"

.- VMware exploits internal programming API calls, knowing that
.- stability of internal programming API is not being guaranteed

.- Thus, when loading VMware modules, the kernel correctly qualifies itself as "tainted"

VMware nevertheless decided not to invest into keeping up with
development of internal calls being exploited in / for their (closed-source) application.
Which is righteously their sovereignty.

"Supported ..." : The marks are clearly set.

" Love it - change it - or leave it "

mkubecek supported "change it" :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants