Slashdot Mirror

An anonymous reader writes "Novell has unveiled some of the fruits of its technical collaboration with Microsoft in the form of Moonlight 1.0, a Firefox plug-in which will allow Linux users to access Microsoft Silverlight content. Officially created by the Mono project, it is available for all Linux distributions, including openSUSE, SUSE Linux Enterprise, Fedora, Red Hat and Ubuntu. Also included in Moonlight is the Windows Media pack, with support for Windows Media Video, Windows Media Audio and MP3 files."

bigmonachus writes "Miguel de Icaza has posted on his blog that linux users will be able to watch the Obama inauguration using Moonlight. Just go to the Moonlight download page to get it. He also said that some Microsoft engineers worked hard last night to make this happen."

smbarbour writes "The Mono project (the open-source .NET compatibility library acquired by Novell when Ximian was purchased) has released version 1.2. They are now including support for WinForms. Ars Technica has a detailed rundown on the new release. The Mono project supports Visual Basic.NET as well, so developers that use VB.NET now have the possibility of directly porting applications to Linux." From the article: "Relatively high memory consumption and performance bottlenecks are commonly perceived as being amongst Mono's most significant weaknesses. Some critics frequently refer to various performance issues to support arguments against broader adoption of Mono technology in open source projects, most notably within the GNOME community. The performance improvements in Mono 1.2 could potentially address such criticisms, but it is likely that a lot more work will be required before the problems are completely resolved."

Eugenia writes "OSNews posted an article accounting the applications created in GTK# the past 8 months, since the release of Mono 1.0. While many of them are still in their infancy, it's clear that the platform had a healthy progress, with 'super-hits' like Tomboy, F-spot, MonoDevelop, Muine & Blam! and other, less known gems, like SportsTracker, PolarViewer, MooTag, GFax, GIB, Sonance and Bluefunk. The 2.0 version of Mono is expected around May, but the developers advised distros and users to upgrade to Mono 1.1.4 despite being a beta."

christophw writes "The programmers of SharpDevelop (better known to the /. crowd will be its sibling MonoDevelop) together with the publisher Apress made the book Dissecting a C# Application - Inside SharpDevelop available as a freely downloadable PDF document (no, no registration required). So if you want to judge for yourself if one can build an application of scale with .NET (or Mono for that matter), you now have a 500+ pages book for the holiday reading season (or the virtual bookshelf)."

vertigo writes "I am reasonably proficient in C and C++ as well as the more common scripting languages, but i always felt the lack of a sweet spot between the hard and fast low-level programming languages and the loosely typed scripting languages. Lately, my interest in the Mono project has been growing. The C# language appears to offer just that sweet spot between power and productivity I've been looking for, and its class libraries like Gtk# seem to provide the programmer with a very clean and intuitive API." Read on for vertigo's review of Mono: A Developer's Handbook from O'Reilly. Mono: A Developer's Handbook author Edd Dumbill and Niel M. Bornstein pages 278 publisher O'Reilly Media, Inc. rating 8 reviewer vertigo ISBN 0596007922 summary An introduction to programming with Mono

When learning a new language such as C#, or working with a new development environment such as Mono, it usually takes some time before you get up to speed in developing programs. Wading through the reference documentation and reading other people's source code often provides much-needed information on how to do certain things. Both, however, are very time consuming and tedious.

Enter Mono: A Developer's Notebook. This book provides a series of task-driven chapters which are thin on theory, but rich on practical content and example code. The featured code snippets are, in contrast to ones in books that teach theory and concepts, not solely designed to illustrate a specific theoretical aspect of programming. Each one is designed to perform a useful task that is essential in day-to-day application programming. What sets this book apart from the multitude of .NET books already available on the market? In order to answer this question it is neccesary to provide a short introduction on Mono.

Mono is essentially an open source cross-platform implementation of Microsoft's .NET development framework and implements the API's which are standardized by ECMA. It is, however, not an exact clone. Besides providing a (partially implemented) stack that provides compatibility with Microsoft's .NET API's, Mono adds a whole new API-stack of its own, consisting of open source technologies such as the Gtk+ toolkit and the Gecko HTML rendering engine. This makes it possible to develop cross-platform applications based on open source technology while (mostly) compiling from a single code-base. In contrast to most .NET books available on the market, which focus primarily on Microsoft's API's in the context of Visual Studio.NET, this book concentrates on the basic ECMA API's and Mono's own open source stack. A complete coverage of .NET and the Mono architecture is outside of this review's scope, so for more information you are advised to check the Mono Project's website.

Before we dive deeper into the content of the book, a short introduction on the Developer's Notebook series by O'Reilly may be useful. The books in this series are styled to resemble the kind of notebooks college students carry around during their classes in which to take notes or, more commonly, draw caricatures of their teachers. The 'notebook' theme persists throughout the look-and-feel of the book. The 278-page thick paperback has a glossy blue cover, complete with faux post-it note and coffee-stains. Inside, the pages are not clean white but lined like the pages found in math notebooks. In the margin, useful comments are scribbled in a font that resembles handwriting. At first I suspected that the 'busy' look would distract from the content, but in practice this was no problem, thanks to the thick black typewriter font in which the bulk of the text is printed.

The chapters in this book are referred to as labs. Each of them focuses on a specific set of tasks and/or features and is divided into several paragraphs. Most paragraphs consist of a number of standard sections following a rigid formula that help you understand a certain aspect of working with Mono. The most common sections are:

• How do I do that?: Often using a liberal amount of practical code, this section shows how to accomplish the task at hand, for example working with files.
• How it works: In this section, the code and concepts involved in the previous section are explained more in depth, step by step.
• What about...: Offers a short focus on more advanced topics or pitfalls.
• Where to learn more: If you are craving more information after reading the previous sections, you are often offered a helping hand on where to find more information, providing url's to relevant documentation such as MSDN and other websites.

The first chapter, Getting Mono Running, describes how to get Mono up and running on Linux, Windows or Mac OS X, and how to compile from source on other platforms. The installation instructions for Windows only describe how to install Mono and Gtk#. Integration of Gtk# only in an existing Visual Studio.Net installation falls outside of the scope of the book, but a recent blog entry offers some hints on how to accomplish this. Besides installation, the first chapter offers a short description of the individual tools that make up the mono development. After installation, you will want some kind of editor or IDE to work with. Both the MonoDevelop IDE and several other ways of integrating Mono into your existing environment as a Java or Windows developer are covered. Finally, the community is an important aspect of every open source project. Ways of interacting with the community as well as a guide on how to submit bugs and links to some working Mono/C# applications are part of this chapter.

The C# introduction in the second chapter, Getting Started with C#, is tailored towards people who have at least some proficiency in using an object-oriented language such as C++ or Java. Some differences between C#, Java and C++ are discussed, as well as the differences between value- and reference types, the basics of error handling, working with assemblies and more. Concepts such as classes, methods, inheritance and namespaces are assumed to be known territory. If you have no previous programming experience, Mono: A Developer's Notebook is only useful in combination with a book that teaches programming with C# such as The C# Programming Language by Anders Hejlsberg.

An important part of any modern language is its class libraries. The third chapter, Core .NET, provides an introduction to the standard Framework Library Classes, which describes essential everyday tasks that are part of every program, such as working with files, strings, searching for text patterns and handling collections of data. Besides those basic functions, the chapter also dives deeper into the internals of a compiled assembly, the handling of processes and easy multitasking using threads. Finally, the last paragraph explains how to use a .NET version of the JUnit Java Unit testing framework, Nunit, to test your code.

Developing Gtk-applications with Mono and C# is remarkably easy. Chapter 4, Gtk#, describes the basics of writing Gtk# applications. First, it's neccesary to remark that Gtk# might be a bit of a misnomer. Besides the raw Gtk+ toolkit functionality, Gtk# also includes most of the Gnome libraries like gconf, the gnome canvas, libglade and more. Chapter 4 describes functionality available in the Gtk namespace, the basic Gtk+ toolkit. Gtk+ is a constraints-based toolkit, which means that widgets are not positioned using absolute pixel coordinates but rather on basis of their logical relation to each other. This can be a bit confusing for novices, but this chapter provides a good introduction to the basic principles of writing layouts using Gtk#. The authors provide descriptions of essential operations that almost every application needs, such as creating menus and drawing pixmaps (or more advanced things like using the treeview widget and drag-and-drop), assisted by easy-to-read code snippets.

While chapter 4 introduces basic Gtk# functionality, chapter 5, Advanced Gtk#, delves deeper into more advanced features of the Gtk# library which also include functionality outside of the basic Gtk-namespace, such as the Gnome libraries. Working with Gnome button toolbars, the Glade user interface designer, storing your application settings in Gconf, setting up some preferences through the use of a wizard/druid, asynchronous operations and threading to increase responsiveness of your application while performing background tasks, rendering HTML in your application using the Gecko rendering engine and internationalisation and translation of applications are all described in this chapter.

The use of XML is tightly integrated throughout the Mono framework. It is, for example, the underlying format of the messages that web services use to communicate using the SOAP and XML-RPC protocols. The 6th chapter, Processing XML, describes the XML functionality available in Mono. It starts off by simple operations, reading and writing to an XML-file using relevant examples such as RSS and Dashboard clue-packets. It then proceeds to describe how to modify XML in memory, how to navigate and transform XML using Xpath and XSLT, how to constrain XML in several ways and how to serialize and deserialize objects into and from their XML representation. As in previous chapters, the information density is very high so it might take several reads to grok everything explained. The code examples and accompanying text however are very clear and concise.

The 7th chapter called Networking, Remoting, and Web Services describes the networking functionality available in Mono. The chapter starts off with ASP.NET. Mono's stand-alone XSP webserver and Apache integration with mod_mono are discussed, as well as the basics of writing a web application using ASP.NET's code-behind functionality which enables web applications to completely seperate presentation from the underlying code. Communication using plain tcp/ip, remoting using binary serialized objects and invoking remote procedures using XML-RPC as an alternative to SOAP are also described in this chapter. You might want to encrypt the data you send over the network, so a basic description of the Mono cryptographic API is provided. Finally, a short introduction to database handling using ADO.NET concludes chapter 7.

The 8th and last chapter titled Cutting Edge Mono starts off with an introduction on how to use the GNU Automake, Autoconf and the pkg-config tools to create an easy to build source package of your project. It then proceeds to describe various pitfalls and considerations in case you want to write cross-platform applications using Mono, such as filesystem layout, configuration storage and the calling of native code using p/invoke. A particularly cool project is IKVM, which translates Java bytecode into the Common Intermediate Language bytecode Mono uses. This enables Mono to run Java applications and allows Java and Mono code to inter-operate. A short introduction on the use of IKVM is provided, as well as some code examples on how to call Mono assemblies from Java and use the Java class libraries from within Mono applications. The chapter ends with some other cutting-edge functionality, like how to run a development version of Mono, a preview of the Generics (templates in c++) implementation available as featured in C# 2.0 and how to write Mono programs in Basic.

What is missing? The book doesn't contain a reference section on any of the described API's. If you need detailed information on the C# language specification or an API reference you will need to consult external resources such as the documentation provided with Mono, MSDN, or a separate book covering the topic to make optimal use of the information contained in this book. Fortunately, the book kindly provides pointers on where to find those. The information-density is much higher than you would expect from a book this size. This means the information contained in it is terse. Many topics are treated in a only a couple of pages and the book doesn't take time to explain a lot of programming concepts. The information gets you 'on the road' quickly however, which is exactly what this book is supposed to do.

The strength of this book is that it fills the gap between the earlier-mentioned reference documentation and the need to go out and try to read sourcecode to find out how a particular thing is done. The writing style is clear, concise and neutral. Some topics are clarified by the use of screenshots, which is especially useful in the chapters dealing with Gtk# widgets. All in all, if you are a developer with previous experience in object-oriented programming, Mono: A Developer's Notebook will provide you with an excellent introduction into many of the aspects of working with Mono, its associated libraries and programs.

More information and a sample chapter can be found at the book's homepage.

You can purchase Mono: A Developer's Handbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

theblackdeer writes "Just poking around the go-mono.com Mono website; it's now the multi-colored mono-project.com. Even better, it updated before my eyes to include the 1.0 release. Screenshots are (slightly) updated, too. Mono 1.0 includes the Mono Develop IDE (based on SharpDevelop, I believe). Download now and start your GTK# engines!" Alliante adds "You can download the Release Notes and the Packages on their website."

steve_deobald writes "The Mono team just released Beta 3, the final beta before we see the 1.0 release candidate and final. Binary packages can be had for Red Hat, Fedora, and SuSE. Although not officially released, the new website is up and running. Also of note, MonoDevelop 0.4 was recently released, and has RPMs available for the first time."

steve_deobald writes "The Mono team just released Beta 3, the final beta before we see the 1.0 release candidate and final. Binary packages can be had for Red Hat, Fedora, and SuSE. Although not officially released, the new website is up and running. Also of note, MonoDevelop 0.4 was recently released, and has RPMs available for the first time."

A little birdy writes "Less than a month after Beta 1 was released, Mono Beta 2 has been released. See the Release Notes, or go directly to the download page. It includes a C# compiler, an implementation of the Common Language Infrastructure and two stacks of APIs: a Unix, Linux, GNOME, Mono stack for APIs that takes the most advantage of your Unix server and desktop and a set of APIs compatible with the Microsoft .NET Framework 1.1 that provides support for ASP.NET (web services and web forms), ADO.NET and many other components." And in a related story: darthcamaro writes "The drive to develop a FOSS implementation of Microsoft's .NET framework by DotGNU and Novell's Mono project is being painted as a contest between the Free and Open Source communities in an article on internetnews.com. The article details the running argument between DotGNU's Norbert Bollow and Mono's Miguel de Icaza on the issues of commercial involvement, software patents and all the 'religious' stuff that the Free software community holds against the open source community."

A little birdy writes "Less than a month after Beta 1 was released, Mono Beta 2 has been released. See the Release Notes, or go directly to the download page. It includes a C# compiler, an implementation of the Common Language Infrastructure and two stacks of APIs: a Unix, Linux, GNOME, Mono stack for APIs that takes the most advantage of your Unix server and desktop and a set of APIs compatible with the Microsoft .NET Framework 1.1 that provides support for ASP.NET (web services and web forms), ADO.NET and many other components." And in a related story: darthcamaro writes "The drive to develop a FOSS implementation of Microsoft's .NET framework by DotGNU and Novell's Mono project is being painted as a contest between the Free and Open Source communities in an article on internetnews.com. The article details the running argument between DotGNU's Norbert Bollow and Mono's Miguel de Icaza on the issues of commercial involvement, software patents and all the 'religious' stuff that the Free software community holds against the open source community."

Good news for those of you who've went through the pain of trying to get Mono installed on Mac OS X: the team has quietly added a Mac OS X package. If you previously installed to /usr/local, however, be aware that the packaged version installs to /opt/local and adjust any paths accordingly. The Beta-1 Windows installer has also been fixed; download it here.

Eugenia writes "OSNews had an interesting discussion with Miguel de Icaza about all things Linux and Novell. Miguel talked about the general patent problem and how this will become the one single stumbling block of widespread adoption of Linux in USA, while he asserts that Longhorn uses some 'new' technologies already found on Gnome and elsewhere. Miguel believes that poor countries will be the first that will adopt widely Linux, and as long the EU won't adopt a similar system to US for patents, Europe will follow soon after, leaving no option to USA but to eventually adopt Linux as well in the long run (despite potential patent problems). Another strategy Miguel discussed was about moving as many F/OSS applications as possible to Windows in order to familiarize the casual users with open source. Among many other interesting tidbits he also mentions that Quark is now using Mono on Mac OS X." Of course, the EU not adopting software patents seems to be less and less likely.

AArnott writes "Ximian has just released beta 1 of its open-source implementation of Microsoft .NET platform. Mono allows .NET applications to run on Linux, Mac OS X, Unix, Windows. Mono 1.0 is slated for release on June 30, 2004." sjanes71 adds "The first 'beta' always gets heaps of attention, and this is the first of three planned for the Mono project. Some of the new features touted for this release that updates Mono v0.31 include a faster interpreter, a global assembly cache, support for the StrongARM and HPPA platforms, generics support in the VM and C# compiler and an early alpha of System.Windows.Forms. C# and .NET is Microsoft's answer to Sun Microsystem's Java platform and Project Mono aims to create the Open Source, cross-platform version of Microsoft's new development environment."

AArnott writes "Ximian has just released beta 1 of its open-source implementation of Microsoft .NET platform. Mono allows .NET applications to run on Linux, Mac OS X, Unix, Windows. Mono 1.0 is slated for release on June 30, 2004." sjanes71 adds "The first 'beta' always gets heaps of attention, and this is the first of three planned for the Mono project. Some of the new features touted for this release that updates Mono v0.31 include a faster interpreter, a global assembly cache, support for the StrongARM and HPPA platforms, generics support in the VM and C# compiler and an early alpha of System.Windows.Forms. C# and .NET is Microsoft's answer to Sun Microsystem's Java platform and Project Mono aims to create the Open Source, cross-platform version of Microsoft's new development environment."

AArnott writes "Ximian has just released beta 1 of its open-source implementation of Microsoft .NET platform. Mono allows .NET applications to run on Linux, Mac OS X, Unix, Windows. Mono 1.0 is slated for release on June 30, 2004." sjanes71 adds "The first 'beta' always gets heaps of attention, and this is the first of three planned for the Mono project. Some of the new features touted for this release that updates Mono v0.31 include a faster interpreter, a global assembly cache, support for the StrongARM and HPPA platforms, generics support in the VM and C# compiler and an early alpha of System.Windows.Forms. C# and .NET is Microsoft's answer to Sun Microsystem's Java platform and Project Mono aims to create the Open Source, cross-platform version of Microsoft's new development environment."

AArnott writes "Ximian has just released beta 1 of its open-source implementation of Microsoft .NET platform. Mono allows .NET applications to run on Linux, Mac OS X, Unix, Windows. Mono 1.0 is slated for release on June 30, 2004." sjanes71 adds "The first 'beta' always gets heaps of attention, and this is the first of three planned for the Mono project. Some of the new features touted for this release that updates Mono v0.31 include a faster interpreter, a global assembly cache, support for the StrongARM and HPPA platforms, generics support in the VM and C# compiler and an early alpha of System.Windows.Forms. C# and .NET is Microsoft's answer to Sun Microsystem's Java platform and Project Mono aims to create the Open Source, cross-platform version of Microsoft's new development environment."

AArnott writes "Ximian has just released beta 1 of its open-source implementation of Microsoft .NET platform. Mono allows .NET applications to run on Linux, Mac OS X, Unix, Windows. Mono 1.0 is slated for release on June 30, 2004." sjanes71 adds "The first 'beta' always gets heaps of attention, and this is the first of three planned for the Mono project. Some of the new features touted for this release that updates Mono v0.31 include a faster interpreter, a global assembly cache, support for the StrongARM and HPPA platforms, generics support in the VM and C# compiler and an early alpha of System.Windows.Forms. C# and .NET is Microsoft's answer to Sun Microsystem's Java platform and Project Mono aims to create the Open Source, cross-platform version of Microsoft's new development environment."

