On Tuesday, Jun 23, 2020 at 2:07 PM, G 3 <programmingkidx@gmail.com> wrote:
On Jun 22, 2020, at 6:33 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
On Mon, 22 Jun 2020 at 00:36, G 3 <programmingkidx@gmail.com> wrote:I noticed on the page https://wiki.qemu.org/Hosts/Mac you deleted the
download section. I actually needed qemu-system-i386 today.
Yes; the download links were to random mediafire download URLs
(ie not trustable, not something we would want to imply to users
that they should be downloading and running) and were also for
ancient versions of QEMU (so not being updated or maintained).
What
would it take to have an office download for QEMU binaries for Mac OS X?
The project doesn't provide binary downloads; this would be
a lot of effort for minimal gain. For users who don't want to
do a full-compile-from-source we recommend using homebrew
(https://www.qemu.org/download/#macos), which is the equivalent
for OSX of "get binary packages from your distro" for Linux.
I don't think this is acceptable for Mac users. We don't do things the Linux way. Linux users tend to have to compile their own software due to the segmented nature of having over 30 distributions to work with. Mac users on the other hand like a more laid back and relaxed computing experience. Having to build from source is so not fun. It is very difficult and time consuming. A binary download would solve this problem. We need binary download for Mac OS X (and Mac OS 11 soon).
Yes, and if you’d noticed, at least on current release versions of macOS, the Homebrew software distribution supplies binaries. In fact, lately, they only supply binaries, and do not supply a mechanism for building anything. You can maybe wait for the macOS 11 support there, or stick with Catalina until the support comes along.
Apple is already contributing to those code bases, so you will get support soon enough, including on “Apple Silicon” Macs, when those materialize. Of course, I wouldn’t expect miracles, like the x86 version of qemu working any better under Rosetta 2 than the ARM native version already does at running x86 code. Which is to say, it probably won’t be very pretty either way.
