Alvaro points out that in the Language Shootout Benchmark Mono comes in 18th place compared to Java's 10th place.

We know that Sun's proprietary Java edition (not the open source one, as that one is nowhere to be found yet) is faster than Mono, but I was surprised that we were so far behind. So I looked at the comparison between Java6 and Mono.

Memory usage wise, we mostly come ahead, but in performance, there were two places where Sun's server VM beat Mono seriously in performance (5x or more), one is the regex-dna test and the other one is pidigits test.

The regex test is a test of the regular expression matching engine in the class libraries, not really a test of the language or VM performance, but library implementation. Clearly, our Regex implementation could use some work.

The pidigits test was showing up as 6x better with Java than with Mono. But the test is basically comparing C# vs assembly language. In Mono's case it is using a full C# implementation of BigInteger while the Java version uses the C/assembly language GMP library that has been tuned with hand-coded assembly language.

I ported Java's pidigits to C# to also use native GMP, and the results are promising, we now have a 4.7x speedup and the process size is one megabyte smaller. I was unable to test the Java version on my machine, as I could not find the native "libjgmp" library.

I wonder what the policy is for the language shootout to use external libraries. If its ok, I should contribute my port, if its not, the Java test should be rewritten to be a fully managed implementation.

If you run all the tests the gap between Java and Mono goes from 8 places, to 3 places; If you remove the two bad tests (Our Regex implementation, and the pidigits test) Mono is only one slot behind Java server; and if you also account for memory usage (but still account for all the tests), Mono comes ahead of Java.

Of course, we got homework to do: why is our Regex implementation so much slower?

Update: As it turns out, Mario Sopena pointed out that, another 25% performance improvement can be achieved if the implementations are similar. The C# sample does a lot more regex work than the Java implementation does. The Python implementation has further refinements on the algorithm that could improve the performance further.

Some Observations

It is interesting to see in the benchmarks the progression:

• Close to the metal languages are the first tier (C, C++, D, Pascal, even Eiffel).
• Compiled functional languages come next (OCaml, ML, Haskell, Lisp).
• Java and Mono are on the next tier.
• A big jump comes next: Erlang, Smalltalk, MzScheme.
• Next big jump: Pike, Perl, Python.
• Another jump: PHP, Javascript.
• Tcl: a class on its own.
• Ruby, last one.

There are a few rarities, like Fortran being in the same tier as Java and Mono, which probably means the tests for Fortran have not been tuned up, I would expect it to be in the same tier as C.

Also, am surprised by Ruby being the last on the list, I expected it to be roughly in the same range as Python, so I suspect that the tests for Ruby have not been tuned either. Update: my readers also point out that Ruby 1.9 will improve things.

