Finkelstein in Toronto

Mark Pilgrim has a great follow up to his freedom-0 article.

Nemerle, C# and Anonymous Methods.

Spent some time this afternoon playing with Nemerle and their latest release.

Specially nice since now MonoDevelop supports Nemerle in the built-in editor.

My main problem is that I find it hard to think in any other way which is not the standard programming that I have grown up to do, maybe I need a hobby programming task to do. It will have to wait until we release Mono 1.0, right now things are busy.

My personal wish: I would like a C#-like scripting language myself. Sprinkle a few perlisms, rubyisms and pythonisms in there. Drop the class carcass.

A small patch I have been playing with in my copious spare time is one to turn all unresolved method calls in C# to a dynamic code translation. So basically:

  object a = new XmlDocument ();
  a.Load ("/tmp/a.xml");

ie, notice that the type of the variable is `o'. The downside: the runtime has to transform the incoming parameters to something that matches the call, you loose the compiler safety net, and its slower. But at least you can prototype quickly ;-)

I do not like the current implementation of anonymous methods, it really does not work in the presence of nested anonymous methods, so I have gone back to the drawing board and have now a new design for this internal chunk of the compiler that am a lot happier with. As soon as the beast compiles, I will upload a new patch.

The C# compiler also gained recently a new flag: -pkg:NAME which integrates pkg-config directly into the compiler. We are making the world a better place, one command line option a day.

Managed code is fast

Andreas, Ben and Paolo have been discussing moving existing code that we implement in C to the managed world, as our JIT is in some cases as good as the C compiler and the transition from managed to unmanaged is too costly: we can now move more code into the managed world.

The old gcc exceptions mechanism that the Mono JIT used for a long time to speedup calls into the unmanaged world is gone. It was too much of a support nightmare (gcc and libc would often be out of sync, rendering the optimization useless), and instead Zoltan has cooked up some ways to improve the transition cost on x86 and SPARC.

Ports

The PowerPC port got a big boost today with various fixes checked in from Paolo; Neale continues to update the S390 port and Zoltan has checked in some fixes to support Linux on the SPARC (in addition to Solaris).

We still need to support the Itanium and the x86-64 CPUs (if you have a good recommendation about a book on these platform, please mail me) as they are important platforms for SUSE.

Thread.Abort and File locking

Lluis completed this week the Thread.Abort implementation for Mono. Our old implementation had various issues if we aborted thread while we were in unmanaged code (since there was no way to clean things up). Lluis' new implementation now shuts down things properly.

Now this might seem like a problem that few people would run into, but the reality is that it happened a lot with people using ThreadPools, ASP.NET or WebRequests since all of them triggered a call to Thread.Abort, and the side effects were ugly: from assertions in the runtime, to hangs at program exit.

This fixes the last major reliability blocker problem we had for Mono 1.0.

Dick in the meantime implemented the locking functionality for Files, a feature that some people needed and that was not really there before.

Xslt Joshua and documentation

Joshua has checked in the tools to produce HTML out of Monodoc. Real men use Monodoc, but if you feel like giving up on your manhood, now you can browse uncompressed, not-as-beautiful, not-indexed classes ;-)

Marek. Martin. Raja

They are rapidly closing the last pending bugs in the MCS compiler, none of them are crucial, but we want to ship with as few bugs as possible in the compiler. At this point, we are no longer accepting large changes to the compiler (which also means that Anonymous Methods will just not make it into the 1.0 release, too bad, they were too cute).

Seth has raised some valid points on the patent problem, as it related to Mono.

A big problem with everyone raising potential patent problems with Mono is not that they are wrong in any way, but there are a few problems with it:

• Not using Mono in any shape or form is not a blank waiver against patents. That means that even if you choose to stick to your beloved C, Python, C++ or anything else, for any new software you write, you are likely to infringe on someone else's patents (or even the same ones that Mono could potentially infringe).
• Patents can be: declared void with prior art showing that such invention did exist in the past. Alternatively, you can route around it by using a different technique than the one described in the patent to provide the same feature (or something close) to avoid infringing on a patent.
• Most people have no idea of what a patent is, or how it works. The actual invention is the claims bit. Not the introduction, not the summary, not the background, not the references and not the drawings. They help in making the claims, but they are not the patent itself. If you want to play patent-lawyer on Internet, you should at least familiarize yourself with the process.

Now, it is hard to argue with the nay-sayers about routing around the patent for two reasons: we do not know what might be patented and valid (ie, no prior art can be found or properly articulated) and most importantly for any given topic we can engage in weeks of discussion on what-if scenarios.

We do not plan on infringing patents, and if were to infringe on patent, we will either find prior art that renders that particular claim invalid, or rewrite the code to work in a different form. We do not like software patents, but we will abide by the legal rules.

If you can not think of a different way of running a C# program than the one that exists today, you are not a very imaginative/innovative programmer. The worst possible scenario is not `They will stop distribution forever'. The worst possible scenario is `They can stop distribution until we find a workaround'.

And again, remember, the software patents problem is not limited to the specific instance of Mono. Everything Seth said applies equally well to every bit of our open source stack today: do we infringe on a Microsoft patent? Do *you* know for sure you do not? Have you performed a patent search? On every possible bit?

Red Hat has chosen to adopt Java (despite the same potential problems with patents) and has decided that it is in their interest not to use C#/Mono. Like Red Hat's Seth states: this is self inflicted damage on their part, and they will not be able to ship any of our leading edge GPL code (Simias, iFolder, F-Spot or any of our future development tools).

Red Hat could either stop whining, and have their developers work in Mono and use Mono, and help us fight bogus patents or route around them, or they can keep posting to their blogs more fear-mongering.

Andy Satori has posted his insight here.

If you are going to reply, I just ask you that you take a step back, and for every instance of the word `Mono' replace it with every major open source project today `gnu libc', `linux kernel', `Open Office', `samba', `x11', `cairo', `gtk+', `qt', `binutils', `gcc', gnome', `qt', `mozilla', `my favorite file system', use your imagination.

Does your foe have a patent to it? Or someone that can be acquired by your foe?

On Stop Energy: my policy

Most people operate in Stop Energy mode, so I typically ignore them, and keep moving.

A small story I like to tell people: when I started writing Gnumeric, I was very afraid of one thing: the computational engine. How do we recalculate the value of cells when a change happens? How do we make this perform well? How do we do iterative computations? How do you resolve recursive references?

All of those problems were fairly scary, and I did not have an answer to them. I looked at all the source code I could find for spreadsheets around that time, and none of it did even a remotely good job: it was all pretty amateur, and none of it really did anything remotely close to what commercial software did.

I started work on Gnumeric nonetheless, figuring `When the time comes, I will face that problem', and spent the next three months making sure that Gnumeric was visually pleasant, that it looked like Excel, and that the "feel" was right. I tried to implement computations trivially during that time in a couple hour hack and that failed miserably.

By the third month, I decided I would not touch a computer until I figured out an algorithm for doing these computations, I took a pencil and a notebook and went to write down the steps. Surprisingly after a few hours of work I had something that looked correct.

That same day I implemented the computational engine with the features I wanted and it just worked!

What I like about this story, is that I could have given up at any point since there was a large problem ahead of me: a problem I had no answers to. And I see this with many free software developers, students and even in normal social situations: people stop doing things because they see a big problem ahead of them that they can not possibly conceive working around. My advise to every young programmer is to start writing code and delay addressing imaginary problems until they become real.

I like people who find and propose solutions.

The Mono team (both the community and the Novell employees working on it) is pretty much such a group: a group solving problems, and moving forward.

Interview with a soldier

Ran into this interview this morning. From the Sacramento Bee.

Incidentally, watched For of War this week, McNamara at some point says `We need to win the hearts and minds of the Vietnamese people'.

Kristian Rietveld picked up on the challenge to write a WHIRL to CIL compiler. This means that any languages supported by the GCC WHIRL fork (C, C++ and the two Fortrans) could be used as compiler front-ends.

Kris has a sample of his work so far: a small C program translated to WHIRL (gcc), then to CIL (he had to write his own WHIRL reader.

Congratulations!

Sweet Interview with Nat Friedman

A sweet interview with Nat on the Novell Linux Desktop.

The JBoss soap opera

Man, I spent some quality time going over the JBoss soap opera. I always felt things were not quite right when I was reading TheServerSide.

Not everyone gets the importance of free software at once. To me the point of no return came when I was using non-Intel Linux machines, and could not run any of the new proprietary Linux software on the Alpha host we had.

The Movable Type licensing term changes have done the same for a new generation. Dive into Mark's Freedom 0 article rings true. The same kind of feeling we had when we started the Gnome project, we decided to not look away with something that was `free enough'.

After five months of delays, Massimiliano Mantione has joined the Novell Mono team. His focus will be on compiler optimizations.

As part of his interview process (which lasted a month), Massimiliano completed the arrays bounds check elimination feature for the JIT compiler. Now that he is part of the Novell staff he is redoing his work to match the current VM.

Mono Beta

Plenty of good feedback from the Mono Beta 1. Duncan has been taking care of the packaging things, and as of today we are shipping zip files with all the packages for those of you who did not want to manually download all of the packages one by one.

Novell has just open sourced the Evolution connector to Exchange. The code is available on our ftp server or you can browse CVS.

Congratulations to everyone involved!

Was reading Robert Fisk's latest article and googled for the keywords. Here is the shocking video.

Some cartoons, and a couple of interesting sites: Talking Points Memo and the Media Matters web site.

Jon Johansen's used Mono and MonoDevelop to build DeDRMS, a program used to decrypt the music you purchase from iTunes Music Store.

I tried it out, and I was able to play the music I had purchased on Linux, it is really nice.

Johansen was on the #mono channel, and we got a chance to look into some of the performance issues in Rijandel. Ben noticed something interesting: plenty of our array access was done with a byte value on an array that always had at least 255 elements. So he cooked up a patch that does said ABC elimination.

A more comprehensive patch has been cooked by Massimiliano (who joined Novell today to work on Mono) which hopefully will make it before Mono Beta 1.

Roadmapy things

A series of dates for the Mono 1.0 have been posted.

Jeff seems to like Cringley's statement of "The central point was that paying too much attention to Microsoft simply allows Microsoft to define the game. And when Microsoft gets to define the game, they ALWAYS win."

A nice statement, but nothing more than a nice statement, other than that, its all incorrect.

Microsoft has won in the past due to many factors, and none of them related to `Let them define the game', a couple from a list of many:

• They leveraged their monopoly to break into new markets. The most discussed one is when they used brute force and anti-competitive strategies to get their products into new markets, but in some other cases they got fairly good adoption of their products with little or no effort: just bundle it with Windows: MSN messenger, Media Player.

• Competitors were outmaneuvered or were incompetent (See HIgh Stakes No Prisoners).

• People were sleeping at the wheel.

  In 1993-1994, Linux had the promise of becoming the best desktop system. We had real multi-tasking, real 32-bit OS. Client and Server in the same system: Linux could be used as a server (file sharing, web serving), we could run DOS applications with dosemu. We had X11: could run applications remotely on a large server, and display on small machine. Linux quickly became a vibrant innovative community, and with virtual-desktops in our window managers, we could do things ten times as fast as Windows users! TeX was of course `much better than Windows, since it focuses on the content and the logical layout' and for those who did not like that, there was always the "Andrew" word processor. Tcl/Tk was as good as building apps with QuickBasic.

  And then Microsoft released Windows 95.

• A few years later, everyone is talking components: Netscape is putting IIOP on their client and server (ahead of their time, this later became popular as web-services on the browser); Xerox ILU; Bonobo; KParts; the Borland sponsored event to build a small component system that everyone agrees with; language bindings are at their top.

  The concensus at that time? Whatever Microsoft is doing is just a thin layer on top of COM/DCOM/Windows DNA which to most of us means `same old, same old, we are innovating!'.

  And then Microsoft comes up with .NET.

Does something like XAML matter? Not really. But it makes it simple to create relatively cute apps, by relatively newby users, in the same way anyone could build web pages with HTML.

Does Avalon really matter? Its a cute toolkit, with tons of widgetry, but nothing that we cant do on a weekend, right?

Does the fact that its built on top of .NET matter? Well, you could argue it has some productivity advantages, security features and get into a long discussion of .NET vs Java, but its besides the point.

Everyone is arguing about tiny bits of the equation `We have done that with Glade before!', `Gtk/Qt are cross-platform!', `We can get the same with good language bindings!', `We already have the widgets!', `Cairo is all we need', `What do users really want?' and of course `Dont let them define the game!'.

They are all fine points of view, but what makes Longhorn dangerous for the viability of Linux on the desktop is that the combination of Microsoft deployment power, XAML, Avalon and .NET is killer. It is what Java wanted to do with the Web, but with the channel to deploy it and the lessons learned from Java mistakes.

The combination means that Longhorn apps get the web-like deployment benefits: develop centrally, deploy centrally, and safely access any content with your browser.

The sandboxed execution in .NET [1] means that you can visit any web site and run local rich applications as oppposed to web applications without fearing about your data security: spyware, trojans and what have you.

Avalon means also that these new "Web" applications can visually integrate with your OS, that can use native dialogs can use the functionality in the OS (like the local contact picker).

And building fat-clients is arguably easier than building good looking, integrated, secure web applications (notice: applications, not static web pages).

And finally, Longhorn will get deployed, XAML/Avalon applications will be written, and people will consume them. The worst bit: people will expect their desktop to be able to access these "rich" sites. With 90% market share, it seems doable.

Will Avalon only run on Longhorn? Maybe. But do not count on that. Microsoft built IE4 for Windows 98, and later backported it to Windows 95, Windows 3.11 and moved it to HP-UX and Solaris.

The reason people are genuinely concerned and are discussing these issues is because they do not want to be caught sleeping at the wheel again.

Will this be the end of the world for Linux and the Mac? Not likely, many of us will continue using our regular applications, and enjoy our nicely usable and consistent desktops, but it will leave us out of some markets (just like it does today).

Btw, the Mozilla folks realized this already

[1] Although it was easy to see why .NET supported the Code Access Security (CAS) in .NET 1.0, there was no real use for it. With Longhorn/Avalon/XAML it becomes obvious why it was implemented.

Planning for the future

Although some of the discussion has centered around using a native toolkit like Gtk+/XUL to build a competitor that would have ISV sex-appeal, this is not a good foundation as it wont give us Web-like deployment (we need a stack that can be secured to run untrusted applications, and we need to be able to verify the code that is downloaded, which leaves us with Java or .NET).

The time is short, Microsoft will ship Avalon in 2-3 years, and they got a preview of the technology out.

I see two possible options:

• Implement Avalon/XAML and ship it with Linux (with Mono).
• Come up with our own, competitive stack.

I think someone will eventually implement Avalon (with or without the assistance of the Mono team), its just something that developers enjoy doing.

If we choose to go in our own direction, there are certain strengths in open source that we should employ to get to market quickly: requirements, design guidelines, key people who could contribute, compatibility requirements and deployment platforms.

We have been referring internally at Novell to the later approach as the Salvador platform (after a long debate about whether it should be called MiggyLon or Natalon).

We do not know if and when we would staff such an effort but its on the radar.

The patent issue

Are there patents in Avalon? It is likely that Microsoft will try to get some patents on it, but so far there are little or no new inventions on Avalon:

• Canvas graphics, persistent objects (Tk Canvas, Gnome Canvas)
• With AA/vector-based graphics (Gnome AA Canvas)
• With animation (Nautilus Andy-branch Canvas items)
• With Vector graphics (Gnome Print, librsvg)
• With A 2D graphics model (PDF, Libart, Cairo)
• With Web-like-Deployment security (SecureTcl, Tcl Plugin, Java)
• XAML has been done before (Glade, Qt designer), but am not sure that XAML is the best "authoring" model yet. The power lies in their deployment power.