Re: [Qemu-devel] Qemu development schedule?

["Jeebs" <Jeebs@yango.us>]

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.