Update: I just noticed that Eiffel is on the first tier, performance wise, but has pretty much all the properties and features of the third tier (garbage collection, strong typing, bounds checking). This means that you get the best of both world with it (and Eiffel's compiler is now also open source).

Language Productivity

And of course, at the end of the day, what matters is how productive you are writing code in a language. The Wikipedia is powered by PHP, Amazon by lots of Perl and C, Google uses Python extensively, and the stellar productivity that can be achieved with Ruby on Rails is hardly matched. So even if your language is slower than the first few tiers, to many developers and sites deploying software what matters is productivity.

Choosing between Mono's C# and Java, both languages being roughly on the same class, is a function of the libraries that you use, the ecosystem where the code will be developed/deployed and to some extent the language.

Alvaro's teammates at Sun have a difficult challenge ahead of them when it comes to the language: how to fix a language that has been so badly bruised by their generics implementation, their refusal to acknowledge delegates, the ongoing saga over the catastrophic closure proposals [1] and the lack of a strong language designer to lead Java into the future.

So even if we have a slow regular expression engine, we have working closures, iterators, events, the lock and using statements in the language and LINQ.

Of course, I wish them the best luck (in the end, Mono is a language-independent VM, and we are just as happy to run C# code as we are running Java code, which incidentally, just reached another milestone) and we certainly plan on learning from the open source Java VM source code.

Alternatively, you can use Mainsoft's Grasshopper to write C# code, but have it run on a Java VM.

[1] Am tempted to write a post about the mistakes that both Java closure proposals have. But it seems like it will be a waste of time, it feels like there is just too much hatred/NIH towards C# in that camp to make any real progress.

paint-mono is a port of Paint.NET. The only way it could be built in the past was using a development version of MonoDevelop and there was no way of generating packages for it.

Since then, MonoDevelop has progressed to the point where it can generate standard Unix makefiles and generate the proper scripts, pkg-config files and produce code that conforms to the Mono Application Deployment Guidelines from a Visual Studio solution.

It is now easier than ever to try Paint.NET on Linux, all you need is:

• Mono 1.2.6.
• Your favorite form of Unix (Linux, BSD, OSX, Solaris).
• An SVN client.

To build it, use the following steps:

	$ svn co http://paint-mono.googlecode.com/svn/trunk/src paint-mono
	$ cd paint-mono
	$ ./configure
	$ make
	$ make install
	

To run, just type "paintdotnet" on the shell, this should come up:

I have not spent much time porting the SystemLayer.dll, but it is enough to access most features in Paint.NET. A real method-by-method audit needs to be done for the port to be considered complete though.

We are calling it "Mono Paint" as the authors of Paint.NET have requested us that we do not use the same name for the porting effort. The idea is that eventually the port will merely be a drop-in replacement for the "SystemLayer.dll" the library where all the OS-specific code is located.

For more details on downloading it, filing bugs, or tracking the project, see the paing-mono's home page at Google Code.

This is a cute hack that I put together today.

For months I have wanted to colorize the output of the compiler for errors. Sometimes in a sea of warnings its difficult to find the error that broke the build with a quick visual inspection.

Most civilized people use IDEs, or even Emacs to build their stuff, but for some reason I end up building from an xterm all the time.

Today I introduced the MCS_COLORS environment variable that the compiler will use to configure its colors, the default. This is the default, witness this high-tech beauty:

My personal default is slightly different, as I use grey-on-black terminals, its more of a DOS-days Turbo-Pascal kind of color scheme for errors:

This is my personal setting:

	export MCS_COLORS=errors=brightwhite,red
	

Am not making this the default, it seems too strong for public consumption.

If you absolutely hate this, you can use:

	export MCS_COLORS=disable
	

Am not sure how come I never made the connection between Matt Warren and his involvement in C# 3.0 and LINQ (I only made the connection while reading Tim Anderson's review of VS 2008).

I have been re-reading his blog in fascination in my spare time, but this caught my attention:

Ever since I joined up with the C# team nearly two years ago I've been frustrated by my inability to wax poetic about all the goodness we were working on. I was sworn to secrecy. Mum was the word. Perhaps if you were paying attention to the work in C# 2.0 and C-Omega, you may have guessed what was to come. Looking back, it's easy enough to recognize it in the design of Generics, Iterators and Anonymous methods. The existence of Nullables in there as well should have made it obvious. We were planning ahead for the big pay off, language integrated query.

You may be amazed that so much planning goes on in the features that we roll out version to version. Sometimes big ideas and far-reaching visions take many releases to come to fruition. You cannot always do them in one release. Sometimes you have to take a risk and dole them out piece by piece. This may cause a bit of confusion at first, when no one can truly understand why a particular feature was included and not others, or why one design was chosen. Yet once all the pieces are together you can finally make sense of it all, and then as if by magic it all just seems right.

At some ECMA meetings in 2004 (the time stamps for some of my notes on the disk are January of 2004) some of the new features were being presented at ECMA and it was obvious to see the benefit for those features (generics, check; anonymous methods, check; iterators, check; partial classes, check) but a few of the features made no sense.

Nullable type decorations made no sense to me ("int? a"). I remember feeling that they were pure compiler bloat and that the use case of databases made no sense. Am not a database developer, but I felt that the syntactic sugar at the time really was not bringing much to the plate. During one of the meetings, I remember putting together a parody for new type qualifiers (which is the timestamped file I kept) for other domain-specific features that I felt were just as useless.

Even with early access to the C# 2 specification for so long, I did not see these components coming together and fitting perfectly to create LINQ.

Nat just landed, and we were touring the office when we ran into a messy room.

Nat: what happened here?

me: Oh, that's the xbox room.

me: but the xbox is not here now.

Nat: so what do you call this now? "The room"?

After the world acclaimed announcement of gui.cs eight months ago the developer user base has doubled!

That is correct. We now have 2 (two) applications using the awesome gui.cs rich-console-application development platform to deliver the best ncurses has to offer to all those vt100-derived emulators:

You can see some screenshots.

Of course, the UI still has to support some legacy users that require GUI support (Vista with Gtk# and the same app running with Gtk# on KDE).

Although I had a great testimonial from my first user, it was not suited to be printed on a family blog.

Calvin who is way better organized than I am posted the details about the job positions at Novell working on UIA for Linux.

In Calvin's blog there is a link to Michael's details about the work that they will be doing.

You can still send me your information, I will likely help the guys doing the interview, but the actual HR-esque process that organized people at Novell use is available.

Again, these are not a jobs in the Mono team, but in the desktop team although plenty of the code that you will write will end up in the standard Mono distribution.

We are doing some work to make Windows.Forms and Moonlight accessible. The desktop team is hiring people for the Cambridge office (USA) that want to work on accessibility technologies, free software, C#, Mono and the UI Automation framework.

If you are interested, drop me an email with the subject line "AccessibilityJob" and we will reply in the next couple of weeks with one of those exercise interviews that we do.

Although a lot of the work will end up in Mono, this is part of an effort from the desktop team, so technically you will be reporting into a different organization than the Mono team.

The Dennis Kucinich campaign is doing a fund drive this Saturday. You can sign up here or contribute directly by clicking on "Contribute: Online" at the top.

Reddit-poll after reddit-poll has shown that am most closely aligned with Kucinich than any other candidate for president of the US. Read the summary of his positions:

• No funding of the illegal War on Iraq.. He has consistently voted to stop the funding on the War on Iraq without weasling his way out like some other people. He also wants to stop the use of depleted uranium, he is for the nuclear non-proliferation treaty.
• Single-payer, not-for-profit health care system. For some backgrond information, see Sicko. I also blogged about that when the movie came out.
• Comprehensive social programs. I rather have my taxes go into these programs than killing people.
• Restoring Constitutional Government and he is also against torture.
• Fairness in Global Trade. As a fan of Joseph Stiglitz' Globalization and its Discontents am a fan of reform on this area.
• Dealing with the War on Drugs as a medical problem. Not a law enforcement problem. As Kucinich says, they promised an end to drugs through force by 1995, and they have yet to deliver. It is time to stop that ridiculous program. Also read his take on decriminalization of Marijuana.
• Against the Death Penalty. Enough said.
• Reproductive Rights for women. The only form of abstinence I support is this one.

More details: here.

My dear friend Chris Toshok recently discovered that he had developed diabetes.

Tomorrow he is going to be admitted into an experimental treatment program for it. He will undergo four days of treatment.

The day that he told us about the experimental program, I had just seen this:

Good luck Chris!

Amazon reports that a new Chomsky book is on the pipeline. Essential Chomsky. Hope it is as awesome as some of the collected essays from Gore Vidal.

Am myself a fan of his Understanding Power book. Maybe as much as a fan of it, as a fan of the various Gore Vidal books that they sell on airports, the pocket book editions (Imperial America, Perpetual War for Perpetual Peace).

Guy Lunardi just emailed me a link to a very clever hack from Johnny Chung Lee at CMU.

How to use the Wii remote to capture finger movement. A brilliant hack.

The Wiimote library is released under the MS-PL, and I think this requires a port to Linux. I have added this wish-item to the Google Highly Open Participation project for Mono.

Having missed on games for the past 15 years last year I finally got myself a Wii. Other than Wii Sports and now Metroid 3, I have yet to find anything worth playing.

Nat recommended a Nintendo DS, and you guys had some great suggestions back in September. So far the only one I liked was Metroid Hunters (the control is so similar to the Wii, that its a pleasure to play) and am still making my way through the Sudoku's on the DS.

I tried Halo3 but with its up/down/left/right-cursor-like technology to aim at enemies, it feels almost like am playing with a keyboard in 1988. After using the Wii for point-and-shoot, anything short of that for point-and-shoot feels unnatural. Like when the dentist stuffs your mouth with junk and still tries to have a conversation with you or trying to use a bendy straw for snorkeling.

So am looking at expanding my Console Empire at home and purchasing either a PS3 or an XBox360. Aaron insists that I should not get the PS3 because Blue Ray this-and-that which I do not particularly care about.

Aaron also claims that eventually you get used to up/down/left/right. I guess I will have to live with that, as the Wii is barely getting any games worth playing. And as a rule, I do not play anything that glorifies war, but am OK shooting at strange looking aliens.

So am stuck, and willing to learn to use those unnatural controls on the PS3 and the XBox if there is something worth playing.

Dear readers, what should I get, PS3 or XBox? And which games are worth playing? I do not care about movies on demand, or whatever other TV features they are trying to sell me, I already have Tivo HD and Tivo with DVD playback and recording.

You can either email me or post here your suggestions.

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.

Zoltan just checked-in support for ahead-of-time (AOT) compilation in Mono for ARM processors.

We are looking for volunteers to test the support and post their findings to [email protected]. In particular, we are hoping that this should further reduce startup time and memory usage on Maemo devices.

An old post of mine covers the basics of using it.

I still hate the classification of anything that describes itself as enterprise (and I work for a company slogans are sprinkled with enterprise).

Yesterday someone emailed me:

It was not the point of your blog today but I'd be interested in hearing about company's usage of Mono in embedded systems. Because of our affinity for C#/.NET we originally looked at WinCE for the next generation of one of our product platforms. It didn't go very well (we were still at WinCE 5 so I can't say how 6 is). Ironically, using Mono on a Linux Embedded system seems to give you more .NET / C# then you get with CF on WinCE.

So I reached out to a friend that has raved about Mono in the past, and I wanted to get a quotable answer from him (I asked him if I could quote one of his emails from last year). He did give me a quote that I can send around to folks, but his company will not publicly endorse his quote.

Which is exactly the problem that I was describing yesterday. Anyways, the quote is:

C# and mono is a great way to develop embedded products. If you separate the heavy lifting from the application logic properly, the performance impact of C# is not significant and makes application development much faster and less buggy.

I've been doing embedded development with C# for over 5 years and mono is way better than .NetCF due to superior performance and binary compatibility with MSFT's desktop .Net.

One thing that is particularly handy is that you can prototype on a desktop PC and just drop the managed binaries on the device and they just work - no need to recompile.

So anyways, you are going to have to trust me that I did not make up that quote myself.

And today we delivered a gift (or in Don Box parlance, a "small bouquet of flowers") for those embedded people that use ARM processors.

Update: The author of the quote comments:

When you mention embedded development with mono, it might be worth mentioning that there is some startup cost for the JIT, depending on the CPU speed and how much managed code there is, and that the memory footprint with mono will be larger than it would be without. For most devices this may not be an issue, but it is something a device developer should keep in mind. Hopefully the AOT support will mitigate the startup costs.

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:

• Codice
• Fanfare
• Unity
• Versora
• Voelcker

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.

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.

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.

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.

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.

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.

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.