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.
(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.
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.
Andreas
Currently what QEMU can point with is richer machine and hardware
emulation and its license; if we want more users than that, we'll
need to deliver what users usually want the most - stability,
performance and ease of use... and good marketing.
They may as well be merged into qemu.git directly, so long as:
- the GUI has its own maintainer
- the prepackaged GUI doesn't get access to internal APIs, compared
to external tools
--
error compiling committee.c: too many arguments to function
