[kwlug disc.] vmware and fedora and corporate responsibility -- what's the deal?

[unsolicited]

Robert P. J. Day wrote, On 8/19/2007 11:20 AM:
>   as a followup to my earlier post on vmware player not installing
> properly on a fully-updated fedora 7, i'm interested in others'
> opinions on how annoyed i should be about this.  or whether i have the
> right to be annoyed at all.

You're coming from the 'wrong' perspective.

You're coming from a FOSS perspective, whereas they grew up from a
'non-FOSS' perspective (despite ESX being Red Hat based).

You're not being unreasonable, you're just in two different universes.

It is only relatively recently that there even have been Linux
versions. And it is only relatively recently that they have completely
revamped their product line. e.g. Many products being free.

And only relatively recently that they appear to have committed
themselves to coming out with Linux versions of everything.

One of the things they, like many others, have struggled with is just
what distros to support, let alone how recent.

And being closely tied to the kernel, they are wary of bleed-out on
being bleeding edge, particularly on a FOSS thing they make no direct
income on. They hope, without assurance, that you'll like their free
stuff so much, and see so much advantage in doing so, that you'll go
spend hard cash on their other product lines.

Your annoyance is something most have shared for years. It's just the
way it's been. And what one has to live with. It's not just the Linux
side, this has been noticeable on the Windows side as well,
particularly as new hardware lands such as network storage connected
to Blade Centers via fibre, etc.

In my perception, they get a bit better on things every year. In my
mind, this is all a direct result of Linux gaining more popularity,
and the number of 'mainstream' distro's settling down. I don't think
vmware is unique in where they're at, like many others they're
struggling towards 'the new reality,' whatever that is.

Virtualization is still in the dancing bear world. Doesn't really
matter how well the bear dances, the fact that it dances at all is
what's important. Until the quality of the dance starts to matter, by
means of virtualization product saturation as well as competition,
this situation will continue. Once those points are hit, then, and
only then, will not addressing these issues start to affect the
viability of the company. At which point your (and everyone's)
irritations will be better addressed.

> 
>   a decent discussion on this topic is here:
> 
> http://www.vmware.com/community/thread.jspa?messageID=696176
> 
> note the primary point that's being presented there -- that an updated
> version of fedora 7 will contain a "bleeding edge" linux kernel that's
> not supported by vmware.  but just how convincing a defense is that?

In a Windows / non-FOSS world, very.

Do I want you to support that new storage array first, or that Linux
distro I don't use?

> 
>   the last recent major release of the kernel that contained the
> vmware-incompatible change is 2.6.22, which had a release date of july
> 8.  so it's been almost six weeks and, given that fedora has a
> reputation of being bleeding edge in the first place, one would think
> that six weeks is more than enough time for a company to update their
> source to handle that change, *especially* when we're talking about a
> distro that's one of the most popular on the planet.  but it's
> actually worse than that.

Think BSD not Linux in terms of attitude / approach. Rock-solid bullet
proof service with 99 44/100 % uptime. It matters less if we support
that widget if we don't go down.

You're serving up slices of CPU, memory, disk, whatever. Where is the
majority of my immediately incoming revenue stream coming from -
customers who want to risk moving their backbone servers to the latest
and greatest Linux, or those running out of space and need the latest
largest storage array? Do they need to serve out sessions to users a
la terminal server from a central server replicated elsewhere with
seamless failover, support 10 GB storage backbones, or support yet
another kernel rev.?

>   as i mentioned earlier, that actual change was applied to the main
> kernel git tree back on april 10, which means it's been over *four
> months* that the kernel tree wouldn't have worked with vmware player.
> it may be true that a company has no obligation to be compatible with

They are obligated to do zip.

Except serve their shareholders by expending resources in the order of
maximum return.

> the latest git tree, but it would seem that it would be at least a
> little irresponsible to not be *tracking* the tree on a regular basis

Irresponsible? To whom?

> so that you can flag these things the instant they appear and prepare
> to deal with them when the time comes.

Why?

The majority of your customer base doesn't move that fast. And you
have to look at where the majority of your new sales come from. From
their actions, presumably it will not be as a result of supporting
this kernel.

> 
>   the fact that vmware knew (should have known?) about this issue over
> four months ago and did nothing about it, causing grief for numerous
> users upon release of a new kernel, strikes me as just plain bad
> quality assurance.  but i'm willing to be convinced otherwise.
> 
> rday

Pardon me, but your indignance is sounding like someone who didn't get
their ice cream. Like you are entitled. And typically people don't
react very well to that.

Cheers.

-- Bill