Fedora Core 5 includes Mono

cyberjessy writes "Surprise! The Fedora Core 5 Release will include Mono in the distribution, in spite of Red Hat's opposition. In addition to the Mono runtime, it will also include Mono applications like Beagle and F-Spot. Is the Linux community finally ready to accept Mono? Mono is becoming increasing important due to Windows Vista, which has WinFX (the next .Net Framework) as its core API. This will mean that in future, all native Windows applications will easily run on Linux, with Mono. Will Mono achieve what WINE could not?"

Comments

Summary

[Locarius]

Yes, off topic, but it's nice to see a well written and concise topic summary around here once in a while.

Re:Summary

[timeOday]

Yes, off topic, but it's nice to see a well written and concise topic summary around here once in a while.

But how accurate is it?

This will mean that in future, all native Windows applications will easily run on Linux, with Mono.

I think that's far premature. Without even knowing yet what the catch is, I know there will be some. I just don't think Microsoft will let Windows apps seamlessly run under Linux, one way or another.

Will all applications be rewritten?

[mwvdlee]

This will mean that in future, all native Windows applications will easily run on Linux, with Mono.
Will all major Windows applications be rewritten to .NET?
I just can't imagine Adobe, Autodesk, Corel, etc. translating their code to .NET in the near future.

Re:Will all applications be rewritten?

[anarxia]

All applications.. no chance. Some of them might.

The problem is that MS (intentionally or not) left a lot of functionality out of the .NET standard libraries _AND_ made it almost trivial to call native code from within .NET.
The end result is that most applications end up using Win32 DLLs directly so wine is still necessary.

Easily run

[DrXym]

Someone has obviously never tried running a .NET application under Mono. More often than not, it calls Win32 via PInvoke, uses an ActiveX control / COM interop, or does something else which renders it unusable on other platforms. Some apps might work, particularly command line tools, but it is by no means guaranteed or even probable.

And this is probably what MS had in mind all along. And I don't see it changing either. Microsoft make it easy to slap together apps with their stack and tools. Mono makes it hard to do the same with theirs. That means Mono will constantly be playing catch-up with Microsoft, reaching for but never getting close to 100% compatibility.

Re:Easily run

[jonwil]

And that is where WINE comes in.
The people behind Mono and the WINE people should work together so that Mono will use WINE for any PInvoke (either standard win32 APIs or something custom that comes with the .NET app) and hence the WINE implementation of COM & OLE for any ActiveX controls or COM interop.
If the item being used (e.g. the API call being PInvoked) is a standard windows item, then the .NET app will run on any system that has a usable port of WINE and Mono on it. If it is a non standard item for which source code is available, again, it could be ported and run via WINE or WineLib somehow. (or if its closed source but documented, it could be cloned somehow)
Even if the item being used is a closed source propriatory item for which there is no possible clone or use on non x86 platforms, Mono with WINE could still be used to run the whole thing on x86 linux

The question is whether the WINE people are prepared to do what is necessary to allow Mono to use WINE for the bits it needs (including PInvoke, COM and the talked-about implementation of System.Windows.Forms which has to go on top of something looking like user32 so that all the support is there)

talking about exaggeration

[Anonymous Coward]

This will mean that in future, all native Windows applications will easily run on Linux, with Mono.

How about

This may mean that in the future, some native Windows applications will run on Linux, with Mono.

Re:From the article you linked to:

[H4x0r Jim Duggan]

"The problematic parts are not the core technologies submitted to the ECMA or the Unix/Gnome-specific parts."

The problem (software patents) can affect any part. If MS have claimed they don't have patents on "core parts", you cannot trust them. If the Mono devs have claimed that MS don't have patents on "core parts", they are saying something they can't possibly know.

As well as including "according to the public statements of MS and the Mono devs", you should also read that sentence with the qualification: "for now anyway".

if you say something is not well thought out, also saying why

The reasons why their plan is not well though out are given in that article, in the last paragraph of that section, just after the list of the 3 strategies.

Re:Unless you use python

[amightywind]

Sadly the portage system is written in Python, which is my point. Gentoo depends on Python. A simple clean design would have Gentoo consist of a kernel, binutils, compiler stack, init scripts, and portage written in C and depending on the C library only. Instead the portage system pulls in Python for no particular reason. By all means use Python as an application language. Foundational system services should not be written in it.

Eh... no

[adolfojp]

Mono is becoming increasing important due to Windows Vista, which has WinFX

Mono is becoming such an important platform because it is such a great platform to develop for. If you like statically typed languages C# has no equal. If you like virtual machines, mono is the only one that performs well and is open source. If you like python, you will be able to compile python to bytecode for added performance.

Winforms on mono is not complete yet and it will be a long time before a compatibility WinFX layer is ready. Mono is great for what it is, not for what it could be.

Cheers,
Adolfo

Re:Will Mono achieve what WINE could not?

[MobyDisk]

Actually it is quite easy because of one crucial difference. It's not the implementation that matters, it is the interface. And .NET provides a good interface.

Even if Microsoft implemented the .NET APIs as wrappers around Windows APIs, the fact is that the APIs are clean and they are well documented. They follow the rules of encapsulation well. That makes it possible to re-implement them in a straightforward fashion. The problem with WINE is that the Windows API does not follow good design and rules of encapsulation, so the implementation is often exposed. WINE is not an implementation of an API as much as it is a reverse-engineering of one. But that problem goes away with .NET.

Mono today works stunningly well today. The only issue is Windows Forms, because it isn't as well encapsulated as the rest of the API.

Re:Unless you use python

[gowen]

Instead the portage system pulls in Python for no particular reason.

Portage is a complicated set of programs. Complicated programs are easier to write in python, because of the languages features, and complicated secure programs even more so. They're written in python because the developers consider it (one of) the best solutions to the problem.

If you know better, and think it should have been written in C, I', sure the present developers would be very interested in seeing your port.

Misleading

[JanneM]

The whole "run Win-apps under Linux" really is a little misleading. That's not really the point of Mono for most users.

The point, rather, is that it is a very, very nice development environment and a very pleasant language, well-suited for application development, as f-spot and others are a testament to. As a bonus, the apps written under mono will be easy to deploy under Windows as well, should it be needed.

And when you use Mono to write desktop apps under Linux you aren't using anything Windows-related that isn't covered by the ECMA standard. You have no larger exposure to patent issues than you have under any other environment (possibly barring plain C and POSIX libs. Possibly).

Re:Mono and python

[m50d]

How is it a boil? It's a great language, very useful, makes the base system smaller overall (because so many things can be made much smaller in python) and is nice to be able to depend on it being available. Slating distributions for depending on python is like criticising them for depending on libc.

Re:From the article you linked to:

[JanneM]

This more general patent problem is not limited to Microsoft and not limited to Mono. Java is no more protected, and neither is any other reasonably modern implementation of anything non-trivial.

The only way to be _sure_ you aren't violating a patent is to turn off the computer and leave it altogether.

Re:Heh.

[Hosiah]

linux to be able to run .Net apps,

Hey...wait a minute. Do you mean Net apps like in "Visual Basic Script-Kiddies EZ Virus Kit"? Maybe this isn't something to dance in the streets about after all...

Re:The patent problems have not been addressed

[afabbro]

What is this .Net related lock-in that you are speaking of?

Hey, I'd like to develop a .Net program and run it on Solaris/AIX/Linux/etc. Oh, I can't? Gee, seems like I'm locked in to the Windows platform with .Net.

Compare and contrast with Java. Or open source code. Or a lot of closed-source code, for that matter. Just like Visual Basic, if you write in .Net, you're only writing for Windows.

Completely missing the point

[GauteL]

The inclusion of Mono in Fedora is the first step towards healing a rather serious potential rift in the GNOME world. Up until now, you could not develop a Mono-app with GTK# and expect it to work on all major updated distributions without added software.

Don't worry about Windows compatibility, Mono is cool enough on it's own, especially because Novell/Ximian has done such a good job with the Mono-wrappers for GNOME-technologies. Hopefully this will see more GNOME-development.

Re:Mono and python

[m50d]

Distributions depend on libc because they have to.

No they don't. They could write everything in assembler and just use the kernel calls. They depend on libc because it's easier to write programs in C and use the library - the exact same reason they depend on python.