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.