[Qemu-devel] Qemu development schedule?

[Qemu-devel] Qemu development schedule?

[Jeebs]

[I am *not* a developer, but since the user's list doesn't work, I lurk 
here.]

What is the development schedule for Qemu?

In other words, what priority is there for various things?

Fabrice's recent comment about vastly speeding up Qemu got me thinking that 
perhaps it might be better to work on other things first.

Don't misunderstand me... The recent discussion about performance 
improvements, and Fabrice's comments were *very* exciting.

But I was just thinking that before you do the exciting and the 'sexy' 
things, that perhaps you should work on the more mundane things needed to 
make Qemu into a highly usable product.

Like vastly improving the user interface.  Especially for Window's users 
(such as myself.)

Improving the basic virtual system to add things like full Pentium-3 
support.  MMX, SSE, cpuid, etc. etc.

Making sure the FPU behaves like it's supposed to.

Improving data transfers to/from the guest / host.

And a bunch of other 'minor' details.


As I said above, I'm not a developer.  So maybe I'm out of place even making 
these questions and comments.  If so, I apologize.  I do indeed think Qemu 
is an excellent project.  It's very exciting and that's why I'm here 
lurking.

I'm just a little concerned that maybe qemu might always be an incomplete, 
un-stable, un-usable beta program.  An interesting program without the 
refinements and the polishing.

If all you ever do is work on the exciting stuff, and fix the occasional 
problem, then the project may have trouble reaching the level of quality it 
should.

That's why I was wondering what the project schedule actually was.  At what 
points are things going to be added or fixed or improved.

Or is Qemu still in the "free for all" early development stage where people 
work on whatever exciting or sexy thing they feel like, with no actual plan 
or organization?

Re: [Qemu-devel] Qemu development schedule?

[John R. Hogerhuis]

There are already projects around adding front ends. QEMU works just
fine from the command line. This is a proper separation of work from a
software designer's point of view.

For most, usability of an emulator can be summed up in one word: speed.
Any effort to address speed improvements (and at the same time,
stability which is ongoing) is core development.

Are you sure it makes sense have the core developers concentrating on
Windows installers or front ends?

For those that can't wait for "polish," commercial products are out
there for the Windows platform, and Linux too.

The other thing is that front ends will constantly be in flux as new
core features are added. For now, all those features are easily
accessible from the command line for those willing to track cvs.

Having watched this project for a while I see QEMU as a very healthy
project. It is growing rapidly and improving in core functionality. In
some areas it has already outstripped commercial offerings.

But I suppose the only real indicator of real success of FOSS projects
is when the complaints start rolling in ;-)

-- John.

Re: [Qemu-devel] Qemu development schedule?

[Jeebs]

> There are already projects around adding front ends. QEMU works just
> fine from the command line. This is a proper separation of work from a
> software designer's point of view.

The only gui front end I've seen is Qemu Workstation, and the last I 
checked, it was way out of date and didn't work with the current builds.

The command line is okay, but it's a little inconvenient at times.  And 
switching back & forth between the target screen and the command screen 
doesn't always work with the Windows version.  I often end up with just a 
black screen.  (Maybe that has been fixed.  I've been busy the past two 
weeks and haven't tried any of the daily builds on FreeOSZoo.)

> For most, usability of an emulator can be summed up in one word: speed.
> Any effort to address speed improvements (and at the same time,
> stability which is ongoing) is core development.

I think usability and accuracy tend to be a bit more important.

It doesn't matter how fast it is, if it can't emulate a real computer enough 
to do what you need / want to do.

(Of course, that doesn't mean you should make it as slow as Bochs...[grin])

> Are you sure it makes sense have the core developers concentrating on
> Windows installers or front ends?

I'm not really sure who the "core" developers are.  All I ever see is 
Fabrice.

Everybody else just seems to be doing the occasional patch to fix some 
little aspect etc.

I've been lurking here for 3+ months and I'm not sure what organization, if 
any, there is in this project.


> For those that can't wait for "polish," commercial products are out
> there for the Windows platform, and Linux too.

I'm currently using VMWare.

But as I said in my message, I was just getting the feeling that things were 
being implemented on "whims" by lots of people, with no real plan of what 
was needed, what was important, etc. etc.

That's the way it often is with open source porjects.  Everybody does their 
own thing when ever they feel like, and since most people don't like to do 
the "grunt" work, many important but less exciting issues often get pushed 
off to the side or only done "good enough for now".

> Having watched this project for a while I see QEMU as a very healthy
> project. It is growing rapidly and improving in core functionality. In
> some areas it has already outstripped commercial offerings.

I fully agree with out.

It's developing very very rapidly.  That's one of the reasons I've been 
following the development for the past few months.


> But I suppose the only real indicator of real success of FOSS projects
> is when the complaints start rolling in ;-)

I wasn't trying to complain.

My message was a genuine question.

And it was sort of a 'notice' to people that maybe it might be a good idea 
to start working on things that are at least as important, but aren't 
"sexy".

Re: [Qemu-devel] Qemu development schedule?

[Johannes Schindelin]

Hi,

On Mon, 30 Aug 2004, Jeebs wrote:

> > For most, usability of an emulator can be summed up in one word: speed.
> > Any effort to address speed improvements (and at the same time,
> > stability which is ongoing) is core development.
>
> I think usability and accuracy tend to be a bit more important.

No, not really. What makes Qemu special is speed. If it wasn't for the
exceptional speed, I would not use it.

I don't want to be harsh, but for me it is only important that the stuff I
need works, the rest doesn't matter to me as long as I don't benefit from
it...

> I'm not really sure who the "core" developers are.  All I ever see is
> Fabrice.

I think he meant developers who work on the core of Qemu, i.e. the
emulator itself, not a front end.

> Everybody else just seems to be doing the occasional patch to fix some
> little aspect etc.

If you look at dad-answers, you will see that there are quite a few non
trivial patches implementing features which were implemented by quite a
few programmers.

> I've been lurking here for 3+ months and I'm not sure what organization, if
> any, there is in this project.

You might want to read about "The Cathedral and the Bazaar" by Eric S.
Raymond:

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

Fabrice started this project. When it was already quite usable, others
joined this mailing list, and since then there is a loose development
team. This is the beauty of "free as in free speech": you are free to do
what you want.

> That's the way it often is with open source porjects.  Everybody does their
> own thing when ever they feel like, and since most people don't like to do
> the "grunt" work, many important but less exciting issues often get pushed
> off to the side or only done "good enough for now".

If you want to do the "grunt" work, you are very welcome. I will never say
that open source projects are free as in free beer, i.e. you get something
for free. That just wouldn't be fair, right? A developer who spends time
and thought to implement something has to get something for it.

> And it was sort of a 'notice' to people that maybe it might be a good idea
> to start working on things that are at least as important, but aren't
> "sexy".

Again, read "The Cathedral and the Bazaar". You might want to learn to do
it yourself or to convince somebody who can.

Ciao,
Dscho

Re: [Qemu-devel] Qemu development schedule?

[Jeebs]

From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>

>> I think usability and accuracy tend to be a bit more important.
>
> No, not really. What makes Qemu special is speed. If it wasn't for the
> exceptional speed, I would not use it.

I wouldn't use it either if it can't actually run what I need.

For an effective emulator, you need both.  But improving the speed is 
"sexy".  Adding features to suit your own needs is "exciting".  Making the 
emulator more accurate isn't, and seems to be left to people who are doing 
it whenever they feel like it.  With no real plan or goal among them.

Progress is most definetly being made, but it seems like it's all "hit or 
miss".

> I don't want to be harsh, but for me it is only important that the stuff I
> need works, the rest doesn't matter to me as long as I don't benefit from
> it...

**BINGO!**

That's precisely the kind of attitude I was concerned about.

Many, if not most, small or early stage open source projects are focused 
solely on what they themselves want.  What others want, or even the goal of 
a 'polished' emulator is irrelevant.

Which is indeed understandable for an early stage project.  Pretty much a 
necessity in most cases.

At some point, successful open source projects have to transition from the 
'free for all' attitude and organization to one with some actual specified 
goals and some organization.

Qemu may or may not be at that stage yet.  I don't know.  That was sort of 
one of the things I was asking about....  Is there a development schedule? 
Is there even a list of things that need to be done?  Etc.


>> Everybody else just seems to be doing the occasional patch to fix some
>> little aspect etc.
>
> If you look at dad-answers, you will see that there are quite a few non
> trivial patches implementing features which were implemented by quite a
> few programmers.

Maybe I shouldn't have used "little aspect".  I stand corrected.

But it still definetly seems that everybody is working on whatever whim they 
want.

>From what I can tell, nobody in here even knows what still needs to be done 
to make Qemu into a "complete" product.

Maybe Qemu isn't far enough along to really start thinking about that.  But, 
considering that Qemu can now run a number of OS's, I kind of have the 
feeling that it has progressed that far.

I'm not saying you need a strict timeline or any of that garbage.

But at least a list of things to do and a schedule that says things like: 
"When we add x, y, and Z and fix critical bugs 1, 2, 3, and 4, we'll 
probably release the next version."  That wouldn't stop people from adding 
their own patches to fix their own problems.  Or maybe do a feature early 
(provided more critcal stuff isn't being neglected).

But it would at least let people know what still needs to be worked on, and 
what the goals of the immediate future are.


> Fabrice started this project. When it was already quite usable, others
> joined this mailing list, and since then there is a loose development
> team. This is the beauty of "free as in free speech": you are free to do
> what you want.

Free speech doesn't exactly mean you are free to do what you want.

But I know what you mean.

But that does highlight some of what I had said before.

If everybody is working on the 'sexy' stuff, then who is going to be doing 
the less glamorous stuff?


>> That's the way it often is with open source porjects.  Everybody does 
>> their
>> own thing when ever they feel like, and since most people don't like to 
>> do
>> the "grunt" work, many important but less exciting issues often get 
>> pushed
>> off to the side or only done "good enough for now".
>
> If you want to do the "grunt" work, you are very welcome. I will never say

As I said in my original posting... I am not a developer.

I haven't done much 'development' since I was still using DOS.  I never 
learned C++, Java, etc.  I stayed with C and I'm out of practice with it.  I 
don't even have a C compiler installed anymore.

> that open source projects are free as in free beer, i.e. you get something
> for free. That just wouldn't be fair, right? A developer who spends time
> and thought to implement something has to get something for it.

That is true if you are talking about small projects or such.

But when you are working on larger, more important projects, at some point 
you have to have some sort of organization, some sort of list of things to 
do, etc.  And at some point, somebody is going to have to work on things 
that need to get done that aren't "fun", or even usable for themselves.


If the project is going to *stay* as a "hacker" level program, then who the 
heck cares if it's complete or if it crashes occasionally, or if you have to 
enter 51,342 character long commands to get something done.  You are a smart 
person and you can figure it out.  That's part of the excitement.

But if the project has the *eventual goal* of being more usable for a wider 
range of people, then at some point you have to change how things are done. 
At the very least, you need a list of things that eventually need to be 
done.

After several months of lurking in here, I don't know which category Qemu 
falls into.

I hope the second category.

Re: [Qemu-devel] Qemu development schedule?

[Joe Batt]

[I normally hate posting rants partially off topic, but I am anyway.]

On Tue, 2004-08-31 at 10:58, Jeebs wrote:
> blah, blah, blah...
Great.  Do it.  You aren't talking about development and you aren't a
developer, so it sounds like a perfect match.

Write up the documents describing what is needed and why.  You may even
convince a developer to do the work.  You may drum up enough support to
sponsor a developer to do the work.

If you do a good job, people will use your work.  If you don't they
wont.

I think you are a bit confused by the FOSS model.  People don't write
code because they are trying to improve the world.  The code is written
for themselves (for use or cash) and is shared with the world (why not,
it doesn't cost to share it and it may come back improved).

[Even further off topic: I just don't understand the whole "front end"
thing.  What can be simpler that typing or building a short
cut/alias/script/batch file to 'qemu -hda w2k.img'?  Qemu seemed much
simpler than VMWare to install and run.]


> At some point, successful open source projects have to transition from
> the 'free for all' attitude and organization to one with some actual
> specified goals and some organization.

You must measure 'successful' differently.  Take a look at the Linux
project someday.  13 years old and there is still confusion as to how a
new developer should get his or her patches in, what will be part of the
next release and when releases will happen.  Most collaboration happens
in a mailing list and I'll bet Linus doesn't read all of his email. 
Linux is made user friendly somewhere else (RedHat), not by the core
team.

Joe

Re: [Qemu-devel] Qemu development schedule?

[Jeebs]

From: "Joe Batt" <Joe@soliddesign.net>

> On Tue, 2004-08-31 at 10:58, Jeebs wrote:
>> blah, blah, blah...
> Great.  Do it.  You aren't talking about development and you aren't a
> developer, so it sounds like a perfect match.

As I stated in the original message... The user's list does NOT work!

But you apparently went out of your way to not notice me saying that...

And you also apparently didn't notice that my original message was a genuine
question about the focus of the development.  Whether it was on the exciting
stuff, or whether there were any genuine plans to make a more user friendly
product with a more complete emulation.

> I think you are a bit confused by the FOSS model.  People don't write
> code because they are trying to improve the world.  The code is written
> for themselves (for use or cash) and is shared with the world (why not,
> it doesn't cost to share it and it may come back improved).

Some projects are done for personal reasons.

Some evolve into more than their limited beginings.

> [Even further off topic: I just don't understand the whole "front end"
> thing.  What can be simpler that typing or building a short
> cut/alias/script/batch file to 'qemu -hda w2k.img'?  Qemu seemed much
> simpler than VMWare to install and run.]

If all you are wanting to do is a short command line, then okay.  Once
you've read all the docs (assuming those are up to date), and you figure out
what options are actually needed.

I've got a couple of batch files that do that for several of the different
virtual machines.

But:

1) Under windows, it can be inconvenient.  Bill Gates hates command lines
and sometimes seems to go out of his way to irritate users.  Not Qemu's
fault, but that's the way it is.

2) A startup shell / wrapper / script can make it a lot more convenient,
provided it actually provides all the options needed and is done in such a
way as to be more intuitive and convenient than doing it by hand.  And that
it actually creates a batch file or config script or something so you don't
have to redo it every single time.

3) trying to remember and type the path name to the disk image can be
inconvenient.  Not all images are right there in the same directoy.

4) Try to find the right disk image (such as for a virtual cd you are
changing) is a whole lot easier when you have a little gui that can browse
to it.  Especially if the image is named such as "Windows XP Pro  (sp2).iso"
Looks simple, right?  Guess what, there are two spaces before (sp2).  I
know, that's a contrived example.  But it's not too unrealistic.  There are
times when a gui does make things easier.

(A 'gui' doesn't have to be super fancy.  Heck, go get a text gui. 
TurboVision.  Or Al Steven's D-Flat.  And there was even a later independant 
version of  D-Flat which fixed some of the bugs and could even work with 
Curses or dial-up BBS's using ANSI escape codes.  I remember seeing that 
years ago.)


>> At some point, successful open source projects have to transition from
>> the 'free for all' attitude and organization to one with some actual
>> specified goals and some organization.
>
> You must measure 'successful' differently.  Take a look at the Linux
> project someday.  13 years old and there is still confusion as to how a

I have looked at Linux...

Guess what....  It has evolved.  It is more organized than what it was in
its early beginings.  Surprise.

It's not 100% strictly disciplined, and I never suggested nor implied that
Qemu be that way either.

Re: [Qemu-devel] Qemu development schedule?

[Kai Cherry]

On Aug 31, 2004, at 1:42 PM, Jeebs wrote:

> (A 'gui' doesn't have to be super fancy.  Heck, go get a text gui. 
> TurboVision.  Or Al Steven's D-Flat.  And there was even a later 
> independant version of  D-Flat which fixed some of the bugs and could 
> even work with Curses or dial-up BBS's using ANSI escape codes.  I 
> remember seeing that years ago.)
>
That would be a start. I suggested something even more simple just 
minutes ago: a config file :)
Most simple UI in the world, but very, very helpful.

qemu -c <somefilefullofoptions>

Would that be helpful? (It would be commented nice for ya, as well.)

-K

Re: [Qemu-devel] Qemu development schedule?

[andrej]

Quoting Kai Cherry <kaicherry@mac.com>:
> That would be a start. I suggested something even more simple just 
> minutes ago: a config file :)
> Most simple UI in the world, but very, very helpful.
> 
> qemu -c <somefilefullofoptions>
> 
> Would that be helpful? (It would be commented nice for ya, as well.)
I think that would be a great idea, and I'd rather
have it as a flat-file, too. Editing xml files with
all their tags in vi/emacs is tedious ;)



> -K

Re: [Qemu-devel] Qemu development schedule?

[Joe Batt]

On Wed, 2004-09-01 at 14:25, Kai Cherry wrote:
> On Aug 31, 2004, at 1:42 PM, Jeebs wrote:
> ...
> That would be a start. I suggested something even more simple just 
> minutes ago: a config file :)
> Most simple UI in the world, but very, very helpful.
> 
> qemu -c <somefilefullofoptions>
> 
> Would that be helpful? (It would be commented nice for ya, as well.)

And every computer I've ever used already has a method to do that.  In
DOS I used batch files, VMS command files, Unix shell scripts, windows
shortcuts.

What is the difference between creating a configuration file that has
qemu options or making a shortcut with qemu options?  Either way you
have a file with expressions that have to be looked up in a manual.

I prefer the short cut method, to eliminate a file.  With a
configuration file, I have to have qemu.exe, qemu.conf, and the qemu
shortcut to click on.  Since I have to have the shortcut anyway, why
have the configuration file?  Adding layers does not make it easier.

It could even be self describing... 'qemu --help'.  For even more
information, you could 'man qemu'!

Now, if someone were to write a qemu configuration wizard that for some
on foreseen reason can't modify the shortcut, then I'm on board.

Joe

Re: [Qemu-devel] Qemu development schedule?

[Mike Tremoulet]

If I may, I'd like to make some suggestions to keep this discussion productive.

Some good points have been raised and discussed about the mode of
development for qemu.  At this point, it does become a "religious
debate", where two sides both believe they are right and no correct
answer is actually called for - it's just two different styles of
working.  I can't see much more productive coming from that
discussion, so I respectfully suggest we let that rest.

The idea of a front-end, or minimally a "configurator" to generate the
command line, is interesting.  I'd happily welcome something that gave
me some check boxes and text fields to select from, and set up the
command line switches for me to save for use.  I suspect that, unless
it is built in to the application window (see the OSD part of the
thread, or something like PearPC's choice of boot device), the graphic
form will be platform specific.  Work is already being done in this
area, but I'm not holding my breath for the all-in-one GUI.

However, the real reason I was writing was to gauge interest in some
of the ideas this thread gave me:

- Would there be interest in a bugtrack of sorts for qemu?  My
suspicion is that the platform isn't quite so stable to warrant this,
but it is something I could help set up.  Or promote the use of the
tracker on the Savannah project page?

- Similarly, what about a feature list/request tracker?  Something a
little more focused to capture the wishlist items?

- Finally, a request.  One of the more daunting tasks for me as a
new-to-qemu developer is to read and discover the design of the
system.  What I'd like to do is prepare a brief catalog of each of the
pieces of code, so interested people can more quickly find where to
tie in with the existing code.  In order to produce this quickly,
then, I'm asking that list members please email either myself or the
list with a quick one or two sentence description of each code file
that they touch.  This should only take a couple of seconds, but would
greatly help me compile a table of contents, if you will, of the code.
 An example that I *think* is correct (let me know if I'm off):
NE2000.c - Emulates an NE 2000 NIC in the guest OS.  Sends packets
to/from the QEMU engine.

[Also, if there's a list to be compiled of configure or make options,
or of existing command line switches, I'll be happy to pull those
together as you present them to me.]

Thanks,
-- Mike

Re: [Qemu-devel] Qemu development schedule?

[Kai Cherry]

You've got my vote. Its one of the things the we here where I am would 
find *very* useful as well.

Great suggestion!

-K


On Sep 1, 2004, at 4:34 PM, Mike Tremoulet wrote:

> This should only take a couple of seconds, but would
> greatly help me compile a table of contents, if you will, of the code.
>  An example that I *think* is correct (let me know if I'm off):
> NE2000.c - Emulates an NE 2000 NIC in the guest OS.  Sends packets
> to/from the QEMU engine.
>
> [Also, if there's a list to be compiled of configure or make options,
> or of existing command line switches, I'll be happy to pull those
> together as you present them to me.]
>
> Thanks,
> -- Mike

Re: [Qemu-devel] Qemu development schedule?

[Kai Cherry]

This methodolgy requires too much system level knowledge for regular 
users of commodity OS's?

or to put it another way:

How does *what I proposed* "hurt' you in ANY way?

Why can't people *stick to the matter at hand* instead of picking out a 
piece to lauch off on their Holy War of the day?

qemu -c <somefile> is an *option*..if you prefer the other way then it 
would logicall still be there.

-K

On Sep 1, 2004, at 3:46 PM, Joe Batt wrote:

> And every computer I've ever used already has a method to do that.  In
> DOS I used batch files, VMS command files, Unix shell scripts, windows
> shortcuts.
>
> What is the difference between creating a configuration file that has
> qemu options or making a shortcut with qemu options?  Either way you
> have a file with expressions that have to be looked up in a manual.

Re: [Qemu-devel] Qemu development schedule?

[Jim C. Brown]

On Wed, Sep 01, 2004 at 03:25:08PM -0400, Kai Cherry wrote:
> 
> That would be a start. I suggested something even more simple just 
> minutes ago: a config file :)
> Most simple UI in the world, but very, very helpful.
> 
> qemu -c <somefilefullofoptions>
> 
> Would that be helpful? (It would be commented nice for ya, as well.)
> 
> -K
> 
> 

Fabrice mentioned .qmu files a while ago ... perhaps those are what you are
talking about?

I wrote a script wrapper that takes a config file and uses it to pass options
to qemu, so I've had this ability for a long time.

> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

[Qemu-devel] Filegetopt (Was: Qemu development schedule?)

[Renzo Davoli]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

I sent to Fabrice my filegetopt library. (I am not blaming in any way
Fabrice that we know is very overbusy in a productive way).
I made a test integration with an old version of qemu long time ago.

It has been designed to convert programs using getopt_long.

It has been released under the LGPL then can be used by a BSD,
or there is no problem to simply "get inspired" for a configuration
file management.

ciao
	renzo

filegetopt is here attached.

[-- Attachment #2: filegetopt.tgz --]
[-- Type: application/x-gtar, Size: 14506 bytes --]

Re: [Qemu-devel] Qemu development schedule?

[Johannes Schindelin]

Hi,

On Tue, 31 Aug 2004, Jeebs wrote:

> > I don't want to be harsh, but for me it is only important that the stuff I
> > need works, the rest doesn't matter to me as long as I don't benefit from
> > it...
>
> **BINGO!**
>
> That's precisely the kind of attitude I was concerned about.

So you are saying that because you like what the developers did so far,
they please now should change their attitude according to your
expectations?

> At some point, successful open source projects have to transition from the
> 'free for all' attitude and organization to one with some actual specified
> goals and some organization.

Why?

> But at least a list of things to do and a schedule that says things like:
> "When we add x, y, and Z and fix critical bugs 1, 2, 3, and 4, we'll
> probably release the next version."  That wouldn't stop people from adding
> their own patches to fix their own problems.  Or maybe do a feature early
> (provided more critcal stuff isn't being neglected).

You are so welcome to do that.

> If everybody is working on the 'sexy' stuff, then who is going to be doing
> the less glamorous stuff?

Those who need it. I personally know people who learnt Tcl/Tk just for
that stuff. I personally know people who can't write or fix programs, so
they had to provide detailed bug reports, get updated sources or patches
which they learnt to apply themselves, recompile, and test.

> I haven't done much 'development' since I was still using DOS.  I never
> learned C++, Java, etc.  I stayed with C and I'm out of practice with it.  I
> don't even have a C compiler installed anymore.

Cool! Almost the whole source code of Qemu is in C!

> > That just wouldn't be fair, right? A developer who spends time
> > and thought to implement something has to get something for it.
>
> That is true if you are talking about small projects or such.
>
> But when you are working on larger, more important projects, at some point
> you have to have some sort of organization, some sort of list of things to
> do, etc.  And at some point, somebody is going to have to work on things
> that need to get done that aren't "fun", or even usable for themselves.

Again, why? If things get unusable for a developer, she will fix it. If
things get unusable for a non-developer, he will try to find somebody who
can and wants to fix it (often you can help the 2nd part).

> But if the project has the *eventual goal* of being more usable for a wider
> range of people, then at some point you have to change how things are done.

Why should the project have that goal? I am not Jesus nor RMS.

> At the very least, you need a list of things that eventually need to be
> done.

No. You don't. Nobody has a (complete) list of things that need to be done
for the Linux kernel.

Read "The Cathedral and the Bazaar". Don't expect other people to do what
you would like them to do unless you are willing to be fair and give them
something in return.

This was my last post about that subject.

Ciao,
Dscho

Re: [Qemu-devel] Qemu development schedule?

[Jeebs]

From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>

>> That's precisely the kind of attitude I was concerned about.
>
> So you are saying that because you like what the developers did so far,
> they please now should change their attitude according to your
> expectations?

No, I'm saying it because I am concerned that how Qemu has been developed in
the past will soon turn out to be a liability and impeed future progress.


>> At some point, successful open source projects have to transition from
>> the
>> 'free for all' attitude and organization to one with some actual
>> specified
>> goals and some organization.
>
> Why?

Because most non-'toy' projects fail if they don't adapt.

Writing a program for your own use is one thing.  Writing a program for more
general use by other, non-developer, people is an altogether different
thing.

Non-developers have different expectations.  Even if they don't expect 100% 
perfect results and bug-free code, they still have different expectations, 
and a 'developer' attitude rarely addresses those kinds of expectations.

I think I read somewhere in the archives that Fabrice (?) once said (not in
these exact words) that he was kind of dreading the day that Qemu was
'discovered' by public because their expectations would be much different
than those of the developers.

>> But at least a list of things to do and a schedule that says things like:
>> "When we add x, y, and Z and fix critical bugs 1, 2, 3, and 4, we'll
>> probably release the next version."  That wouldn't stop people from
>> adding
>> their own patches to fix their own problems.  Or maybe do a feature early
>> (provided more critcal stuff isn't being neglected).
>
> You are so welcome to do that.

Alright.

How do I do it?

Since I'm not a developer, how do I determine what to put onto the list of
things that need to be done?  A wee bit of a problem there.


>> If everybody is working on the 'sexy' stuff, then who is going to be
>> doing
>> the less glamorous stuff?
>
> Those who need it. I personally know people who learnt Tcl/Tk just for
> that stuff. I personally know people who can't write or fix programs, so
> they had to provide detailed bug reports, get updated sources or patches
> which they learnt to apply themselves, recompile, and test.

Which is fine for an early stage project.

>> I haven't done much 'development' since I was still using DOS.  I never
>> learned C++, Java, etc.  I stayed with C and I'm out of practice with it.
>> I
>> don't even have a C compiler installed anymore.
>
> Cool! Almost the whole source code of Qemu is in C!

But as I said, I'm out of practice.

Just last week I was trying to tell somebody about a library function, and I
had to actually go dig out my ref books just to see what header it's in and
what the params are.

After several years of no programming at all, I honest and truely seriously 
doubt you'd be happy with the quality of code that I'd be writing today.


> Again, why? If things get unusable for a developer, she will fix it. If
> things get unusable for a non-developer, he will try to find somebody who
> can and wants to fix it (often you can help the 2nd part).

Alright....

So these users complain.  Which has been starting to happen.

What are the chances those bugs will get fixed?  Especially if nobody is
bothering to even write them down?

Pretty much zero.

Unless a developer happens to decide that particular day to work on that 
particular bug, he's likely to forget about it.

If it's about his code, then he may remember a little longer.  But if it's 
somebody else's problem, then there's not much chance of him remembering it 
or working on it.

>> But if the project has the *eventual goal* of being more usable for a
>> wider
>> range of people, then at some point you have to change how things are
>> done.
>
> Why should the project have that goal? I am not Jesus nor RMS.

If it doesn't, then okay.  If the actual, official goal of the project is to
do it only as a developer project and not a user project, then okay.

But that needs to be stated, otherwise a whole lotta people are wasting
their time watching this project.


>> At the very least, you need a list of things that eventually need to be
>> done.
>
> No. You don't. Nobody has a (complete) list of things that need to be done
> for the Linux kernel.

Not a 100% list, probably not, no.  But they do (and did) have a rough list
of problems and things to do and test.

Re: [Qemu-devel] Qemu development schedule?

[Lionel Ulmer]

> But that needs to be stated, otherwise a whole lotta people are wasting
> their time watching this project.

Well, seeing that the project was never widely advertised (at least not by
Fabrice from what I know except the initial mails to the wine-devel /
linux-kernel mailing lists), one cannot blame the QEMU developpers for you
loosing your time :-)

Heck, it never even did any /. headlines despite booting Windows since at
least 6 months (the only references I know of where indirect like the
DarWine story). Maybe the day it will boot OS/X like PearPC.

Anyway, I would say that this is a wonderful opportunity for someone to do a
business (like CodeWeavers and TransGaming are doing for Wine, the prime
example of the 'never finished / never working' project :-) ).

    Lionel (for whom the QEMU code is a bit too much over his head to
            actively participate :-) )

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] Qemu development schedule?

[John R. Hogerhuis]

On Tue, 2004-08-31 at 10:40, Jeebs wrote:

> No, I'm saying it because I am concerned that how Qemu has been developed in
> the past will soon turn out to be a liability and impeed future progress.
> 

I'll believe it when I see it. For now, progress is fantastic. You not
being a developer means you don't know what you're talking about. So how
can you provide constructive criticism about development methodology? Do
you claim to know under what conditions Fabrice and those who provide
patches here, are effective, efficient developers?

> 
> >> At some point, successful open source projects have to transition from
> >> the
> >> 'free for all' attitude and organization to one with some actual
> >> specified
> >> goals and some organization.
> >
> > Why?
> 
> Because most non-'toy' projects fail if they don't adapt.
> 

Can you say passive aggressive? Your attitude implicit in the way you
say things is very negative. You will catch more flies with honey than
vinegar. Implying QEMU is a toy project is what you just did, that's
just going to piss off the folks that know you're wrong, and they will
stop listening to you, as I am about to do.

> Non-developers have different expectations.  Even if they don't expect 100% 
> perfect results and bug-free code, they still have different expectations, 
> and a 'developer' attitude rarely addresses those kinds of expectations.
> 

And non-programmers apparently have different expectations than
programmers, like, if someone places software for freely available for
download they are inviting me to come and whine about how they organize
the development they do in their free time...

How would you like your boss to show up at your house on the weekend and
give you advice on how to deal with your personal issues, or organize
your chores more effectively and efficiently around your house?

FOSS developers do things in their free time. They don't mind if you ask
politely for features or file/post bug reports. You are treading
dangerous ground though when as a non-contributor you start making
complaints about development style.

> Since I'm not a developer, how do I determine what to put onto the list of
> things that need to be done?  A wee bit of a problem there.
> 
> 

As a non-developer you may qualified to write howtos, documentation,
make bug-reports, and collect traces showing how to fix those bugs. What
you are not qualified to do is determine the best way a FOSS project
should be organized or what is the most effective/efficient way to get
useful features into a product. But that seems to be all that I'm
hearing from you.

But what it sounds even more like, is that you know enough about
software to get by. If you knew C once, you could pick it up again. But
it seems you would rather wallow in your helplessness, since then you
don't actually have to do anything about the problems you whine about.

> But as I said, I'm out of practice.
> 
> Just last week I was trying to tell somebody about a library function, and I
> had to actually go dig out my ref books just to see what header it's in and
> what the params are.
> 

Most programming these days is API treasure hunt. Do you seriously think
anybody but an idiot savant really has all argument lists and parameters
in his head? Learn to use grep.

> After several years of no programming at all, I honest and truely seriously 
> doubt you'd be happy with the quality of code that I'd be writing today.
> 

Probably not (that's why you need to give more respect to the type of
work that Fabrice is interested in doing, which is hard stuff the
average code monkey cannot do in a reasonable period of time), but does
that mean you can't design an API, build a front end, etc. Sometimes
just providing a working "seed" can spur another developer to extend it,
clean it up, or provide their own implementation. 

> 
> > Again, why? If things get unusable for a developer, she will fix it. If
> > things get unusable for a non-developer, he will try to find somebody who
> > can and wants to fix it (often you can help the 2nd part).
> 
> Alright....
> 
> So these users complain.  Which has been starting to happen.
> 

Not really. I haven't noticed much in the way of complaints aside from
yours. Most of the things I've read from non-programmers is "I can get
such and such to work, I've tried 6 ways, I read the FAQ, can't get it
to work, what do I do?" This is 100% legitimate. How to ask questions is
covered thoroughly by ESR, I suggest you learn to do it and ask one. If
you want to file bug reports against a front end, you're in luck as
there are front end projects out there (I believe there were 2 at last
count... but have you even tried contacting the folks at the project you
do know about?)

> What are the chances those bugs will get fixed?  Especially if nobody is
> bothering to even write them down?
> 
> Pretty much zero.
> 

Folks are generating patches, they post them to the list, and Fabrice
applies them as he sees fit. That's how it works. Do you have any reason
to believe he's dropping legitimate patches that should be applied?


> >
> > Why should the project have that goal? I am not Jesus nor RMS.
> 
> If it doesn't, then okay.  If the actual, official goal of the project is to
> do it only as a developer project and not a user project, then okay.
> 

Huh? I can use it. I don't have to tweak any code to use it. Therefore
it is usable. Does that make it a "user project", I don't know, since
I've never heard that term before...

What is a "developer project?" did you make that up? Do you know any
software projects that don't start out with sharp edges outside of
medical and aerospace? QEMU is remarkably usable for a young project of
its complexity. How much did you pay for VmWare? Look at how much you
paid for QEMU, and consider that QEMU is probably at or exceeding vmware
functionality in many ways, and is rapidly improving in the important
areas.

Since Fabrice said he would commit a decent GUI implementation to source
control, you can either pray that someone does it, learn to do it
yourself, pay someone to do it (i.e. start a company like Codeweavers
and build a polished front end and focus on showstopper bugs and
usability issues), etc. What won't work is whining to the list.

> But that needs to be stated, otherwise a whole lotta people are wasting
> their time watching this project.
> 

Or else what, the Free Software Regulatory Agency is going to fine the
project? If you're asking for permission to go find something else to do
while QEMU "evolves" past a "toy " "developer project" (all your words)
then I give you permission. Go find something else to do. Whining about
things you clearly don't grok is unproductive. In the meantime you
apparently have a copy of VmWare to use.

If one non programmer on this list is making good use of QEMU, than you
are dead wrong on this about people "wasting their time." QEMU has
gotten steadily more useful in the important ways, even if not your pet
feature (GUI front end)

> 
> >> At the very least, you need a list of things that eventually need to be
> >> done.
> >
> > No. You don't. Nobody has a (complete) list of things that need to be done
> > for the Linux kernel.
> 
> Not a 100% list, probably not, no.  But they do (and did) have a rough list
> of problems and things to do and test.
> 

No you are wrong. Linux is chaos with some controls, i.e. Linus and his
lieutenants. There is no roadmap a la a commercial project. And if you
notice, even in the commercial world, without a contract, roadmaps and
the substrate the bits travel is worth the substrate.

-- John.

Re: [Qemu-devel] Qemu development schedule?

[Kai Cherry]

I think the comment below sums up exactly what the guy is talking about:

I don't care how much code you contribute, you hostility is a DETRIMENT.

My suggestion: Help the guy, consider what he's saying...or if you find 
he is "unworthy" of your help then STFU.

THE MAN SAID the user list doesn't work, and instead of taking this 
under advise ment, you go into an all-too-familiar quasi-religious 
rant.

If you have nothing to add to the thread besides Stump-Poundin' FOSS 
tripe (as if YOU spoke for the whole damned thing...you know what its 
"really" about)..
then just walk away.

You sound like someone that got burned during the .bomb by a crap 
company or something. I don't think he's that marketing guy you hated 
from back then...

-K

On Sep 1, 2004, at 1:03 PM, John R. Hogerhuis wrote:

> You not
> being a developer means you don't know what you're talking about

Re: [Qemu-devel] Qemu development schedule?

[Info]

Thanks for clarifying this to some people. I have seen a 
lot of other newslists where similar people are 
complaining about the free and good work of genious 
persons. I like this project and it helps some people to 
get there old OS and apps working on a new machine. Why 
should the normal user relearn every thing again when he 
got his apps that do what he need ?

Thanks to Fabrice and all supporting people.

Andreas

On Wed, 01 Sep 2004 10:03:40 -0700
  "John R. Hogerhuis" <jhoger@pobox.com> wrote:
>*This message was transferred with a trial version of 
>CommuniGate(tm) Pro*
>On Tue, 2004-08-31 at 10:40, Jeebs wrote:
>
>> No, I'm saying it because I am concerned that how Qemu 
>>has been developed in
>> the past will soon turn out to be a liability and impeed 
>>future progress.
>> 
>
>I'll believe it when I see it. For now, progress is 
>fantastic. You not
>being a developer means you don't know what you're 
>talking about. So how
>can you provide constructive criticism about development 
>methodology? Do
>you claim to know under what conditions Fabrice and those 
>who provide
>patches here, are effective, efficient developers?
>
>> 
>> >> At some point, successful open source projects have 
>>to transition from
>> >> the
>> >> 'free for all' attitude and organization to one with 
>>some actual
>> >> specified
>> >> goals and some organization.
>> >
>> > Why?
>> 
>> Because most non-'toy' projects fail if they don't 
>>adapt.
>> 
>
>Can you say passive aggressive? Your attitude implicit in 
>the way you
>say things is very negative. You will catch more flies 
>with honey than
>vinegar. Implying QEMU is a toy project is what you just 
>did, that's
>just going to piss off the folks that know you're wrong, 
>and they will
>stop listening to you, as I am about to do.
>
>> Non-developers have different expectations.  Even if 
>>they don't expect 100% 
>> perfect results and bug-free code, they still have 
>>different expectations, 
>> and a 'developer' attitude rarely addresses those kinds 
>>of expectations.
>> 
>
>And non-programmers apparently have different 
>expectations than
>programmers, like, if someone places software for freely 
>available for
>download they are inviting me to come and whine about how 
>they organize
>the development they do in their free time...
>
>How would you like your boss to show up at your house on 
>the weekend and
>give you advice on how to deal with your personal issues, 
>or organize
>your chores more effectively and efficiently around your 
>house?
>
>FOSS developers do things in their free time. They don't 
>mind if you ask
>politely for features or file/post bug reports. You are 
>treading
>dangerous ground though when as a non-contributor you 
>start making
>complaints about development style.
>
>> Since I'm not a developer, how do I determine what to 
>>put onto the list of
>> things that need to be done?  A wee bit of a problem 
>>there.
>> 
>> 
>
>As a non-developer you may qualified to write howtos, 
>documentation,
>make bug-reports, and collect traces showing how to fix 
>those bugs. What
>you are not qualified to do is determine the best way a 
>FOSS project
>should be organized or what is the most 
>effective/efficient way to get
>useful features into a product. But that seems to be all 
>that I'm
>hearing from you.
>
>But what it sounds even more like, is that you know 
>enough about
>software to get by. If you knew C once, you could pick it 
>up again. But
>it seems you would rather wallow in your helplessness, 
>since then you
>don't actually have to do anything about the problems you 
>whine about.
>
>> But as I said, I'm out of practice.
>> 
>> Just last week I was trying to tell somebody about a 
>>library function, and I
>> had to actually go dig out my ref books just to see what 
>>header it's in and
>> what the params are.
>> 
>
>Most programming these days is API treasure hunt. Do you 
>seriously think
>anybody but an idiot savant really has all argument lists 
>and parameters
>in his head? Learn to use grep.
>
>> After several years of no programming at all, I honest 
>>and truely seriously 
>> doubt you'd be happy with the quality of code that I'd 
>>be writing today.
>> 
>
>Probably not (that's why you need to give more respect to 
>the type of
>work that Fabrice is interested in doing, which is hard 
>stuff the
>average code monkey cannot do in a reasonable period of 
>time), but does
>that mean you can't design an API, build a front end, 
>etc. Sometimes
>just providing a working "seed" can spur another 
>developer to extend it,
>clean it up, or provide their own implementation. 
>
>> 
>> > Again, why? If things get unusable for a developer, 
>>she will fix it. If
>> > things get unusable for a non-developer, he will try 
>>to find somebody who
>> > can and wants to fix it (often you can help the 2nd 
>>part).
>> 
>> Alright....
>> 
>> So these users complain.  Which has been starting to 
>>happen.
>> 
>
>Not really. I haven't noticed much in the way of 
>complaints aside from
>yours. Most of the things I've read from non-programmers 
>is "I can get
>such and such to work, I've tried 6 ways, I read the FAQ, 
>can't get it
>to work, what do I do?" This is 100% legitimate. How to 
>ask questions is
>covered thoroughly by ESR, I suggest you learn to do it 
>and ask one. If
>you want to file bug reports against a front end, you're 
>in luck as
>there are front end projects out there (I believe there 
>were 2 at last
>count... but have you even tried contacting the folks at 
>the project you
>do know about?)
>
>> What are the chances those bugs will get fixed? 
>> Especially if nobody is
>> bothering to even write them down?
>> 
>> Pretty much zero.
>> 
>
>Folks are generating patches, they post them to the list, 
>and Fabrice
>applies them as he sees fit. That's how it works. Do you 
>have any reason
>to believe he's dropping legitimate patches that should 
>be applied?
>
>
>> >
>> > Why should the project have that goal? I am not Jesus 
>>nor RMS.
>> 
>> If it doesn't, then okay.  If the actual, official goal 
>>of the project is to
>> do it only as a developer project and not a user 
>>project, then okay.
>> 
>
>Huh? I can use it. I don't have to tweak any code to use 
>it. Therefore
>it is usable. Does that make it a "user project", I don't 
>know, since
>I've never heard that term before...
>
>What is a "developer project?" did you make that up? Do 
>you know any
>software projects that don't start out with sharp edges 
>outside of
>medical and aerospace? QEMU is remarkably usable for a 
>young project of
>its complexity. How much did you pay for VmWare? Look at 
>how much you
>paid for QEMU, and consider that QEMU is probably at or 
>exceeding vmware
>functionality in many ways, and is rapidly improving in 
>the important
>areas.
>
>Since Fabrice said he would commit a decent GUI 
>implementation to source
>control, you can either pray that someone does it, learn 
>to do it
>yourself, pay someone to do it (i.e. start a company like 
>Codeweavers
>and build a polished front end and focus on showstopper 
>bugs and
>usability issues), etc. What won't work is whining to the 
>list.
>
>> But that needs to be stated, otherwise a whole lotta 
>>people are wasting
>> their time watching this project.
>> 
>
>Or else what, the Free Software Regulatory Agency is 
>going to fine the
>project? If you're asking for permission to go find 
>something else to do
>while QEMU "evolves" past a "toy " "developer project" 
>(all your words)
>then I give you permission. Go find something else to do. 
>Whining about
>things you clearly don't grok is unproductive. In the 
>meantime you
>apparently have a copy of VmWare to use.
>
>If one non programmer on this list is making good use of 
>QEMU, than you
>are dead wrong on this about people "wasting their time." 
>QEMU has
>gotten steadily more useful in the important ways, even 
>if not your pet
>feature (GUI front end)
>
>> 
>> >> At the very least, you need a list of things that 
>>eventually need to be
>> >> done.
>> >
>> > No. You don't. Nobody has a (complete) list of things 
>>that need to be done
>> > for the Linux kernel.
>> 
>> Not a 100% list, probably not, no.  But they do (and 
>>did) have a rough list
>> of problems and things to do and test.
>> 
>
>No you are wrong. Linux is chaos with some controls, i.e. 
>Linus and his
>lieutenants. There is no roadmap a la a commercial 
>project. And if you
>notice, even in the commercial world, without a contract, 
>roadmaps and
>the substrate the bits travel is worth the substrate.
>
>-- John.
>
>
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Qemu development schedule?

[John R. Hogerhuis]

On Tue, 2004-08-31 at 09:32, Johannes Schindelin wrote:

> Why should the project have that goal? I am not Jesus nor RMS.


Heheh...

I heard that Jesus is *all about* usability, and that he uses a "Mac".

Hence the heuristic, "What would Jesus design?"

-- John.

Re: [Qemu-devel] Qemu development schedule?

[andrej]

Quoting "John R. Hogerhuis" <jhoger@pobox.com>:

> I heard that Jesus is *all about* usability, and that he uses a "Mac".
Macs suck :) ... if anything, He'd run Linux on a quad-opteron ...

