Brad Abrams (one of the authors of the .NET Framework Design Guidelines, which PVanhoof really likes) invited me to share the stage at his keynote for ReMix 07 in Boston.

Oh the excitement!

After my last post, Matt Asay and myself exchanged a few emails regarding Novell and open source. And Matt posted a very nice follow up: "80% on Novell" on his blog about Novell and our involvement in open source, so some good came out of this:

Net net: I'm going to work on seeing Novell with less bite and more neutrality. It's admittedly very hard for me.

His post is difficult to quote without removing too much context and doing justice to it, so you should read it yourself.

Simon engadged in a lengthy discussion on my blog's comments on Google Group here and here.

We exchanged platitudes and concluded that patents are bad (shocking, I know) and that the "system" is far from optimal (second shock). We both agreed that Sticking it to the Man was a worthy goal.

Turns out that one of my favorite sites (Reddit) stored plain text passwords on a database. The reddit database recently was stolen, and now whoever stole it has all the passwords to reddit. The rationale for this was:

Personally, I prefer the convenience of being having my passwords emailed to me when I forget, which happens from time to time since I use difference passwords everywhere.

Not hashing was a design decision we made in the beginning, and it didn't stem from irresponsibility-- it stemmed from a decision to provide functionality that I liked.

It bit us in the ass this time, and we are truly sorry for it. The irresponsibility (and there is some) was allowing our data to get nabbed.

So the convenience of emailing a password when you forget it is what caused the developers to keep the passwords in the open.

Now, I do not particularly care if my reddit password is stolen. I have a policy of using a different password for every site that wants me to create an account with them. I use wildly different passwords for each site that I register with, so I manage to limit my exposure by limiting the damage to that particular site.

But many of my friends use combinations of "the same password everywhere" (specially the non-technical), "the password with the site name" (slightly more technical), "three tiers of passwords: weak, normal and high-security".

Everyone in those groups is vulnerable to have their password cracked open on other sites. Not good.

But the second realization that I had is that this practice is incredibly common. In the last month I have probably requested to "recover my password" from six or seven sites and at least two of them sent me back my original password. I remember thinkin "Oh, that is handy, am glad I did not have to go through a reset password process". Only now I realize that these sites are basically exposing my password to the world. This is not a phenomenon limited to reddit, it is incredibly common.

Here is a tutorial on how to implement this correctly on your web site: Don't let password recovery keep you from protecting your users. If you are using ASP.NET, the Membership infrastructure will take care of this for you.

Server folks also need to use stronger encryption mechanisms. As Jeff points out on his Rainbow Hash Cracking

You should use a differnet password for each site that you visit. Even if you knew the site you visit will not store the password in plain text (and there is no way of finding out) these days tools to crack passwords take advantage of available memory and disk space to crack stuff rapidly. See Jeff Artwood's Rainbow Hash Cracking post where he installs Ophcrack (open source software, available for most platforms) and cracks most "strong" passwords in a matter of minutes.

For dealing with one-password-per-site I keep a GPG encrypted file and use a script that Gonzalo wrote. Maybe its too simple, but it works (source is here).

Windows has a couple of tools that can keep your passwords encrypted. It would be nice if someone wrote a nice UI for this for Unix. The gnome-keyring is a step in the right direction, but the UI (gnome-keyring-manager) is not really designed for end users to use. It is more of a front-end to the password backend for the desktop.

We need to make this kind of tool pervasive on all of the desktop systems (and Mozilla remembering passwords is not enough to be practical).

Update: Jensen Somers in the comments points us to Revelation a tool for the Gnome desktop that does this.

Always loved Naomi Klein and today I found on reddit that Alfonso Cuaron did a short based on her latest book The Shock Doctrine. Am a fan of both.

The short-film is six minutes, and you can watch it here.

Last night Simon Phipps blogged about the Moonlight announcement.

It is funny to be lectured about software freedom from people that use MacOS computers as their main desktops instead of Linux. And to be lectured about whether implementing Moonlight for Linux or not is a good idea. If you smell an inconsistency here, is because its their trademark.

Simon is usually a sensible person, I met him at GUADEC a few years ago and I consider him a good friend and has a great reputation in the open source world for helping Sun open source Java. I have fond memories of hanging out at FooCamp and FOSDEM with him, so I was surprised about his post.

As I pointed out on his blog entry comments he made a number of mistakes on his analysis of the license.

He opens with the following paragraph:

I see Miguel is expecting flak for his initiative to implement Silverlight on GNU/Linux, and I'm sure he'll get it. The thing that caught my eye, however, was what terms I was asked to agree to if I as much as give Silverlight a try on any other platform in the ecosystem Miguel is helping create. Just take a look at the license agreement you're assumed to agree to if you so much as click the "Get Silverlight" button (yes, your acceptance is there in 4-point text in the Get... graphic). You will be agreeing you will not:

He is implying that Moonlight will be covered by Microsoft's EULA. This is not the case. Moonlight is released under a combination of LGPLv2 and MIT X11 licenses. I did bring this up on his comments, and Simon replied with:

Oh, and I didn't intend to imply Moonlight was equally tainted, I didn't think for a moment that you'd license it as anything but Free software and I think I made that clear in my first paragraph. My apologies if you thought otherwise.

I keep re-reading the original paragraph and it is very ambiguous to the point of leading to the confusion. The only point where he addresses this is several paragraphs later: "Miguel is encouraging you to surrender your freedoms if you're using the technology he promotes anywhere but the operating system he is working on. He's the lure for someone else's trap.".

Simon is concerned that using Silverlight on Windows comes with a bunch of requirements that are contrary to software freedom. But Simon, if you care about your software freedom, why are you using MacOS (or Windows) in the first place? If people care about that issue, they should switch to a fully open source system. And correct me if am wrong Simon, but since you link to a Mac license, I can imagine your main desktop is a MacOS machine (I vaguely remember that to be your main desktop; Why not OpenSolaris or Linux?), it seems like you have already surrendered your software freedom rights a long time ago.

And let me add, you can always port Moonlight to Windows. It is free software, remember?

His blog post is confusing, a commenter on Simon's blog points exactly that:

Just to let you know that I skimmed this post after it was linked on Louis' blog and got the impression that the points in the license that you raise are in Moonlight rather than Silverlight.

I didn't realize until I read Miguel's comment that this is not the case.

Of course, it is obvious on a second reading that you are talking about Silverlight. But I hope no-one else makes the same mistake as me, but worse does not realize it.

So one person is already confused. But it gets better. Pundit Matt Asay gets it wrong too (For those not familiar with Matt Asay, he is like the Robert Novak of open source punditry). He opens his own blog entry with:

Simon Phipps takes apart the licensing maze required to start "enjoying" Novell's Moonlight. Novell clearly wants to be popular with someone, and so has settled on Microsoft.

So Simon text is definitely obscure enough that pundits are making the same "mistake" I made when I read Simon's obscure blog post. On the other hand, it was pundits that got the US into the Iraq war, so we must cut the punditry circles some slack, we can not expect them to be scholars.

Now it is time to take exception at Matt's claim that:

Simon [...] takes apart the licensing maze required to start enjoying Novell's Moonlight"

No Matt, Simon did not explain anything about Moonlight, he was talking about Silverlight's EULA license, and while doing so, he managed to botch his analysis on several counts.

I am not in the business of defending Microsoft's EULAs, but in this case Simon tried to imply that we were covered by it. And well, Moonlight is not, as I said above Moonlight is under the LGPL/X11 licenses.

It seems that the EULAs for these proprietary plugins are pretty much all the same. As Stephen Walli pointed out on the comments for Simon, he is throwing rocks in a glasshouse, here are some EULAs that just as bad or worse as the Silverlight one:

• Java Binary Code License Agreement
• Adobe Acrobat
• Helix Player
• Flash Player.
• And since Matt Asay from Alfresco seems shocked at Silverlight's license (not Moonlight mind you), here are some Alfresco Terms. Most of the criticism from Simon applies equally well.

Silverlight terms are simpler to read than any of the previous five. This seems like an improvement.

When it comes to damages, a topic that Simon seems to care about as he writes: "that the limit of Microsoft's liability in any matter (including "internet services") is $5", here is the breakdown of the other EULAs:

• Acrobat: 50 dollars.
• Helix: 5 dollars.
• Silverlight: 5 dollars.
• Java: 0 dollars.
• Flash: 0 dollars.

And for good measure the GPL, LGPL and MIT X11 licenses put that at zero. So Acrobat, Helix and Silverlight are actually the most generous in this space.

I am not going to accuse Simon of double-standards, as he acknowledges in a comment that he would like to see those removed from Sun software as well:

As to glass houses: I expect there are Sun agreements that actually are a threat to software freedom, but it's my (and I believe Sun's) goal to eliminate as many of them as possible. By contrast, the Silverlight agreement is new, and its terms appear intended not just to protect Microsoft but to advantage them. I'm a bit surprised to find you making this apples-to-oranges comparison. I'm an easy target when I'm talking about what concerns me, but do you really believe there's no issue here?

I am not sure to what extend the EULA for Silverlight "its terms appear intended not just to protect Microsoft but to advantage them". Simon botched the analysis on most of his claims (including his statement about video and the MPEG-LA claim, he needs to read the (b) section).

So what we have is a case of exaggerated outrage over a silly license and for good measure a little bit of smearing of Moonlight by association.

Simon also complains that by accepting the license, "* that Microsoft can gather information about your computer and internet connection; * that they can automatically modify the software."

That is incorrect Simon. The license that you accept does not give Microsoft the right to gather the information (unlike the Java license that explicitly states that Sun can gather the information). In addition, Simon conveniently ignores the fact that the the Silverlight EULA states that you can opt-out from automatic-updates (see the license for yourself).

Finally, Simon's take on Mono:

I suppose this is just the same as my issue with Mono; that it's a trailing-edge implementation of an ecosystem that's intended by its architects to take away freedoms. That's what I'm reacting to.

Simon, that was uncalled for. Mono might be trailing behind Microsoft's APIs, but Mono has its own vibrant community and its own stack of open source libraries that are 100% independent of Microsoft's own stack based on the ECMA 335 core. You should know better than that. Mono is able to plot its own destiny and its own ecosystem on his own thank-you-very-much.

Matt Asay Shortsightedness

Matt Asay's bitter blog post misses the point as well, his argument of "position of strength" is a laughable one. Lets play, spot the inconsistencies (post your thoughts):

In other words, if someone is going to be Microsoft's toady, Novell wants to be darned sure it's them. It would be much better to command interoperability from a position of strength, as Red Hat is doing (or as MySQL is doing in databases, JBoss has done in application servers, etc.), rather than between mouthfuls of Microsoft's toejam.

Well Matt, we actually started on Moonlight without any management approval. All my bosses knew about our effort to implement Moonlight was that I requested a trip to Paris on June 21st ("Am going to accept this invitation to ReMix in Paris, the opportunity sounds priceless"). Nobody knew what my engineering group was cooking. And I for one had no expectations at that point to become a "toady", but I guess that is for a psychiatrist to figure out the day I get one.

So we are very excited that we turned our 21-day hackaton into a collaboration to productize Moonlight and to be able to bring Silverlight to Linux users.

To me, Moonlight is of crucial importance because I believe that Microsoft will be successful in getting Silverlight deployed in many sites, and as a Linux desktop user (unlike some outraged open source advocates that stick to OSX :-) I want to make sure that I have access to the Silverlight content from my Linux box.

