Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Daniel Egger]

On 12.02.2005, at 14:42, Brad Campbell wrote:

> If you recall, the stated objective was to speed up x86 on x86,
> this meets the stated objective.

x86_64 *is* x86 + 64bit additions. If implemented right you
can run a complete 32bit userspace in 64bit kernel and have
single 64bit applications in cases where that makes sense;
problem here is that you can't mix 64bit and 32bit kernel code
and userland helpers. Two examples for affected users would
be kqemu and 32bit iptables.

> Where is the problem? If you want to improve x86 on x86_64,
> then work on it.

I'm not necessarily interested in x86 on x86_64 bit
emulation simply because it would be sort of hard (like
reimplementing the 32bit mode from the kernel in qemu)
to run 32bit code natively from a x86_64 application.

What does work though (with qemu-fast) is to run qemu as
32bit application on x86_64 and get pretty close to native
speed. This does *not* work with kqemu for above reasons.

> Give the guy a break before you bust his balls.

I'm not busting anyones balls; I was just pointing out
that it is you who's judging by two different measures.

> Can qemu-fast run anything other than free operating systems?

No, it'll only run Linux with a special kernel. However
this is not a problem for some specialised applications
like several Linux VMs on one capable machine. Since all
powerful x86 machines now and in the future will support
64bit and running a 64bit kernel is really important for
SMP and to get around the memory limitations this is a
severe restriction.

> Stop jumping to conclusions.

I'm sorry?

> So don't use that part of the emulator. Simple.

You do understand that this comes with a huge performance
penalty which wasn't there before, do you?

> What is being built here is a system that will rival vmware. Doing 
> this takes time and at the moment there are several companies watching 
> qemu with an eye to using it as the core of their technology. (As they 
> can with the current license). If Fabrice releases the accelerator 
> under the same license as the rest of the project, these companies 
> have no incentive to contribute financially to the project. Simple. 
> It's a lever.

This is pure speculation on your side and very easy to
prove wrong. I personally know hundreds of people who are
paid for working on OpenSource projects, including me. And
I suspect you'll hardly find *any* project that has partly
gone from OpenSource to OSS with restricted binary or even
completely closed source to raise money.

I stand by my claim that this way is very unconventional and
may not have the effects Fabrice is hoping for; but hey,
everyone deserves the right to make mistakes.... ;)

I'm definitely not saying that I have any problems myself with
the new licensing other than that it is a step backwards for me
in terms of usability because it castrates the system for
certain uses which are becoming more and more common.

> I'm quite sure that in time, someone is going to value the product 
> highly enough to pay for it, which in turn will allow the opening of 
> the source. All in good time.

Interesting opinion.

> In the mean time, deal with it. Use it if you want to (I am and it's 
> great). If you don't, then do what you were doing before. If you can't 
> use it because it just does not work for your particular application, 
> talk to Fabrice about helping out perhaps.

Let's wait until we receive some response from Fabrice about
some of the proposals that were made on the list. Once we
know about his real incentives the people will try to address
them and arrange something.

Servus,
      Daniel

PGP.sig
Description: This is a digitally signed message part