Re: [Qemu-devel] Qemu development schedule?

[Kai Cherry]

You guys are actually quite humorous...I like that :)

On Aug 31, 2004, at 3:07 PM, andrej@paradise.net.nz wrote:

> Quoting "John R. Hogerhuis" <jhoger@pobox.com>:
>
>> I heard that Jesus is *all about* usability, and that he uses a "Mac".
> Macs suck :) ... if anything, He'd run Linux on a quad-opteron ...
>

Heheh Linux on Opertons is more of his Dad's thing..the 
Rumble/power/Fire/Brimstone deal.

"And the heavens SHOOK and ROARED...."


The J-man has that whole "suffer the children/water to wine" type 
approach...

"as easy as turning water to wine...see?"
"Wowwww...where do I sigh up?"

-K

>
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] Qemu development schedule?

[Hetz Ben Hamo]

Although I'm not Fabrice, I'll try to answer your questions..

> What is the development schedule for Qemu?

Unknown at the moment ;)

> In other words, what priority is there for various things?

Looking at the CVS commits from Fabrice, I'd say it's in the features adding 
stages, and some occasional bug fixing (see the Fedora core fixes for 
example)

> Fabrice's recent comment about vastly speeding up Qemu got me thinking that
> perhaps it might be better to work on other things first.
>
> Don't misunderstand me... The recent discussion about performance
> improvements, and Fabrice's comments were *very* exciting.

