Slashdot Mirror
Miguel de Icaza Explains How To "Get" Mono
LeninZhiv writes "It's perhaps the most controversial project in the open source world, but this mostly stems from misunderstanding: Mono, the open source development platform based upon Microsoft's .NET framework. Immediate reactions from many dubious Linux developers have ranged from confusion over its connection with .NET to wondering what the benefits of developing under it are. Throughout the course of its four years of intense development, sponsored by Novell, Mono founder Miguel de Icaza has had to frequently clarify the .NET issue and sell the community on it. In this new interview, Howard Wen asks Miguel to explain himself one more time."
About a year ago, I wrote a C# webserver that did basic authentication, cgi, and directory browsing. It had a GUI but I partitioned it so that the webserver wasn't depenent on the GUI interface. I downloaded mono, created a console front end, compiled and ran it. Flawless. I didn't have to change one single line of code in the webserver class. Thats all I need to know. (BTW, this was on a windows box.)
I'm sure I know less than most, but here are my general experiences with it.
.Net C# - The only major difference is mono's lack of complete support for windows.forms. This is windows primary API for building C# gui apps under windows. Mono is working on an implementation of windows.forms, but I personally prefer gtk# which is portable (at least to windows afaik). Also, they have and ASP.net implementation which is suppose to have great compatability but I can not speak from experience here
.net platform. We're talking about ECMA specifications here, so they really can strive for compatability, it's less of (though not completely) a moving target than the WINE people have to deal with. They use to have a page listing package status, I can't seem to find the link anymore.
Mono Vs C++ - this is not a normal comparison due to one being a byte-code language and the other being compiled. That being said, I'm continuously impressed with mono's speed (especially compared to Java). It's current downside is an increase in memory utilization (compared to c, c++).
Mono Vs.
Mono compatability claims - here's the shocker, it really is very compatable with microsoft's C#
Disclaimer: I've been working on various small personal projects using mono for the last 6 months and have been using various apps centerend around mono for about the same.
Fear trumps hope and ignorance trumps both
No forms at all, gtk or windows. As I said I whipped up a console (cmd line) front end just for the mono test. I should also mention that this webserver was heavily multithreaded - which is another important yardstick for the maturity and stability of their code.
My only gripe was the lack of a decent debugger (monodbg hardly worked then), but it was quite a while ago, and I hope someone would post their experience with a newer version of the debugger.
de Icaza: We are making Linux a fertile ground for third-party developers: we are allowing developers with Windows/.NET expertise to use and distribute software for Linux, easing the adoption of Linux.
Programmer productivity is higher in garbage-collected (MS calles them "managed") environments such as Java and .Net/C#.
In addition, it's much harder to make programming blunders such as overstepping the bounds of an array or string, which can in turn lead to security vulnerabilities.
Those two reasons alone are enough to favour a Java/C#-type approach in situations where absolutely bleeding-edge performance isn't a requirement (i.e. almost all of them).
Lol. I love these kinds of conspiracy theories. They completely ignore the facts.
.NET, whether it wants to or not. Longhorn's userland is now largely .NET based (WinFX) making .NET apps first class citizens of the OS. Core Longhorn technlogies such as Avalon and Indigo are written in .NET.
.NET anytime soon.
Microsoft is now wedded to
MS isn't dumping
If you need web hosting, you could do worse than here
Mono really is a godsend in this respect. I have a lot of C# experience, as do the programmers with whom I work - it is a very productive language for medium to large middleware projects. Some of our larger projects require that we lease both the hardware and software stack to our clients, most of whom are non-profits who don't have huge amounts of cash on hand. Windows licensing for a small server could seriously eat into any profit margin when dealing with 50 remote offices (with about 20 users each), without a dedicated net connection (so a web-based app won't help). Mono lets us install a small Debian-based server at each small location, reducing licensing costs to zero - but not requiring that we abandon our existing codebase/installed base by switching to Java. All told, savings can easily run into the tens-of-thousands per larger client, per year.
Lead developer, http://wisptools.net
A C# front-end to Gcc might have some value for compiling programs so unwisely written in that language, but a bytecode interpreter seems just silly.
.NET and Mono. While it's true that the first version of mono was interpreted, no version of MS's .NET ever has been and the most recent version of Mono does not interpret either. It uses JIT compilers to compile code at runtime as it's accessed.
You seem to have a fundamental misunderstanding of
This is actually a nice situation in some ways, since the JIT compiler knows more about the machine's runtime situation than a static compiler can.
For example, it can compile to 64 bit on 64 bit machines with zero changes in the source bytecode. It can also adapt to runtime situations (such as low memory conditions) more easily.
Of course this has the penalty of a slightly less responsive application the first time the code executes, but that's a small price to pay.
If you need web hosting, you could do worse than here
Real world .NET applications are peppered with PInvokes, COM interop, MSSQL / IIS extensions and various other crap which makes the run badly or not at all on Mono. Even the best will in the world won't change this.
WINE might help a bit, but its too bad if you're on a non-x86 platform.
Even Microsoft don't give a damn about portable .NET. Witness their new Enterprise Library which they're pushing on developers. It contains several dozen Win32 calls right there in this common library. Any enterprise app that relies on it will be infected as a result.
Have you tried using Monodoc? We have documented most of the Gtk namespace, and most of the underlying libraries (Gdk, GObject).
There are a couple of missing pieces like the Accessibility Toolkit (Atk) or Pango, but we are working towards finishing it.
Miguel.
Seems fairly simple to intercept those calls and map them to managed code.
We might evaluate interception on a case-by-case basis.
Miguel.
You're absolutely correct. In the end, .NET apps written on windows will not work on Linux. But .NET apps written on Linux will surely work on windows. How this gives people incentive to move towards linux(as opposed to away from it) I will never understand. I want to see MS write MS Office in .NET so that it runs on linux. You think they'll do that? Yeah Right!
mp3's are only for those with bad memories
C++ is an ISO standard. And you do realize that C#, CLI, and C++/CLI are ECMA standards. And soon to be ISO standards.
EDG is in the process of writing a front end for C++/CLI. The EDG parser is used by Intel, Borland, Comeau, and others. Although C#, CLI, C++/CLI were primarily created by MS, calling them MS technologies is inaccurate.
(Note: .NET/CLR is MS's implementation of CLI. Mono is another implementation of the CLI. Think of it as analagous to JRE in the Java world. Which by the way is not standardized.)
The flattened tree is equivalent to the stack-based layout of Java opcodes (since the JVM knows the arity of each method call) so that's just "revisionist naming" practiced in C# and its libraries to not look like a pure rip of Java.
.NET is faster loading but slower at runtime. Check the language shootout for instance.
Assemblies aggressively optimized means they are internally linked ahead of time like a normal DLL, so internal inlining uses static rules. Cross-assembly inlining is also more difficult. Basically
Yes, the C# of the MS world is MS only which sucks. However, Mono has taken C# to Linux, Windows, Mac, Solaris, FreeBSD and more coming in the next version due this year. The architectures are x86, PowerPC, S390 and SPARC-based systems and the next version coming out is going to have more. There are two 64 bits ports: SPARC v9 with Solaris and the AMD64 port. When Mono 1.2 comes out this year, there won't be any reason for me to use Java really. I personally like C# better and the big thing I _hate_ about Java has always been Java exceptions. Exceptions in C# are much nicer and you are not forced to handle them.
I have also noticed a huge advantage to Mono/.Net when it comes to memory footprint. When I run Java apps the memory usage gets high and the virtual memory usage gets really high. I love the Azureus program, however it always causes my MS Windows box to start hitting the swap file and MS Windows sucks at swap file usage compared to Linux so I am always forced to use Azureus under Linux. When I run C# apps, be it with Mono under Linux or MS .Net under MS Windows, the memory foot print is much smaller and swap is almost never used.
The last two GUI apps I have written have been in C# and they have at least the same startup time if not faster than a similar Java program and the memory foot print doesn't even come close to being as high as a similar Java program would be.
I don't want to sound as if I hate Java, because as I have said, I use both Java and C# and like them both. I have used some really nice Java apps that do things to keep the memory foot print down like IntelliJ IDEA. However, even with great programs like IntelliJ IDEA, the virtual memory still gets way up there due to the JVM.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison