From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D1u1F-0007Q1-RU for qemu-devel@nongnu.org; Thu, 17 Feb 2005 17:21:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D1u17-0007M9-Fc for qemu-devel@nongnu.org; Thu, 17 Feb 2005 17:21:04 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D1u16-0007HX-2g for qemu-devel@nongnu.org; Thu, 17 Feb 2005 17:21:00 -0500 Received: from [212.16.62.51] (helo=mail.13thfloor.at) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D1tav-0006nc-4L for qemu-devel@nongnu.org; Thu, 17 Feb 2005 16:53:57 -0500 Date: Thu, 17 Feb 2005 22:53:50 +0100 From: Herbert Poetzl Subject: Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005 Message-ID: <20050217215350.GB1446@mail.13thfloor.at> References: <200502121018.09039.jm@poure.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Grzegorz Kulewski Cc: qemu-devel@nongnu.org On Sat, Feb 12, 2005 at 11:41:55PM +0100, Grzegorz Kulewski wrote: > Hi, >=20 > On Sat, 12 Feb 2005, Jean-Michel POURE wrote: > >Following Fabrice decision to transform QEMU into a proprietary closed > >solution >=20 > No, Fabrice did not transform QEMU into anything. He simply added anoth= er=20 > optional module than can make QEMU faster and more bug-free. You can st= ill=20 > use QEMU without the accelerator and be perfectly happy with it. Also a= ny=20 > further development in area of IO, devices and so on will make both=20 > versions better. KQEMU is only very small accelerator. well, unfortunately together with the following mail ... | From: Fabrice Bellard | To: qemu-devel@nongnu.org | Date: Sat, 29 Jan 2005 22:48:24 +0100 | | Hi, | | I plan to remove the 'qemu-fast' target in the next release of QEMU. It | is too painful to maintain, difficult to port and it needs a patched | guest OS to work correctly. | | This target is replaced by the standard QEMU with soft mmu support. The | QEMU Kernel Acceleration Layer which will be unveiled very soon will | give much more performance while working with unpatched guest OSes. | | Fabrice. the future looks more like this: - you want the same performance or better as before? then you have to use 'my' proprietary kernel module which isn't even open source (so that somebody could verify that it isn't that evil ...) - of course, you can use the slow version and contribute to the development of the commercial? version ... > Think about PHP and different accelerators. PHP itself is free product=20 > (PHP licence, IIRC). But there are many (often commercial but not all)=20 > accelerators for it (one even made by Zend - autor of PHP). But this=20 > does not make PHP less free. There are milions of people using PHP with= out=20 > any accelerator, there are some using it with commercial accelerator an= d=20 > there are few using it with one of free accelerators. Exactly the same=20 > goes for QEMU. >=20 > QEMU is even better because no non-free part is linked with any code in= =20 > QEMU (userspace). This way no QEMU based free products (for example GUI= s=20 > or anything other) are affected by this addition and no licence is brok= en.=20 > GPL, of course, allows calling non-free program or using GPLed program = on=20 > OS with non-free module. >=20 > Strictly speaking there are more problems at the kernel level. This is=20 > because Linus and other gave their permission to load non-free modules = to=20 > the kernel but only as a special exception and mainly because some kern= el=20 > modules were written for some other OSes and were ported to Linux and=20 > their code cannot be opened. This is not the case for KQEMU because it = was=20 > written especially for Linux but I think this is still more-or-less ok.= =20 > Nobody will hopefully complain. proprietary kernel modules are a dangerous thing ... - first, you basically lose any support from the=20 kernel developers, when your kernel is tainted - then you do not know what the module will do to your system (i.e. what crashes it may cause) - and finally, if you're paranoid, you will not know what kind of information that module might gather and send to who-knows-where ... > [ Fabrice, please make sure that all files linked with QEMU are free=20 > because GPL demands that. I did not investigated this but if the header= =20 > for the module is used in userspace please make it free (BSD?) too.=20 > Thanks. ] >=20 > Of course it will be better if KQEMU will go opensource but I hope it w= ill=20 > happen fast. open source, good -- free software, even better ... but don't get me wrong, it's totally up to Fabrice under what license he releases his software, and we have everything required to start of our own QEMU branch (just under a different name if I got the=20 Trademark comment right ;) and continue with free software development based on qemu/qemu-fast ... > >without any kind of future, I don't find any reason to loose my > >company time and money fostering FreeOSZoo. >=20 > Of course its your decision and you have perfect right to make it. But=20 > please think once more about it. I think that your project is very=20 > valuable for the community. >=20 >=20 > >I will hand over the project to any interested person, for exampe Raph= a=EBl=20 > >if > >he is interested by FreeOsZoo. >=20 > How fast must be the connection for it? How large is it? How much GB/mo= nth=20 > does it generate currently? I'm still hoping for the best, but expecting the worst ...=20 best, Herbert > Thanks, >=20 > Grzegorz Kulewski > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel