Miguel de Icaza's web log

Arrived to Bangalore

A very pleasant journey to Bangalore. At the lounge in Boston they had Champagne and Burritos:

Champagne and Burritos For the Traveling Connoisseur.

During the six hour layover in the Frankfurt airport, I did some low-hanging-fruit hacking: reduced MCS compilation times and memory usage a bit more. On the airplane I managed to get Gtk# using Cairo# which required fixing various Cairo# issues, and adding some custom features to Gtk#. Will check those in, once we decide on the new name for the `CairoState' object, which we currently call `Cairo.Object' which is just not right.

Barb wire, keeping someone out of something.

Planet Novell

Following the steps of PlanetGnome, Novell now has an aggregated service of Novell blogs at Planet Novell

Monodoc Editing

Added some helper buttons to assist the folks writing documentation with Monodoc, also we have now activated the Monodoc editing web service, so those users that are using Monodoc CVS are now able to send their contributions back from the GUI.

Our web service is running on Mono ASP.NET with the Apache2 module. For the curious, our web service is hosted here.

Posted by Miguel de Icaza on 29 Nov 2003

Going to Bangalore

Am taking a plane to Bangalore in a few hours. This trip is to meet with my colleagues at Novell/Bangalore who will be working in Mono (starting next week) and also to attend the Bangalore Linux Conference. Will be talking about Mono as a development platform, and meeting with some of the existing contributors to Mono and Gnome that have e-mailed me.

On my way back, am planning on stopping by Germany and Spain, but the exact dates and locations have not been sorted out yet.

The Mono team is in good hands, with a flury of activity on every corner: we are advancing quickly on completing the .NET 1.1 APIs for the Mono 1.0 release, and a few team members have been amusing themselves implementing features from the .NET 1.2 release.

As I write this, am migrating my album from my mPhoto software to Ettore's F-Spot photo management application (both written in C#, but Ettore has done a much better job than I did with mPhoto ;-).

Lastly, I have been playing with Cairo in Gtk#, and having a fun time using it from C#, it needs a bit of loving which am going to be doing on the airplane, and will have something to check in when I land in India.

Cool link of the day, comes from Brad Adams blog: http://broken.typepad.com/

Posted by Miguel de Icaza on 28 Nov 2003

Editorial Prize

My friend Mancha (Fernando Magari�os) worked for two years on and off doing the typography for a physics book in Mexico, and the book was just awarded the prize for the best typesetting, layout and editing in Mexico.

Mancha composed the book with TeX. Will post links when I have them.

Posted by Miguel de Icaza on 27 Nov 2003

Sun's Linux Desktop in China

Congratulations to Sun on getting the deal with the government of China. We are competitors, but still the software they are delivering is open source.

I know various of the hackers and developers at Sun that have worked hard on this: on Gnome, in OpenOffice and Java, and I am glad that their hard work is going to in such a large deployment.

A few years ago, we met with John Heard and Marco Boerries who were working on various angles of Sun on the desktop. It was back then that John had seen a future for Gtk+ as an ISV platform, and that Marco would bring up the idea of open sourcing StarOffice (which we have been very excited about contributing to). They wanted to see Gnome mature: and they were two important driving forces for the establishment of the Gnome Foundation. Through all these years of work, Sun has funded big parts of development of various components of the open source.

Despite all the criticism they get from Jonathan Schwartz quotes about Linux, Sun is a massive contributor to the open source pool. OpenOffice alone is a big chunk of functionality. But their daily involvement in Gnome 2 has been a pleasure to watch: they were the first to push Gnome to be fully accessible to comply with government regulations.

Anyways, good luck to our competitors. Tonight is a big win: at least 1.3 billion people will be running Evolution.

Royalty-Free Office XML file formats

Microsoft announced the specs for the XML markup for Office, and they are royalty free. The actual license text contains:

If you distribute, license or sell a Licensed Implementation, this license is conditioned upon you requiring that the following notice be prominently displayed in all copies and derivative works of your source code and in copies of the documentation and licenses associated with your Licensed Implementation:

"This product may incorporate intellectual property owned by Microsoft Corporation. The terms and conditions upon which Microsoft is licensing such intellectual property may be found at http://msdn.microsoft.com/library/en-us/odcXMLRef/html/odcXMLRefLegalNotice.asp?frame=true."

By including the above notice in a Licensed Implementation, you will be deemed to have accepted the terms and conditions of this license. You are not licensed to distribute a Licensed Implementation under license terms and conditions that prohibit the terms and conditions of this license.

It appears that the above *might* be incompatible with the GPL. It sounds like the BSD advertisement requirement. Further study is needed to really understand the issues.

Posted by Miguel de Icaza on 18 Nov 2003

Lessons from the PDC

Lessons from the PDC: (Article Permalink)

This is the long promised write-up of the PDC trip. It has taken quite some time to digest what was unveiled there.

At the PDC we saw the latest ways in which Microsoft has pushed the operating system beyond its roots into an advanced operating system; far more than the universe of read(), write() and poll() that Linux developers usually think of as being "the OS."

The PDC

Brady, Gonzalo, Lluis and myself went to the PDC, to check the latest product announcements related to the .NET Framework. We were in for a surprise. As I left the Boston airport, I confidently told Nat `Everything is under control, there will be some generics, some of this and some of that, will report back'.

I religiously sleep until noon, so waking up at 7am to attend the keynote conference was against possibly my most sacred principle. We had accumulated plenty of miles to be there and we were three hours behind Boston time, so I capitulated and was happily having breakfast at the conference center at 8am. By 8:10 I had already purchased a stack of books on ASP.NET 2.0, System.Xml 2.0, the new C# spec and the annotated CLI book. Me and the janitor were the only customers going through the books. For a second, the thought that the conference was empty crossed my mind, but the sales dude rapidly informed me that I had only 20 seconds to make it to the opening keynote. I ran.

The keynote

You probably have read about the keynote material everywhere by now. There were a few things announced:

There was a lot of wow-factor from the various demos as they were building them. They have this new file format called `Xaml' that is used to specify GUI layouts with XML. It was interesting that the demos were done with Emacs and VI. On one hand, they showed that there was no trick (or that these technologies were not `simplexity-based'), but on the other hand, I realized: they do not have a GUI builder for Avalon yet.

Xaml was particularly interesting, for Gnome people this is not news, but it is worth describing: the XML format binds the element names to .NET classes, and each one of the attributes maps to a property, so something roughly like:

<Window> <Button id="button" Background="Red"> <SimpleText>Hello</SimpleText> </Button> </Window>

The above gets translated with the XAML compiler into something like:

Window w1 = new Window (); Button button = new Button (); SimpleText s1 = new SimpleText ("Hello"); button.Items.Add (s1); w1.Items.Add (button);

So as you can see, pretty straightforward. Of course, the wow-factor comes when one of the attributes can be a video, and you can apply arbitrary Postscript-like transformations to the whole thing. Very much like Display Postscript-based systems, the MacOS or the venerable NeWS system (the difference being that Microsoft will drive this into every desktop, while the other systems never made it into the mass market).

One of the best moments of the keynote was the demostration by the guy from Amazon. They showed a beautiful GUI client, that was apparently fully written using Avalon in a month of work. I allocated a full 30 minute slot to a quest to reimplement it at home, and I can say with authority that 30 minutes are not enough.

During the next few days of the PDC, I attended the core CLR/.NET talks and the GUI ones; Gonzalo took on the ASP.NET ones and Lluis attended the Indigo talks. We met with Brady from the iFolder team at Novell, and he attended the WinFS talks.

The BOF

My friend Benjamin knew that the Mono BOF had not been approved by the INETA folks, so he invited me to talk a bit about Mono on his own BOF on Sunday, the title was `Microsoft and Academia' (this is when we patched the main program to mention Mono). I did a small 5-minute presentation on Mono, and got to meet a few folks after the presentation.

On Monday, it was clear that we needed to put together another meeting. People on the hallways were asking when we would have the Mono meeting. In particular Sami Jaber who was covering the event for DotNetGuru in France volunteered to announce a new venue, and guaranteed `At least the French contingent will show up'. So we pulled out our maps, and found a perfect spot for the event: the Foyer that connected two hallways in the LA Conventions Center. We announced it on the relevant sites, and relevant blogs, and went on with life. Picking a time for a BOF was hard: there were pleny of other activities every day, so we basically picked the dinner time.

The day of the event, we went to pick up the Ximian/Mono T-Shirts to the hotel, we had plenty of time: 30 minutes to the BOF, and the hotel was only a few blocks away. Of course, we did not plan for one of those mythical traffic jams to play a role, and we managed to walk back from the hotel carrying boxes of t-shirts and being embarassingly late by 30-minutes.

Sami was there, and we started to gather a small group of people, but once the audience identified the t-shirts, we got together a pretty large group. The group took over all the available seats in the foyer, probably sixty to eighty people, hard to estimate.

I did a tiny introduction to Mono, really small, and then the next 90 minutes we spent them doing questions and answers. I got to meet various Mono contributors and regulars from the list: Dave Bettin, Kral Fretch, Urs Muff and plenty of actual users that do not hang around on the list. Since the audience was very .NET-savvy, that made my job a lot simpler, and the questions were fantastic. I like this format more than the regular formal Mono presentation, but I realize that this group of people was unique.

The introduction was basically the first ideas on what Mono 1.0 should be. The introduction, plus some of the insight from further discussion became the Mono Roadmap.

We now need to work hard on that roadmap and deliver on it. It is going to be hard.

Layout

Both Windows.Forms and XAML do layout of their widgets with some engine. The main mistake of Windows.Forms was not copying the constraint-based system that Gtk uses, and the Gtk containers that Gtk uses.

In .NET 1.2 they have an attempt to fix this by introducing various new widget containers: grids (tables), flows (not available on Gtk, but never needed it) and a few others. The main problem is that you have to "attach" the containers to its parent before you can do anything with them. A step in the right direction, but too cumbersome to use.

Hopefully, Avalon will promote a different model, a more sane one.

Xaml and Avalon

During the event everything was demoed by using this new markup language. Of course, everything produced with it looks terrible. And the reason is simple, XML might be a nice replacement for a few lines of code, but doing GUI layout in code is always a boring, error-prone, and most of the time the results are of low quality.

Xaml was pitched as a way of splitting the work between a designer and a programmer, which has an element of truth to it, but in reality they need a good GUI designer for producing interfaces (very much like Glade is to Libglade in Gnome).

Xaml is just a markup language that wires CLI classes together, so although it was demoed as a GUI composition tool, it could be used to wire together other components as well. My guess is as good as everyone else: it was probably intended to be a decent serialization format. A definite improvement for those folks building round-tripping IDEs, since now they only have to parse one language, and a fairly easy one to parse as well.

Now, the Avalon components that can be wired up have been built on its entirety on a new rendering framework, one that seems fairly powerful: a PDF like 2D imaging system, with video playback integrated.

This leads me to my first prediction: the first generation of Avalon applications will:

This brings me to the next point: the Microsoft folks, realizing that Avalon turn the rest of the century on the return of the <blink> tag on steroids, they have produced a number of interesting documents and on their public UI talks, they not only made fun of themselves, but they also have visibly taken the Joel-on-Software usability pill, and they are talking about the same thing we have been talking about in Gnome: usability, simplification, consistency.

Building rich desktop applications with Xaml is very easy: things can begin as "prettier" web pages. You do not have to be a programmer to use Xaml, and if you are, you can add extra functionality, just like Javascript does for the Web.

This of course poses a threat for the open source desktop, more on this on the upcoming sections.

New XML File Formats

Jon Udell in his blog points out that there are various new XML formats coming out of Microsoft that have some ammount of overlap with exising technologies: Adaptive Flow Format instead of CSS; Windows Vector Graphics instead of SVG; WinFS schema definition language vs Xml Schema.

At least for the first two, I can understand why the engineers rolled their own. It might not even be a case of not-invented here, it was just that given their model, it was just simpler to follow this path.

