On 09/05/2010 06:01 PM, Andreas Färber wrote:
Am 05.09.2010 um 13:19 schrieb Avi Kivity:
On 09/04/2010 04:56 PM, Andreas Färber wrote:
Maybe it's time to rethink the relation between QEMU and its
frontends / management tools? If we want to compete with the
commercial products (sic), we might agree on some "official"
frontend per GUI-centric platform, with a Git-based repository (like
qemu-kvm.git) and synchronized releases that may call themselves
"QEMU", linked from qemu.org, rather than having a variety of
(outdated) Q* frontends per platform of which most are nothing more
than a configuration window to spawn the regular qemu[-system-x86_64].
There is also virt-manager which is quite rich at this time.
Seems I didn't get the point across too well: Standard users on
Windows-PC and Mac expect a solution to their needs, not a forest of
well-designed libraries and tools with .tgz downloads. QEMU has no
such product identity, and there's no prominent binary download link
for Win/Mac on the qemu.org frontpage.
virt-manager is neither prominently advertised there either, nor does
it have a Windows download.
Definitely, virt-manager is not a solution for Windows/Mac.
(Fwiw while it's certainly nice on Linux and to some limited degree on
Solaris (ancient fork apparently), I wouldn't exactly describe the
virt-install versions I've seen as "rich"... and setting up the VM is
somewhat a prerequisite to using virt-manager's indeed nice features.
I believe you can install a guest through virt-manager; virt-install is
just a shortcut.
Fedora's default security policies on top don't exactly make it easy
to try out .isos or downloaded disk images with virt-manager, its
German translation had a severe contentual error in the VM's menu and
a felt 80% of the BRC bug reports get ignored and closed by a bot
anyway, but that's another topic.)
But sure, on Linux there's a plethora of simplistic Q* frontends, too.
(n.b., virt-manager didn't match that regex ;)
Choice and diversity isn't wrong per se, just the comparison of the
available options on the two given platforms has shown not to make
QEMU a common choice. Whining about lack of bugfix contributions is
unlikely going to change that imo.
As a baby step, is there any chance of publishing an automatic nightly
Windows (cross-)build as a .zip file on qemu.org? That might give more
users a chance of detecting runtime faults during the development cycle.
That's doable and useful, yes. But I don't really see a path towards a
competitive full fledged bundled/native qemu GUI. It's a huge amount of
work, no one seems interested (or has an employer who's interested), and
it requires talent we don't have.
It will take a sustained effort by multiple people. Until then, Windows
will be a second class host and we'll have to rely on external GUIs.
--
error compiling committee.c: too many arguments to function