the.jedi writes "With the release of GTK+ 2.4, and Gnome 2.6 due out some time next week, it seems of some the Gnome developers are looking at how they'll be coding Gnome and the rest of the Linux desktop. Havoc Pennington of Planet Gnome has written a short blog pondering and analyzing the available options as coders move towards high-level languages like java and C#. He gives a good overview and assessment of technologies like mono, OO.org's UNO framework, as well as other ways of tying new languages to the existing code base. An extremely interesting read for desktop linux hackers everywhere." Update: 03/17 14:44 GMT by T : Speaking of the future of Gnome, aeneas writes with a list of Gnome 2.6 release parties around the world (linked from gnome.org/start/2.5).

Blair16 writes "From OSNews -- Mono 0.30 has been released. This release includes four components at once: the Runtime and Software Development Kit, the Documentation browser, and the ASP.NET server with its Apache module. Packages for various distributions are also available from our download page. This is mostly a fine-tuning release: bug fixing and performance improvements are the major benefits, but new classes and new features are also included. See the rest of the notes for details."

Blair16 writes "From OSNews -- Mono 0.30 has been released. This release includes four components at once: the Runtime and Software Development Kit, the Documentation browser, and the ASP.NET server with its Apache module. Packages for various distributions are also available from our download page. This is mostly a fine-tuning release: bug fixing and performance improvements are the major benefits, but new classes and new features are also included. See the rest of the notes for details."

Blair16 writes "From OSNews -- Mono 0.30 has been released. This release includes four components at once: the Runtime and Software Development Kit, the Documentation browser, and the ASP.NET server with its Apache module. Packages for various distributions are also available from our download page. This is mostly a fine-tuning release: bug fixing and performance improvements are the major benefits, but new classes and new features are also included. See the rest of the notes for details."

H0ek writes "Seems Mono is still moving along in spite of the Novell purchase. They present a nicely comprehensive roadmap. You can read the official Novell press release if you're into that kind of nonsense. All I can say is, go Miguel! Don't let the Man get you down!"

msh104 writes "The Mono project just released a nice status update for Mono. They also preview a roadmap for what the future will be like. It's quite nice to read if you want to find out if writing .Net programs for Linux will have a future for you. The Mono roadmap is available here." And gibbon writes "The DotGNU Project announced the availability of the DotGNU 0.1 CD-ROM release. It runs on many platforms and the CD contains documentation, packages for GNU/Linux, FreeBSD and MS Windows. It is now possible to use the base class libraries and XML. System.Windows.Forms and the web services are coming along well, too. The announcement contains more information and download links."

Slashback tonight brings updates on the recent Google hiccup, LookSmart and the FBI's note-snooping in the Adrian Lamo case, as well as (at long last!) a list of the theaters whose seats will soon be smooshed for far longer than usual under the weight of those dedicated enough to sit through 10 hours of Lord of the Rings. Read on below for the details.

Microsoft thinks LookSmart looks less smart. securitas writes "Internet search company LookSmart was dropped by Microsoft's MSN service today. MSN has decided not to extend its licensing contract with LookSmart beyond January 2004. The news is devastating for LookSmart since, 'Microsoft accounted for approximately 65 percent of listings revenues, and all of LookSmart's licensing revenue in the second quarter of 2003,' according to a company press release not listed on LookSmart's site. The move comes after LookSmart recently launched its own Overture-style pay-per-click service and indicates Microsoft is close to launching its new search engine technology designed to unseat Google for the search crown. All of this is against the backdrop of acquisitions by rival Yahoo. More coverage at SearchEngineWatch and a Reuters mirror at CNN Money."

They could have fixed this if they'd googled for an answer ... powerg3 writes "This follow-up, explains the Google wackiness posted yesterday. Here's the quote from the Google Weblog: '...when a spam result comes up in a search, Google not only blocks the spam, but every result after it. This means that for searches where spam results manage to rise to the top, very few -- sometimes zero -- results will be returned....It's pretty amazing that such a serious bug made it past Google's tests. It will be interesting to see how quickly it's fixed.'"

Pardon me, mum, can I borrow your hard drive? AndreL writes "The Guardian has an update about the BBC's digital archive plans. They're considering using P2P technology to avoid bandwidth bottlenecks. The bad news: because of technical, financial, and legal problems nothing will happen until 2006 at the earliest."

Please arrive in costume if at all. KTecumseh writes "The list of theaters showing the extended editions of LOTR as been revealed. You can check out the list at the official website, and before you look, pray that you live somewhere close by to take advantage of this once-in-a-lifetime experience. For those that can not make the full 10-hour saga, they are also showing the first two extended additions on different dates, but who wants to miss out on an entire theater of sweaty LOTR fans."

Shamus Arrigan asks plaintively "There is no mention of these ticket sales in any other country. Does anyone know when and where these tickets will be sold at? (Canada especially)"

Wait, are you fellas press? Dangnabbit! ccnull writes "Good news from the inquest against hacker Adrian Lamo. According to a paragraph in a Washington Post column (buried about 3/4 of the way down the story), the FBI appears to be backing off from pursuing reporters' notes in the case. Relevant quote: 'A Justice Department official says the FBI agent "acted out of turn" by not seeking approval from the U.S. attorney's office in Manhattan and Attorney General John Ashcroft's press office. "The agent did not follow standard procedures," the official says. "We're just not going to pursue it. It is the policy of the Justice Department to exhaust all other means before seeking information from members of the media."'"

Eh, what's a few orders of magnitude? Grant hayes writes: "It seems the decimal point in the Mono story you ran is being a bit ambitious. We should be reading Mono 0.28, not Mono 2.8. Check the link below as well as links there to other Mono resources; I see 0.28 throughout." Here's the Mono site -- guilty as charged. Thanks for the correction.

mallumax writes "A new veriosn of Mono(2.8) has been released: Mono has now integrated SourceGear's webservice enhancements, and there has been a lot of improvement in XML, serialization and web services. Other features are new thread locking and ahead-of-time compiler optimisations. Check out the Mono website for more details." Congratulations are in order for the Mono team as well -- SourceGear was their first customer.

Gianluca Insolvibile writes "I plead guilty: I have always admired Microsoft's COM architecture and the relative simplicity that allows you to reuse already installed components to create even complex programs. And I have always been fascinated by the distributed nature of DCOM, which seemed to me much more graspable than complex monsters like CORBA and J2EE. While looking for equally expressive Open Source component technologies among GNOME and KDE, I was never able to find something fitting my needs (I never got into Bonobo deeply enough, though)." Read on to see how this led Gianluca to Juval Loewy's O'Reilly-published Programming .NET Components, and what he thinks of the book. Programming .NET Components author Juval Loewy pages 460 publisher O'Reilly rating 7.5 reviewer Gianluca Insolvibile ISBN 0596003471 summary An introduction to components-oriented development with the tools and services provided by the .NET framework

One day, I stumbled upon the mono and Portable.NET projects, which are trying to bring all the .NET stuff to the penguin platform. This was the main reason that convinced me to learn more on .NET: open specs, a component-enabling technology, the cross-platform mirage, a completely new (well, sort of) set of concepts to be grasped, and something which I could use both on Linux and on Windows.

Armed with these expectations, I decided to look for a good introductory text on the .NET framework focused on components development. Among the plethora of publications on the subject, I decided to stick with a publisher having a long and respectable tradition in Open Source related books. Among the herd of funny beasts that populate O'Reilly's catalog, I picked out a "land hermit crab," aka Programming .NET Components, by Juval Loewy.

