4 ms·

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 appreciat

by pm215 9y ago

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...

brudgers 9y ago
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.
- pm215 9y ago
  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"...
  - brudgers 9y ago
    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. [1]: https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem https://meta.stackexchange.com/questions/66377/what-is-the-x... [2]: http://norvig.com/21-days.html http://norvig.com/21-days.html

by pm215 9y ago

brudgers 9y ago

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.

pm215 9y ago
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"...
- brudgers 9y ago
  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. [1]: https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem https://meta.stackexchange.com/questions/66377/what-is-the-x... [2]: http://norvig.com/21-days.html http://norvig.com/21-days.html