Re: [Qemu-devel] Unmaintained QEMU builds

[Avi Kivity <avi@redhat.com>]

  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