90% of the time I receive an auto-reply that "support is offline", and am prompted to enter an email address. Which just proves the whole thing is pointless when you have customers/users/visitors in foreign timezones.

Yes, designers should make quality webpages. But if history is any indicator, they won't. It's easier, imo, to filter out those bad designs.

Well, they claim it's "like QEMU but 5 times faster!" but that's probably in some specific test conditions. I can't find any proof to this claim such as an independent review of their software across a variety of productive use scenarios.

> You can even run Windows applications on your ARM Mini PC using x86 Wine.

Or, wait until Microsoft finalises their x86 translation layer for Windows 10 ARM, and don't bother with running an i686 Linux distribution under emulation and running Wine within that. They don't seem to support x86_64 Linux distributions, so I wonder what they're planning to do since some distributions will be dropping i686 support soon. [0]

If you wanted to run Windows binaries on an ARM board, I can't see why you'd go for this over Windows 10 with x86 translation. No sane x86 proprietary software vendor would ever support Exagear's solution.

[0] https://www.archlinux.org/news/phasing-out-i686-support/

https://eltechs.com/qemu-exagear-on-raspberry-pi/

Not vouching for them, just noting that some were published.

For example, one test the benchmark runs is x264 – H.264 video encoding where apparently ExaGear is an amazing 9.21 times faster than QEMU.

No frame rate mentioned for either QEMU or ExaGear, and they don't include a comparison to x264 encoding running natively (probably because it would make ExaGear look quite bad).

They also don't mention at all what QEMU options they're using. Maybe they're emulating an x86 in QEMU which lacks SIMD instructions? It's impossible to know without them publishing more information about their test methodology.

http://parsec.cs.princeton.edu/

Feel free to bug Princeton if you need specifics. I mean, I don't really care about this program, but it's not that difficult to beat qemu. Their whole thing is that they focus on accuracy and cross-platform compatibility. Both those things make optimizations difficult-at-best. If you're only coding a VM for a certain translation (x86->ARM, for instance), you can optimize like crazy.

ARM64, not ARMv7.

Also, from what I hear, binaries need to be compiled specifically for this - others just use a slower JIT emulator.

The BCM2837 on the RPi 3 is ARMv8 (aarch64/ARM64). [0]

[0] https://devsidestory.com/build-a-64-bit-kernel-for-your-rasp...

Oh, you mean for you? It's not clear if there are. You possibly save time trying to configure everything (qemu, storage for disk images, installing an OS under qemu, configuring the OS for OpenGL acceleration under qemu), so that might be worth it if you don't have the time or don't want to learn how to do it yourself.

https://wiki.debian.org/QemuUserEmulation

Using AFL like this sounds like it could be fun to experiment/play with, although I don't know if it has the necessary comprehension to handle "emulation or host program running guest program" semantics at the moment, where two programs (the emulator and the guest program) both need to be tracked for best results.

These ideas don't exactly find any time to fix bugs, however...

Thanks for explaining that. I was actually aiming to describe code coverage in my previous comment, but completely overshot that and went to fuzzing instead, lol.

I just found https://coverage.nodejs.org/, which you're probably already aware of. Apparently it uses istanbul for JS coverage and gcov for V8.

Also, https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#s... says that `make test` runs tests, presumably from https://github.com/nodejs/node/tree/master/test. Thinking about it, if Node.js' tests pass running under QEMU usermode, that should be good evidence that QEMU usermode is working too, right?

Looking further afield, I wonder if running tests from other large projects - Qt comes to mind, although you could also be utterly insane and try GCC/LLVM xD - could be used to exercise QEMU.

As an aside, I'm very curious to learn what QEMU's corner cases are, if just so that if I want to do horrible things in ELF files one day I know what won't work. :P

Or to put it another way, "just run qemu" is a useful response to some people and not to others.

The technology is only part of the story. The context of the larger ecosystem is also relevant to people.

In this context it doesn't really matter how good virt-manager is because it does not directly solve the problem. Instead it is just a for of the rabbit hole of Linux systems administration...I mean suddenly KVM got thrown into the discussion. That's great for someone whose goals include learning the difference between KVM and qemu. It's not great for someone who wants to run Winzip in NOOBS and doesn't really understand why it should be a technical issue.