Overview The book begins with a chapter giving a rationale behind component-oriented programming versus object-oriented programming, that is, interfaces versus inheritance. The second chapter shows how those concepts are reflected in the .NET Framework, briefly introducing the Common Language Runtime (CLR), the Intermediate Language (IL) and .NET Assemblies. The following three chapters deal with interface-based programming, objects lifecycle management and versioning, gradually introducing the underlying concepts and showing how they become concrete in the .NET framework (more specifically, by using the C# language). No formal introduction to C# language constructs is given, but if you are familiar with C++ or Java you will be able to follow the code snippets fairly easily.

Events and asynchronous code execution are the subjects of Chapters 6 and 7, respectively. While the former is just a quick introduction to the C# approach to delegates and events (yet useful if you are new to the matter), the chapter on asynchronous calls is much more substantial. The mechanics behind async calls are explained, together with pros and cons of using callbacks, BeginInvoke() and EndInvoke() calls, one-way methods, and so on.

Chapter 8 is devoted to Multithreading and Concurrency. Commonplace concepts like threads application and usage are explained, as always dressed with a bit of C# syntax. While such concepts are easily found in any multithreaded programming tutorial on the Internet, explaining them from the basics never hurts -- and prepares the reader to the most insidious traps of multithreaded programming. Synchronization appropriately takes a fair part of Chapter 8: automatic and manual synchronization provided by the .NET runtime environment are explained, together with the concepts of contexts and synchronization domains. This part is quite interesting, since it delves into .NET specific concepts which are quite new to programmers who had a happy Microsoft-less childhood (though they might not be so new to people who speak COM fluently). Other .NET threading related services (such as timers) are presented at the end of the chapter.

Chapter 9, devoted to object serialization and persistence, describes how live objects can be transformed (formatted) into a stream of bytes to be sent over a network channel, or stored on a persistent storage medium. This chapter lays the grounds for the exacting chapter on remoting, which follows immediately. Chapter 10 is the longest and most content-rich chapter of the book: first, the entire story of native processes, .NET app domains and assemblies is told. After reading it here, it won't look so confusing as before. Then, objects marshaling, remote callbacks, synchronization and activation modes are described, including client and server activated, single-call and singleton modes. Afterwards, the author gets to a global overview of the .NET remoting architecture, its basic building blocks (like proxies, transport channels and call dispatchers) and working mechanisms (like type registration and environment configuration). A reprise on objects sponsorship and leasing closes the chapter and completes the discussion on objects' lifecycle left pending in Chapter 4. Chapter 10 offers a lot of interesting cues, but unfortunately cannot dig deeply enough in the subject (after all, this is not a book on remoting). Many people (including Juval himself) recommend Ingo Rammer's Advanced .NET Remoting (APress) to learn more on the topic, but I have yet to get my hands on it.

Chapter 11 reprises the description of contexts in .NET, this time focusing on calls interception. The whole interception architecture is described with a fair level of detail and, as always, in a clear and understandable way. Context-agile and context-bound objects are described, as well as .NET and custom component services. While reading this chapter, you start understanding that contexts, app domains, call interception and remoting are tightly interwoven and that their full understanding is the real key to the exploitation of the .NET platform potential. Unfortunately, this is where the book leaves you alone -- but I strongly suspect that a full coverage of these topics would have required an entire book on its own.

The last chapter of the book deals with the .NET Security architecture, introducing the concepts of permissions, code groups and policies. Security administration is explained, both from a system configuration and a programmatic point of view.

What's to like What I liked most is the straightforward approach of the author in introducing the rationale behind components, components-based programming and their support in the .NET Framework: each concept is walked through step-by-step, instead of being presented in a complete working example with little or no explanation. Hence, you won't get working code on page 3 of the book -- instead, you will gradually learn how to write some.

Indeed, I found the description of awkward concepts like asynchronous calls, multithreading and remoting very clear, even for someone with no previous experience with .NET and C#.

I also consider a plus the broad experience the author has in the field, which shines through the many programming hints given, and in lots of references to concepts in COM which have an homologous in .NET.

I finally found the book to have the right balance between printed code and text (that is: do not fill hundreds of pages with code, I'll look at it online).

What's to consider Programming .NET Components is just an introductory book: it points you in the right direction toward components programming with .NET, but does not bring you very far. If you are really serious about learning .NET advanced topics, you will need a more specific tome to complement (or substitute for) this one.

More specifically, the 70 pages which cover remoting are just an introduction to the matter. The same applies to some of the most important concepts revolving around .NET (app domains, contexts, and the like).

Finally, despite the subtitle ("Design and Build Maintainable Systems using Components-Oriented Programming"), be warned that this is not at all a book on software design (components oriented programming is covered in just 15 pages).

The summary Reading the book goes without a glitch, thanks to a smooth writing style and a very structured approach to explaining concepts. Still, when I turned the last page of the book I felt that my understanding of components within the .NET platform was far from complete.

.NET Components Programming is quite fair to its title: it will teach you how to program components by using .NET constructs, but (apart from some quick notes here and there) it will not provide extensive coverage of components oriented design and development. If you are already familiar with .NET concepts and are looking for something shedding light on components programming, this book will not help you significantly. On the contrary, if you know something about components and want to start developing them into the .NET Framework, this will surely be an interesting read.

Table of Contents
Preface
Chapter 1. Introducing Component-oriented programming
Chapter 2. .NET Component-oriented Programming Essentials
Chapter 3. Interface-based Programming
Chapter 4. Lifecycle Management
Chapter 5. Version Control
Chapter 6. Events
Chapter 7. Asynchronous Calls
Chapter 8. Multithreading and Concurrency Management
Chapter 9. Serialization and Persistence
Chapter 10. Remoting
Chapter 11. Context and Interception
Chapter 12. Security
Appendix A. Interface-based Web-services
Appendix B. Custom Security Principal
Appendix C. Reflection and Attributes

You can purchase Programming .NET Components from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

miguel writes "Today Zoltan Varga announced that he got Eclipse running on Mono using the open source IKVM Java virtual machine for .NET by Jeroen Frijters. This is the first time a complete free software JVM implementation can run eclipse in a reasonable time. This runs with our latest Mono release. Mandatory screenshot"

miguel writes "Today Zoltan Varga announced that he got Eclipse running on Mono using the open source IKVM Java virtual machine for .NET by Jeroen Frijters. This is the first time a complete free software JVM implementation can run eclipse in a reasonable time. This runs with our latest Mono release. Mandatory screenshot"

miguel writes "Today Zoltan Varga announced that he got Eclipse running on Mono using the open source IKVM Java virtual machine for .NET by Jeroen Frijters. This is the first time a complete free software JVM implementation can run eclipse in a reasonable time. This runs with our latest Mono release. Mandatory screenshot"

Wojina writes "Microsoft has applied for a comprehensive patent on what appears to be the entire implementation of the .NET CLR (Common Language Runtime) and the framework APIs. Microsoft's CLR is an implementation of the CLI (submitted to ECMA for standardization). Does this bode ill for the Mono project? See the CNET News story." And a chaser: Nept points to this interesting Microsoft-funded .NET obfuscation project.

Caoch93 asks: "I recently read the Mono project's rationale and have found it compelling in the way it shows the Mono project as being the result of engineering concerns rather than concerns of siding with Microsoft. One thing that it has strongly bolstered in me is my belief that runtimes which interpret intermediary languages are going to play an increasingly important role in programming in the years to come, and it makes me wonder- should the open source community consider developing its own runtime (ala JVM or CLI) which would thus be totally open to the public? Currently, it seems like the options for a runtime are the JVM, which is still dominated by Sun with respect to its design future, and CLI, which is an ECMA standard but is critical to the Microsoft .NET platform. It would seem to me that having an open source runtime (and languages that compile to it) could be critical to moving with the times, and the freedom from proprietary influences would seem to be important to keeping such a system truly in the interest of its programmers. I don't know...is CLI already achieving this? I an ECMA standard enough, or is an ECMA standard really just codification of proprietary interests. If so, should the open source community consider its own itermediary language runtime...and what would be proper goals for such a project?"

ceejayoz writes "MSNBC has an interesting article about the Mono project, saying that the 'volunteer effort could oblige Microsoft to work with Linux'."

Miguel de Icaza writes "We have just released the new version of Mono the new version includes a working version of ASP.NET. The release includes a sample web server that "hosts" the ASP.NET runtime (it can be hosted anywhere, for instance in Apache, with mod_haydn). The web features of ASP.NET would not be very useful without the support of a backing database. The new version of Mono includes database providers for Oracle, MS SQL, Sybase, ODBC, OleDB, Gnome Data Access, SqLite, MySQL and of course, Postgres. The C# compiler is now 37% faster due to some nice optimizations on the JIT engine and in our class libraries. You can use it to develop GUI applications using Gtk#. Screenshots for mPhoto and the GUI debugger (which can debug both JITed apps and native applications). "

all-of-the-dot writes "Would you use an open-source implementation of the .NET Framework? Ximian's Mono project enables you to build .NET apps that run on Linux and Unix as well as Windows. Check out the story from .NET Magazine's interview with Miguel de Icaza, Ximian cofounder and CTO" Added to which, AirLace writes "The Mono project has just achieved full self-hosting on Linux. While the C# compiler, itself written in C#, has been able to compile itself since March, Mono can now compile its own complete set of class libraries too. This announcement closely follows the release of the Phonic media player, the first .NET application for the GNOME desktop."

Dre writes: "Today marks a special coincidence. First, Adam Treat released the initial version of Qt bindings for C#, which consists of 476 Qt classes converted to C#. The bindings work with the Mono compiler, runtime environment and class libraries, enabling a fully Open Source implementation of C# for Qt. While not yet ready for a real application, Adam has managed to write and execute a Hello World! program (screenshot). KDE bindings are on the drawing board. Shortly thereafter, Phil Thompson, Jim Bublitz and theKompany.com released KDE 2 and KDE 3 bindings for Python. Together with the Java, Objective C and C bindings in the kdebindings module, as well as the Ruby bindings, KDE is providing developers a broad gamut of application development languages."

thing12 writes "On Thursday Paolo Molaro announced that he had managed to build the MCS C# compiler using MCS. This is a big step forward for Mono, as it means that Mono is almost a self hosting environment."

thing12 writes "On Thursday Paolo Molaro announced that he had managed to build the MCS C# compiler using MCS. This is a big step forward for Mono, as it means that Mono is almost a self hosting environment."

Bob Smith writes: "Miguel just commited the last patch nessisary to get Mono's C# compiler to compile itself. After 7 odd months, MCS is now self hosting." jbarn adds: "Mono-list email is here."

Pnet Guy writes: "Portable .NET is a component of the dotGNU meta project to provide a CLI (ECMA standard) platform for free software. The project true to its name runs on a variety of platform including Linux,Hurd and Cygwin GNU systems. To avoid any legal problems Pnet has decided to go the hard way and bootstrap our compiler off gcc. Unlike Mono which uses microsoft's runtime to run their compiler. Our premier developer Rhys Weatherly has contributed 254,423 lines written since Jan 1, 2001. Which amounts to about 5000 lines per week which is phenomenal for any programmer. He is dotGNU's one-man army. So join him in celebrating his quarter billion lines of his code." Update: 12/27 02:41 GMT by T : Note that as many readers have pointed out, that's just like the headline says -- a quarter million lines, rather than billion. Some related links to check out include the dotGNU home page, the Southern Storm Software (Rhys Weatherley's shop, with Portable .NET information), Mono's page and Pnet's CVS repository.

Thanks to Dare Obasanjo for conducting this interview with [Miguel De Icaza], and sending it on to me. I've posted the interview below here - interesting answers, and very thorough. Well done, Dare.

Interview With Miguel de Icaza Bringing a component architecture to the UNIX platform

Summary
In this interview, Miguel de Icaza, the founder of GNOME and Ximian, talks about UNIX components, Bonobo, Mono and .NET.

By Dare (Carnage4Life) Obasanjo

Dare Obasanjo: You have recently been in the press due to Ximian's announcement that it shall create an Open Source implementation of Microsoft's .NET development platform. Before the recent furor you've been notable for the work you've done with GNOME and Bonobo. Can you give a brief overview of your involvement in Free Software from your earlier projects up to Mono?

Miguel de Icaza: I have been working for the past four years on the GNOME project in various areas: organization of it, libraries and applications. Before that I used to work on the Linux kernel, I worked for a long time on the SPARC port, then on the software raid and some on the Linux/SGI effort. Before that I had written the Midnight Commander file manager.

Dare Obasanjo: In your Let's Make Unix Not Suck series you mention that UNIX development has long been hampered by a lack of code reuse. You specifically mention Brad Cox's concept of Software Integrated Circuits, where software is built primarily by combining reusable components, as a vision of how code reuse should occur. Many have countered your arguments by stating that UNIX is built on the concept of using reusable components to build programs by connecting the output of smaller programs with pipes. What are your opinions of this counter-argument?

Miguel de Icaza: Well, the paper addresses that question in detail. A `pipe' is hardly a complete component system. It is a transport mechanism that is used with some well known protocols (lines, characters, buffers) to process information. The protocol only has a flow of information.

Details are on the paper:
http://primates.ximian.com/~miguel/bongo-bong.html [Dare -- check the section entitled "Unix Components: Small is Beautiful"]

Dare Obasanjo: Bonobo was your attempt to create a UNIX component architecture using CORBA as the underlying base. What are the reasons you have decided to focus on Mono instead?

Miguel de Icaza: The GNOME project goal was to bring missing technologies to Unix and make it competitive in the current market place for desktop applications. We also realized early on that language independence was important, and that is why GNOME APIs were coded using a standard that allowed the APIs to be easily wrapped for other languages. Our APIs are available to most programming languages on Unix (Perl, Python, Scheme, C++, Objective-C, Ada).

Later on we decided to use better methods for encapsulating our APIs, and we started to use CORBA to define interfaces to components. We complemented it with policy and a set of standard GNOME interfaces for easily creating reusable, language independent components, controls and compound documents. This technology is known as Bonobo. Interfaces to Bonobo exist for C, Perl, Python, and Java.

CORBA is good when you define coarse interfaces, and most Bonobo interfaces are coarse. The only problem is that Bonobo/CORBA interfaces are not good for small interfaces. For example, an XML parsing Bonobo/CORBA component would be inefficient compared to a C API.

I also wrote at some point:

My interest in .NET comes from the attempts that we have made before in the GNOME project to achieve some of the things .NET does:

• APIs that are exposed to multiple languages.
  
• Cross-language integration.
  
• Contract/interface based programming.
  

And on top of things, I always loved various things about Java. I just did not love the Java combo that you were supposed to give or take.

APIs exposed to many languages we tried by having a common object base (GtkObject) and then following an API contract and a format that would allow others to wrap the APIs easily for their programming language. We even have a Scheme-based definition of the API that is used to generate wrappers on the fly. This solution is suboptimal for many reasons.

The Cross-language integration we have been doing with CORBA, sort of like COM, but with an imposed marshalling penalty. It works pretty well for non inProc components. But for inProc components the story is pretty bad: since there was no CORBA ABI that we could use, the result is so horrible, that I have no words to describe it.

On top of this problem, we have a proliferation of libraries. Most of them follow our coding conventions pretty accurately. Every once in a while they either wont or we would adopt a library written by someone else. This had lead to a mix of libraries that although powerful in result implement multiple programming models, sometimes different allocation and ownership policies and after a while you are dealing with 5 different kind of "ref/unref" behaviours (CORBA local references, CORBA object references on Unknown objects, reference count on object wrappers) and this was turning into a gigantic mess.

We have of course been trying to fix all these issues, and things are looking better (the GNOME 2.x platform does solve many of these issues, but still).

.NET seemed to me like an upgrade for Win32 developers: they had the same problems we had when dealing with APIs that have been designed over many years, a great deal of inconsistency. So I want to have some of this new "fresh air" available for building my own applications.

Dare Obasanjo: Bonobo is slightly based on COM and OLE2 as can be gleaned from the fact that Bonobo interfaces are all based on the Bonobo::Unknown interface which provides two basic services: object lifetime management and object functionality-discovery and only contains three methods:

 
        module Bonobo {
                interface Unknown {
                        void ref ();
                        void unref ();
                        Object query_interface (in string repoid);
                };
        };

 

which is very similar to Microsoft's COM IUnknown interface which has the following methods

 
HRESULT QueryInterface(REFIID riid, void **ppvObject);
ULONG AddRef();
ULONG Release();
 

Does the fact that .NET seems to spell the impending death of COM mean that Mono will spell the end of of Bonobo? Similarly considering that .NET plans to have semi-transparent COM/.NET interoperability, is there a similar plan for Mono and Bonobo?

Miguel de Icaza: Definetly. Mono will have to interoperate with a number of systems out there including Bonobo on GNOME.

Dare Obasanjo: A number of parties have claimed that Microsoft's NET platform is a poor clone of the Java(TM) platform. If this is the case why hasn't Ximian decided to clone or use the Java platform instead of cloning Microsoft's .NET platform?

Miguel de Icaza: We were interested in the CLR because it solves a problem that we face every day. The Java VM did not solve this problem.

Dare Obasanjo: On the Mono Rationale page it is pointed out that Microsoft's .NET strategy encompasses many efforts including

• The .NET development platform, a new platform for writing software.
• Web services.
• Microsoft Server Applications.
• New tools that use the new development platform.
• Hailstorm, the Passport centralized single-signon system that is being integrated into Windows XP.

and you point out that Mono is merely an implementation of of the .NET development platform. Is there any plan by Ximian to implement other parts of the .NET strategy?

Miguel de Icaza: Not at this point. We have a commitment to develop currently:

• A CLI runtime with a JITer for x86 CPUs.
• A C# compiler.
• A class library

All of the above with the help of external contributors. You have to understand that this is a big undertaking and that without the various people who have donated their time, expertise and code to the project we would not even have a chance of delivering a complete product any time soon.

We are doing this for selfish reasons: we want a better way of developing Linux and Unix applications ourselves and we see the CLI as such a thing.

That being said, Ximian being in the services and support business would not mind extending its effort towards making the Mono project tackle other things like porting to new platforms, or improving the JIT engine, or focusing on a particular area of Mono.

But other than this, we do not have plans at this point to go beyond the three basic announcements that we have made.

Dare Obasanjo: There are a number of other projects that are implementing other parts of .NET on Free platforms that seem to be have friction with the Mono project. Section 7.2 of Portable.NET's FAQ seems to indicate they have had conflict with the Mono project as does the banning of Martin Coxall from the dotGNU mailing list. What are your thoughts on this?

Miguel de Icaza: I did not pay attention to the actual details of the banning of Martin from the DotGNU mailing lists. Usenet and Internet mailing lists are a culture of their own and I think this is just another instance of what usually happens on the net. It is definitely sad.

The focus of Mono and .NET is slightly different: we are writing as much as we can in a high level language like C#, and writing reusable pieces of software out of it. Portable.NET is being written in C.

Dare Obasanjo: There have been conflicting reports about Ximian's relationship with Microsoft. On one hand there are reports that seem to indicate that there may be licensing problems between the license that will govern .NET and the GPL. On the other hand there is an indication that some within Microsoft are enthusiastic about Mono. So exactly what is Ximian's current relationship is with Microsoft and what will be done to ensure that Mono does not violate Microsoft's licenses on .NET if they turn out to be restrictive?

Miguel de Icaza: Well, for one we are writing everything from scratch.

We are trying to stay on the safe side regarding patents. That means that we implement things in a way that has been used in the past and we are not doing tremendously elaborate or efficient things in Mono yet. We are still very far from that. But just using existing technologies and techniques.

Dare Obasanjo: It has been pointed out that Sun retracted Java(TM) from standards processes at least twice, will the Mono project continue if .NET stops being an open standard for any reason?

Miguel de Icaza: The upgrade on our development platform has a value independently of whether it is a standard or not. The fact that Microsoft has submitted its specifications to a standards body has helped, since people who know about these problems have looked at the problem and can pin point problems for interoperability.

Dare Obasanjo: Similarly what happens if Dan Kusnetzky's prediction comes true and Microsoft changes the .NET APIs in the future? Will the Mono project play catchup or will it become an incompatible implementation of .NET on UNIX platforms?

Miguel de Icaza: Microsoft is remarkably good at keeping their APIs backwards compatible (and this is one of the reasons I think they have had so much success as a platform vendor). So I think that this would not be a problem.

Now, even if this was a problem, it is always possible to have multiple implementations of the same APIs and use the correct one by choosing at runtime the proper "assembly". Assemblies are a new way of dealing with software bundles and the files that are part of an assembly can be cryptographically checksummed and their APIs programmatically tested for compatibility. [Dare -- Description of Assemblies from MSDN gloassary]

So even if they deviate from the initial release, it would be possible to provide assemblies that are backwards compatible (we can both do that: Microsoft and ourselves)

Dare Obasanjo: Looking at the Mono class status page I noticed that a large number of .NET class libraries are not being implemented in Mono such as WinForms, ADO.NET, Web Services, XML schemas, reflection and a number of others. This means that it is very likely that when Mono and .NET are finally released apps written for .NET will not be portable to Mono. Is there any plan to rectify this in the future or is creating a portable .NET platform not a goal of the Mono project? Similarly what are the short and long term goals of the Mono project?

Miguel de Icaza: The status web page reflects the classes that people have "requested" to work on. The status web page is just a way of saying `Hey, I am working on this class as of this date' to avoid code duplication. If someone registers their interest in working on something and they do not do something after some period of time, then we can reclaim the class.

We are on the very early stages of the project, so you do see more work going on the foundational classes than on the end user classes.

I was not even expecting so many great and talented programmers to contribute so early in the project. My original prediction is that we would spend the first three months hacking on our own in public with no external contributions, but I have been proved wrong.

You have to realize that the goals of the Mono project are not only the goals of Ximian. Ximian has a set of goals, but every contributor to the project has his own goals: some people want to learn, some people like working on C#, some people want full .NET compatibility on Linux, some people want language independence, some people like to optimize code, some people like low level programming and some people want to compete with Microsoft, some people like the way .NET services work.

So the direction of the project is steered by those that contribute to it. Many people are very interested in having a compatible .NET implementation for non-Windows platforms, and they are contributing towards filling those gaps.

Dare Obasanjo: How does Ximian plan to pay for the costs of developing Mono especially after the failure of a number of recent venture funded, Free Software-based companies like Indrema, Eazel and Great Bridge and the fact that a sizable percentage of the remaining Free Software based companies are on the ropes? Specifically how does Ximian plan to make money at Free Software in general and Mono in particular?

Miguel de Icaza:Ximian provides support and services. We announced a few of our services recently, and more products and services have been on the pipeline for quite a while and would be announced during the next six months.

Those we announced recently are:

• Red Carpet Express: a subscription service for those who want a reliable high speed access to the Red Carpet servers.
• Red Carpet Corporate Connect: We modified our Red Carpet updater technology to help people manage networks of Linux workstations easily and to deploy and maintain custom software packages.
• Support and services for the GNOME desktop and Evolution: Our latest boxed products are our way of selling support services for the various products we ship.

We have also been providing professional services and support for people integrating free software based solutions.

The particular case of Mono is interesting. We are working on Mono to reduce our development costs. A very nice foundation has been laid and submitted to ECMA. Now, with the help of other interested parties that also realize the power of it, we are developing the Mono runtime and development tools to help us improve our productivity.

Indeed, the team working on Mono at Ximian is the same team that provided infrastructural help to the rest of the company in the past.

Dare Obasanjo: It is probably little known in some corners that you once interviewed with Microsoft to work on the SPARC port of Internet Explorer. Considering the impact you have had on the Free Software community since then, have you ever wondered what your life would have been like if you had become a Microsoft employee?

Miguel de Icaza: I have not given it a lot of thought, no. But I did ask everyone I interviewed at Microsoft to open source Internet Explorer, way before Netscape Communicator was Open Sourced ;-)