Indeed, but I would suggest to wait for some more info from Fabrice until he 
publishes somsthing..

> But I was just thinking that before you do the exciting and the 'sexy'
> things, that perhaps you should work on the more mundane things needed to
> make Qemu into a highly usable product.
>
> Like vastly improving the user interface.  Especially for Window's users
> (such as myself.)

Fabrice didn't do the Windows version port, someone else did it and I think 
someone else is doing some front end for it (see my URL: 
http://dad-answers.com/qemu/patches for win32 stuff)

[snip]
> As I said above, I'm not a developer.  So maybe I'm out of place even
> making these questions and comments.  If so, I apologize.  I do indeed
> think Qemu is an excellent project.  It's very exciting and that's why I'm
> here lurking.
>
> I'm just a little concerned that maybe qemu might always be an incomplete,
> un-stable, un-usable beta program.  An interesting program without the
> refinements and the polishing.
>
> If all you ever do is work on the exciting stuff, and fix the occasional
> problem, then the project may have trouble reaching the level of quality it
> should.
>
> That's why I was wondering what the project schedule actually was.  At what
> points are things going to be added or fixed or improved.
>
> Or is Qemu still in the "free for all" early development stage where people
> work on whatever exciting or sexy thing they feel like, with no actual plan
> or organization?

QEMU is a "one man show" (fabrice) while some other contribute stuff for it. 
It's not being developed under a sponsorship and Fabrice does it in his free 
time. Same thing goes with other features that people wrote and Fabrice 
committed to CVS - they might continue develop it or not, but with open 
source, someone else could possibly continue working on it..

If some white knight would approach fabrice and would suggest to sponsor the 
QEMU development, then I think that QEMU will have roadmaps, scheduling and 
other "sexy" stuff. For now - it's Fabrice "show" and others 
contributions....

Hope it helps,
Thanks,
Hetz

Re: [Qemu-devel] Qemu development schedule?

[Jeebs]

From: "Hetz Ben Hamo" <hetz@witch.dyndns.org>
>> Don't misunderstand me... The recent discussion about performance
>> improvements, and Fabrice's comments were *very* exciting.
>
> Indeed, but I would suggest to wait for some more info from Fabrice until
> he  publishes somsthing..

Well, I'm not going to go and throw out my VMWare just yet, if that's what
you mean...[grin]

But it is very nice to see an open source project making such progress!



> Fabrice didn't do the Windows version port, someone else did it and I
> think

Right.  I do know there are people in here besides him.  It was just his
statement about the possible future performance that got me really excited.

> someone else is doing some front end for it (see my URL:
> http://dad-answers.com/qemu/patches for win32 stuff)

The only Windows front end I've seen was "Qemu Workstation" and that's
rather out of date and doesn't even work with the current daily FreeOSZoo
builds.

> QEMU is a "one man show" (fabrice) while some other contribute stuff for

That I didn't know.

I knew Fabrice was important, but  wasn't aware that he was doing most of 
the core stuff.

> committed to CVS - they might continue develop it or not, but with open
> source, someone else could possibly continue working on it..

Yup.  That's one of the reasons I'd prefer an opensource product over 
VMWare.



> other "sexy" stuff. For now - it's Fabrice "show" and others
> contributions....
>
> Hope it helps,

Thanks.

That does explain a few things.

So basically, there's no roadmap or schedule for features, etc.  And it's 
basically going to be a "free for all" for the foreseeable future.

Re: [Qemu-devel] Qemu development schedule?

[John R. Hogerhuis]

On Mon, 2004-08-30 at 15:59, Jeebs wrote:

> So basically, there's no roadmap or schedule for features, etc.  And it's 
> basically going to be a "free for all" for the foreseeable future.

And I'd argue that this is a completely normal, effective, proven
pattern for FOSS projects. Given this is volunteer work it is completely
natural that the developer(s) organize work fun-down. Can you name any
projects that don't operate this way and also do not have corporate
sponsorship?

Thankfully, the fun-down approach actually means the heavy lifting gets
done early by characters like Fabrice.

Polish (nice frontend) is something that can be thrown on later once the
core functionality is in (that means speed, accuracy, and hardware
emulation, in that order, IMHO...)  If you need it now, contribute to
the front end projects in some way; report bugs, talk to the developers,
or fork it (last resort). Front end code isn't the hardest stuff to
develop. As proof look at the VB programmer infestation in any corporate
office.

When Fabrice thinks that the software is too big to maintain alone, I'm
sure he will delegate work. He doesn't seem to be at his breaking point
yet. For now he seems to accept good patches, or writes patches himself
when he doesn't like the way something was done.

-- John.

Re: [Qemu-devel] Qemu development schedule?

[Kai Cherry]

On Aug 30, 2004, at 7:34 PM, John R. Hogerhuis wrote:

> Polish (nice frontend) is something that can be thrown on later once 
> the
> core functionality is in (that means speed, accuracy, and hardware
> emulation, in that order, IMHO...)

I think this is actually a *failing* of most FOSS projects...the 
afterthought of how "regular" folks will *use* the thing.

Then again, I'm a mac developer; we learn to design the solution around 
people ;)

(thats a friendly jab folks... :))

