4 ms·

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

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.

brudgers 9y ago
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.
- 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.
    - 9y ago

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.

brudgers 9y ago

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.

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.
  - 9y ago