Thanks to Dare Obasanjo for conducting this interview with [Miguel De Icaza], and sending it on to me. I've posted the interview below here - interesting answers, and very thorough. Well done, Dare.

Interview With Miguel de Icaza Bringing a component architecture to the UNIX platform

Summary
In this interview, Miguel de Icaza, the founder of GNOME and Ximian, talks about UNIX components, Bonobo, Mono and .NET.

By Dare (Carnage4Life) Obasanjo

Dare Obasanjo: You have recently been in the press due to Ximian's announcement that it shall create an Open Source implementation of Microsoft's .NET development platform. Before the recent furor you've been notable for the work you've done with GNOME and Bonobo. Can you give a brief overview of your involvement in Free Software from your earlier projects up to Mono?

Miguel de Icaza: I have been working for the past four years on the GNOME project in various areas: organization of it, libraries and applications. Before that I used to work on the Linux kernel, I worked for a long time on the SPARC port, then on the software raid and some on the Linux/SGI effort. Before that I had written the Midnight Commander file manager.

Dare Obasanjo: In your Let's Make Unix Not Suck series you mention that UNIX development has long been hampered by a lack of code reuse. You specifically mention Brad Cox's concept of Software Integrated Circuits, where software is built primarily by combining reusable components, as a vision of how code reuse should occur. Many have countered your arguments by stating that UNIX is built on the concept of using reusable components to build programs by connecting the output of smaller programs with pipes. What are your opinions of this counter-argument?

