1. The Mono project has certainly come a long way since the last time we talked, please tell us what were the major milestones you hit the last 8 months and what new features are the priority for the near future?
Miguel de Icaza: Most importantly the Mono community has grown tremendously: today 150 developers have CVS commit access to the Mono source code repository, and a lot of the community’s effort has been focused in making Mono more reliable, more feature complete, and most importantly we have
been doing work to make Mono a good development toolkit on Linux/Unix.
Mono would not be possible without the day-to-day work of hundreds of developers that make it happen. I suggest for those interested in a particular area in Mono, to check the ChangeLogs and the mailing list to identify the developer that has created this technology. Since Mono is a large community effort, I could not list the responsible developers on each section in the following answers as I would have liked to, because it would have taken me another week to reply.
There are of course major developments that have occurred in the past few months which are worth mentioning:
* Mono can now run ASP.NET web applications, we have demonstrated IBuySpy running with Mono, and we are polishing it every day to make it better and support more applications.
* The ADO.NET universe in Mono has matured quite a bit: not only we have the standard classes as found on the Microsoft .NET Framework, but we have added a number of providers ourselves, so we have a pretty good coverage for the databases available on Unix: Postgress, MySQL, SqlLite, Sybase, SQL server, Oracle, DB2, Odbc and more.
* Robustness and completeness: this is just a side effect of Mono being used on a day-to-day basis by developers.
* IKVM.NET support: IKVM is a Java Virtual Machine that runs on top of .NET. It essentially translates java classes into Common Intermediate Language (CIL) code at runtime, and uses the .NET/Mono JIT compiler to execute the code.
What this means is that it is possible to run Java applications on Mono. The IKVM.NET for example is able to run the IBM Eclipse IDE editor with the CIL runtime.
* A Debugger Framework: we started our debugger effort about eight months ago.
We have a set of classes to produce and consume debugging information. Today our compiler for example generates debugging information (which is conveniently stored as a resource withing the executable) and our runtime engine can use this information to produce stack traces that contain line information.
The debugger proper is written in C# with a little support library written in C for the low-level access routines, and it is relatively portable to various systems.
Mono requires a pretty featured debugger. The debugger supports multi-threaded application debugging, multi-language debugging as well as managed and unmanaged code debugging, including the debugging of the runtime and the JIT themselves.
The debugger is still being worked on and it is not ready for production use. Although the command line version is useful, most people will want to use the GUI version, and that will require some more usability work.
* Gtk# maturity: The Gtk bindings for Mono/.NET have reached a level of maturity that has enabled people to write various graphical applications with it.
For instance, our debugger and documentation browser are written with Gtk#.
Gtk# provides bindings to various libraries from the Gnome world, it is not limited to Gtk+, but includes support for Gnome, Libart, Rsvg, Atk, Pango, Glib and Gstreamer, with more features being added by the developers.
One nice extra of C#’s overloaded method mechanism is that we can have multiple routines with the same name, and we can afford to provide a simpler to use Gtk than the native C binding. Also accessors have been mapped to C# properties, and signals to C# events, so the binding reflects the .NET spirit. Other features include the attribute-based Glade support.
Since .NET allows applications to bundle various extra bits as “resources” of an executable or library, developers can ship a single binary that contains all the supporting data an application might need, as opposed to scattering images, glade files, resources and configuration files all over the file system.
Bindings for OpenGL and GtkMozEmbed (the Mozilla bindings for Gtk) exist as well.
* Documentation effort: A very important step has been undertaken to produce free documentation for the class libraries. Both .NET class libraries and the class libraries that we have produced in Mono or around Mono.
We have a documentation browser, and a documentation compiler. The documentation system is designed so multiple providers can be used, a feature that we will be using to integrate various kinds of documentation: ECMA XML documentations, C#-compiler generated documentation, our own HTML tutorial, C# language reference documentation, compiler reference, tools references and anything else that a developer would need to become productive on this environment.
A set of tools have been produce to maintain and track libraries as they evolve, a fundamental part of keeping our things documented.
* Remoting platform: various developers have stepped up and have implemented the remoting framework for .NET, a remarkably large task, as well as documenting the Binary formatter.
Remoting is a general purpose framework for building RPC systems that takes advantage of the .NET Framework’s runtime introspection facilities to simplify the development of clients and server, and create stub-less and skeleton-less RPC endpoints.
* Apache integration: The System.Web classes can be hosted in any web server, and in particular a new Apache Module for Apache 2 does this. This is a frequently asked question.
Also, more and more commercial developers have been running their code
on Mono, and we frequently get feedback on missing features or bugs in
our implementation. With their help, the team has been addressing
those issues, and making Mono a good choice for re-targeting their
applications to Linux/Unix.
There are some missing components in Mono today though:
* System.Windows.Forms is still on its early development stages. Although some sample applications are starting to run, and the issues we had with the Wine integration have been sorted out, there is still a lot of work left to be done.
* EnterpriseServices and DirectoryServices are essentially non-existent today.
* Web Services: the client and server support is missing, although some of the infrastructure pieces they depend on have been implemented.
Regarding our future directions for Mono, we are aiming for feature
completeness and robustness first, so far the team has done a great
job here. We routinely bootstrap the Mono environment from scratch and
run our regression test suites, but more would be of course welcomed.
We have been working on a new JIT engine that will replace the current engine. The objectives for the new engine are outlined here:
* Ahead-of-time compilation.
The idea is to allow developers to pre-compile their code to native code to reduce startup time, and reduce the working set that is used at runtime in the just-in-time compiler.
Although in Mono this has not been a visible problem, we wanted to pro-actively address this problem.
When an assembly (a Mono/.NET executable) is installed in the system, it would then be possible to pre-compile the code, and have the JIT compiler tune the generated code to the particular CPU on which the software is installed.
This is done in the Microsoft.NET world with a tool called ngen.exe
* Have a good platform for doing code optimizations.
The design called for a good architecture that would enable various levels of optimizations: some optimizations are better performed on high-level intermediate representations, some on medium-level and some at low-level representations.
Also it should be possible to conditionally turn these on or off. Some optimizations are too expensive to be used in just-in-time compilation scenarios, but these expensive optimizations can be turned on for ahead-of-time compilations or when using profile-guided optimizations on a subset of the executed methods.
* Reduce the effort required to port the Mono code generator to new architectures.
For Mono to gain wide adoption in the Unix world, it is necessary that the JIT engine works in most of today’s commercial hardware platforms.
This new JIT engine should be released shortly, still working out on the release issues for it.
We are also tracking the new submissions of Microsoft to the ECMA group, and we will be publishing versions of our tools that provide the new features like Generics, anonymous methods, partial types and iterators.
Screenshots probably speak better, we have some at our site.
2. Portable.NET and dotGNU is keeping close to Mono’s advancements as much as possible. What do you think about their progress? Which implementation do you see to be the most-used alternative to .NET?
Miguel de Icaza: I think they are doing good progress, and am glad that there are other implementations of the ECMA standards available. They are free to use our class libraries as they are licensed under very liberal terms (the MIT X11 license, which is even laxer than the original BSD license).
Mono is probably going to be the most used alternative .NET
implementation, but only time will tell.
3. When you started Mono about 2 years ago, a lot of people were angry at you feeling… betrayed that you chose to embrace a Microsoft technology. However, I heard someone saying that these very same people will thank you for your work when the right time comes in a few years, when Mono will be obvious of its importance on keeping Linux “current” in the technologies of this future time. What do you think about this public outcry you had back when you started Mono and do you agree with the above said person about the future?
Miguel de Icaza: I do not particularly mind the outcry. It is important to have a dialog and
discuss the pros and cons of every approach, and the early discussions
were good in that they helped crystallize the vision for Mono. The
situation was obviously not helped by the fact that the name `.NET’
had been overloaded to mean different things.
Today I think the situation has changed as people understand that Mono
is an implementation of the .NET framework and that the scope of the
project is well defined.
If you like the .NET framework or you happen to have code written for
it (GUI, server based or web based), then Mono is a tool you would
use. The Mono team obviously believes that this is a great
technology, and you have to try it out, but if you prefer to use PHP,
Java, C++ or any other technology, that is fine with us. In fact,
some developers are already working on bridging these worlds
together (there are PHP bridges and Java VMs for .NET/Mono in existence today)
Two years ago Mono was only a vision, today people can write code for
it, and run it, so the perception obviously changes.
4. How do you feel about Mono on cell phones and other mobile devices? Any thoughts on this?
Miguel de Icaza: Mono is already running on the iPaq, here is a screenshot.
We hope that the new JIT engine will soon be ported to this CPU.
It would be extraordinary to see Mono running on more embedded
You might want to compile a subset of the class libraries when running
on machines with limited resources, and am sure that when the time
comes, we will see patches that will conditionally compile out parts
of the class libraries.
5. I read a long discussion about D-BUS on the Gnome mailing list. What’s the deal with D-BUS, what is it, what it will offer and what will it replace (if anything)?
Miguel de Icaza: D-BUS does not replace anything, it is a new addition to the desktop.
D-BUS is a message bus, think of it as a broadcast system for sending
messages to applications on your computer. A bus is a useful
abstraction, and it would obviously be useful to have this thing done
in an very desktop-neutral fashion.
The debate on the mailing lists was not about whether a bus was
important, but what technology should be used for the bus plus other
6. What do you think about KDE and Gnome interoperability/compatibility/common standards? Are you for some kind of technological/standards unity between the two DEs, or do you prefer the two DEs to be separate?
Miguel de Icaza: You have to look at the larger picture. Gnome and KDE are not the
only players in the desktop: Gnome, Java, KDE, Mozilla, OpenOffice,
Real, and Wine are all citizens of the desktop, and from our point of
view, to make the desktop succeed and integrate, we should work on
getting all the players to agree in as much as possible where in the
areas where there is an overlap for the sake of the user.
I have not been involved in these efforts, mostly because I have been
busy with Mono which is a universe on its own, but the people
implementing and promoting the interoperability are key to the success
and future of Gnome as a competitive desktop.
7. Is there any serious attempt so far to port Mono on MacOSX and without the use of X11?
Miguel de Icaza: Mono works on MacOS X without X11.
You only need X11 if you are using X11 libraries, for example Gtk+. I
am sure that eventually a native version of Gtk+ will be done for the
MacOS, very much like the WIMP version of Gtk+ that makes Gtk+
applications blend and adopt the user interface of Windows.
8. How’s Gnumeric development these days? How is the application holding against all these office suites available for Linux, and when it is going to be completely ported in GTK+ 2.0 as a stable release?
Miguel de Icaza: Gnumeric is being maintained by Jody Goldberg, I am no longer involved
with the project.
Gnumeric has a number of unique features, and it is still one of the
nicest code bases to work with. Gnumeric’s code was designed to be
maintainable and clean, and this has paid off. But Gnumeric is still
far from being a drop-in replacement for Excel, although it has
features that are unique to it (like the spreadsheet conversion tool)
which will guarantee its continued development.
From Ximian’s perspective, we are focusing on improving Open Office as
it presents a complete office suite that has the functionality and
integration that users demand today. You can see some slides of the
work that Ximian has been doing on Open Office here.
Gnumeric will still have a market for smaller systems, or even for
embedded situations like PDAs or whenever the engine has to be reused
on special situations: Gnumeric is also very easy to modify and adapt,
so its pieces can be reused in other setups.
Answering your question about the Gtk 2 availability: I believe that
Gnumeric has already been ported to Gtk 2.0, but I would have to
differ to Jody on the precise answers.
9. Which part of Mono was the most difficult to implement, and which one you think you might get you some trouble in the future? How many people are in the “core team” of Mono today?
Miguel de Icaza: All of Mono has presented various challenges, and I have only hands-on
experience on a few parts, but I know that various areas of Mono have
proven to been challenging at times, and as such fun at times, and
hard at others.
* The JIT engine is obviously non-trivial work.
* The Windows API emulation layer was required to provide matching implementations for the IO and threading subsystems on Windows for Unix. This code is non-trivial, and its functionality not given the credit it deserves.
* The second-generation JIT is obviously non-trivial work.
* Application Domains and MarhsalByRef objects and the whole infrastructure for Remoting I know was complicated, but I could not say how much.
* Metadata handling: reflection and reflection.emit: I know these were tricky, because they were part of our chicken-and-egg problem when initially bootstrapping the compiler. The compiler was written in C#, and required extensive functionality from the runtime and the class libraries to be there. Getting this working in such a short amount of time was a miracle.
* Threading and thread pools.
* The C# compiler is the part am most familiar with. I have to say that writing a C# compiler in C# was both fun and challenging. I wish I had more time to work on tuning the compiler speed.
It is hard to estimate how many people are in the “core”. 150
developers have CVS commit access, but like every other open source
project, contributors are not working full time on Mono, they come and
go, depending on their spare time and their current obligations. I
would say that roughly 40 developers are actively involved on a given
week in the project. This number I draw from the Mono Weekly News.
Anyways, there are plenty of fun activities in the Mono world, it is
definitely the most fun project I have done, and it is also
interesting because as an open source project, we get to work with the
Windows developer community, a community that we have been
historically isolated from.
10. I hear rumors… a new JIT for Mono, ‘they’ say. If this is true, why is the new JIT being developed in secret? And why the need for a new JIT?
Miguel de Icaza: I already talked about the new JIT properties and objectives before.
An article with the details about the new JIT engine will be available
at the time of the release.
The new JIT began as a research prototype, on a `minimally’ new
infrastructure that would plug into the current JIT (that is why it is
internally called `mini’). And it kept growing until today’s JIT, it
grew out of a prototype.
The new JIT development has never been a secret, but it has been
developed internally. It will be released when we feel that we can
support it and answer questions about it. We have already given early
copies of the JIT engine to a few individuals that have been actively
involved with the JIT engine.
11. How about performance? How Mono stacks up speed-wise against the .NET and dotGNU implementations?
Miguel de Icaza: It is hard to answer this question, because a complete benchmark is hard to build: it has to test raw performance, garbage collection, threading, scalability, features, modes of operations and more.
A complete benchmark suite is difficult to build, and so far, nobody
has created a comprehensive one that could be used to compare it.
The JIT from Mono is obviously faster than PNet’s interpreter, and the
Microsoft JIT compiler is a well tuned engine that is better than
Mono, something that we hope will change with our new JIT engine.
But even if we get better raw speed from code which is pre-compiled, scalability issues, thread pools, application domains and many more factors will play into competing performance wise with the Microsoft CLR.
UPDATE: The Gnumeric maintainer, Jody Goldberg, emailed us about some info regarding Gnumeric:
1) Gnumeric’s distance from being a ‘drop-in replacement for Excel’ This is a matter of perspective. MS Excel does have features that Gnumeric lacks. However, they are not features that are necessary in most common use cases. The quality of what we do have is high. Especially the analytics (statistical tools, and worksheet functions). These implement almost a complete superset of MS Excel. We’re missing 2 out of 400 odd functions in MS Excel, and have added an additional 50.
2) The projected use case for Gnumeric in ’embedded situations like PDAs’. Our target audience are spreadsheet users. Its true that Gnumeric is light and fast in comparison to OpenOffice. However, that is far from the main claim to fame. As mentioned previously
our analytics are in good shape. We also have better quality support for some of MS Excel’s trickier calculation mechanisms. Additionally we support things like encrypted or protected xls files.
In short we’re still developing Gnumeric. For people that need an Office Suite, OpenOffice is a good choice. However, if someone is looking to use a spreadsheet, and wants easy extensibility and solid analytics, then I think Gnumeric is the way to go.