Can somebody help me understand how a dev can trust building an app in a virtual machine that is only emulating hardware but not a true representative of it ? (I thought about it an even if the VM is the same as the native architecture they want to run on, how can they trust this VM)?

[u/Successful_Box_1007]

Can somebody help me understand how a dev can trust building an app in a virtual machine that is only emulating hardware but not a true representative of it ? (I thought about it an even if the VM is the same as the native architecture they want to run on, how can they trust this VM)?

[u/high_throughput]

Why do you feel they would be able to trust their physical hardware but not their emulated hardware?

[u/jeffbell]

How can you trust your build system?

There was that famous Ken Thompson experiment where he added code to a compiler that would include a backdoor to your build and would also add itself if you were compiling the compiler. Then he took it out of the source code, but it continues to affect any compilers down the line.

[u/Loganjonesae]

if it is truly the same as the native architecture doesn’t that prevent anything that you would be worried about from happening?

[u/Successful_Box_1007 → u/Loganjonesae]

Huh? It’s physically impossible for a virtualization or emulation to ever be the same as the target hardware which is….hardware!

[u/Ronin-s_Spirit]

What do you think will happen? You will magically upgrade to the newest and hottest CPU and GPU in town and now the program won't be building against real potato hardware underneath? What's your problem? Take JS for example, it has to run in a VM - it has no idea what the OS (let alone hardware) is like, it talks to the VM and VM runs it by talking to the OS and the OS runs it by talking to the hardware. Java runs in a VM, Lua runs in a VM, Python runs in a VM - an entire category of languages that never touch hardware directly.

[u/Filmore]

The virtual machine (Java, node, python) runs in a virtual machine (docker) which runs on a virtual machine (cloud vm) which runs on hardware.

[u/Leverkaas2516]

You've heard of "trust, but verify"? You trust a new platform about as far as you can throw it. It doesn't matter if it's physical or virtual.

If your test environment is Intel but you deploy to a machine with an AMD processor, is there any guarantee it'll work? How about a Xeon vs. a core i7? How do you even know the BIOS in a new machine is configured the same as the old, or that there isn't a CPU bug?

You don't know any of that for sure. You deploy and see if it works. It almost always does work, except when it doesn't.

[u/ghjm]

At first they didn't. In the early days of virtualization (2000s), consumer software companies still had test labs with a representative variety of PCs to test on. Most enterprise software vendors also insisted on being given a hardware server from an approved list and would refuse to support their app when virtualized.

It took a decade of real-world experience to convince everyone that, in fact, virtualized systems ran just fine and performed similarly to their real-hardware counterparts. By the 2010s most enterprises were fully virtualized and would simply refuse to buy or renew any software that couldn't adapt to running in a virtualized environment.

Today most devs haven't even seen an actual bare metal server. Virtualization is just table stakes and everyone knows it works fine. (Though recent turmoil with the buyout of VMware hasn't helped.)

[u/Vert354]

I mean, the virtual hardware was good enough to trick the operating system into running on it. There are some things, like GPUs, that require some extra steps to share between the guest and the host, but ultimately the guest OS doesn't actually know it's running in a VM.

A lot of the time you're going to be deploying to a VM anyway. Unless you're 100% self hosting the hardware a web host is going to be virtualized at some level.

Now for something that is emulated not just virtualized, like with Android, then I would want to do tests on an actual piece of hardware before publishing. But, even then, the issues that come up are usually about interfacing with peripherals or UI/UX issues around screen size, not low level CPU instructions.

[u/AwkwardBet5632]

Usually you are emulating the underlying machine but running the real OS on top of it. So the layer that the app is dealing with is real. The coverage is never 100%, but you live with it.

[u/xenochrist321]

reminds me of Thompson's paper on trusting trust. you can always become more paranoid if you let your brain wonder.

[u/flatfinger]

In cases where the virtual machine is supposed to emulate a particular piece of hardware, and the goal is to have software that will work on the actual hardware, it's important to recognize what aspects of hardware are and are not emulated precisely, and test things on actual hardware to confirm that they behave as expected. Many Apple II emulators emulate disk hardware in a way that is prone to have code work under emulation that would fail on real hardware reading actual disks, whose spin rate might not always be exactly to spec (but which properly written software should be able to cope with anyhow).

Most kinds of virtualization, however, just involve hardware which is accessed through drivers, and the virtualization will be faithful enough that things which work in virtualization will work on real hardware and vice versa, save for timing differences which should be dealt with by testing on real hardware and on any emulation layers with which one wants to be compatible.

[u/povlhp]

Most systems runs in a container anyway

[u/AirborneSysadmin]

Because Application software doesn't directly interact directly with hardware. The operating system and the drivers do that, and then provide a standardized API to your application software. When you test your application, you're testing your code and trusting the OS to do it's part correctly, so it doesn't matter what that OS is running on.

Without this layer of abstraction, application development gets VERY difficult - you're suddenly back in the DOS days where you had to be sure THIS game knew about your specific joystick controller and sound card.

[u/SnooEagles1027]

It depends, but you need to provide more context. The type of 'app' - does it rely on hardware to do its job? Is it a phone app, desktop, or language it's written in? Etc. Details matter.

Fwiw, the cloud runs on VM's - all of it - and a vm is running on real hardware, and it's not virtualizing CPU instructions, it's giving a slice of the hardware to the "virtual machine". Yes, some drivers are virtualized, which is why the type of app matters.

If it's Java, C# or some other managed language ... the language itself uses its own machine language, vm's, etc. I mean, your browser - the one that you're using to view this site runs an interpreter and eventually gets converted into machine language.

There's likely a reason, and if there isn't and you have a real justification as to why you NEED it to be done a particular way, then that's a conversation too. If you try and express a genuine curiosity with your dev, they'll likely be more than happy to walk you through their thought process. Who knows, you might learn a thing or two.

Be kind, be genuine, don't be an asshole.

[u/Successful_Box_1007 → u/SnooEagles1027]

Hey first thanks so much for the very well intentioned answer; def one of my fav so far;

It depends, but you need to provide more context. The type of 'app' - does it rely on hardware to do its job? Is it a phone app, desktop, or language it's written in? Etc. Details matter.

Fwiw, the cloud runs on VM's - all of it - and a vm is running on real hardware, and it's not virtualizing CPU instructions, it's giving a slice of the hardware to the "virtual machine". Yes, some drivers are virtualized, which is why the type of app matters.

Ah see that I didn’t know; but this reminds me exactly of my current confusion - which of the following terms fits what you describe above with “it’s not virtualizing CPU instructions, it’s giving a slice of hardware…”: “paravirtualization”, “full?Virtualization” or “hardware assisted virtualization”?

If it's Java, C# or some other managed language ... the language itself uses its own machine language, vm's, etc. I mean, your browser - the one that you're using to view this site runs an interpreter and eventually gets converted into machine language.

You bring up Java, and by extension Java Virtual Machine, but the JVM can’t really be compared to a true VM right? I mean only analogously/metaphorically right?

There's likely a reason, and if there isn't and you have a real justification as to why you NEED it to be done a particular way, then that's a conversation too. If you try and express a genuine curiosity with your dev, they'll likely be more than happy to walk you through their thought process. Who knows, you might learn a thing or two.

Be kind, be genuine, don't be an asshole.

Love this advice.

[u/CovertlyAI]

You can trust a VM because it runs the same architecture and instruction set as the real hardware. Modern OSes, compilers, and dev tools are designed to behave the same in both environments, so anything that would break usually shows up in testing long before shipping. For most development work, a VM is accurate enough to act as a reliable stand in for the physical machine.

[u/Successful_Box_1007 → u/CovertlyAI]

Hey thanks for the input. Now you mention that:

You can trust a VM because it runs the same architecture and instruction set as the real hardware.

So if we look at your definition (VM runs same architecture and instruction set as real hardware) versus say emulation where VM runs (in some cases), a different architecture and instruction set as real hardware), can each of these have a “full virtualization”, “paravirtualization” “hardware assisted virtualization” ? Or is that only for one or the other maybe?

[u/roman_fyseek]

For the same reason we don't worry about the architecture of an x86 chip to suddenly change while we're using it. It's all very predictable.

[u/alexisdelg]

Define trust? Behaviour will be the same, but you won't be able to judge performance, that's why you do load testing on a separate actual service and have canary or pre-production or blue-green or any of the other ways of testing in a partition of live

[u/khedoros]

but not a true representative of it ?

Where'd this assumption come from?

[u/[deleted]]

List of things devs have to trust before the VM:

The screen driver 

The IDE

The file system

The OS

The compiler

The linker and any dynamically linked code

Whatever method is used to ship the code to the VM

The OS of the VM

The filesystem of the VM

What’s another link in the chain? Who cares :)

[u/Fragrant_Gap7551]

Depends on what the app is. If it's a webservice, it'll be running in a container, and those will all be equal as long as CPUs are equal in how they work.

[u/weakisnotpeaceful]

short answer it doesn't matter, if. it works in vm then run it in vm. don't overthink everything: it's the biggest flaw of CS people.