Miguel de Icaza: Well, the paper addresses that question in detail. A `pipe' is hardly a complete component system. It is a transport mechanism that is used with some well known protocols (lines, characters, buffers) to process information. The protocol only has a flow of information.

Details are on the paper:
http://primates.ximian.com/~miguel/bongo-bong.html [Dare -- check the section entitled "Unix Components: Small is Beautiful"]

Dare Obasanjo: Bonobo was your attempt to create a UNIX component architecture using CORBA as the underlying base. What are the reasons you have decided to focus on Mono instead?

Miguel de Icaza: The GNOME project goal was to bring missing technologies to Unix and make it competitive in the current market place for desktop applications. We also realized early on that language independence was important, and that is why GNOME APIs were coded using a standard that allowed the APIs to be easily wrapped for other languages. Our APIs are available to most programming languages on Unix (Perl, Python, Scheme, C++, Objective-C, Ada).

Later on we decided to use better methods for encapsulating our APIs, and we started to use CORBA to define interfaces to components. We complemented it with policy and a set of standard GNOME interfaces for easily creating reusable, language independent components, controls and compound documents. This technology is known as Bonobo. Interfaces to Bonobo exist for C, Perl, Python, and Java.

CORBA is good when you define coarse interfaces, and most Bonobo interfaces are coarse. The only problem is that Bonobo/CORBA interfaces are not good for small interfaces. For example, an XML parsing Bonobo/CORBA component would be inefficient compared to a C API.

I also wrote at some point:

My interest in .NET comes from the attempts that we have made before in the GNOME project to achieve some of the things .NET does:

• APIs that are exposed to multiple languages.
  
• Cross-language integration.
  
• Contract/interface based programming.
  

And on top of things, I always loved various things about Java. I just did not love the Java combo that you were supposed to give or take.

APIs exposed to many languages we tried by having a common object base (GtkObject) and then following an API contract and a format that would allow others to wrap the APIs easily for their programming language. We even have a Scheme-based definition of the API that is used to generate wrappers on the fly. This solution is suboptimal for many reasons.

The Cross-language integration we have been doing with CORBA, sort of like COM, but with an imposed marshalling penalty. It works pretty well for non inProc components. But for inProc components the story is pretty bad: since there was no CORBA ABI that we could use, the result is so horrible, that I have no words to describe it.

On top of this problem, we have a proliferation of libraries. Most of them follow our coding conventions pretty accurately. Every once in a while they either wont or we would adopt a library written by someone else. This had lead to a mix of libraries that although powerful in result implement multiple programming models, sometimes different allocation and ownership policies and after a while you are dealing with 5 different kind of "ref/unref" behaviours (CORBA local references, CORBA object references on Unknown objects, reference count on object wrappers) and this was turning into a gigantic mess.

We have of course been trying to fix all these issues, and things are looking better (the GNOME 2.x platform does solve many of these issues, but still).

.NET seemed to me like an upgrade for Win32 developers: they had the same problems we had when dealing with APIs that have been designed over many years, a great deal of inconsistency. So I want to have some of this new "fresh air" available for building my own applications.

Dare Obasanjo: Bonobo is slightly based on COM and OLE2 as can be gleaned from the fact that Bonobo interfaces are all based on the Bonobo::Unknown interface which provides two basic services: object lifetime management and object functionality-discovery and only contains three methods:

 
        module Bonobo {
                interface Unknown {
                        void ref ();
                        void unref ();
                        Object query_interface (in string repoid);
                };
        };

 

which is very similar to Microsoft's COM IUnknown interface which has the following methods

 
HRESULT QueryInterface(REFIID riid, void **ppvObject);
ULONG AddRef();
ULONG Release();
 

Does the fact that .NET seems to spell the impending death of COM mean that Mono will spell the end of of Bonobo? Similarly considering that .NET plans to have semi-transparent COM/.NET interoperability, is there a similar plan for Mono and Bonobo?

Miguel de Icaza: Definetly. Mono will have to interoperate with a number of systems out there including Bonobo on GNOME.

Dare Obasanjo: A number of parties have claimed that Microsoft's NET platform is a poor clone of the Java(TM) platform. If this is the case why hasn't Ximian decided to clone or use the Java platform instead of cloning Microsoft's .NET platform?

Miguel de Icaza: We were interested in the CLR because it solves a problem that we face every day. The Java VM did not solve this problem.

Dare Obasanjo: On the Mono Rationale page it is pointed out that Microsoft's .NET strategy encompasses many efforts including

• The .NET development platform, a new platform for writing software.
• Web services.
• Microsoft Server Applications.
• New tools that use the new development platform.
• Hailstorm, the Passport centralized single-signon system that is being integrated into Windows XP.

and you point out that Mono is merely an implementation of of the .NET development platform. Is there any plan by Ximian to implement other parts of the .NET strategy?

Miguel de Icaza: Not at this point. We have a commitment to develop currently:

• A CLI runtime with a JITer for x86 CPUs.
• A C# compiler.
• A class library

All of the above with the help of external contributors. You have to understand that this is a big undertaking and that without the various people who have donated their time, expertise and code to the project we would not even have a chance of delivering a complete product any time soon.

We are doing this for selfish reasons: we want a better way of developing Linux and Unix applications ourselves and we see the CLI as such a thing.

That being said, Ximian being in the services and support business would not mind extending its effort towards making the Mono project tackle other things like porting to new platforms, or improving the JIT engine, or focusing on a particular area of Mono.

But other than this, we do not have plans at this point to go beyond the three basic announcements that we have made.

Dare Obasanjo: There are a number of other projects that are implementing other parts of .NET on Free platforms that seem to be have friction with the Mono project. Section 7.2 of Portable.NET's FAQ seems to indicate they have had conflict with the Mono project as does the banning of Martin Coxall from the dotGNU mailing list. What are your thoughts on this?

Miguel de Icaza: I did not pay attention to the actual details of the banning of Martin from the DotGNU mailing lists. Usenet and Internet mailing lists are a culture of their own and I think this is just another instance of what usually happens on the net. It is definitely sad.

The focus of Mono and .NET is slightly different: we are writing as much as we can in a high level language like C#, and writing reusable pieces of software out of it. Portable.NET is being written in C.

Dare Obasanjo: There have been conflicting reports about Ximian's relationship with Microsoft. On one hand there are reports that seem to indicate that there may be licensing problems between the license that will govern .NET and the GPL. On the other hand there is an indication that some within Microsoft are enthusiastic about Mono. So exactly what is Ximian's current relationship is with Microsoft and what will be done to ensure that Mono does not violate Microsoft's licenses on .NET if they turn out to be restrictive?

Miguel de Icaza: Well, for one we are writing everything from scratch.

We are trying to stay on the safe side regarding patents. That means that we implement things in a way that has been used in the past and we are not doing tremendously elaborate or efficient things in Mono yet. We are still very far from that. But just using existing technologies and techniques.

Dare Obasanjo: It has been pointed out that Sun retracted Java(TM) from standards processes at least twice, will the Mono project continue if .NET stops being an open standard for any reason?

Miguel de Icaza: The upgrade on our development platform has a value independently of whether it is a standard or not. The fact that Microsoft has submitted its specifications to a standards body has helped, since people who know about these problems have looked at the problem and can pin point problems for interoperability.

Dare Obasanjo: Similarly what happens if Dan Kusnetzky's prediction comes true and Microsoft changes the .NET APIs in the future? Will the Mono project play catchup or will it become an incompatible implementation of .NET on UNIX platforms?

Miguel de Icaza: Microsoft is remarkably good at keeping their APIs backwards compatible (and this is one of the reasons I think they have had so much success as a platform vendor). So I think that this would not be a problem.

Now, even if this was a problem, it is always possible to have multiple implementations of the same APIs and use the correct one by choosing at runtime the proper "assembly". Assemblies are a new way of dealing with software bundles and the files that are part of an assembly can be cryptographically checksummed and their APIs programmatically tested for compatibility. [Dare -- Description of Assemblies from MSDN gloassary]

So even if they deviate from the initial release, it would be possible to provide assemblies that are backwards compatible (we can both do that: Microsoft and ourselves)

Dare Obasanjo: Looking at the Mono class status page I noticed that a large number of .NET class libraries are not being implemented in Mono such as WinForms, ADO.NET, Web Services, XML schemas, reflection and a number of others. This means that it is very likely that when Mono and .NET are finally released apps written for .NET will not be portable to Mono. Is there any plan to rectify this in the future or is creating a portable .NET platform not a goal of the Mono project? Similarly what are the short and long term goals of the Mono project?

Miguel de Icaza: The status web page reflects the classes that people have "requested" to work on. The status web page is just a way of saying `Hey, I am working on this class as of this date' to avoid code duplication. If someone registers their interest in working on something and they do not do something after some period of time, then we can reclaim the class.

