Here's the thing: Java and .NET have their own instruction sets (there's even a microprocessor that can run Java baremetal). So in my eyes it makes them "VM-y enough". > a VM has to effectively sidestep the underlying OS What do you mean about that? Is a paravirtualized kernel not a VM in your terms because it uses the host's OS API to perform its tasks? Or KVM, because again, it utilizes OS-supplied methods? > running files on a different OS on top of the underlying OS What about virtualizing MCUs/PICs or whatever embedded systems for testing purposes, which have no OS? Is anything a VM then? > PDF readers are VMs I'm not sure about PDFs, but PostScript engines are definitely VMs "I don't think about dying. It is the last thing I want to do. :) " - theoldfool

> but a byte code interpreter cannot be realized by a file system driver Of course it can :P (Not at all saying that you should though...) On a more serious note: you've nicely summed it up. Not all virtualizations are created equal. "I don't think about dying. It is the last thing I want to do. :) " - theoldfool

I usually use TigerVNC, it works OK. Also, there's Remmina, which can connect to both VNC and RDP servers, but has some minor shortcomings in terms of supported features. "I don't think about dying. It is the last thing I want to do. :) " - theoldfool

USB is complicated. Trust me. I would highly discourage you to implement your own. That said, the protocol you're looking for is the USB Mass Storage CDC (Common Device Class). You're probably going to have to toush USB Attached SCSI as well. If you want to do that though, this CH340 won't do, because it is a USB **device** and not a **host**. You'll need something with either a USB ROOT hub (like a RasPi), or USB OTG (I heard some AT90's and PIC16F's are capable of this, but I never found anything like that, so dunno). You also don't "select" devices per se. When a USB device is connected, the USB hub sends you (the ROOT hub) a message. Let's say, it was hub #5. Then you instruct said hub to reset it. This will make the newly attached device assume an address of "5.0". Now, you send a GET DESCRIPTOR followed by a SET ADDRESS to USB address "5.0.0", which is the CONTROL endpoint of the new device. In SET ADDRESS, you give it a permanent address that it can use moving forward. Now, why did I say you don't really "select" devices? Because, even though you *can* address individual devices, *all* attached USB devices will hear the ROOT's messages, and it is up to them to decide whether to activate or not. If you misconfigure a device and cause an address collision, you're screwed. I could go on and on about USB, but I think you get the point: Don't Implement Your Own. For your purposes, I'd use a SD/microSD card instead, as these can be used in SPI transfer mode, which is a cakewalk to implement, as opposed to the pain-in-the-backyard you're gonna have if you try to implement a USB host yourselves. "I don't think about dying. It is the last thing I want to do. :) " - theoldfool

I'm not even old (just above 20) and rarely do I have to go above 1080p... "I don't think about dying. It is the last thing I want to do. :) " - theoldfool

I also thought that a valid JSON document has to have a root object. Is it not the case then? Anyways, I prefer the first one because it's shorter, and since it is a response, you should already well know what's gonna be in it: exactly the data requested. However, I have had some issues with the Java JSON library being unable to parse arrays by themselves. As a result, the way it's implemented in production right now (as suggested by StackOverflow :P ) is as follows: - JSON comes in on the network, looking like the first example you gave - Function checks if it starts with '[' and finds that yes, it does - So it appends some string around the received text, making it look like the second one - JSON lib parses this. The returned JsonObject's only JsonArray member is saved, the rest discarded - Prod code gets this JsonArray back to do whatever Fun times! "I don't think about dying. It is the last thing I want to do. :) " - theoldfool

I'm guessing it is the IntelliJ-based Android Studio we're talking about. IntelliJ is notorious for its long indexing times :P The JVM is - in my experience, at least - not too CPU-intensive, it is mostly the RAM that gets used up quick (or at least with the ConcMarkSweep GC; in Java 8, the G1 seems to do better: -XX:+UseG1GC)

And JavaCard... Edit: I mean yes, in order to make JavaCard a thing, they took out I/O streams, Garbage collection etc. But still, it runs on a string of wire powered by radio waves!