-K

Re: [Qemu-devel] Qemu development schedule?

[Patrick Mauritz]

> I think this is actually a *failing* of most FOSS projects...the
> afterthought of how "regular" folks will *use* the thing.
I guess no-one would mind you stepping in and help

> Then again, I'm a mac developer; we learn to design the solution around
> people ;)
so that's why mac is again being marginalized?

> (thats a friendly jab folks... :))
dito :)


patrick

Re: [Qemu-devel] Qemu development schedule?

[Kai Cherry]

On Aug 31, 2004, at 6:15 AM, Patrick Mauritz wrote:

>> I think this is actually a *failing* of most FOSS projects...the
>> afterthought of how "regular" folks will *use* the thing.
> I guess no-one would mind you stepping in and help

Its not "important" :)

actually we were thinking about a nice document-centric approach for 
setting up virtual machines...

Not sure how suited it would be for anything but OS X...and i don't 
like that xml gui renaissance thing.

>
>> Then again, I'm a mac developer; we learn to design the solution 
>> around
>> people ;)
> so that's why mac is again being marginalized?

Because it doesn't run Win32, I'd imagine. For some reason, heheh folks 
seem to see this as a *negative*.

>
>> (thats a friendly jab folks... :))
> dito :)
>

Its all good...many roads, many paths :)