We are on the very early stages of the project, so you do see more work going on the foundational classes than on the end user classes.

I was not even expecting so many great and talented programmers to contribute so early in the project. My original prediction is that we would spend the first three months hacking on our own in public with no external contributions, but I have been proved wrong.

You have to realize that the goals of the Mono project are not only the goals of Ximian. Ximian has a set of goals, but every contributor to the project has his own goals: some people want to learn, some people like working on C#, some people want full .NET compatibility on Linux, some people want language independence, some people like to optimize code, some people like low level programming and some people want to compete with Microsoft, some people like the way .NET services work.

So the direction of the project is steered by those that contribute to it. Many people are very interested in having a compatible .NET implementation for non-Windows platforms, and they are contributing towards filling those gaps.

Dare Obasanjo: How does Ximian plan to pay for the costs of developing Mono especially after the failure of a number of recent venture funded, Free Software-based companies like Indrema, Eazel and Great Bridge and the fact that a sizable percentage of the remaining Free Software based companies are on the ropes? Specifically how does Ximian plan to make money at Free Software in general and Mono in particular?

Miguel de Icaza:Ximian provides support and services. We announced a few of our services recently, and more products and services have been on the pipeline for quite a while and would be announced during the next six months.

Those we announced recently are:

• Red Carpet Express: a subscription service for those who want a reliable high speed access to the Red Carpet servers.
• Red Carpet Corporate Connect: We modified our Red Carpet updater technology to help people manage networks of Linux workstations easily and to deploy and maintain custom software packages.
• Support and services for the GNOME desktop and Evolution: Our latest boxed products are our way of selling support services for the various products we ship.

We have also been providing professional services and support for people integrating free software based solutions.

The particular case of Mono is interesting. We are working on Mono to reduce our development costs. A very nice foundation has been laid and submitted to ECMA. Now, with the help of other interested parties that also realize the power of it, we are developing the Mono runtime and development tools to help us improve our productivity.

Indeed, the team working on Mono at Ximian is the same team that provided infrastructural help to the rest of the company in the past.

Dare Obasanjo: It is probably little known in some corners that you once interviewed with Microsoft to work on the SPARC port of Internet Explorer. Considering the impact you have had on the Free Software community since then, have you ever wondered what your life would have been like if you had become a Microsoft employee?

Miguel de Icaza: I have not given it a lot of thought, no. But I did ask everyone I interviewed at Microsoft to open source Internet Explorer, way before Netscape Communicator was Open Sourced ;-)

Thanks to Dare Obasanjo for conducting this interview with [Miguel De Icaza], and sending it on to me. I've posted the interview below here - interesting answers, and very thorough. Well done, Dare.

Interview With Miguel de Icaza Bringing a component architecture to the UNIX platform

Summary
In this interview, Miguel de Icaza, the founder of GNOME and Ximian, talks about UNIX components, Bonobo, Mono and .NET.

By Dare (Carnage4Life) Obasanjo

Dare Obasanjo: You have recently been in the press due to Ximian's announcement that it shall create an Open Source implementation of Microsoft's .NET development platform. Before the recent furor you've been notable for the work you've done with GNOME and Bonobo. Can you give a brief overview of your involvement in Free Software from your earlier projects up to Mono?

Miguel de Icaza: I have been working for the past four years on the GNOME project in various areas: organization of it, libraries and applications. Before that I used to work on the Linux kernel, I worked for a long time on the SPARC port, then on the software raid and some on the Linux/SGI effort. Before that I had written the Midnight Commander file manager.

Dare Obasanjo: In your Let's Make Unix Not Suck series you mention that UNIX development has long been hampered by a lack of code reuse. You specifically mention Brad Cox's concept of Software Integrated Circuits, where software is built primarily by combining reusable components, as a vision of how code reuse should occur. Many have countered your arguments by stating that UNIX is built on the concept of using reusable components to build programs by connecting the output of smaller programs with pipes. What are your opinions of this counter-argument?

