supporting closed source operating systems?

On Thu, Jul 10, 2008 at 02:06:50AM +0300, Axel Thimm wrote:
> On Wed, Jul 09, 2008 at 11:51:51PM +0100, Richard Jones wrote:
> > On Thu, Jul 10, 2008 at 12:57:57AM +0300, Axel Thimm wrote:
> > > But we're beyond the age of this kind of symbiosis, Linux (or
> > > GNU/Linux ...) and Fedora in particular doesn't need this anymore.
> >
> > The actual reality, real stuff in the real world, is that 90%+ of
> > users of desktop computer systems run Windows, another 5%+ are running
> > Mac OS X, and almost nobody (perhaps 10, 100 people in the whole
> > world?) are running a completely free operating system (inc. BIOS
> > etc).
>
> No one denies that, but don't we want to keep the fruits of F/LOSS to
> encourage more F/LOSS usage? Hijacking F/LOSS solutions back to closed
> source will not change the percentages above, on the contrary, you
> remove some of the good reasons to go Linux.

On the contrary - we are providing a viable migration path to Linux which
does not currently exist, due to combined vendor lockin of VMWare & Windows.
You can't switch one without the other & that's not something that it
viable for people to do.

Our motivation here is not to hijack or sabotage Fedora or F/LOSS, but
to promote its use and expand the userbase of Fedora.

Fedora provides an excellant platform for hosting virtual machines either
with Xen or KVM. The libvirt API provides a vendor-independant managment
API which helps users avoid vendor lockin to both the hypervisor, and
their management tools that you see when using VMWare & other commercial
virtalization projects.

Fedora has been leading the entire open source distro field in its
virtualization capabilities since Fedora Core 6, and feeds into many
other distros - RHEL or course, but also Ubuntu , SUSE and Solaris
are following our lead in management tools.

The main competition is obviously VMWare and they have been dominant
in all areas for years - every company which has a virtualization
management product/application supports VMWare. We've slowly been
trying to get these people to support libvirt, so that they can easily
manage virtual machines hosted on Fedora. The sad reality is that
most commercial management products use Windows as their base and
so unless we can provide libvirt for Windows they'll not use it and
thus not have any support for managing Fedora hosts, and just stick
with VMWare.

Having people ignore Fedora as a virtualization platform in favour
of VMWare is not what anyone wants. Hence we want to provide the
cross compiler toolchain in Fedora, so that we can build libvirt
client & client tools for Windows.

This will allow people with Windows desktops & management tools
to make use of Fedora virtualization. This will increase the userbase
of Fedora, and Linux based virtualization platforms. It will also
fully establish libvirt as the primary cross-platform, vendor neutral
management API for virtualzation. This is a huge step for F/LOSS over
the total dominence of VMWare in this area.

I can see further use cases where providing a MinGW toolchain will
benefit Fedora and F/LOSS. The FreeIPA project is providing state
of the art authentication & directory services based on F/LOSS in
Fedora, to rival the dominence of propriety ActiveDirectory services.
This is already a huge step forward in a homogeneous environment
of Linux servers and Linux desktops. Unless they can also support
Windows desktops as clients though, it will forever be a niche player
in the authentication/directory services arena. This is not good
for F/LOSS or Fedora. A MinGW toolchain will facilitate the support
of Windows clients and directly benefit the uptake of Fedora and
F/LOSS in this area.

The current situation where people have to use VMWare for virt if they
use Windows on the desktop does not provide an easy migration path to
Fedora, because they have to replace both their management infrastructure
and their desktop infrastructure at the same time. By providing a libvirt
client enabled for Windows, we provide a viable migration path from a
Windows world to a Fedora world. They can start off using Fedora for
hosting their virtual machines, and as they discover the benefits of
Fedora & F/LOSS they're more likely to also switch their desktop to Fedora.

So far from hijacking / sabotaging Fedora's principles, we're re-inforcing
the value of Fedora and what it stands for and introducing it to a group
of user who have never had any option to use it in the past.

Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board

