Track Moonlight Status

by Miguel de Icaza

Rusty has setup a nice page that tracks the Moonlight 1.0 status with various applications out there. We are using this as part of our QA and development process.

As it turns out, it was easier to support .NET-based Silverlight (1.1) applications than the Javascriped-based ones (1.0) as the .NET-based ones tend to do all the heavy lifting in managed code. And it was very easy for us to use tools like corcompare to ensure API completeness.

With 1.0, the story was different, we were debugging things on a when-we-find-a-problem-we-fix-it approach. JB recently created a tool based on the Microsoft specifications that helped us close the gap quickly. We went from hundreds of missing entry points to less than a dozen in a week.

We now have cute Firefox installers for 1.0 and 1.1 on Linux/x86 and Linux/x86-64, once we have the new codec framework in place we will make them available to the public for testing. In the meantime, people interested in testing Moonlight still need to build it themselves. See our Mono Olive mailing list for details.

Posted on 07 Dec 2007

Mono Usage in the Enterprise

by Miguel de Icaza

Over at the Enterprise Linux Blogs there is a quite positive article about Mono and I wanted to comment on it without having to fill 20-pages worth of questions to post a reply there.

Schley makes a few good points, but its worth pointing out some things:

2. People assume that Mono is not ready for the enterprise.

One of the reasons for this is because not many enterprise projects are being built with it (I'll get to that later.) Instead, Mono is primarily being used to construct desktop software.

The second reason for this misconception is the Mono project's inability to stay in step with Microsoft .NET. Currently, Mono is somewhere between .NET version 1.1 and 2.0 while .NET 3.5 was just released. This is not the Mono team's fault. Microsoft does not collaborate with them, so everything the Mono team accomplishes is through their own blood, sweat and tears. Nevertheless, this version discrepancy creates the perception that Mono is just a .NET wannabe.


With the exception of iFolder, Mono is not being used to develop any truly useful enterprise applications. Great desktop applications are being created, like Tomboy and Beagle, but no one has created the next great server application using Mono.

He is correct that Novell's use of Mono has been mostly focused on the desktop.

But there are quite a number of applications beyond the desktop that are being developed with Mono outside Novell. We have been tracking a list of companies using Mono and the list of programs and libraries keeps on growing every day.

A problem that we do have is that of the companies using Mono have policies of not publicly endorsing third party products. Also, we typically only find out about who is using Mono when they have a bug to report, or need some new feature to be implemented. And in many of those cases we are not in a position to use them as reference customers.

If you look at the posts, sigs and domains of people posting to the forums and the mailing lists, you will get a better idea of what kind of applications people are building, and who is building them.

A few companies have agreed to allow us to publish success stories about their use of Mono, some of them are:

Some other serious uses of Mono, but without a full success-story case include Fiducial.FR (their intranet runs on Mono), Zing (mp3 and Sirius radio players), Medsphere (Health Care software), Quantify Solutions (financial tools), MindTouch (commercial Wiki hosting) and its even used by companies in the USC 2257 space to build enterprise solutions (for an interesting definition of enterprise).

At least a few years ago, the Wikipedia search engine was powered by Mono. I do not know if that is still the case.

The goal of the Mono team at Novell is not only to help our internal users, but to make sure that external developers can use Mono without a problem. We fix bugs, improve performance, improve compatibility and write new libraries (both Microsoft compatible, or part of Mono's own stack).

Maybe the issue is that we do not have a lot of server-side applications that are part of a default Linux install. What we do have are plenty of vertical applications that people are developing or porting.

Memory Leaks If you have ever used Beagle you know that it can heinously crash your system. Since it's inception, Mono has been plagued with a random memory bug. Your system memory will go from 1% to 1000% in a matter of seconds, without warning. If the Mono developers want to make Mono more than just a desktop hobbyists language then they need to fix this bug once and for all.

As for memory usage problems: there are certainly memory leaks in Mono, but nothing as bad as a show stopper. Mono can not reduce memory usage if an application uses a lot of memory. Sometimes the blame for memory consumption falls on the application and is usage patterns.

Beagle might have had bad memory usage patterns on its early days, but a lot of this changed in newer releases.

There is one particular class of memory-hungry applications: any .NET applications that used generics (the 2.0 profile) extensively was negatively impacted by memory consumption before Mono 1.2.5. On one hand, we are glad that application developers switched to 2.0, as they helped us find the bugs and limitations in Mono, but it also meant that users had to suffer as we understood all the ramifications of the 2.0 profile and generics.

The situation will dramatically improve with our upcoming Mono 1.2.6. As Aaron already reported 1.2.6 had a dramatic impact on memory usage in Banshee (a generics-heavy application).

Python Effect There is a huge movement in the Gnome community to make Python the standard language for Gnome development. Mono is a close second, thanks in part to the great desktop applications being written with it. However, if Python is officially adopted, there will be a backlash against Mono, or pressure on developers to adopt Python and port their once Mono applications to the official language. In order to prevent this from happening, Mono developers need to demonstrate Mono’s cross-compatibility.

Python is indeed making great strides as a desktop development platform and am not sure that we are in the business of competing with it. If people like writing Python code, they should just keep writing python code.

Myself, I like the IronPython variation of Python more. IronPython just happens to be JITed Python and in most tests it is faster than CPython. For the past year or so, we have also been in love with Boo, another .NET language. Boo has support for strong typing, so for certain scenarios you will get even better performing code (basically, when you can determine the type of a variable ahead of time, instead of having the variable be entierly late bound).

At the Mono Summit, a developer had built a game that was scripted with Python, said something more or less like this: "Our game used to be very slow, when we switched to Mono, all those problems went away" (edited for political correctness).

So each developer will make up his mind as to what is best for a particular use case.

The Mono team needs to have Mono installed by default into Linux so that if you write an application with Mono it can run in Windows AND Linux (and even OS X).

We agree with that. Applications built with Mono on Linux already work on Windows and MacOS (including Windows.Forms).

When it comes to Gtk# applications, Our Mono on Windows ships with Gtk# and we recently announced that we will be supporting it as well on MacOS X and that we will be extending our OSX support.

Posted on 06 Dec 2007

Real Time Linux

by Miguel de Icaza

Today there was some claims from a Red Hat VP regarding Novell shipping of Real Time Enterprise Linux.

I find it odd that Red Hat would make those claims, as for more than a year on all sorts of meetings SUSE Real Time development status updates come back and forth. Usually they are high level, but we get to hear a lot about Moiz's team work at these meetings.

Kevan Barney from Novell PR posted a response to the claims that Novell has not contributed code. And points to the mailing list where you can see that Novell engineers have been contributing code and participating on Real Time Linux with the rest of the community for a long time.

Posted on 05 Dec 2007

Pure Comedy

by Miguel de Icaza

It can not get better than this.

The neoconservatives response was swift, check the professionally summarized version of all the punditry in one easy blog post.

Posted on 04 Dec 2007

Love Kucinich

by Miguel de Icaza

This is just brilliant.

Hope my American friends like Kucinich as much as I do.

Update: Slate covers the health plans. Kucinich is the best.

More Kucinich Awesomeness: New NIE Report Shows Bush Administration Has Once Again Tried To Falsify Grounds For A War With Iran.

Posted on 04 Dec 2007

Mono on OSX, Win32

by Miguel de Icaza

In general, the focus of the Mono team is on Unix system, and more specifically for open source versions of Unix (Linux and BSD) but we still provide provide some support for Win32, Solaris and OSX even if they are proprietary and OpenSolaris (even if its licensed for mininal collaboration and cross pollination with Linux).

In general, our cross platform story has suffered a little bit when it comes to GUI toolkits: our Windows.Forms implementation works with X11, but Mac users really want to run a native version of it, without requiring an X server.

Gtk# suffers from the same problem: it works on X11, OSX and Windows, but on OSX it requires the X11 driver which is suboptimal.

In general, I do not like to support proprietary operating systems, but in the particular case of OSX, there is enough of a user-base that it made sense to bend backwards for the sole purpose of increasing the contributor and user bases.

At the Mono Summit we outlined our new strategy for OSX:

  • Our Windows.Forms now has a native OSX back-end. Mono 1.2.6 will ship with it, and Mono 1.2.7 will ship with several upgrades (some already on SVN) that will make Windows.Forms applications run even better on OSX.
  • We will distribute Imendio's Gtk+ for OSX and Gtk# as part of our runtime. It has now reached a maturity point that allows applications like MonoDevelop to run natively (without X11).
  • We will distribute MonoDevelop for OSX users as a pre-compiled package, and we will provide support for it.
  • MonoDevelop will also be ported to Windows. The work necessary to port MonoDevelop to OSX is also going to help the port of MonoDevelop to Windows. This should be useful for people that are building Gtk#-centric applications on Windows. For other uses Visual Studio and SharpDevelop will continue to be better IDEs to use.

We will support the following, but only as a lower priority, and work on them will be preempted by other needs in Mono:

  • We will support Objc-Sharp for those that need bridges between Objective-C and Mono. But
  • We will depend on the community, and provide some assistance to those that rather use the CocoaSharp bindings to the native Cocoa APIs.

A screenshot of a Windows.Forms app running with the native driver (click for a full shot):

A screenshot of MonoDevelop, our Gtk# based IDE on MacOS with Gtk's native OSX driver:

We are shipping MonoDevelop 1.0 at the end of January, after this, we will start work on the debugger integration into MonoDevelop (the most requested feature) and we will also add support for developing Silverlight applications with it.

At the Mono Summit, we got Moonlight running on MacOS X (including desklets!) which means that our Silverlight designer (currently called LunarEclipse) will be available on MonoDevelop on OSX. But we will not support Moonlight on the browser on Safari or Firefox on OSX as you can run Microsoft's edition there.

Posted on 02 Dec 2007

The Mono Summit is Over

by Miguel de Icaza

The summit was fantastic. The first two days we did a bit of internal planning for the project (we had Novell employees and contributors that day).

Although I had originally wanted to have as much empty space as possible to do some more Unconference style presentations, we probably had too much structure in place. At least we had some large holes between presentations for people to talk to each other (except that not one talk finished on time, which meant that we were always a few hours later to end the day).

The event was supposed to end every day at 17:45pm, but most of us barely left the place before 9pm (which was nice of them, to keep the place open for us until late). Followed by a late-dinner in Madrid, and a then some socializing in the hotel lobby or nearby bars turned into four hours of sleep every night.

Thanks to everyone that made this happen, and for our Ismael Olea who provided our logistic support at the event every day and Alejandro S�nchez that got us this beautiful venue in Madrid.

I hope that all the attendees got to talk to the team members; I know that many of you did, and I hope that we fixed your issues, or we came up with a solution for your issues.

Posted on 02 Dec 2007

XML Conference

by Miguel de Icaza

Next week I will be attending the XML Conference here in Boston. Am looking forward to the opening keynote on Monday by Douglas Crockford.

My friend Rich Saltz invited me to talk about Moonlight: our open source implementation of Silverlight on Linux (Wednesday).

On Tueday I will talk about our efforts to support both ODF and OOXML at Novell in our edition of OpenOffice.

Posted on 02 Dec 2007

Botijos in New York City

by Miguel de Icaza

My friend Karla Frechilla will be presenting her artwork in New York City starting this Saturday until the 15th.

There will be an opening reception on Tuesday December 4th from 6 to 8 pm at Jadite Galleries 413 W 50th St in New York City.

She will be presenting her Botijos as well as some of her paintings.

Posted on 30 Nov 2007

Generics Memory Usage

by Miguel de Icaza

Aaron walked into my office today to get some some feedback on some implementation detail for his new listview in Banshee.

Before he left the office he said something like, but not necessarily "In some Microsoft blog someone commented that I should not use generics for small arrays of value types" (see Update at the bottom).

So we decided to measure with a trivial program the memory consumption for storing small arrays with and without generics with Mono 1.2.5 and Mono 1.2.6.

Storing 8 megs of ints (32-megs of data) on an array of objects has a high overhead: the actual data, the box, the object lock which means that you end up using about 21.5 bytes per int:

		object [] e = new object [size];

		for (int i = 0; i < size; i++)
			e [i] = 1;

With a generic array, you are as close as possible to a real array and you only consume 38 megs of ram (this is the full process size, the 32 meg array plus the Mono runtime, JIT, etc), the following sample ensures that am not using a regular int array, but an instantiated generic class with ints:

		public class D<T> {
			public T [] t;
			public D (int size)
				t = new T [size];

		D<int> d = new D<int> (size);
		for (int i = 0; i < size; i++)
			d.t [i] = 1;

The regular collection consumes 178 megs of ram, while the generics collection consumes 38 megs of ram (when running with Mono).

I was a bit shocked about the 178 megs of ram used by regular object wrappers, so I wrote the equivalent for Java, to see how they fared compared to Mono:

	      Object [] x = new Object [8*1024*1024];

	      for (int i = 0; i < 8*1024*1024; i++)
                     x [i] = new Integer (i);

Java uses 248 megs of ram, so it is chubbier than regular C# at 30 bytes per boxed int on average (this was with Sun's Java 1.6.0, maybe there are newer versions, but thats what I got on my system).

I got no Java/generics skills to implement the above with Java, but since Java does not really have generics at the VM level (they are implemented purely as a language-level feature), I do not think that the numbers would be significantly different).

Mono 1.2.6 also introduces a number of memory reduction features for generics that reduce the size of our interfaces. When using generics, in 1.2.5 on a List<int> case we were generating a lot of useless stuff:

IMT tables size: 7752
IMT number of tables: 102
IMT number of methods: 2105
IMT used slots: 872
IMT colliding slots: 486
IMT max collisions: 27
IMT methods at max col: 134
IMT thunks size: 19060

With the upcoming 1.2.6 release the memory savings for the metadata kept resident by the runtime are also significant:

IMT tables size: 7752
IMT number of tables: 102
IMT number of methods: 4
IMT used slots: 2
IMT colliding slots: 1
IMT max collisions: 3
IMT methods at max col: 3
IMT thunks size: 34

There is still an issue of locality. Using the boxing collections has the advantage that the same code is shared across all possible types. The generic versions on the other hand get their own JITed versions of every method involved (at least today).

You can track Mark's progress to change this as he continues with our implementation for generic code sharing.

Summary: From a memory consumption point of view, the bottom line is: if you are storing value types (non-object values like ints, longs, bools) it is better to use generic collections (System.Collections.Generic) than using the general-purpose collections (System.Collections). If you are just going to store references to objects, there is really no difference.

Update: The comment was from Rico Mariani, and the source of the confusion was:

List<T> offers generally better performance than ArrayList as well as type safety. We recommend using List<T> over ArrayList always if T is a reference type. If T is a value type there is additional cost assocated with creating a specialized version of List<T> for that value type. When T would be a value type we recommend List<T> if the savings in boxing is greater than the cost of the additional code -- this tends to happen if you store about 500 elements across all your List<T> objects.

OK, so the confusion is not that it might be worse for value types, but that the JIT will have to generate specific instantiations of generic methods (Insert for example) based on the parameter type.

So the JIT generates separate code for a List.Insert of int and for a List.Insert of long. Considering the savings for even small apps, I will go with "Go wild with the value types" myself as the code for the collection code is really small.

Posted on 21 Nov 2007

« Newer entries | Older entries »