WVG/SVG is the obvious case where it might be convenient to bend the rules of Xaml: interop in this area is more important than the minimal benefit of integrating with the CLR. This is just just like coping with JPEG or GIF files: it is just not worth changing them.

From the Mono perspective, it is still an early technology to implement, but it is definitely an area that we are studying and we are hoping to produce some implementation guidelines for the most courageous developers. The core Mono team is right now working hard in producing Mono 1.0, and we are not planning on working on it immediately.

Avalon appears to be a large beast. I am left wondering if this is why the Microsoft developers have been talking about reducing the number of APIs exposed. It might be a good idea.

It might be interesting to build a smaller Avalon, one that could run on smaller devices, and would consume less resources would be a fun project.

Xaml as an HTML replacement.

Xaml is HTML merged with the Desktop UI

Although Xaml seems to be only a cute idea, it is simple enough, and each one of the individual components are powerful enough that it is very likely that Xaml could replace HTML as a way of creating rich content on Windows platforms. It would leave out of the equation Linux, Solaris and MacOS.

For free software users this again becomes a problem, since we continuously face proprietary protocols and file formats as a limitation of our platform. A limitation that we have to address every step of the way. In the case of Xaml, it is not the lack of documentation or a proprietary protocol, it is just that it is intimately tied to the .NET Frameworks.

Using Mono we will be able to bridge this gap: if people produce XAML-based applications and content, we want to be able to render that, and to do it right, we will have to implement the whole stack.

Various components will make XAML an attractive authoring environment:

A lot of fun work lies ahead of us.

ASP.NET 2.0 and XML 2.0

The good news is that the ASP.NET team surprised everyone: ASP.NET was already simple, and they made it simpler, and they added much wanted features like master pages, many small controls that factor-in common functionality on web sites. My personal favorite: pre-compiled deployment of web sites.

The XML folks did not stay behind: there are many new features: XQuery appeared in the framework and the new XPathDocument.

The bad news for Mono are thatn ASP.NET has more than doubled in size since the 1.1 release and the features in XML are fairly large improvements. The good news is that we were starting to get bored with the existing class libraries: largely bug fixing was the major focus, this injects a lot of fun into the Mono equation again.

For instance, a group is already working on an early implementation of ObjectSpaces.

WinFS

The new storage facility to be available in Longhorn has some interesting features that have lead to lengthy debates in the Linux communities. WinFS will be released as part of Longhorn, so it will become available in 2006 and only to users that migrate to the new OS.

Brady explained to me WinFS, and his own project: iFolder 3.0. The features in WinFS will be available in Novell's own iFolder 3.0 by mid-next year. Both the workgroup client and the server will be open source offerings, and we plan on adding the same kind of GUI functionality that people saw at the PDC (the UI elements are being developed with .NET: Windows.Forms on Windows, and Gtk# on Unix).

iFolder is in fact one of the most interesting pieces of technology that Novell has been working on, and we hope to bring these features to Linux and Windows users (needless to say, before WinFS ships, and in more platforms than they will run ;-).

Some confussion still remains in the open source world about the inner working of the WinFS. WinFS does not replace the existing file system: it still uses it to store the actual bits of a file. WinFS basically is a layer that can extract interesting information from files when stored on it: the regular data goes into an underlying file system storage, and juicy metadata bits are extracted and recorded at this point. One possible use scenario of WinFS is to perform queries on the juicy information.

Jeroen and IKVM

Hacker extraordinaire Jeroen, the author of IKVM was also at the conference, and we got to hang around with him.

The Three Pillars

At this point you might have realized that the new three pillars of the new OS are:

More information on Indigo is available in Lluis' Indigo blog entry.

Closing remarks: A managed world.

Microsoft has taken another bold move in moving all of their new API development into .NET.

Not only are the new operating system features cool, but they have turned them into an API.

It is now our turn in the open source world to track these innovations, and expose turn applications into API providers.

It is important for Mono to continue its path (Note: we should do this in an orderly fashion, in peace if you will. Not screaming, waving our hands and banging our heads against the wall).