Don't get me wrong. I am fan of free software and think Stallman is right and has changed the world for the better. But I'm ok with people paying money to solve their problems and $50 is cheaper than hiring a consultant to setup qemu or virt-manager and configure it to solve the original problem. It's also cheaper than the time it takes to discover virt-manager and decide that it is trust worthy and understand what it does and why it solves the problem and get it installed and configured.

I mean the typical event sequence is hear about qemu. Try to figure it out. Maybe install it. Struggle to get it to work. Read some more blogs that are written by people who already know qemu. Maybe see something about virt-manager after a few days. Install it. Struggle to get it to work. Read some blogs by people who already know virt-manager. Hear about KVM, think maybe that's the solution. Etc.

The difficult part of Linux is that in the end the answers lie in man pages and info files and the ability to read and parse those has a long and often steep learning curve. Spending all one's workdays in a community of people working up the same learning curve makes it easier. For the person who is often the most technical person in the room simply because they can run command.com and type dir, qemu and virt-manager are not NOOBS friendly.

If you have an x86 app then by far the best way to run it is on an x86 box, because there's just so much x86 hardware available and it will just work. If none of the people familiar with a problem space have felt it worth the effort to make a simple writeup of a particular technical approach, there's probably a reason why not...

To put it another way, if a hobbyist has an Rpi then "buy an x86 board" might be kinda sorta be missing the point...part of the point is often running things on the Rpi. Even at the technical end, running an x86 board to make LED's blink or to warn when the ficus needs watering requires engagement with a different culture. x86 boards are not marketed and sold and blogged about and Youtubed like Rpi's.

One of the features of the Rpi is that it is accessible. There is a well established channel and culture around selling them one at a time to people who will only ever buy one. That's not the world that most open source projects live in.

The advantage of Linux is that it makes doing hard technical things less hard. The disadvantage of Linux is that it makes doing technically easy things harder...not because of a technical shortcoming but due to community norms. One of those community norms is to frown upon approaches that are not considered technically best.

It's ok if someone else doesn't do things the best way over the long run. Most of what most people do on computers is disposable and unimportant. There's no need to boil the ocean. Excellence when unzipping a file is not really necessary, and settling for good enough is not a moral failing. By 'good enough' I mean good enough for the user, not for an old Linux hand.

Good solutions meet the user where they are not where someone else is. If I'm standing at someone's desk in a place of business, then the "use a native Linux program" might do that because I am there to guide them through it and I will be there in two weeks when they have to do it again and in two months and so on...though that perhaps suggests another reason to just let that person run Winzip with poor performance.

From personal experience of learning Linux on my own, eventually after several years I have reached the point where I usually try to do things a Linuxy way, first...or within an hour or two of trying to do it a more familiar way. Doing things in a Linuxy way means I often wind up boiling a large lake if not the ocean.

Sometimes I think, Norvig's advice [2] is better for teachers than students.

[1]: https://meta.stackexchange.com/questions/66377/what-is-the-x...

[2]: http://norvig.com/21-days.html

It seems like someone packaged up Chromium with Widevine already installed, and then provided instructions for changing the agent string to something appropriate. The post is under a month old, and it came up in a discussion about a couple of alternate Linux distros for the Pi that are trying to make their name based on Netflix compatibility.

This only happens because of proprietary software shipped in binary format. I'm not against proprietary software, but at some point vendors need to ship in a different format like LLVM bitcode or something that the customer can re-target.

Sun set out to solve this 23 years ago. It didn't work out very well, mainly because of a) Microsoft and b) native UIs being different and Java's UI solutions being slow (IMHO). Also, Sun failed...

Microsoft is already preparing for the ARM-war with Windows 10 on ARM, intel has already made threats that x86 emulation is a litigious minefield, etc. They need to go, and I think Microsoft has their hammer and nails ready for the service.

Bill Gates should spend some of that charity money on LLVM, that'd be great too.

Any feedback from people using something similar and their uses cases is interesting to me.

Thanks!

[1] https://eltechs.com/company/about-us/