supporting closed source operating systems?

On Mon, Jul 14, 2008 at 12:06 PM, Yaakov Nemoy <loupgaroublond@gmail.com> wrote:
> If you can show a demo of compiling certain open source windows apps
> so that they can work on Fedora via wine, then I can definitely argue
> that this is no longer secondary architecture.
>
> I have a couple of VJ programs some friends asked about getting into
> Fedora, all open source, but some run on windows. Being able to build
> them on Fedora easily will make it very easy for them to create a
> Fedora based VJ station.

I will fight you tooth and nail on this. It might even come down to a
Dance Dance Revolution Dance off. If we can distribute it under the
Fedora brand, we must have a version that runs natively before we
consider a windows cross-compiled binary that runs under wine. I
personally draw the line there. Native first, emulated second. If
native doesnt work, get it fixed, or its not going to be part of
Fedora.

-jef

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

On Mon, Jul 14, 2008 at 10:11 PM, Jeff Spaleta <jspaleta@gmail.com> wrote:
> On Mon, Jul 14, 2008 at 12:06 PM, Yaakov Nemoy <loupgaroublond@gmail.com> wrote:
>> If you can show a demo of compiling certain open source windows apps
>> so that they can work on Fedora via wine, then I can definitely argue
>> that this is no longer secondary architecture.
>>
>> I have a couple of VJ programs some friends asked about getting into
>> Fedora, all open source, but some run on windows. Being able to build
>> them on Fedora easily will make it very easy for them to create a
>> Fedora based VJ station.
>
> I will fight you tooth and nail on this. It might even come down to a
> Dance Dance Revolution Dance off. If we can distribute it under the
> Fedora brand, we must have a version that runs natively before we
> consider a windows cross-compiled binary that runs under wine. I
> personally draw the line there. Native first, emulated second. If
> native doesnt work, get it fixed, or its not going to be part of
> Fedora.

Frets on Fire.

Seriously, we might as well write the program over from scratch,
cannabalizing the algorithms from it as we go along. Doing that would
probably mean making a free-codec and nonfree-codec version too.
Currently, it's supported by searching in all the usual windows places
to see if codecs are installed.

Now that wine is 1.0, I think it really deserves the same pariah
status that Mono should get. It's an API controlled by a single
corporation that is not 100% documented, complex, and been
reimplemented from the inside out. Where do we draw the line between
Mono compiling EXEs and DLLs that work under .Net on Windows and a
cross compiler compiling EXEs and DLLs that work on windows without
.Net? If you really want to make this argument, why don't we draw the
line at Mono?.

(Before anyone brings it up, Gstreamer's latency is too high for some
of the things these guys are doing, which is a shame because it's just
modular enough to make things like this less messy.)

-Yaakov

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

Yaakov Nemoy wrote:

On Mon, Jul 14, 2008 at 10:11 PM, Jeff Spaleta <jspaleta@gmail.com> wrote:

On Mon, Jul 14, 2008 at 12:06 PM, Yaakov Nemoy <loupgaroublond@gmail.com> wrote:

If you can show a demo of compiling certain open source windows apps
so that they can work on Fedora via wine, then I can definitely argue
that this is no longer secondary architecture.

I have a couple of VJ programs some friends asked about getting into
Fedora, all open source, but some run on windows. Being able to build
them on Fedora easily will make it very easy for them to create a
Fedora based VJ station.

I will fight you tooth and nail on this. It might even come down to a
Dance Dance Revolution Dance off. If we can distribute it under the
Fedora brand, we must have a version that runs natively before we
consider a windows cross-compiled binary that runs under wine. I
personally draw the line there. Native first, emulated second. If
native doesnt work, get it fixed, or its not going to be part of
Fedora.


Frets on Fire.

Seriously, we might as well write the program over from scratch,
cannabalizing the algorithms from it as we go along. Doing that would
probably mean making a free-codec and nonfree-codec version too.
Currently, it's supported by searching in all the usual windows places
to see if codecs are installed.

Now that wine is 1.0, I think it really deserves the same pariah
status that Mono should get. It's an API controlled by a single
corporation that is not 100% documented, complex, and been
reimplemented from the inside out. Where do we draw the line between
Mono compiling EXEs and DLLs that work under .Net on Windows and a
cross compiler compiling EXEs and DLLs that work on windows without
.Net? If you really want to make this argument, why don't we draw the
line at Mono?.

If I understand your question correctly, the big difference that I see
is that .Net EXE's and DLLs (assemblies) run on any platform. AFAIK,
windows .DLLs and .EXEs will only run on wine on x86.


-Toshio

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

On Mon, Jul 14, 2008 at 12:48:38PM -0700, Karsten 'quaid' Wade wrote:
>
> On Sun, 2008-07-13 at 19:30 +0300, Axel Thimm wrote:
>
> > I think this is a rephrasing of Jeff's brigth line that he seeks to
> > draw and wants to know what it will include and what not.
>
> Thanks for this post, for me it did a good job of separating the
> technical from $other considerations.
>
> The Fedora brand is a Linux brand. It makes sense to have some
> Microsoft Windows stuff where it supports that story, such as tools to
> assist migration ... to Linux. The libvirt pieces seem, to me, to be a
> good enough fit and belong on this side of the bright line.
>
> But we need to make it clear that we are not going to morph Fedora into
> being some super-meta-FLOSS thing. So, to me, the productivity apps
> belong on the other side of the bright line. If we want to be involved
> in helping people switch from Microsoft Windows by supporting
> productivity FLOSS stacks that runs on that OS, it should be under a
> brand other than Fedora. Such as "Mozilla". ;-D


I'm OK with Fedora's scope being expanded beyond just "Linux". The
Apache Foundation is an example where this has worked quite well.

As for mingw, I agree, the resultant bits need to land in their own
directory structure outside the main tree, just like we do with
seconaries.





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

On Mon, Jul 14, 2008 at 12:30 PM, Yaakov Nemoy <loupgaroublond@gmail.com> wrote:
> Now that wine is 1.0, I think it really deserves the same pariah
> status that Mono should get. It's an API controlled by a single
> corporation that is not 100% documented, complex, and been
> reimplemented from the inside out. Where do we draw the line between
> Mono compiling EXEs and DLLs that work under .Net on Windows and a
> cross compiler compiling EXEs and DLLs that work on windows without
> .Net? If you really want to make this argument, why don't we draw the
> line at Mono?.

Did you miss what happened in the runup to F9? We actually pulled
pre-compiled stuff out of some mono packages...and it really pissed a
few people off...but we did it.

-jef

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

On Mon, Jul 14, 2008 at 10:35 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
> Yaakov Nemoy wrote:
>>
>> On Mon, Jul 14, 2008 at 10:11 PM, Jeff Spaleta <jspaleta@gmail.com> wrote:
>>>
>>> On Mon, Jul 14, 2008 at 12:06 PM, Yaakov Nemoy <loupgaroublond@gmail.com>
>>> wrote:
>>>>
>>>> If you can show a demo of compiling certain open source windows apps
>>>> so that they can work on Fedora via wine, then I can definitely argue
>>>> that this is no longer secondary architecture.
>>>>
>>>> I have a couple of VJ programs some friends asked about getting into
>>>> Fedora, all open source, but some run on windows. Being able to build
>>>> them on Fedora easily will make it very easy for them to create a
>>>> Fedora based VJ station.
>>>
>>> I will fight you tooth and nail on this. It might even come down to a
>>> Dance Dance Revolution Dance off. If we can distribute it under the
>>> Fedora brand, we must have a version that runs natively before we
>>> consider a windows cross-compiled binary that runs under wine. I
>>> personally draw the line there. Native first, emulated second. If
>>> native doesnt work, get it fixed, or its not going to be part of
>>> Fedora.
>>
>> Frets on Fire.
>>
>> Seriously, we might as well write the program over from scratch,
>> cannabalizing the algorithms from it as we go along. Doing that would
>> probably mean making a free-codec and nonfree-codec version too.
>> Currently, it's supported by searching in all the usual windows places
>> to see if codecs are installed.
>>
>> Now that wine is 1.0, I think it really deserves the same pariah
>> status that Mono should get. It's an API controlled by a single
>> corporation that is not 100% documented, complex, and been
>> reimplemented from the inside out. Where do we draw the line between
>> Mono compiling EXEs and DLLs that work under .Net on Windows and a
>> cross compiler compiling EXEs and DLLs that work on windows without
>> .Net? If you really want to make this argument, why don't we draw the
>> line at Mono?.
>>
> If I understand your question correctly, the big difference that I see is
> that .Net EXE's and DLLs (assemblies) run on any platform. AFAIK, windows
> .DLLs and .EXEs will only run on wine on x86.