We have to leverage what is unique about Linux, iFolder, Gnome, Cairo, the VFS, our databases and expose those features to the managed world.

Mono needs to become a core feature of every application.

Posted by Miguel de Icaza on 13 Nov 2003

Chema Celorio, we will miss you

Chema Celorio, a good friend for the past four years died yesterday on a skydiving accident in Mexico City.

The Gnome folks might remember Chema for taking over gEdit, the Gnome Printing platform and later on managing the Ximian team in Mexico and the Ximian Desktop effort. He was became famous for being the #1 bug reporter to Gnumeric, and a close friend to everyone that met him.

He helped bring newbies by fueling the Gnome-Love project, a project, where developers would be hand-hold, and no question was too simple to be asked.

Chema was passionate about skydiving, technology and free software. He was preparing for a mexican record of skydiving in the upcoming weeks. We had dinner frequently when he was in town, and he would always ask the right questions, and make us laugh all.

Just two weeks ago Maria and I had him for dinner at home, and we taught him to cook crepes. We will miss him.

There is a skydiver's forum: in Mexico.

Chema was thinking about moving to Europe.

I have a few pictures I took from Chema, from Barcelona in September: here, here, here, here, here and here.

Nat has a picture of Chema last year at the Cave.

Nat comments

Posted by Miguel de Icaza on 10 Nov 2003

Mono Roadmap

My main work this the PDC was completing the Mono Roadmap and the list of things that I feel comfortable releasing in 1.0 form.

The roadmap is important to help people plan ahead of time. They now will be able to know what things we will support and when we will support them. Until now it was an open-ended question.

Mono 1.0 contains less features than expected. A short sample of what some people wanted: more platforms for the JIT, EnterpriseServices, WindowsForms, development tools and more stable database providers.

I debated for a long time what to do about Mono 1.0: should it be a full .NET 1.0/1.1 release, or should it be a subset of it? It is clear at this point that we wont be able to release a product if we wait until everything is done. Specially since .NET 1.2 with its big changes is going to be released very soon now.

Today, different assemblies in Mono have different stability levels, and I have decided that enough is enough: we will release the stable components and focus on making those rock solid in 1.0. In upcoming versions as components mature we can expand the offering.

A big motivating factor was the recent PDC conference. It is obvious that many hackers will want to work on the more fun new features, but if we jump into that bandwagon now, we will never have a usable release. So the roadmap helps to solidify the direction of the team, while keeping the doors open for those who want to try something new to work on.

The missing functionality in Mono can be divided in:

Some developers are already working in 1.2 features. For instance, the C# compiler has iterators and some generics support. Our runtime engine has some generics support as well, and we have got a few baby steps in ASP.NET done.

Linux Developers

Linux Developers: (Article Permalink)

A friend of mine at the Microsoft PDC conference who is an Independent Software Vendor (ISV) made a few observations: the continuous breakage of the Linux development platform is hurting them. Linux is still a small market compared to the Windows and Mac markets. In most cases, the revenue opportunities for the small and medium ISVs are too small to make a Linux port worthwhile, and when it is, the staffing requirements for maintaining and testing their software for a dozen of distributions and release versions quickly becomes a big burden.

In particular my friend complained about the a.out to ELF migration; Then the ELF libc5 to libc6 migration, and apparently the new version of libc6 breaks their application again. They still update their software, but older binaries distributed to the public stop working on new releases of the product. Internally I know that all those changes were needed for Linux, and also that it is possible for the Linux community to provide the backwards compatible packages. Although this is possible in theory, in practice these compatibility libraries are not shipped with the main distributions.

In his view, this is scaring off developers (both his customers and themselves), and he has noticed a decrease in the demand for their software on the Linux platform and an increase on the MacOS X platform. As an anecdote I would not worry much about it, but the problems he described resounded with what we have heard from customers.

