qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Mount image file feature


From: Max Reitz
Subject: Re: [Qemu-devel] Mount image file feature
Date: Sat, 29 Aug 2015 21:34:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

On 29.08.2015 20:34, MagicCat Software wrote:
> 
> On Aug 29, 2015, at 2:01 PM, Max Reitz wrote:
> 
>> 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.
> 
> 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.
> 
> Really? It has been months since Peter Maydell implemented my GUI patches
> 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.

> 
>> So while it is always a nice thing to have, it comes at a hefty price.
> 
> 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. 
> 
>>
>>> 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. 
>>> 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-manager
>> *cough*.
> 
> 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?
> 
> 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 stuff 
>>> like
>>> freezing and restoring a session would be awesome and a real time saver.
>>
>> Might be trivially possible with the things I described, since there is
>> HMP's savevm/loadvm.
> 
> It is just a few patches away from working well.
> 
>> 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.
> 
> Probably true. 
> 
>>
>> 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.
>> 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.
> 
> Part of making QEMU easier for the user is not having to install more 
> software.
> 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.
> 
> 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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]