qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] feature idea: allow user to run custom scripts


From: Programmingkid
Subject: Re: [Qemu-devel] feature idea: allow user to run custom scripts
Date: Fri, 2 Oct 2015 13:57:24 -0400

On Oct 2, 2015, at 12:21 PM, Eric Blake wrote:

> On 10/02/2015 08:37 AM, Programmingkid wrote:
>>> Even if it were a fancier GUI, I don't think it would really go very far to
>>> providing users a solution which is on a par with VirtualBox or VMWare 
>>> Desktop
>>> which are the benchmarks, as the GUI will forever be limited to only dealing
>>> with a single VM at a time. As soon as you want to deal with more than 1 VM
>>> at a time, a GUI built-in to QEMU is a non-starter as you need to manage 
>>> many
>>> QEMUs. So encouraging new users to use a built-in QEMU GUI is sending them
>>> down a dead-end - we should be ensuring they can find the viable long term
>>> UI straight away. This means directing them to things like GNOME Boxes or
>>> virt-manager or one of the other UIs that exist.
>> 
>> Sorry to say but this belief you have it exactly what is keeping
>> the GUI in QEMU from being great. Can only deal with one VM at a time?
> 
> A good gui will have a single process dealing with multiple guests at a
> single time.

Going to have to agree to disagree on this point.

> 
> When you are reading email, do you want to fire up two separate email
> processes per mail?  Or do you want to fire up a single email reader,
> that can then browse multiple mails, and maybe even open multiple
> windows to compare mails side by side?
> When you open your browser, do you want to have two browser processes
> for separate URLs open at the same time?  Or do you want a single
> browser with multiple tabs?

This may be fine for emails and web pages, but we are talking about
emulators here. I'm not against this idea, but improving QEMU's GUI and
implementing this megaGUI can happen at the same time. 

> We already KNOW that qemu only manages one guest at a time.  But I argue
> that any GOOD gui for managing guests can manage multiple guests in a
> single gui process. So qemu is NOT the place to be working on a GOOD
> gui.  It only needs enough of a gui to make development easier, NOT to
> make end user life easier.

Definitely going to have to agree to disagree on this point.

> 
> We WANT to point end users to a better application, _built on top of
> qemu_.  Whether that be GNOME boxes, virt-manager, or some new tool, I
> don't care.  But we do NOT want qemu to become that tool.

Everybody can win in this situation. The Anti-GUI people can win by using 
--disable-gtk/--disable-cocoa, and the Pro-GUI people can win by using
their respective GUI's. 

> Instead of wasting our time beating a dead horse, you'd get further if
> you started porting one of the existing VM guis that can already manage
> qemu to run well on OS X.

That is much easier said than done. What you want could take years to
accomplish. Adding a few features to the GUI doesn't sound that bad. It
also doesn't hurt someone who doesn't use the GUI, so why have a problem
with it?

> 
>> The GUI in QEMU can become great. We just have to let it do so. 
> 
> No.  Please don't.  I do not want the qemu gui to be a selling point of
> qemu.

Selling point? Are you afraid a really good GUI for QEMU might put
Libvirt out of business? Isn't the general trend in technology for things
to become better? Trying to hold back the GUI is anti-technology 
thinking. We need pro-technology thinkers to advance our way of
life. I am sure that technology has put people out of business. If you 
want to cling to the pony express way of life, good luck. I think you 
and everyone else would be much better suited to moving forward
and adapting to change. 


reply via email to

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