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.
> proprietary software that only does as much as qemu? Any advantages to this?
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.
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.
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.
The Raspberry Pi 3 is ARM64 (Cortex-A53). However the Raspberry Pi foundation has thus far chosen not to ship an aarch64 version of Raspbian so software for previous Raspberry Pi units remains compatible.
The BCM2837 on the RPi 3 is ARMv8 (aarch64/ARM64). [0]
I did mean this
"It's not Windows as most people understand it. A fresh install of Windows 10 on the Raspberry Pi doesn't boot to the familiar Windows desktop. Instead, Windows 10 IoT Core will show users a single full-screen Universal Windows app. The system will only display the interface of a single app at a time, although additional software can be run in the background. Apps are loaded onto the Pi from a Windows 10 desktop machine."
from http://www.techrepublic.com/article/windows-10-on-the-raspbe...
QEMU's user mode emulation is a bit unloved, though. We did manage to fix some longstanding bugs a while back, but it's still I think a bit unreliable on complex multithreaded apps. It could really use somebody with a few months to work on testing some big apps (eg node.js), dig into why they're not working and fix the issues. But many more people and companies care about QEMU for KVM support and for full system emulation, so those get the lion's share of maintenance effort...
I don't quite have the domain knowledge required to tie weird/confusing app breakages back to specific QEMU issues, but I'm curious what "testing" actually means. For example, using american fuzzy lop to run apps inside qemu-user-??? could be one way to generate a steady stream of noise/data.
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...
No, I mean "try big complicated programs, see whether they fail or not, narrow down what's going wrong". What we need to do is get the expected cases to work. AFL is good for checking that weird corner cases don't blow up, but we don't care so much about those for user-mode, because by definition we allow the guest app to call any syscalls it likes -- you don't need to overrun a buffer to run arbitrary code because you're already running arbitrary code. (Also, there are a number of things that are technically permitted and supported by a native Linux kernel but which QEMU's user-mode emulation doesn't support, but which don't matter because real-world programs don't use those corner cases. AFL can't tell the difference between "bug that doesn't matter" and "bug that real code will hit".)
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.
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
If it removes the need to understand qemu and all the other moving parts of the system in order to just do what a user wants, that's probably worth $50 to a lot of people. I mean, in the long run the learning process that goes with setting up qemu is probably worth it to some people. For a lot of people, qemu is the wrong level of abstraction.
Or to put it another way, "just run qemu" is a useful response to some people and not to others.
virt-manager presents a quite nice frontend for qemu and KVM. It's all free and open source, no need to pay $50 and you get nice remote connectivity support and stuff.
I agree. My point is that the assumed user problem is running x86 applications on an Rpi and the suggestion of qemu comes with a big learning curve for most people [consider that the default OS for an Rpi is NOOBS].
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.
My honest opinion here (as a QEMU dev) is that part of the problem here is that a lot of the people who want to run x86 apps on their rpi don't really appreciate that even if they did get it working the end result is unlikely to have satisfactory performance, simply because of how much slower an rpi is than an x86 desktop system and how much overhead emulation adds. So it doesn't seem worth expending a lot of effort on trying to make it much easier out of the box to do this, because if people get past the initial hurdles of getting the thing running, the next thing they'll hit will be "this is a complicated multithreaded program and it probably tickles qemu usermode emulation bugs", and if they're lucky enough to avoid that then they'll hit the insurmountable hurdle of it just not being fast enough in the end anyway.
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...
I agree that it is almost certainly not worth the time and effort to create a great Rpi + qemu experience out of the box. But we disagree about the problem. The problem has nothing to do with user mode and emulation overhead and the CPU of an Rpi. The problem is running x86 apps on the Rpi because that is the user's problem. That's the beginning and end of it. For most people, qemu is the wrong solution because qemu is not designed and developed for most people. It is developed for industry. Its use mostly depends on an institutional knowledge base and technical culture in the places it is deployed.
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.
In the original quoted case the user's problem is presumably "I have a zipfile I want to unzip", which they have then turned into "and so I want to run this x86 WinZip binary". That's the point where things have gone wrong, because trying to run winzip on a Linux system is just not the right way to solve the problem. It does the user no favours to try to help them to continue the wrong way down this garden path rather than to say "this isn't ever going to work satisfactorily and a better way to solve what you're actually trying to do is to use a native Linux program to extract zipfiles"...
I agree that running Winzip on an Rpi is an XY problem. [1] But I think that's just the way the world works. Sure it can be done with tar plus some indecipherable goboldygook plus a file name. Sure it can be done with some other program that has one name in the GUI (e.g. 'archive manager' on Ubuntu) and who knows what actual name.
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.
I agree that packaging such a solution has 10's of dollars worth of value. What I wonder about is their trying to license it for a single device. If it's just OSS software they can't really make that restriction.
One important difference is the character of the respective communities. Rpi's community has a distinctly different demographic than those built around x86 single board computers. It also has a distinctly different scale than any one community built around a particular x86 board.
The technology is only part of the story. The context of the larger ecosystem is also relevant to people.
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.
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.
> 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...
Those little chat popups on the side of sites like this drive me crazy. I closed the chat, switched tabs, and then when I came back it was there again. Ahhhh I don't want to chat.
Every single time I see a popup-chat window I type "popup chats are annoying".
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.
Can this be used to reasonably run Chrome with DRM plugins on the RPi3? I would like to profit from the Amazon Prime subscription but sadly Google does not publish their plugin for ARM (outside of ChromeOS and moving the plugin from there no longer works)
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.
49 comments
[ 5.1 ms ] story [ 112 ms ] threadOh, 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.
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...
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.
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
The technology is only part of the story. The context of the larger ecosystem is also relevant to people.
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.
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.
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...
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.
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.
Any feedback from people using something similar and their uses cases is interesting to me.
Thanks!
[1] https://eltechs.com/company/about-us/