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.

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

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