>
> patrick
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] Qemu development schedule?

[Gianni Tedesco]

On Tue, 2004-08-31 at 05:21 -0400, Kai Cherry wrote:
> On Aug 30, 2004, at 7:34 PM, John R. Hogerhuis wrote:
> 
> > Polish (nice frontend) is something that can be thrown on later once 
> > the
> > core functionality is in (that means speed, accuracy, and hardware
> > emulation, in that order, IMHO...)
> 
> I think this is actually a *failing* of most FOSS projects...the 
> afterthought of how "regular" folks will *use* the thing.

Technically, if the primitives and operations the programmer exposes to
the uppermost level of API are sound, an effective UI that makes sense
*can* be quite simply "bolted on".

The real failing of such projects is identifying what are the
primitives, and how do they interact. The confused low level design
leads to confused top level design.

The same applies in reverse with a top-down design. That is to say, if
the top level design is confused, then the core functionality will never
work right.

> Then again, I'm a mac developer; we learn to design the solution around 
> people ;)
> 
> (thats a friendly jab folks... :))

That must mean you find that task of adapting software to users
requirements fun? Or you wouldn't develop in that environment right? If
so, then you are in a good position to make these kinds of changes
happen in qemu for example... ;)

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

Re: [Qemu-devel] Qemu development schedule?

[Kai Cherry]

On Aug 31, 2004, at 1:23 PM, Gianni Tedesco wrote:

> That must mean you find that task of adapting software to users
> requirements fun? Or you wouldn't develop in that environment right? If
> so, then you are in a good position to make these kinds of changes
> happen in qemu for example... ;)
>
One of the *good* things about QEMU (besides Fabrice's brilliance) is 
in fact that it might be adaptable to something more than a mere 
"switch wrapper" gui.

GUI's for the sake of not opening the term are usually pretty bad, 
since most things that wrap with this in mind switch one kind of 
confusion for another.

The way qemu is coming along makes it fairly "tight" and I'm glad its 
not (yet) piling flag after flag onto the commandline. It should be 
fairly simple for a user
to set up a "Linux 2.4" Virtual Session "document" for example...a lot 
like the way VirtualPC works.

The point I was trying to make, sort of in parallel to the "many 
questions" post that started this is that for most of the FOSS stuff 
I've tracked, end-user usability is either an
afterthought, or, as some of the posts here seem to suggest, not a core 
consideration, if worth considering at all...with a sprinkle of "arcane 
equals superiority" liberally applied.

"If they can't figure it out, they don't deserve it" sort of 
mentality...as opposed to "if they can't figure it out then perhaps we 
have more work to do."

Making the "impossible" possible is a feat; making the impossible both 
"possible" and "brain dead simple" is a whole other class of 
engineering above that :)

Oddly enough, I have little interest in emulating a pc/pc os on my OS X 
machines (its just too slow for my taste) but moreso PPC OS's.

Re: [Qemu-devel] Qemu development schedule?

[Magnus Damm]

Heya,

> Oddly enough, I have little interest in emulating a pc/pc os on my OS X 
> machines (its just too slow for my taste) but moreso PPC OS's.

Recently me and my girlfriend played through the good old MYST game on
OS 9.x running in the mac-on-linux emulator on a G4 Cube 450MHz.
Real time sound and everything. Kicks ass. =)

/ magnus

Re: [Qemu-devel] Qemu development schedule?

[Fabrice Bellard]

Hi,

To answer the subject of the post, there is no real developement 
schedule for QEMU as I develop it for fun during my free time. As for 
several other of my projects there is also no guaranty that it will ever 
reach version 1.00 and that I won't "switch" to another project soon. In 
the latter case, a new maintainer will be needed.

My current priorities for QEMU are speed and emulation correctness for 
both x86 and PowerPC host and guests. About the GUI, as I said earlier, 
I would be delighted if someone submitted a GTK and/or a win32 GUI 
directly integrated in QEMU - I tend to dislike the 'frontend' approach. 
I won't work on the GUI in the forseeable future.

Note also that I don't use Windows nor Mac OS X, so I cannot maintain 
nor test these ports, but I recognize there are very important so I try 
to merge the porting patches when I consider they are clean enough.

Fabrice.

Re: [Qemu-devel] Qemu development schedule?

[René Korthaus]

Am 31.08.2004 um 22:27 schrieb Fabrice Bellard:

> About the GUI, as I said earlier, I would be delighted if someone 
> submitted a GTK and/or a win32 GUI directly integrated in QEMU - I 
> tend to dislike the 'frontend' approach.

I have to admit that I am rather sceptical about this point. In my 
opinion that could split development of future versions of QEMU and 
threaten a main feature of QEMU - the platform-indepedence. I am 
currently working on a GUI for Mac OS X and I have to admit, too, that 
always working "around" the QEMU binary is not a long-time solution. A 
short-time solution which works for me is getting and installing QEMU 
for the user automatically.

I think it's difficult to find a final solution here, but keep working 
on QEMU. You do a great job.

Greetings

Re: [Qemu-devel] Qemu development schedule?

[Jim C. Brown]

On Tue, Aug 31, 2004 at 11:50:44PM +0200, Ren? Korthaus wrote:
> 
> Am 31.08.2004 um 22:27 schrieb Fabrice Bellard:
> 
> I have to admit that I am rather sceptical about this point. In my 
> opinion that could split development of future versions of QEMU and 
> threaten a main feature of QEMU - the platform-indepedence. I am 
> currently working on a GUI for Mac OS X and I have to admit, too, that 
> always working "around" the QEMU binary is not a long-time solution. A 
> short-time solution which works for me is getting and installing QEMU 
> for the user automatically.
> 

The best solution would be to define an API for qemu. There is a library that
qemu uses, and this library can be compiled to use OSX Gui, Win32 GUI,
X lib, GTK, SDL (which should be decapriated), microX, Qt, wxWidgets, etc.

Basicly, the library is just a set of stubs that, when compiled w/ the right
#define, call the functions of the main library.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] Qemu development schedule?

[Patrick Mauritz]

On Tue, 31 Aug 2004 22:27:06 +0200, Fabrice Bellard <fabrice@bellard.org> wrote:
> I would be delighted if someone submitted a GTK and/or a win32 GUI
> directly integrated in QEMU - I tend to dislike the 'frontend' approach.
> I won't work on the GUI in the forseeable future.
maybe making qemu a library, with the current CLI as default/example
frontend might be better? that way you get tight integration of the
code, but frontends can still be developed separately


patrick mauritz

Re: [Qemu-devel] Qemu development schedule?

[Jim C. Brown]

On Tue, Aug 31, 2004 at 10:27:06PM +0200, Fabrice Bellard wrote:
> My current priorities for QEMU are speed and emulation correctness for 
> both x86 and PowerPC host and guests. About the GUI, as I said earlier, 
> I would be delighted if someone submitted a GTK and/or a win32 GUI 
> directly integrated in QEMU - I tend to dislike the 'frontend' approach. 
> I won't work on the GUI in the forseeable future.
> 

I am curious, what is wrong with using Xlib directly? Would you accept an
Xlib patch if it was simple enough to understand?

> 
> Fabrice.
> 
> 
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] Qemu development schedule?

[Lionel Ulmer]

On Wed, Sep 01, 2004 at 05:58:58PM -0400, Jim C. Brown wrote:
> I am curious, what is wrong with using Xlib directly? Would you accept an
> Xlib patch if it was simple enough to understand?

Well, the problem with using Xlib directly instead of via SDL is that you
loose easy portability to the Win32 platform (except if you ask people to
install an X server in Windows :-) ).

      Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] Qemu development schedule?

[Jim C. Brown]

On Thu, Sep 02, 2004 at 09:26:45AM +0200, Lionel Ulmer wrote:
> On Wed, Sep 01, 2004 at 05:58:58PM -0400, Jim C. Brown wrote:
> > I am curious, what is wrong with using Xlib directly? Would you accept an
> > Xlib patch if it was simple enough to understand?
> 
> Well, the problem with using Xlib directly instead of via SDL is that you
> loose easy portability to the Win32 platform 

So? Fabrice has said that he'll add support got the Win32 GUI directly if some
one sends a patch for it ... surely this makes it hard to port to the Linux
platform???

The idea is, use XLib when qemu is compiled under a *nix, use Win32 for Windows,
the OSX Gui (Aqua?) for Mac OS X, etc. I don't see what the problem here is.

Furthermore, there is a patch for Xlib already. So I ask, why not?