And speaking of freedom and outrage, Simon you do not seem to mind surrendering your freedoms to Apple when you buy proprietary iPods and proprietary connectors, using the proprietary iTunes. And there are other mp3 players that are purely open source. Why are you using that instead of the purely open source Linux + Banshee?

You have the right to choose to iTunes, and others have the right to choose Silverlight. But of course people like to paint things in apocalyptic terms, more along the lines of "Will someone think of the children?". It may be funny, but only when its part of a Simpsons sketch.

It took real change inside Microsoft and Microsoft's internal organization to push for an agreement with Novell that would officially endorse Moonlight and would provide assistance of a kind that has never been seen between Microsoft and the open source community.

Moonlight will probably help Silverlight get adoption, and advance Microsoft's interest position in this space, but:

• From a pure technical perspective: Silverlight is the best of breed on this space. I like it, and it matches my opinions. Maybe not everyone's opinions, but mine and some others.
• As long as I can have my LGPL/X11 licensed code base, am more than happy for Silverlight to become another option on the Internet. Live and let live kind of scenario (Unlike others, I actually love Flash as well, and I love the open source efforts trying to create an open source version even more).
• Silverlight vs Flash vs JavaFX vs AIR is not a zero-sum game. Those who believe that have a strong scarcity mindset. I for one believe that the ecosystem will become richer by having more options. You know, competition, choice, options, styles.
  Just like on the server space source we have competing frameworks: django, rails, turbogears, asp.net and j2ee.

Am no fan of patents or patents lawsuits, but this lawsuit is going to provide some entertainment value for months to come.

It is quickly moving into "he said, she said" territory. NetApp claims that Sun started this thing when they approached NetApp to monetize some patents:

Like many large technology companies, Sun has been using its patent portfolio as a profit center. About 18 months ago, Sun’s lawyers contacted NetApp with a list of patents they say we infringe, and requested that we pay them lots of money. We responded in two ways. First, we closely examined their list of patents. Second, we identified the patents in our portfolio that we believe Sun infringes. With respect to Sun’s patent claims, our lawsuit explains that we do not infringe, and ---in fact--- that they are not even valid. As a result, we don’t think we should be paying Sun millions of dollars.

If this is true, Sun brought this upon themselves.

Of course, on the other hand, Sun claims that this was not the case:

Many of the claims raised in the lawsuit are factually untrue. For example, it was NetApp who first approached Sun seeking to acquire the Sun patents NetApp is now attempting to invalidate. It is unfortunate that NetApp has now resorted to resolving its business issues in a legal jurisdiction (East Texas) long favored by "patent trolls."

BURN!

And from Jonathan Schwartz:

NetApps first approached StorageTek behind the cover of a third party intermediary (yes, it sounds weird, doesn't it?) seeking to purchase STK patents. After Sun acquired STK, we were not willing to sell the patents, We've always been willing to license them. But instead of engaging in licensing discussions, NetApp decided to file a suit to invalidate them. To be clear, we never filed a complaint or threatened to do so, nor did anyone, to the best of my knowledge, in the ZFS community.

Sun also positions this as an attack on open source (since ZFS is under some open source license, the one that is incompatible with the Linux kernel GPLv2):

NetApp's legal attack against Sun's open source ZFS solution which is freely available in the marketplace is a clear indication that NetApp considers Sun technology a threat, and is a direct attack on the open source community.

So software patents suck, we all know that.

One one side, if there is any truth to NetApp's claim that Sun tried to monetize their patents by going on the offenseive this seems to be a case of Sun bringing this upon themselves.

NetApp could respond by issuing a patent covenant for users of open source operating systems (which would include Linux and OpenSolaris, but would still allow them to monetize from the Solaris uses).

Someone on Jonathan's blog raises a good point:

I find your comments contradictory.

"First, Sun did not approach NetApps about licensing any of Sun's patents and never filed complaints against NetApps or demanded anything." on the one hand, and "... we were not willing to sell the patents, We've always been willing to license them."

Can you please address the contradiction between "never demanded" and "always willing to license", Since "Willing to license" is usually simply a code word for "demanding payment for licensing."

If Sun's position that NTAP does not in fact violate the patents in question, and Sun does not violate NTAP's patents, why can't Sun affirmatively state that instead of leaving the issue unresolved?

Warmest Regards,
Max

That is one good question.

On the other side, perhaps NetApp has turned into a patent troll. And there are some indications from NetApp's blog. This is worrysome:

On the other hand, I won’t pretend that we would never have sued if Sun hadn’t approached us first. We focus on innovation as a company, and we do intend to defend our intellectual property.

[...]

Our interest is on commercial use of ZFS. That is, we are concerned with companies who take our IP and turn it into products that they make money on. For obvious reasons, we are especially concerned about commercial use of our IP that would compete with NetApp.

This seems to undermine NetApp's initial claim.

In the meantime, am buying POPC-orn shares, I predict this drama will have the same ratings as the second season of Lost.

Update: I have updated this post addressing some questions that people have raised over email and the group. The updates are flagged with an Update label.

Update: Scott Guthrie at Microsoft blogs about the news: updates to Silverlight 1.1, organizations adopting Silverlight 1.0 and links to various tutorials.

Today we are announcing a new collaboration with Microsoft around Silverlight. The Mono team at Novell will implement open source versions of Silverlight 1.0 and Silverlight 1.1.

Our implementation of Silverlight is Moonlight.

We have had a cordial relationship with many developers at Microsoft for quite some time. Scott Guthrie and Jason Zander provided us with informal advice on how to implement Moonlight, and we also have good relations with the open source teams working on IronPython and IronRuby.

Today we are formalizing a collaboration between Microsoft and Novell with the explicit purpose of bringing Silverlight to Linux and do this in a fully supported way. The highlights of this collaboration include:

• Microsoft will give Novell access to the test suites for Silverlight to ensure that we have a compatible specification. The same test suite that Microsoft uses for Silverlight.
• Microsoft will give us access to the Silverlight specifications: details that might be necessary to implement 1.0, beyond what is currently published on the web; and specifications on the 1.1 version of Silverlight as it is updated.
• Microsoft will make the codecs for video and audio available to users of Moonlight from their web site. The codecs will be binary codecs, and they will only be licensed for use with Moonlight on a web browser (sorry, those are the rules for the Media codecs[1]).
• Novell will implement Silverlight 1.0 and 1.1 and will distribute it for the major Linux distributions at the time of the shipment. We will offer some kind of one-click install for Linux users (no "Open a terminal and type su followed by your password..." as well as RPM and DEB packages for the major distros and operating systems.

This is an historical collaboration between an open source project and Microsoft. They have collaborated with other folks on the server space (Xen and PHP) but this is their first direct contribution to the open source desktop.

Microsoft benefits by making Silverlight reach the Linux and BSD spaces. We benefit by ensuring that users of open source operating systems get access to sites that adopt Silverlight to deliver content or spice up their web apps.

[1] Currently Moonlight video support has been prototyped using the fabulous and LGPLed ffmpeg engine for video and audio. We are unable to redistribute this code commercially due to licensing conflicts. Update: This means that individuals that want to use a 100% pure free software setup can do so. We are unable to redistribute this edition though.

The binary codecs will initially support x86 and x86-64, with other platforms supported on an as-needed basis. Update: The full list of codecs supported in Silverlight 1.0 are listed here (scroll down a bit).

Update: Some comments indicate that people would like to use GStreamer as the media backend (as GStreamer already has licensed codecs and some people might have purchased them already). We would be glad to merge any patches that people send us (copyright assignment required) to add support for GStreamer.

Update: Some folks are asking whether they could use OGG for the video rendering in Moonlight. Today this is already possible because the media engine we use to prototype is ffmpeg which has support for this. From the standpoint of a desktop developer this might be enough, but for the web, the problem becomes an issue of compatibility with the Microsoft Silverlight implementation.

We will bring up with Microsoft the issue of adding a new codec, but I suspect that since they are pressed to minimize the download size this might be difficult. There are other competing codecs though that people on the Silverlight groups are fairly vocal about and my eclipse our request. If you want official Ogg support from Microsoft, please bring this up on the Silverlight.net forums, Microsoft does listen to user feedback.

Update: The "Silverlights"

Update: There are two versions of Silverlight. The version released today (1.0) is basically a canvas that can be programmed through the browser's Javascript engine. ie, you can use "View Source" on your browser to see how everything is done.

The upcoming version (1.1, a year from now) extends the browser plugin with a embedded CLR runtime. This is what got us in the Mono team interested in the technology was precisely this.

Moonlight was originally designed to only implement 1.1, and only later we noticed that it was forwards compatible with 1.0 and that we could deliver both 1.0 and 1.1.

For developing 1.0 applications the only tool you need is either a text editor or a programming language that supports the "print" command. Designers are useful, but not mandatory (on Windows Blend supports Silverlight, and there might be others). We are building an open source designer ourselves for using on Linux.

If you want to take advantage of the features in 1.1, you will most likely want a .NET compiler and the Silverlight 1.1 libraries to link against. Our next release of Mono (1.2.6) contains a C# 3.0 compiler as well as the Silverlight 1.1 libraries that you can use to target Silverlight 1.1 using Mono on your favorite OS. Of course, with this setup you lose the ability to "View Source" as it now features compiled code in binary form (although if you really want to, you can just use Lutz's Reflector to look at it).

Today our plugin depends on Mono on both cases (1.0 and 1.1), but we are exploring our options to remove Mono from the 1.0 case as it would simplify our profiling and valgrinding of our C++ runtime (valgrinding Mozilla + Mono + Moonlight + a web site is a bit slow).

Working Well With Others

We will be supporting Firefox and Linux initially (that is our first goal).

But we are looking forward to work with developers from other operating systems (BSD, Solaris) and other browser (Konqueror, WebKit and Opera) to ensure that Moonlight works fine on their systems.

Thanks

Getting this collaboration in place took a lot of work on both ends: both the business and legal teams in both companies as well as various people inside Microsoft that endorsed the idea of having an independent implementation of Silverlight endorsed by Microsoft.

Special thanks to Bob Muglia at Microsoft and Jeff Jaffe at Novell for getting the official collaboration rolling.

Scott Guthrie, Bill Hilf and many members of his team that are transforming Microsoft from the inside out and have championed approaching the open source community. Brian Goldfarb made sure that the clock ticked and we got the agreement in place and Marc Jalabert invited us to demo Moonlight at the Paris ReMIX, which led to our 21-day hackathon. And everyone that has so kindly answered our questions on .NET and Silverlight and have championed us from the inside.

In the Novell side, Frank Rego, Denzil Harris, Patrick McBride and Guy Lunardi worked around the clock to get everything in place for this launch.

And of course, none of this would be possible without all the members of the Mono team that made our original proof-of-concept possible on June 21st and that have continued to work on all the various pieces that make up Moonlight possible.

Oh, by the way

We are hiring.

If you are a talented software developer with experience in C#, C++, graphics, fonts, audio, Mozilla, Opera, WebKit, QA, packaging or Gtk+ and you do not mind intense and grueling hours of work to produce something millions of people will see and use, send me an email.

Interviews with the Mono team are usually conducted over email and usually include a complicated and completely useless programming exercise that you complete at home.

Watching Moonlight in Action

If you are attending the IBC2007 conference in Amsterdam you will be able to see Moonlight in action at the Microsoft booth. Hacker extraordinaire Rolf Bjarne (of Mono's VisualBasic.NET fame) will be demonstrating Moonlight running on Linux at the show.

Alternatively, if you want to try out Moonlight yourself, you will need to follow the instructions on our Moonlight page. It currently requires users to compile code from our Subversion repository, we will try to put together in the next few weeks a VirtualBox/VMware image for people to try it out easily.

If you try it out, please report bugs here.

Recently we have been fine tuning Mono to render the Halo3 site:

Halo3 Site on Linux.

You can see more screenshots of Moonlight in action here.

Some folks have been asking what kind of interviews we conduct over email for hiring in the Mono team. We allow people to work remotely. To find out how well they can work independently away from our office we came up with some tasks that we give out on job interviews.

In my experience with hiring people at Ximian, the face-to-face interviews did not yield as good results as reviewing someone's existing track record and contributions or these programming exercises.

A resume, plus an interview when you ask the candidate to "implement XX on the whiteboard" and some trick questions have too many problems which are probably worth discussing some other day. In my experience these kinds of interviews that have been popularized in the industry are bad. They evaluate developers on all the wrong dimensions that you need to produce software.

Am posting here two of the interviews that we used in the past to hire for positions into the Windows.Forms group and the Mono VM engine. These interviews are typically conducted over two to three weeks.

A story that I find funny was when we did the Windows.Forms interview. Once I emailed back the applicants with the 2 week deadline, Andreia Gaita replied to me within 2 or 3 days. She was the first to reply, but thought that she was the last, and her code was great, did everything I requested (and if she gives me permission I can post her submission).

Andreia turned out of course to be a superb hacker, see her recent work on Mono/Mozilla integration.

The interviews follow.

These are not the interviews that we will use for Moonlight, but it will give you an idea of what kind of thing we do ;-)

Windows.Forms Interview

Remember: these interviews are designed to be answered at home during your afternoons when you get back from school/work and would usually take a few days.

* The Widget

    You must implement a small rendering engine for a small
    XML-inspired markup language, the language accepts:

    <p>...</p>    To start paragraphs.

    Paragraphs in turn can contain the following:

    <b>...</b>    Where the text ... is bolded.

    <i>...</i>    Where the text ... is italicized

    <link>...</link> Where the ... is rendered as a link

    <blink>...</blink> The text should blink.

        The control must expose one property:

        string Markup { get; set; }

    Which allows the developer to programatically set the markup
    language, for example:

          m = new MarkupControl ();
          m.Markup = "<p>Hello <b>World</b>!</p>";

    The control must also expose an event, so I can hook up
    whenever someone clicks on a link:

    delegate void LinkClicked (object sender, string link_text);

    So I can use it like this:

          m.LinkClicked += my_clicked;
      ...
        
      void my_clicked (object sender, string link_text)
      {
        Console.WriteLine ("The link {0} was clicked", link_text);
      }
                
    You must also provide a complete program that will run when I
    run it in Linux, and you must also exercise the property and
    the event, this would be nice to have:

      void my_clicked (object sender, string link_text)
      {
        Console.WriteLine ("The link {0} was clicked", link_text);
        ((MarkupControl) sender).Markup = "<p>This is the new text after clicking</p>";
      }

    Extra points: when I use blink, you will have to refresh,
    bonus points if you avoid flicker by using double buffering, or
    by only repaining the area that has changed. 

    I want a small and succinct implementation, but this is your
    opportunity to show that you can write *robust* code, so impress
    me.

* Trick Question

    In our corlib implementation, in System/DateTime.cs we have a
    suboptimal implementation of the method "TryParse", we basically
    call Parse inside try/catch.

    Explain:

        * Why do I say that our solution is "suboptimal"?

        * What would it take it to make more efficient?

        * Why did the maintainer that wrote that code not do
          the more efficient thing?

    The trick question is: Why was the faster process not done in
    the first place.

    Explain.
    

JIT Interview

This interview was constructed by Paolo Molaro when we were hiring folks for the JIT. The developers that joined us have been fantastic, Mark and Rodrigo. They are working in adding the CoreCLR security (I blogged about Mark's work before) and the verifier to Mono (which we will need for Moonlight) and have also been doing many other needed tasks on the VM.

    This interview should take a week to complete in your
    afternoons.  Between 8 to 16 hours for someone not familiar
    with Mono.

    We figured that not everyone has time to allocate to this
    immediately, so we will wait until March 30th to review the
    applications.

    All of this can be answered by using the officially released
    Mono packages from:

            http://www.mono-project.com/Downloads

    Get the mono-1.2.3.tar.gz source code download.

    Feel free to ask any questions privately or in any Mono public
    forums.

First Task: Extending the Mono VM

    Given the following program, change the mono JIT to intercept
    the Datum.Add () function and implement it internally with a
    SSE instruction so that the additions happen in
    parallel. Datum.Add () is to be treated like an intrinsic:
    this means that the JIT knows exactly what it's supposed to do
    and doesn't need to actually compile the IL code in it.

    Ie, you catch early on the call to Datum.Add (), there is no
    need to do any advanced compiler optimizations.  The current
    implementation here will be ignored once you have this
    implemented.

using System;

struct Datum {
    float f1; float f2; float f3; float f4;

    Datum (float val) {
        f1 = f2 = f3 = f4 = val;
    }

    void Add (ref Datum b) {
        f1 += b.f1;
        f2 += b.f2;
        f3 += b.f3;
        f4 += b.f4;
    }

    void Print () {
        Console.WriteLine ("{0}:{1}:{2}:{3}", f1, f2, f3, f4);
    }

    const int count = 100;

    static void Main ()
    {
        Datum[] array = new Datum [count];
        float f = 0.1f;
        for (int i = 0; i < count; ++i) {
                array [i] = new Datum (f);
        }
        for (int i = 1; i < count; ++i) {
                array [i].Add (ref array [i - 1]);
        }
        array [10].Print ();
        array [count - 1].Print ();
    }
}

Second Task: 

     Pick one of two:

        * GC Analysis

        * JIT and Generic Analysis

* GC Analysis.

    Given the description in:

        http://www.mono-project.com/Compacting_GC 

    and the implementation in 

                mono/metadata/sgen-gc.c

    describe briefly 3 changes to the GC code and/or JIT-GC
    interface that would provide a significant performance
    speedup. 

    Explain the changes, the reasons it will improve performance
    and provide rough speedup numbers with a benchmark of your
    choice.

* JIT and Generic Analysis

   Mono supports generics in its compiler and VM, this means that
   code like this is supported:

       class MyStack<T> {
               T [] storage;
               int top;

               MyStack ()
               {
                       storage = new T [10];
               }

               public void Push (T datum)
               {
                       storage [top++] = datum;
               }

               public bool Empty {
                       get {
                               return top == 0;
                       }
               }
       }

   If the above code is used like this:

       MyStack<object> object_stack = new MyStack<object> ()
       MyStack<string> string_stack = new MyStack<string> ()
       MyStack<int> string_stack = new MyStack<int> ()

   Explain:

       * When a generic class is instantiated, what pieces of
         code are shared?

       * Why they should be shared?

       * Are they shared in Mono?   

       * If yes, why?   If not, why not?

       * How could this be improved?

    

From Engadge's coverage, Steve Jobs apparently just said today:

"I love Jon Stewart, I hope all of you watch his show. It's the best place to get the news every day."

People living outside the US can watch Jon Stewart on the web. Highly recommended.

As part of the work that we are doing to implement Windows.Forms in Mono we needed to provide a WebControl that applications could use to embed a Web browser.

We needed a bit more control than the control that gtkmozembed offers. Zac Bowling started the work to wrap Mozilla and Andreia Gaita completed it:

See Andreia's post on wrapping Mozilla for use in Windows.Forms.

The public interface is Mono.WebBrowser which currently only provides access to Mono.Mozilla, but we envision that we will have other providers as time goes by (in particular our users on MacOS X with Windows.Forms).