From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47243 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OsGrj-00011V-7s for qemu-devel@nongnu.org; Sun, 05 Sep 2010 11:10:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OsGri-0001CI-3l for qemu-devel@nongnu.org; Sun, 05 Sep 2010 11:10:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65063) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OsGrh-0001C9-PZ for qemu-devel@nongnu.org; Sun, 05 Sep 2010 11:10:42 -0400 Message-ID: <4C83B2ED.5040501@redhat.com> Date: Sun, 05 Sep 2010 18:10:37 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Unmaintained QEMU builds References: <4C62825A.6000903@mail.berlios.de> <4C685F5D.2090707@codemonkey.ws> <4C69A29F.5000606@codemonkey.ws> <4C6AE96C.2040907@codemonkey.ws> <4C837CAF.4080200@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: QEMU Developers On 09/05/2010 06:01 PM, Andreas F=E4rber wrote: > Am 05.09.2010 um 13:19 schrieb Avi Kivity: > >> On 09/04/2010 04:56 PM, Andreas F=E4rber wrote: >>> >>> Maybe it's time to rethink the relation between QEMU and its=20 >>> frontends / management tools? If we want to compete with the=20 >>> commercial products (sic), we might agree on some "official"=20 >>> frontend per GUI-centric platform, with a Git-based repository (like=20 >>> qemu-kvm.git) and synchronized releases that may call themselves=20 >>> "QEMU", linked from qemu.org, rather than having a variety of=20 >>> (outdated) Q* frontends per platform of which most are nothing more=20 >>> 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=20 > Windows-PC and Mac expect a solution to their needs, not a forest of=20 > well-designed libraries and tools with .tgz downloads. QEMU has no=20 > such product identity, and there's no prominent binary download link=20 > for Win/Mac on the qemu.org frontpage. > > virt-manager is neither prominently advertised there either, nor does=20 > 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=20 > Solaris (ancient fork apparently), I wouldn't exactly describe the=20 > virt-install versions I've seen as "rich"... and setting up the VM is=20 > somewhat a prerequisite to using virt-manager's indeed nice features.=20 I believe you can install a guest through virt-manager; virt-install is=20 just a shortcut. > Fedora's default security policies on top don't exactly make it easy=20 > to try out .isos or downloaded disk images with virt-manager, its=20 > German translation had a severe contentual error in the VM's menu and=20 > a felt 80% of the BRC bug reports get ignored and closed by a bot=20 > anyway, but that's another topic.) > But sure, on Linux there's a plethora of simplistic Q* frontends, too.=20 > (n.b., virt-manager didn't match that regex ;) > > Choice and diversity isn't wrong per se, just the comparison of the=20 > available options on the two given platforms has shown not to make=20 > QEMU a common choice. Whining about lack of bugfix contributions is=20 > unlikely going to change that imo. > > As a baby step, is there any chance of publishing an automatic nightly=20 > Windows (cross-)build as a .zip file on qemu.org? That might give more=20 > 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=20 competitive full fledged bundled/native qemu GUI. It's a huge amount of=20 work, no one seems interested (or has an employer who's interested), and=20 it requires talent we don't have. It will take a sustained effort by multiple people. Until then, Windows=20 will be a second class host and we'll have to rely on external GUIs. --=20 error compiling committee.c: too many arguments to function