Correction, .Net EXEs and DLLs will run on any platform only on top of
.Net or Mono.

But otherwise yes.

True, we are limited to a single architecture, but then wine doesn't
run on anything else, AFAIK, anyways.

-Yaakov

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

On Mon, Jul 14, 2008 at 12:38:00PM -0800, Jeff Spaleta wrote:
> On Mon, Jul 14, 2008 at 12:30 PM, Yaakov Nemoy <loupgaroublond@gmail.com> wrote:
> > Now that wine is 1.0, I think it really deserves the same pariah
> > status that Mono should get. It's an API controlled by a single
> > corporation that is not 100% documented, complex, and been
> > reimplemented from the inside out. Where do we draw the line between
> > Mono compiling EXEs and DLLs that work under .Net on Windows and a
> > cross compiler compiling EXEs and DLLs that work on windows without
> > .Net? If you really want to make this argument, why don't we draw the
> > line at Mono?.
>
> Did you miss what happened in the runup to F9? We actually pulled
> pre-compiled stuff out of some mono packages...and it really pissed a
> few people off...but we did it.

But that was stuff where there either wasn't source or there was no
clear chain from the source to the binary.

Please be clear that the MinGW cross-compiler is 100% free software
built from source. If it turns out that any parts aren't, then they
will be removed.

Rich.

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

On Mon, Jul 14, 2008 at 12:44 PM, Yaakov Nemoy <loupgaroublond@gmail.com> wrote:
> Correction, .Net EXEs and DLLs will run on any platform only on top of
> .Net or Mono.
>
> But otherwise yes.
>
> True, we are limited to a single architecture, but then wine doesn't
> run on anything else, AFAIK, anyways.

And does mono run on the other arches?

-jef

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

On Mon, Jul 14, 2008 at 12:50 PM, Richard W.M. Jones <rjones@redhat.com> wrote:
> But that was stuff where there either wasn't source or there was no
> clear chain from the source to the binary.
>
> Please be clear that the MinGW cross-compiler is 100% free software
> built from source. If it turns out that any parts aren't, then they
> will be removed.


Sorry, I didn't mean to confuse the issue. I think Toshio is saying
better what I am trying to say.
There is a difference between cross-compiling code that is inherently
arch-adependent in how its compiled and writing code in a language
that is meant to be managed by a arch-independent virtual machine
layer.

I have a very difficult time seeing wine as similar to any virtual
machine based language such as mono unless wine can be built and run
on multiple arches. So as such I would have a very hard time seeing
any code be branded as Fedora that had to be run under wine to be
useful at all. I'm okay with optionally building a varient that runs
under wine as part of the Fedora project if and only if there is a
native version of that code already available for Fedora Linux. if
wine as a project gets to the point where it can usefully run on ppc,
then i would feel a lot better letting application code inside Fedora
need it. But I'd still want to have it as a side-repo.

-jef

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

On Mon, Jul 14, 2008 at 10:15:58AM -0800, Jeff Spaleta wrote:
> So for the sake of argument, can we teach rpm to understand an arch
> called "mingw-ix86"
> such that it inherits the ix86 packages? We then construct a build
> environment definition in mock which includes the mingw-ix86 and ix86
> branches that will run on ix86 hardware and compile the mingw dll
> subpackages which are ifarch conditioned?

Jeff, you're not offering anything constructive here. There's talk of
mysterious extra repositories, and invasive changes to RPM & mock, but
I'm no closer to understanding what purpose this achieves, or indeed
_how_ to achieve it.

I've presented a plan which involves adding 4 base packages to Fedora
(already built[*]) and some number of additional packages for
libraries (where 'some number' is approximately 7, also already
built[*]). And I've found people who are willing to maintain these
packages in the long term.

Now, it's not perfect -- there are some things we need to resolve such
as the precise naming convention and how to stop the strip command
from damaging DLLs -- but it is nevertheless a plan that one can see
how to finish. It doesn't violate any existing Fedora policy that I
can see, and I've even provided my arguments that it increases the
overall value of Fedora.

So unless you wish to provide a detailed plan -- not hand-wavey stuff
about Fedora providing 'extra infrastructure' or 'teaching RPM to
understand' things -- I really don't think I can sensibly continue
this discussion.

Rich.
[*] http://hg.et.redhat.com/misc/fedora-mingw--devel/

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