>(except if you ask people to
> install an X server in Windows :-) ).
> 

Not a bad idea imho, tho not optimal.

>       Lionel
> 
> -- 
> 		 Lionel Ulmer - http://www.bbrox.org/
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] Qemu development schedule?

[Lionel Ulmer]

> So? Fabrice has said that he'll add support got the Win32 GUI directly if some
> one sends a patch for it ... surely this makes it hard to port to the Linux
> platform???

My only problem with that is that I do not wish to see the QEMU code go down
the #ifdef / #endif hell (with #ifdef X11 / COCOA / WIN32 / .... sprinkled
anywhere over the code).

So such patches are great .... if they are based on a framework that make
adding new display / input / sound drivers painless (i.e. without touching a
single line of code in QEMU's main code).

             Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] Qemu development schedule?

[Jim C. Brown]

On Fri, Sep 03, 2004 at 01:28:35AM +0200, Lionel Ulmer wrote:
> > So? Fabrice has said that he'll add support got the Win32 GUI directly if some
> > one sends a patch for it ... surely this makes it hard to port to the Linux
> > platform???
> 
> My only problem with that is that I do not wish to see the QEMU code go down
> the #ifdef / #endif hell (with #ifdef X11 / COCOA / WIN32 / .... sprinkled
> anywhere over the code).
> 
> So such patches are great .... if they are based on a framework that make
> adding new display / input / sound drivers painless (i.e. without touching a
> single line of code in QEMU's main code).
> 

The ironic thing is that the original X11 driver did this seamlessly.
You just removed the original sdl.c and renamed the X11 file to sdl.c and
recompiled. Not as good as an actual framework tho.

I guess we could split the sdl.c file into grap.c and sdl-driver.c, where
grap.c provides all the functions that qemu calls (such as sdl_update_caption
or toggle_full_screen), and grap.c simply calls a function in sdl-driver.c
... then to add X11 support, one simply has to send a patch to add the
appropriate #ifdefs to grap.c and write an x11-driver.c

>              Lionel
> 
> -- 
> 		 Lionel Ulmer - http://www.bbrox.org/
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] Qemu development schedule?

[Fabrice Bellard]

Having a GUI goes further than just having the display and keyboard API 
(as you implied, such an API already exists in QEMU and it is fairly 
easy to add a new display/keyboard driver). The real problem is to 
handle all the configuration stuff with a simple API and even to manage 
several VMs at once. If a minimal GTK, win32 or Mac OS X GUI is 
submitted, then I'll improve the API.

Fabrice.

Jim C. Brown wrote:
> On Fri, Sep 03, 2004 at 01:28:35AM +0200, Lionel Ulmer wrote:
> 
>>>So? Fabrice has said that he'll add support got the Win32 GUI directly if some
>>>one sends a patch for it ... surely this makes it hard to port to the Linux
>>>platform???
>>
>>My only problem with that is that I do not wish to see the QEMU code go down
>>the #ifdef / #endif hell (with #ifdef X11 / COCOA / WIN32 / .... sprinkled
>>anywhere over the code).
>>
>>So such patches are great .... if they are based on a framework that make
>>adding new display / input / sound drivers painless (i.e. without touching a
>>single line of code in QEMU's main code).
>>
> 
> 
> The ironic thing is that the original X11 driver did this seamlessly.
> You just removed the original sdl.c and renamed the X11 file to sdl.c and
> recompiled. Not as good as an actual framework tho.
> 
> I guess we could split the sdl.c file into grap.c and sdl-driver.c, where
> grap.c provides all the functions that qemu calls (such as sdl_update_caption
> or toggle_full_screen), and grap.c simply calls a function in sdl-driver.c
> ... then to add X11 support, one simply has to send a patch to add the
> appropriate #ifdefs to grap.c and write an x11-driver.c
> 
> 
>>             Lionel
>>
>>-- 
>>		 Lionel Ulmer - http://www.bbrox.org/
>>
>>
>>_______________________________________________
>>Qemu-devel mailing list
>>Qemu-devel@nongnu.org
>>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>
> 
> 

Re: [Qemu-devel] Qemu development schedule?

[Adrian Smarzewski]

Lionel Ulmer wrote:
> So such patches are great .... if they are based on a framework that make
> adding new display / input / sound drivers painless (i.e. without touching a
> single line of code in QEMU's main code).

I think that shared libraries (drivers) would be the best.
Think about binary distributions.

Re: [Qemu-devel] Qemu development schedule?

[Fabrice Bellard]

This is my plan too. When multiple GUIs will be integrated there will be 
a glue API so that no patches are needed in the QEMU core.

Fabrice.

Lionel Ulmer wrote:
>>So? Fabrice has said that he'll add support got the Win32 GUI directly if some
>>one sends a patch for it ... surely this makes it hard to port to the Linux
>>platform???
> 
> 
> My only problem with that is that I do not wish to see the QEMU code go down
> the #ifdef / #endif hell (with #ifdef X11 / COCOA / WIN32 / .... sprinkled
> anywhere over the code).
> 
> So such patches are great .... if they are based on a framework that make
> adding new display / input / sound drivers painless (i.e. without touching a
> single line of code in QEMU's main code).
> 
>              Lionel
> 

Re: [Qemu-devel] Qemu development schedule?

[Daniel Serpell]

Hi!

El Thu, Sep 02, 2004 at 04:56:33PM -0400, Jim C. Brown escribio:
> 
> The idea is, use XLib when qemu is compiled under a *nix, use Win32 for
> Windows, the OSX Gui (Aqua?) for Mac OS X, etc. I don't see what the
> problem here is.
>

The problem when using XLib directly is localization, it's hard
to port your app to other languages. Using Gtk (or other good recent
libs), the localization problem is already solved.

        Daniel

Re: [Qemu-devel] Qemu development schedule?

[Jim C. Brown]

On Thu, Sep 02, 2004 at 07:53:57PM -0400, Daniel Serpell wrote:
> Hi!
> 
> El Thu, Sep 02, 2004 at 04:56:33PM -0400, Jim C. Brown escribio:
> > 
> > The idea is, use XLib when qemu is compiled under a *nix, use Win32 for
> > Windows, the OSX Gui (Aqua?) for Mac OS X, etc. I don't see what the
> > problem here is.
> >
> 
> The problem when using XLib directly is localization, it's hard
> to port your app to other languages. Using Gtk (or other good recent
> libs), the localization problem is already solved.
> 
>         Daniel
> 

This makes sense in general, but in the case of qemu, most of the text
is displayed on stdout (on the console/terminal). Gtk wouldn't make a
difference here, as only the title bar has any text that is send thru the
graphics driver (the text you see in the guest OS, by the time it gets to
SDL/GTK/XLib layer, is just a bunch of pixels). I don't see how localization
applies to qemu. It is true that the help text and such would need to be
localized, but GTK wouldn't help too much for that case anyways.

The only part of qemu that this issue applies to is the caption on the
title bar. Seeing that it is only in one place, this shouldn't be hard to
achieve...

> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] Qemu development schedule?

[John R. Hogerhuis]

With a control API the console stuff would be rewritten to access the
core via control API.

FWIW I think a control API makes a lot of sense. Then GUIs can be added
at will. It also opens the door to making QEMU fully scriptable which
sounds very powerful to me. Imagine being able to start the emulation,
monitor the processor, and pull an image of some portion of RAM or the
display when some condition occurs. Talk about making VmWare play
catch-up!

Here's a rough sketch of the work,

Features:

For now I would take anything that is currently available via the
monitor and divide it into properties and actions. We'd have a couple of
functions and table driven implementation for the property handling.
Very little code. For the actions we just pass through to the core of
QEMU as presently do

Roadbump:

We need to add lifecycle

Some properties can only be modified before the emulation is activated.
So there may be a simple active/inactive state machine, or something
more complex which guards the properties from being diddled at
inappropriate times.

Most of the API is going to be properties which one can get/set. But
given the nature of this being running virtual machines, a lot of those
properties only make sense in certain states. For example, you can't
change the amount of RAM available to a guest after it is launched, but
you can change it any other time. You can get the amount of RAM in use
or associated with a guest any time. So basically there is at least a
simple active/inactive lifecycle, but there may be a more complex
lifecycle state machine. There may be other properties that can be
changed at runtime. Basically anything you can currently manipulate from
the monitor that is not a function call, but just a change of property.

Haven't taken a hard look, most of this probably there in some form, but
may want to give QEMU core would get the following generic interface

init		- init qemu
cleanup		- cleanup qemu
create		- create a vm
destroy		- destroy a vm
activate	- activate a vm
deactivate	- deactivate a vm
prop_get
prop_set

+ you need to add functions for each action which QEMU exposes on the
virtual machine (like power on/off, reset, save state, etc.)

init allows qemu to set up any globals.

activate is what happens after you're done with parameterization
(properties that must be set before the machine is in steady state).

Other related design issues?

-- John.