I used to think that the worst offender in breaking working applications was Debian. Considering that the commercial distributions at least did an effort to make stable releases of their products, as opposed to the continuum of updates that Debian is. Supporting Debian as an ISV is just too hard: there is no way to release software that will be usable a few months down the line, and there its too easy for a Debian user to accidentally move from `stable' to their `bleeding edge' setups. But to these outsiders, Debian is not even on their radar: the support offered by the commercial Linux distributions is flaky compared to what they are used to from the Unix world and Windows.

At Ximian we had a similar experience: the Ximian Desktop was built, packaged and tested on a number of distributions (Debian was supported once upon a time for example). But as time went by the matrix of distributions that had to be supported kept on increasing, the small differences kept on creeping and we were not able to keep up maintaining and testing packages for all these combinations of Linux, let alone support them. And keep in mind that Ximian was a company commited and devoted to support Linux-based applications.

Note about Debian: it is clearly the choice for many free software enthusiasts and is very entrenched due to its deep community roots. Tools like apt-get help people try out the latest developments in the open source world with little effort, and their community commitment is fantastic, but is a very hard platform to support for an ISV.

As much as the free software community would like to see a fully open source system, with every conceivable tool and piece of software available as free software it will not happen in the short or medium term. After all these years of working for this cause, we know that many of these applications will just not materialize as free software: games, vertical applications, developer tools, educational software, just to list a few.

To make Linux a viable platform for mainstream desktop use our community needs to realize the importance of these third-party vendors and not alienate them. Having a stable API, and a stable ABI is very important for this reason. GNOME has learned this lesson and has strict commitments on ABI/API stability (thanks to our friends at Sun that pushed for this) and the XFree folks deserve the credit for making ABI compatibility across operating systems a reality for their drivers. Two good steps in the right direction.

And of course, part of the problem is that it is not fun to work on backwards compatible ways, nor is it fun to work when innovation is hampered by backwards compatibility. Proprietary software is not going away any time soon, and our community should start thinking about ways of co-existing with it, such that ISVs help our platform by enriching it with a larger software offering.

Red Hat has taken an active approach at providing an API-stable edition of Linux with their enterprise editions. It is good as a short-term solution, but it is not a long-term solution, nor a scalable one given Linux's varied offerings. We need to attack the problem at the roots: The culture of API stability needs to be assimilated by maintainers and developers.

Which brings me to Mono (funny how everything I think revolves around this topic). With Mono we are trying to keep things compatible with the .NET Framework: even when we believe we can do better, we avoid introducing incompatible changes. When we have new functionality, we encourage our developers to expose that new functionality in a new library, and encourage them to make it available also to .NET developers (System.Security/Mono.Security is the best example of this pattern).

We very much hope that Mono will become the standard development platform that developers are looking for: a platform that makes strong API/ABI commitments, supports older versions of the libraries and supports their products moving forward (in fact, .NET does provide this very functionality in the GAC). It is useful that the .NET 1.0 and 1.1 APIs are set in stone now, because we have a concrete goal to aim for, and developers will know that those APIs will be supported.

Also, the CLI makes binary compatibility easier to achieve. A lot of thought went into the VM and into the C# programming language to deal with versioning problems that arise during the natural life time of a component. On the VM side, it is possible to add new fields, new methods and rearrange them without suffering ABI breakage. This is possible because the .NET metadata preserves naming information and binary layouts are only computed on the target processor at installation or JIT time.

People sometimes focus on what would happen if Microsoft changes an API in .NET, how would that impact Mono? This is not as much as a problem, given Microsoft's commitment to keep binary compatibility; The major threat to Linux as a development platform is its own development model, mixed with the lack of understanding in many hacker circles that API and ABI binary compatibility are crucial.

Update: And of course if something like the Linux Standard Base would get a long way to make this happen, but it has never got a lot of buy-in from the actual distributions.

PDC Updates:

Still writing it up. Hold on ;-)

Posted by Miguel de Icaza on 04 Nov 2003

Back from the PDC

Am back in Boston from the PDC. Lots of improvements to the .NET Framework in the short-term, and some very interesting but still early work for the long term.

Will post all my notes on Monday, once I decompress.

Posted by Miguel de Icaza on 01 Nov 2003

This is a personal web page. Things said here do not represent the position of my employer.