From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57401) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVltX-0002tE-6b for qemu-devel@nongnu.org; Sat, 29 Aug 2015 15:34:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVltT-0000O2-W2 for qemu-devel@nongnu.org; Sat, 29 Aug 2015 15:34:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43265) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVltT-0000NX-Ns for qemu-devel@nongnu.org; Sat, 29 Aug 2015 15:34:27 -0400 References: <55E1D289.9000202@redhat.com> <55E1E03A.6060002@redhat.com> <1DBD1CD3-3C0E-4AC6-97EB-FC51F09EF5F8@gmail.com> <55E1F385.2040409@redhat.com> <94F6A4AC-9CB6-41A0-BD31-1E680C0700C0@gmail.com> From: Max Reitz Message-ID: <55E2093F.3050600@redhat.com> Date: Sat, 29 Aug 2015 21:34:23 +0200 MIME-Version: 1.0 In-Reply-To: <94F6A4AC-9CB6-41A0-BD31-1E680C0700C0@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="n0WCthm7hqculNfnI1h7xbuU1RxfbLWvx" Subject: Re: [Qemu-devel] Mount image file feature List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: MagicCat Software Cc: Peter Maydell , qemu-devel qemu-devel This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --n0WCthm7hqculNfnI1h7xbuU1RxfbLWvx Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 29.08.2015 20:34, MagicCat Software wrote: >=20 > On Aug 29, 2015, at 2:01 PM, Max Reitz wrote: >=20 >> On 29.08.2015 19:36, Programmingkid wrote: >>> >>> On Aug 29, 2015, at 12:39 PM, Max Reitz wrote: [snip] >>> If making QEMU more user-friendly is a crime, I plead guilty! >> >> Yes, in some people's eyes it is a crime because they say qemu should >> rather be machine-friendly. >=20 > These people have the mentality of terminator robots. Just want to add that by "machine-friendly" I meant "friendly to an upper management layer who will be really, really nice to the user". >> User-friendliness is always expensive, >> difficult to maintain, and a neverending source of complaints. >=20 > Really? It has been months since Peter Maydell implemented my GUI patch= es > for the cocoa interface, and I haven't seen a complaint about it yet. By definition, a user interface is something the user interacts with. People are prone to complain about things they interact with which aren't to their exact liking. What I mean to say is that humans are more complex than machines. It's much more difficult to please a human than to please libvirt. I guess. >=20 >> So while it is always a nice thing to have, it comes at a hefty price.= >=20 > If programmers follow good programming practices, the code should be > pretty much maintenance free. [citation needed] > But I do understand that public API's do > change over time.=20 >=20 >> >>> I'm not a Linux user. I am a proud Macintosh user. We Mac users >>> like our software easy to use. I know this goes against the Linux >>> way of life. That is why this patch would only work on Mac OS X.=20 >>> This will keep QEMU on Linux hard to use... just the way you guys >>> like it. >> >> Erm, well, I think I won't reply to that other than *cough* virt-manag= er >> *cough*. >=20 > Linux exclusive probably. Your point? You said applications on Linux are generally more difficult to use than comparable applications on OS X, by design. I said "Well, there's virt-manager." You say it's available only on Linux. So how does that make qemu on Linux more difficult to use than on OS X? >>>>> Mac OS X users don't have all the fancy GUI wrappers >>>>> for QEMU :( >>>> >>>> Good thing most GNU/Linux distributions are free. ;-) >>>> >>>> (sorry, could not resist) >>> >>> ....lolz >>> >>> But on the other hand, you get what you pay for. >> >> Working qemu/KVM with a nice management layer on top of it? >=20 > Linux has a few advantages. Which don't really matter here, because this thread should really not be about which OS is better (which is a rather pointless question and even more so on the qemu mailing list). The point why I brought up libvirt and virt-manager is simply that those tools do exactly what you want qemu to do. The ratio of how much GUI work we do and how much work we do to have qemu interact nicely with libvirt shows to me very clearly that our current direction is to separate the frontend (libvirt + GUI) from the backend (qemu). It's a pity that libvirt is not available for OS X, but in my humble opinion that's libvirt's fault and not qemu's. Putting features into qemu we apparently decided to leave to libvirt and any management application on top of it doesn't seem quite right. [snip] >>> Ideally I want QEMU's GUI to be similar to VirtualBox's GUI. Doing st= uff like >>> freezing and restoring a session would be awesome and a real time sav= er. >> >> Might be trivially possible with the things I described, since there i= s >> HMP's savevm/loadvm. >=20 > It is just a few patches away from working well. >=20 >> On the other hand, I don't think you'll find (m)any friends for making= >> qemu's GUI as feature-rich as VBox's. There have long been >> "non-invasive" GUIs for managing qemu VMs (such as qtemu), so this isn= 't >> some recent development. >=20 > Probably true.=20 >=20 >> >> Maybe I can get you interested in writing a management application for= >> OS X? I do not think that would be more difficult than plugging these >> features directly into qemu, and I think everyone would like that idea= =2E >> As an OS X user, there shouldn't be any visible difference; and all >> non-OS-X users would not have any reason to complain. >=20 > Part of making QEMU easier for the user is not having to install more s= oftware. > If everything came with in one package, that would be a blessing. I don't know how installing software works under OS X, but as far as I can recall, it was pretty similar to most Linux distributions in that there are package managers. So you'd install the frontend your heart desires and it'd pull in qemu as a dependency. Sometimes package managers support optional dependencies, too. So one of qemu's optional dependencies might be your frontend. Alternatively, your frontend could just be part of the qemu package. Other than that, the difficulty of having to install two packages instead of one doesn't quite strike me as a good argument. >> Because, as much as you may think this is worthless to hear, what you >> are describing is exactly what virt-manager offers. >=20 > Maybe someone might port Virt-manager to other platforms. Shouldn't be = too > difficult. It probably uses multi-platform libraries like GTK. The thing is that it works on top of libvirt. Max --n0WCthm7hqculNfnI1h7xbuU1RxfbLWvx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV4gk/AAoJEDuxQgLoOKytkqcH+QH+xhgd3NfmdWAGSIxdlyp/ tPBTCYlBbX8HD7iCE0bVhHIubJJsiM0Vq1ehiZO1oZP5LSmPZjNBqAvThBLyLoyX 5tsM3oWqZ34Z3HJX7lPkeA/aeiKEJpVVdqyTA7e7mFcNS4dPrrQ1YoAlZQJevAy2 y72ZVKaj3SQ6j0MjYLY4E52+l8dvsST5t9dxyJkG8UeH0xAd69sY7sW6mIZDVsce iETTzEQ4CNQ2wTJBY34q/ujfP2B0BuaPZ+sqqA6HvD82hjBv3j3h7ixG+iVUVZ4H EEDZp9nn7irESwxIBMTrnhcp+UMQu6FHQS/GY40tIhwS2oZXsHPYNz9nZyZVFKc= =IAFd -----END PGP SIGNATURE----- --n0WCthm7hqculNfnI1h7xbuU1RxfbLWvx--