Miguel de Icaza: Well, the paper addresses that question in detail. A `pipe' is hardly a complete component system. It is a transport mechanism that is used with some well known protocols (lines, characters, buffers) to process information. The protocol only has a flow of information.

Details are on the paper:
http://primates.ximian.com/~miguel/bongo-bong.html [Dare -- check the section entitled "Unix Components: Small is Beautiful"]

Dare Obasanjo: Bonobo was your attempt to create a UNIX component architecture using CORBA as the underlying base. What are the reasons you have decided to focus on Mono instead?

Miguel de Icaza: The GNOME project goal was to bring missing technologies to Unix and make it competitive in the current market place for desktop applications. We also realized early on that language independence was important, and that is why GNOME APIs were coded using a standard that allowed the APIs to be easily wrapped for other languages. Our APIs are available to most programming languages on Unix (Perl, Python, Scheme, C++, Objective-C, Ada).

Later on we decided to use better methods for encapsulating our APIs, and we started to use CORBA to define interfaces to components. We complemented it with policy and a set of standard GNOME interfaces for easily creating reusable, language independent components, controls and compound documents. This technology is known as Bonobo. Interfaces to Bonobo exist for C, Perl, Python, and Java.

CORBA is good when you define coarse interfaces, and most Bonobo interfaces are coarse. The only problem is that Bonobo/CORBA interfaces are not good for small interfaces. For example, an XML parsing Bonobo/CORBA component would be inefficient compared to a C API.

I also wrote at some point:

My interest in .NET comes from the attempts that we have made before in the GNOME project to achieve some of the things .NET does:

• APIs that are exposed to multiple languages.
  
• Cross-language integration.
  
• Contract/interface based programming.
  

And on top of things, I always loved various things about Java. I just did not love the Java combo that you were supposed to give or take.

APIs exposed to many languages we tried by having a common object base (GtkObject) and then following an API contract and a format that would allow others to wrap the APIs easily for their programming language. We even have a Scheme-based definition of the API that is used to generate wrappers on the fly. This solution is suboptimal for many reasons.

The Cross-language integration we have been doing with CORBA, sort of like COM, but with an imposed marshalling penalty. It works pretty well for non inProc components. But for inProc components the story is pretty bad: since there was no CORBA ABI that we could use, the result is so horrible, that I have no words to describe it.

On top of this problem, we have a proliferation of libraries. Most of them follow our coding conventions pretty accurately. Every once in a while they either wont or we would adopt a library written by someone else. This had lead to a mix of libraries that although powerful in result implement multiple programming models, sometimes different allocation and ownership policies and after a while you are dealing with 5 different kind of "ref/unref" behaviours (CORBA local references, CORBA object references on Unknown objects, reference count on object wrappers) and this was turning into a gigantic mess.

We have of course been trying to fix all these issues, and things are looking better (the GNOME 2.x platform does solve many of these issues, but still).

.NET seemed to me like an upgrade for Win32 developers: they had the same problems we had when dealing with APIs that have been designed over many years, a great deal of inconsistency. So I want to have some of this new "fresh air" available for building my own applications.

Dare Obasanjo: Bonobo is slightly based on COM and OLE2 as can be gleaned from the fact that Bonobo interfaces are all based on the Bonobo::Unknown interface which provides two basic services: object lifetime management and object functionality-discovery and only contains three methods:

 
        module Bonobo {
                interface Unknown {
                        void ref ();
                        void unref ();
                        Object query_interface (in string repoid);
                };
        };

 

which is very similar to Microsoft's COM IUnknown interface which has the following methods

 
HRESULT QueryInterface(REFIID riid, void **ppvObject);
ULONG AddRef();
ULONG Release();
 

Does the fact that .NET seems to spell the impending death of COM mean that Mono will spell the end of of Bonobo? Similarly considering that .NET plans to have semi-transparent COM/.NET interoperability, is there a similar plan for Mono and Bonobo?

Miguel de Icaza: Definetly. Mono will have to interoperate with a number of systems out there including Bonobo on GNOME.

Dare Obasanjo: A number of parties have claimed that Microsoft's NET platform is a poor clone of the Java(TM) platform. If this is the case why hasn't Ximian decided to clone or use the Java platform instead of cloning Microsoft's .NET platform?

Miguel de Icaza: We were interested in the CLR because it solves a problem that we face every day. The Java VM did not solve this problem.

Dare Obasanjo: On the Mono Rationale page it is pointed out that Microsoft's .NET strategy encompasses many efforts including

• The .NET development platform, a new platform for writing software.
• Web services.
• Microsoft Server Applications.
• New tools that use the new development platform.
• Hailstorm, the Passport centralized single-signon system that is being integrated into Windows XP.

and you point out that Mono is merely an implementation of of the .NET development platform. Is there any plan by Ximian to implement other parts of the .NET strategy?

Miguel de Icaza: Not at this point. We have a commitment to develop currently:

• A CLI runtime with a JITer for x86 CPUs.
• A C# compiler.
• A class library

All of the above with the help of external contributors. You have to understand that this is a big undertaking and that without the various people who have donated their time, expertise and code to the project we would not even have a chance of delivering a complete product any time soon.

We are doing this for selfish reasons: we want a better way of developing Linux and Unix applications ourselves and we see the CLI as such a thing.

That being said, Ximian being in the services and support business would not mind extending its effort towards making the Mono project tackle other things like porting to new platforms, or improving the JIT engine, or focusing on a particular area of Mono.

But other than this, we do not have plans at this point to go beyond the three basic announcements that we have made.

Dare Obasanjo: There are a number of other projects that are implementing other parts of .NET on Free platforms that seem to be have friction with the Mono project. Section 7.2 of Portable.NET's FAQ seems to indicate they have had conflict with the Mono project as does the banning of Martin Coxall from the dotGNU mailing list. What are your thoughts on this?

Miguel de Icaza: I did not pay attention to the actual details of the banning of Martin from the DotGNU mailing lists. Usenet and Internet mailing lists are a culture of their own and I think this is just another instance of what usually happens on the net. It is definitely sad.

The focus of Mono and .NET is slightly different: we are writing as much as we can in a high level language like C#, and writing reusable pieces of software out of it. Portable.NET is being written in C.

Dare Obasanjo: There have been conflicting reports about Ximian's relationship with Microsoft. On one hand there are reports that seem to indicate that there may be licensing problems between the license that will govern .NET and the GPL. On the other hand there is an indication that some within Microsoft are enthusiastic about Mono. So exactly what is Ximian's current relationship is with Microsoft and what will be done to ensure that Mono does not violate Microsoft's licenses on .NET if they turn out to be restrictive?

Miguel de Icaza: Well, for one we are writing everything from scratch.

We are trying to stay on the safe side regarding patents. That means that we implement things in a way that has been used in the past and we are not doing tremendously elaborate or efficient things in Mono yet. We are still very far from that. But just using existing technologies and techniques.

Dare Obasanjo: It has been pointed out that Sun retracted Java(TM) from standards processes at least twice, will the Mono project continue if .NET stops being an open standard for any reason?

Miguel de Icaza: The upgrade on our development platform has a value independently of whether it is a standard or not. The fact that Microsoft has submitted its specifications to a standards body has helped, since people who know about these problems have looked at the problem and can pin point problems for interoperability.

Dare Obasanjo: Similarly what happens if Dan Kusnetzky's prediction comes true and Microsoft changes the .NET APIs in the future? Will the Mono project play catchup or will it become an incompatible implementation of .NET on UNIX platforms?

Miguel de Icaza: Microsoft is remarkably good at keeping their APIs backwards compatible (and this is one of the reasons I think they have had so much success as a platform vendor). So I think that this would not be a problem.

Now, even if this was a problem, it is always possible to have multiple implementations of the same APIs and use the correct one by choosing at runtime the proper "assembly". Assemblies are a new way of dealing with software bundles and the files that are part of an assembly can be cryptographically checksummed and their APIs programmatically tested for compatibility. [Dare -- Description of Assemblies from MSDN gloassary]

So even if they deviate from the initial release, it would be possible to provide assemblies that are backwards compatible (we can both do that: Microsoft and ourselves)

Dare Obasanjo: Looking at the Mono class status page I noticed that a large number of .NET class libraries are not being implemented in Mono such as WinForms, ADO.NET, Web Services, XML schemas, reflection and a number of others. This means that it is very likely that when Mono and .NET are finally released apps written for .NET will not be portable to Mono. Is there any plan to rectify this in the future or is creating a portable .NET platform not a goal of the Mono project? Similarly what are the short and long term goals of the Mono project?

Miguel de Icaza: The status web page reflects the classes that people have "requested" to work on. The status web page is just a way of saying `Hey, I am working on this class as of this date' to avoid code duplication. If someone registers their interest in working on something and they do not do something after some period of time, then we can reclaim the class.

We are on the very early stages of the project, so you do see more work going on the foundational classes than on the end user classes.

I was not even expecting so many great and talented programmers to contribute so early in the project. My original prediction is that we would spend the first three months hacking on our own in public with no external contributions, but I have been proved wrong.

You have to realize that the goals of the Mono project are not only the goals of Ximian. Ximian has a set of goals, but every contributor to the project has his own goals: some people want to learn, some people like working on C#, some people want full .NET compatibility on Linux, some people want language independence, some people like to optimize code, some people like low level programming and some people want to compete with Microsoft, some people like the way .NET services work.

So the direction of the project is steered by those that contribute to it. Many people are very interested in having a compatible .NET implementation for non-Windows platforms, and they are contributing towards filling those gaps.

Dare Obasanjo: How does Ximian plan to pay for the costs of developing Mono especially after the failure of a number of recent venture funded, Free Software-based companies like Indrema, Eazel and Great Bridge and the fact that a sizable percentage of the remaining Free Software based companies are on the ropes? Specifically how does Ximian plan to make money at Free Software in general and Mono in particular?

Miguel de Icaza:Ximian provides support and services. We announced a few of our services recently, and more products and services have been on the pipeline for quite a while and would be announced during the next six months.

Those we announced recently are:

• Red Carpet Express: a subscription service for those who want a reliable high speed access to the Red Carpet servers.
• Red Carpet Corporate Connect: We modified our Red Carpet updater technology to help people manage networks of Linux workstations easily and to deploy and maintain custom software packages.
• Support and services for the GNOME desktop and Evolution: Our latest boxed products are our way of selling support services for the various products we ship.

We have also been providing professional services and support for people integrating free software based solutions.

The particular case of Mono is interesting. We are working on Mono to reduce our development costs. A very nice foundation has been laid and submitted to ECMA. Now, with the help of other interested parties that also realize the power of it, we are developing the Mono runtime and development tools to help us improve our productivity.

Indeed, the team working on Mono at Ximian is the same team that provided infrastructural help to the rest of the company in the past.

Dare Obasanjo: It is probably little known in some corners that you once interviewed with Microsoft to work on the SPARC port of Internet Explorer. Considering the impact you have had on the Free Software community since then, have you ever wondered what your life would have been like if you had become a Microsoft employee?

Miguel de Icaza: I have not given it a lot of thought, no. But I did ask everyone I interviewed at Microsoft to open source Internet Explorer, way before Netscape Communicator was Open Sourced ;-)

An Anonymous Coward writes: "Bad Ximian. In this week's Infoworld opinion piece Nicholas Petreley points out how Ximian's .Net Clone, Mono, may very well be the "Destroy Open Source" Trojan horse that Microsoft has been desperately seeking. Thanks Nick for the wake up slap. We needed it." I don't understand how Ximian expects to succeed either. Lots of other companies have attempted to co-exist with Microsoft in a similar fashion, and they all lasted right up until the instant Microsoft decided to squash them.