Wii Remotes

by Miguel de Icaza

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.

Posted on 12 Dec 2007


Wanted: Game Console

by Miguel de Icaza

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.

Posted on 08 Dec 2007


Embedded, its not part of foreplay, but it is still very important.

by Miguel de Icaza

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.

Posted on 07 Dec 2007


Pre-compilation support for ARM processors

by Miguel de Icaza

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 mono-list@lists.ximian.com. 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.

Posted on 07 Dec 2007


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


« Newer entries | Older entries »