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-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Jeff Spaleta wrote:

> On Wed, Jul 9, 2008 at 3:17 PM, Rex Dieter <rdieter@math.unl.edu> wrote:
>> Imo, motives don't matter here. If it's license-wise (and otherwise
>> policy-wise) ok with fedora, then end of story.
>
> Well, some could argue that policy is another word for motive :->

touche mr. word-twister.

Otherwise, kind of a pet-peave of mine, whenever see I package review
submission, and followups of the form "why would we/fedora want that?".
Because someone is interested in it (and bothered to submit it), that's
why.

There's no significant "useful-ness bar" to reach, other than a package
probably needs to useful or interesting enough to catch someone's attention
to complete a package review.

-- Rex


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

On Thu, Jul 10, 2008 at 5:44 AM, Rex Dieter <rdieter@math.unl.edu> wrote:
> There's no significant "useful-ness bar" to reach, other than a package
> probably needs to useful or interesting enough to catch someone's attention
> to complete a package review.

I believe Axel's question has a more subtle edge and would like to
think he chose the word "promote" deliberately in his opening
sentence.

We "allow" pretty much anything appropriately licensed and legal to
distribute into the distro as a stand alone library or application. I
don't think that is the question of merit. The meater issue is this,
is it worth changing how we do things, how we package other
components, to make the minwg cross-compiler tool chain 'fit' into our
project development environment so that Fedora can build and ship
libraries/utilities/applications with this toolchain that are meant to
be run on Windows. There's already technical discussion about how to
modify some existing development packages to make it possible for this
toolchain to exist.

Allowing the toolchain in and of itself I don't think is the issue.
But there are clearly intentions...motives....floating around to use
that toolchain on a Fedora system to build and distribute
libraries/utilities/applications..possibly as "official" Fedora
bits..though the last hasn't been communicated yet. The plan could be
to do all of the building strictly under the 'Red Hat' brand... with
no direct benefit for Fedora. But plans change. I'm using my crystal
ball a little bit here, and I believe that Axel is too. 'We' need to
know under what situations 'we' are okay with this possible future.
Is it okay if we structure our internal build and development
processes to make it possible to build and distribute binaries in our
infrastructure with this cross-compiler toolchain with the intention
to use the resulting binaries on Windows.

I know what I'm personally okay with "promoting" in that
regard...migration tools. If we can build windows applications as
part of this project that helps people get a Fedora or other linux
install up and running, whether it be virtualized or not..then I'd
probably support it as an official piece of Fedora tech.


-jef

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

On Thu, Jul 10, 2008 at 12:57:57AM +0300, Axel Thimm wrote:
> What is Fedora's motivation is promoting using Open Source on a closed
> source operating system?

Thanks all for enlightening this. Jeff Spaleta more or less outlined
the background thoughts I was having about it - envisioning building
all of our fruits for consumption on the enemy territory was a bit
scary.

Daniel Berrange and Richard Jones explained the libvirt background
which more than justifies this move, thanks for explaining.

But what I'd like to still see addressed is whether there will be a
policy of what other tools/apps are acceptable for Fedora. mingw,
libvirt etc. do have their justification as a means to an end, 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?
--
Axel.Thimm at ATrpms.net

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

On Thu, Jul 10, 2008 at 12:57:57AM +0300, Axel Thimm wrote:
> What is Fedora's motivation is promoting using Open Source on a closed
> source operating system?

Thanks all for enlightening this. Jeff Spaleta more or less outlined
the background thoughts I was having about it - envisioning building
all of our fruits for consumption on the enemy territory was a bit
scary.

Daniel Berrange and Richard Jones explained the libvirt background
which more than justifies this move, thanks for explaining.

But what I'd like to still see addressed is whether there will be a
policy of what other tools/apps are acceptable for Fedora. mingw,
libvirt etc. do have their justification as a means to an end, 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?
--
Axel.Thimm at ATrpms.net

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Thu, Jul 10, 2008 at 1:23 PM, Axel Thimm <Axel.Thimm@atrpms.net> wrote:
> But what I'd like to still see addressed is whether there will be a
> policy of what other tools/apps are acceptable for Fedora. mingw,
> libvirt etc. do have their justification as a means to an end, 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?

So basically the question is.. how much of our existing set of
software is appropriate to rebuild with the mingw chain and make
available as binary packages in the project itself in the form of
packages? If I'm following the technical discussion correctly.. then
we are talking about packaging some set library binaries meant to be
used with mingw. It's not just about making mingw available as a
tool..but its also about building some library binaries with mingw and
packaging them as part of Fedora as part of a mingw development
environment. Or am I wrong about that?

For the sake of this discussion lets just limit ourselves to libraries
and development packages..that's still a big space.

How many libraries should we rebuild and package as part of a
functional mingw development environment as windows DLL? Is it
appropriate to rebuild all of our libraries such that they can be used
with mingw? Saving people the necessary effort to rebuild the
libraries themselves?

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?
Is that potential resource burn worth the trade off of making it
turnkey for people to mingw to build windows executables on Fedora?

The base package definitions at
http://fedoraproject.org/wiki/PackagingDrafts/MinGW may make obvious
sense as a way to get the mingw tool into the distribution. But do the
concepts of packaging Windows DLL and Windows EXEs make sense for us?
Do we want to be distributing a full range of Windows DLLs and Windows
EXEs in our repository? Or do we want to distribute the absolute
minimum set of base packages to get mingw into the hands of users and
let them rebuild the DLLs they need from source?

I'm not sure I'm okay with rebuilding our entire collection of
libraries as Windows DLLs and packaging them as part of our
distribution, taking up project repository and mirror space.

-jef

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Thu, Jul 10, 2008 at 1:23 PM, Axel Thimm <Axel.Thimm@atrpms.net> wrote:
> But what I'd like to still see addressed is whether there will be a
> policy of what other tools/apps are acceptable for Fedora. mingw,
> libvirt etc. do have their justification as a means to an end, 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?

So basically the question is.. how much of our existing set of
software is appropriate to rebuild with the mingw chain and make
available as binary packages in the project itself in the form of
packages? If I'm following the technical discussion correctly.. then
we are talking about packaging some set library binaries meant to be
used with mingw. It's not just about making mingw available as a
tool..but its also about building some library binaries with mingw and
packaging them as part of Fedora as part of a mingw development
environment. Or am I wrong about that?

For the sake of this discussion lets just limit ourselves to libraries
and development packages..that's still a big space.

How many libraries should we rebuild and package as part of a
functional mingw development environment as windows DLL? Is it
appropriate to rebuild all of our libraries such that they can be used
with mingw? Saving people the necessary effort to rebuild the
libraries themselves?

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?
Is that potential resource burn worth the trade off of making it
turnkey for people to mingw to build windows executables on Fedora?

The base package definitions at
http://fedoraproject.org/wiki/PackagingDrafts/MinGW may make obvious
sense as a way to get the mingw tool into the distribution. But do the
concepts of packaging Windows DLL and Windows EXEs make sense for us?
Do we want to be distributing a full range of Windows DLLs and Windows
EXEs in our repository? Or do we want to distribute the absolute
minimum set of base packages to get mingw into the hands of users and
let them rebuild the DLLs they need from source?

I'm not sure I'm okay with rebuilding our entire collection of
libraries as Windows DLLs and packaging them as part of our
distribution, taking up project repository and mirror space.

-jef

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

On Thu, Jul 10, 2008 at 2:26 AM, Daniel P. Berrange <berrange@redhat.com> wrote:
> I can see further use cases where providing a MinGW toolchain will
> benefit Fedora and F/LOSS.

The question is.. what is the appropriate size of the "toolchain" that
we provide as part of our distribution. If we stop at just getting
MinGW into the distro as a useful tool...that's one thing.

But if we are then talking about allowing the use of MinGW or any
other cross compiler in our build process to generate a full range of
new packages and subpackages which contain windows DLLs variants of
general purpose libraries contained in separate packages that can be
installed on Fedora systems pulled from the Fedora repositories...
that is something else entirely. I'm not sure this is something we
want to allow in our build system nor in our packaging.

If we have a specific need to build windows executables, like
migration aids or virtualization clients, then perhaps all of that
should be done outside of our traditional build and packaging system,
so that we are not pressured to rebuild and provide any and all
libraries as Windows DLLs.

Let me sum up where I'm leaning as to a policy statement:
* Building MinGW from sources as part of Fedora's repository offerings
seems acceptable to me. I have no problem seeing cross compiler tools
packaged as linux executables.

* Using MinGW to rebuild anything else, so that we can make Windows
DLLs available in our base repository in binary packages..seems
inappropriate and sets a bad precedent. How do we draw the line as to
what library source (which is distinct from the MinGW sources) we
allow or do not not rebuild and ship as DLLs? Paint me a bright line,
because without a bright line the alternative is to allow all
libraries to be rebuilt and packages as part of the repository in this
way...and I just don't see how that is appropriate. I don't want to
get suckered into a case by case basis where we weight the intended
reason for making a certain library available as a DLL. If we have to
weigh intent, then it should be done outside the repository. There's
nothing stopping us from creating whatever sort of DLLs we need for
Fedora Project window applications as part of our infrastructure
project for specific application needs..outside of the build system
meant to feed the general use repository.

*Having a 3rd party provide MinGW built library packages, and doing
the work necessary to make sure the depresolving actually works with
DLLs and EXEs rpm payloads seems very wise to me.

-jef

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Thu, Jul 10, 2008 at 01:53:18PM -0800, Jeff Spaleta wrote:
> I'm not sure I'm okay with rebuilding our entire collection of
> libraries as Windows DLLs and packaging them as part of our
> distribution, taking up project repository and mirror space.

why is mingw being treated (or proposed as being treated) differently
than a Secondary Architecture? We already have a lot of
infrastructure and policy in place for that; so it's not a different
architecture, but a different underlying OS - same idea to me...

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

On Thu, Jul 10, 2008 at 2:53 PM, Matt Domsch <matt@domsch.com> wrote:
> why is mingw being treated (or proposed as being treated) differently
> than a Secondary Architecture? We already have a lot of
> infrastructure and policy in place for that; so it's not a different
> architecture, but a different underlying OS - same idea to me...

Except its explictly a cross compiler. MinGW itself needs to be part
of a traditional "arch" of Fedora...because it is a linux executable
itself.

Now everything built witn MinGW or any other cross-compiler is no
longer a native executable or library...those are the things I worry
about. Can we put all of those things into a separate repo patterned
on secondary arch repos..even though that repo is not self-hosting?

Or to put it another way. Can we craft a general policy that fits how
we treat any cross-compiled payload moving forward? Whatever we
decide for MinGW.. needs to work equally well when I put NBC forward
as a cross-compiler for the Lego Mindstorm NXT processor. I will very
much desire to build libraries and binaries packaged in such a way
that it makes it easier for people to do Mindstorm NXT development
with the nbc compiler...even though noone will be able to run those
programs directly inside Fedora.

Can we frame MinGW compiled payloads as well as nbc compiled payloads
a distinct repositories, using policy and infrastructure setup to
support the concept of secondary arches?

-jef"I'm not kidding about nbc..."spaleta

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