Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.electronics.design > #451779

Re: VMware v VirtualBox

Show all headers | View raw

On 3/13/2017 3:33 PM, Jon Elson wrote:
> Don Y wrote:
>
>> A colleague asked for my opinions of the two.  But, I only
>> run VMware.  Some googling turns up LOTS of hits re: this
>> issue.  But, all seem to be pretty "sterile" writings.
>>
>> Anyone with experience with *both* (or, who left one in favor
>> of the other) to share some first-hand experiences?
>>
>> [AFAICT, he's looking for this as a way of supporting legacy
>> tools w/o dedicating hardware to the task]
> VMWare's tech support is absolutely the worst in the world!  They make you
> pay to get tech support, and then can't answer the question.  I had some
> simple issues, I ended up telling them how to fix it.

I can't recall relying on "tech support" for ANY product in the past
couple of decades.  The last such contact (telephone call!) was for MS's
first VC++ product.  I interrupted the support guy before he could start
on his "script" and said:
    "Open the product.  Type in the following ~6 lines of code.  Compile.
    See the problem?"
To which he replied:
    "Yup!  You've found a bug.  But, we no longer support that version
    of the product.  For $99 you can upgrade to the NEXT version..."
    <plonk>

> VirtualBox works pretty well.  I can point to a few TINY little nits.
> VMWare keeps separate state for the shift lock in each guest OS, separate
> from the host OS.  VirtualBox seems to only have one shift lock state.

Hmmm... I'd have to think how that would impact *me* -- to imagine how it
might impact others.  I routinely work with as many as six (physical)
workstations, simultaneously, so I manage different UI states all the
time (along with different keyboard layouts, UI characteristics, etc.).
It might be harder for me to carry some state from one to another when
I regularly discard all of that as I move between workstations.

[I don't think there is an easy way for me to test that short of installing
VBox]

> VMWare allows you to turn the parallel port connection between guest and
> physical hardware on and off.  If the VirtualBox guest OS is interfering
> with the parallel port of your host environment, you have to shut down the
> guest OS.
> I use the parport to run some device programmers.  But, that's a really
> minor issue.

I had a similar issue with an earlier version of VMware and the USB subsystem
(but, IIRC, only under Windows host).

I think most folks can adapt to OBVIOUS problems (whether or not they are truly
"problems" or just "unexpected situations").  The bigger issue seems to always
be those things that defy (obvious) logic and require a fair bit of
head-scratching to resolve.  I.e., if it seemed obvious (to you) that your
guest OS was interfering/interacting with the host application and you just
had to grumble and shut it down, that's an "inconvenience".  OTOH, if you
lose a day or more trying to figure out why it works *now* but didn't work
*yesterday* (because you don't have a VBox instance running *now* but did,
*then*), then that becomes an open sore and source of significant lost time.

I spent a fair bit of time trying to understand why a ~75 page document that
I'd been actively creating/editing was suddenly inaccessible to me.  Attempts
to open it just locked up the application.  Given that I'd been able to open
and close it previously, I suspected I might have reached a limit in document
complexity that was taxing the application.  So, manually started truncating
the document (file) with a binary editor:  "Let me get this back to a size
that *works* and then I'll figure out how to glob the balance onto it..."

I eventually traced the problem -- not to file size but, rather, to some sort
of "font" conflict.  If I removed all references to a particular *style* of a
particular *typeface*, the entire original document was still editable.  And,
that I could re-tag text with that font AFTER the application was opened,
giving me the result desired.  *But*, attempting to reopen it with these
modifications back in place would cause the problem to repeat!  <frown>

That's the sort of effort (days to track down, in my case) that I worry about.

Back to sci.electronics.design | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

VMware v VirtualBox Don Y <blockedofcourse@foo.invalid> - 2017-03-11 22:34 -0700
  Re: VMware v VirtualBox bitrex <bitrex@de.lete.earthlink.net> - 2017-03-12 11:39 -0400
    Re: VMware v VirtualBox Don Y <blockedofcourse@foo.invalid> - 2017-03-12 12:38 -0700
      Re: VMware v VirtualBox bitrex <bitrex@de.lete.earthlink.net> - 2017-03-12 15:51 -0400
        Re: VMware v VirtualBox Don Y <blockedofcourse@foo.invalid> - 2017-03-12 14:23 -0700
          Re: VMware v VirtualBox bitrex <bitrex@de.lete.earthlink.net> - 2017-03-13 10:21 -0400
            Re: VMware v VirtualBox Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2017-03-13 16:57 +0100
            Re: VMware v VirtualBox Jon Elson <jmelson@wustl.edu> - 2017-03-13 17:37 -0500
              Re: VMware v VirtualBox Don Y <blockedofcourse@foo.invalid> - 2017-03-13 17:20 -0700
    Re: VMware v VirtualBox Martin Riddle <martin_ridd@verizon.net> - 2017-03-12 16:08 -0400
  Re: VMware v VirtualBox bitrex <bitrex@de.lete.earthlink.net> - 2017-03-12 15:37 -0400
  Re: VMware v VirtualBox Jasen Betts <jasen@xnet.co.nz> - 2017-03-13 11:18 +0000
  Re: VMware v VirtualBox Jon Elson <jmelson@wustl.edu> - 2017-03-13 17:33 -0500
    Re: VMware v VirtualBox Don Y <blockedofcourse@foo.invalid> - 2017-03-14 09:42 -0700

csiph-web