On Fri, Jul 11, 2008 at 12:23:52AM +0300, Axel Thimm wrote:
> but
> what happens when Joe Random Packager discovers the mingw package and
> thinks this is an invitation to rebuild all of Fedora for Windows
> (where possible) and submit as a new package? Do we want this? If not
> how do we prevent this or communicate it properly to the packager
> base?

Joe Random would certainly have a lot of time on his hands to do this.

MinGW cross-compiles are *not* straightforward, and will require a
great deal of care and maintenance, dealing with upstream to fix newly
introduced bugs and so on. As with other Fedora packages, they only
go in if someone is willing to maintain them, and come out if no one
is willing to continue maintaining them.

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board

I would just like to direct people on the fedora-advisory-board list
to my previous reply here, which should address all of Jeff's
questions:

https://www.redhat.com/archives/fedora-packaging/2008-July/msg00043.html

except for this one:

On Thu, Jul 10, 2008 at 01:53:18PM -0800, Jeff Spaleta wrote:
> Is this really an appropriate use of our Project mirroring and
> repository resources? How much bigger would the repository end up
> being if all our existing libraries were repackaged as windows DLLs?

Leaving aside the fact that it's completely unrealistic to think
anyone could recompile every Fedora library, and no one is proposing
to do this anyway (see my answer above), I do have some figures on how
big the MinGW RPMs are on my (32 bit) machine compared to the ordinary
Fedora RPMs [0]:

4.1M mingw-libxml2-2.6.32-1.fc10.i386.rpm

847K libxml2-2.6.32-3.fc10.i386.rpm
1.4M libxml2-devel-2.6.32-3.fc10.i386.rpm

108K mingw-zlib-1.2.3-1.fc10.i386.rpm

75K zlib-1.2.3-18.fc9.i386.rpm
43K zlib-devel-1.2.3-18.fc9.i386.rpm

3.3M mingw-gnutls-2.4.1-2.fc10.i386.rpm

390K gnutls-2.4.1-2.fc10.i386.rpm
2.5M gnutls-devel-2.4.1-2.fc10.i386.rpm
128K gnutls-utils-2.4.1-2.fc10.i386.rpm [1]

If we carry out a plan of building from the same SRPM then there
shouldn't be any significant increase there. There are no debuginfo
packages for MinGW.

Rich.

[0] Note that there is no foo / foo-devel split in the mingw packages.

[1] Windows utilities (certtool.exe etc) are included in the
mingw-gnutls package at present.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 59 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board

On Sun, Jul 13, 2008 at 07:30:12PM +0300, Axel Thimm wrote:
> So, when Joe Random starts preparing to use Fedora as a platform for
> building gimp or some other interesting F/LOSS bits for a proprietary
> system that is harming Fedora *Linux* are we really open to this?

It's not at all clear that being able to build Gimp (as an example) is
harming Fedora.

There are at least three cases:

(1) User switches from Photoshop to Gimp (and other free apps) and
eventually, much later asks themselves 'why am I bothering to pay for
this Windows stuff when Linux runs all the same apps I'm now using?'
and they are then able to easily switch to Linux.

(2) User switches from Photoshop to Gimp, but continues using Windows
forever because they simply prefer the 'Start' menu and other Windows
desktop features.

(3) Because the fedora-packaging mailing list has successfully
prevented any free apps from being available for Windows, user is
forced to switch their entire system (all their apps, operating
system, document formats) all at once from proprietary to free.

Which is likely to happen? No idea. You could, I guess, devise a
study to see what typical users do.

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board

"Richard W.M. Jones" <rjones@redhat.com> writes:

> [...] (3) Because the fedora-packaging mailing list has
> successfully prevented any free apps from being available for
> Windows [...]

That is ridiculous. The most anyone might propose is that if libvirt
wants to mate with proprietary code on windows, that it get
distributed separately from fedora for that market.

- FChE

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board