Trolls

Thanks go out to Stormy Peters and Jo Shields for tweeting a link to Seth Godin's blog post entitled: Trolls. Had they not tweeted it, I likely would have missed these marvelous words of wisdom:

Lots of things about work are hard. Dealing with trolls is one of them. Trolls are critics who gain perverse pleasure in relentlessly tearing you and your ideas down. Here's the thing(s):

1. trolls will always be trolling
2. critics rarely create
3. they live in a tiny echo chamber, ignored by everyone except the trolled and the other trolls
4. professionals (that's you) get paid to ignore them. It's part of your job.

"Can't please everyone," isn't just an aphorism, it's the secret of being remarkable.

Thanks, Seth. I needed to be reminded of this fact.

And yea, Team Mono is remarkable ;-)

Looking Back: 10 Years of Ximian

Nat and Miguel both reflected on the incorporation of Ximian which has made me a bit nostalgic myself. I've only been with Ximian for about 9 and a half years, but they have been pretty awesome years! I'm very thankful for having had the chance to be a part of something great and for having been able to work with both Nat and Miguel, 2 of my heroes.

The things I respect most about both Nat and Miguel are their positive attitudes and energy. They both have an amazing ability to inspire the people around them to do great things, and we did. From Ximian Desktop and Evolution to Mono, Moonlight and SuSE Studio. Nat and Miguel have set out to change the Linux Desktop for the better, and I believe they (and we, together with the rest of the GNOME and Mono communities) have accomplished that. So congratulations Nat & Miguel on 10 years of Awesome(tm)!

Mono not Chasing Tail Lights

I've been on vacation and just got back and heard about this whole Richard Stallman spouting nonsense about Miguel being a traitor thing and saw that OSNews had an article criticizing Stallman for such ridiculous statements, so figured I'd skim the comments. Unsurprisingly someone attacked Miguel and Mono for "always chasing tail lights" which is a common logical fallacy that the anti-Mono folks love to argue, but in response there was, what I thought, a pretty good post by elanthis that rings fairly accurately as far as I remember events happening back in 2001 while I was at Ximian so figured I would quote it in order to share.

This "Mono is just chasing tail lights" crap is getting silly.

If you take Mono to mean "a project whose sole goal is to enable running Windows .NET apps on Linux" then yes, Mono will always be behind.

If you take Mono for what it actually is meant to be and what it is actually freaking used for, which is "a project that provides a clean, modern language on which to more efficiently develop and deliver Linux applications" then you realize that Mono isn't chasing anything, it's actually 20 steps _ahead_ of anything else on the Linux front.

If Microsoft came along and said, "we're going to assert some mythical patents and Mono can't be compatible with the ECMA CLR or class library anymore," Linux and Mono would not be devastated in the least by it. Mono would drop the offending bits and it would _still_ be a clean, modern language with a helluva-efficient runtime library providing a ton of brand-new non-Microsoft-derived Linux-focused APIs and libraries (from POSIX to dbus to GTK to OpenGL and so on) that real applications like Tomboy or Banshee or iFolder or MonoDevelop or Unity3D or SunUO or Landell and countless others can continue to be built on top of, taking full advantage of the features of C# (or even a "very similar to C#" language, if some change were forced on Mono by MS), the high quality Mono runtime implementation, and the quality APIs and tools developed by the Mono community.

There's no difference in theory behind a project like Mono and a project like Python, other than that Mono leisurely follows a language specification for the sake of being compatible __as a nice side benefit__ while Python just makes shit up as it goes. Oh, and Mono is way faster, has significantly better documentation, has better tools, and is already used in large-scale commercial apps (that have NO dependency on being Microsoft .NET compatible) despite having been around for a far shorter amount of time.

Honestly look around and see how many people try to use or even _care_ about using Mono as a way to run apps developed for Microsoft .NET. You just don't see it. Mainsoft makes a business out of making it easy to get ASP.NET apps running on Linux servers and that's about the end of it. All of the really cool users of Mono are people that are using it either because it provides a top-notch embeddable VM that blows away every other FOSS scripting engine (e.g., Unity3D) or because it provides some of the best APIs around for creating brand-new Linux-specific applications (e.g. Beagle).

The only people who are even remotely hung up on chasing Microsoft's taillights are the people who don't understand what the purpose of Mono is and use their misconception as a strawman argument against the Mono project.

Mono was conceived by the Ximian folks because of their experience with Evolution. They were writing big Linux desktop apps. Writing them in C sucked. Writing them in C++ sucked slightly less. Writing them in Python sucked far less in some ways and far more in other ways. Writing them in any FOSS-friendly language available was a nightmare. They saw C#. They saw it was like Java, except it fixed many of the things that sucked about Java. They thought, "it would be sweet if we had a language like that to develop in." They thought, "we could write a language like that to develop in." They thought, "we could write a totally new language, but then we have to solve a bunch of problems that have already been solved over and over and over" and they knew that good engineers don't waste time resolving old problems. They thought, "if we make a C# compiler and runtime for Linux, not only do we get what we want, but what the heck maybe it'll help bring more ex-Windows developers over to the Linux side and make the world a better place." And, instead of sitting around bitching about all the hard work other people are doing, they went ahead and made the project. Their lives got easier, the lives of quite a few Linux developers got easier, the lives of even a number of Windows developers got easier, and the regular users started seeing some cool software that none of the Linux developers were making pre-Mono because it was such a time-consuming pain in the ass to do it before, and Windows users even started seeing more cool software because now there was this awesome tool for embedding high-performance reliable easy-to-write scripts into larger applications which made the applications more awesome.

Everyone has won because of Mono, and because Miguel and the many other awesome contributors to Mono have done something FOSS never did before. The only thing the FOSS world has that even comes close to Mono is Java, and that was only just recently Open Sourced, and Sun's Java is actually already way behind Mono despite being far older.

So, seriously, quit with the taillight chasing crap. The Microsoft specification is largely irrelevant to just about all users of Mono, it's not even a priority for the Mono developers, and Mono has far surpassed anything else the FOSS community has in the same field.

C/C++ are a pain in the ass to work with and are light years behind modern languages in ease of use and features, and modern VM technology is already more or less on par with C/C++, and upcoming VM technology is quite likely to exceed the performance of C/C++. Python, Ruby, Perl, and so on are all great languages for some tasks but are total whores to work in for a great deal of other tasks, and they'll never be able to match Mono in speed (simple fact -- even if you implement the same VM technology in something like Parrot as you have in Mono, dynamic typing will always be slower; even if you use the same tracing optimizing JIT to compiler both C# and Python to machine code, the C# result will need far less type guards than the Python result would... which you can even prove by just using IronPython on Mono).

The point of Mono is NOT CLR compatibility. It's not even C# the language. The point of Mono is having a runtime and multiple languages that make developing real-world applications easy and making those applications more reliable, which frees up more developer time to work on actual features and performance rather than working on endless layers of complicated framework code or debugging stupid bugs that only exist because of poor language design.

As always, you have the typical know-it-alls who attacked the response saying that C# doesn't have many advantages over C++/Qt, but as usual, they neglect to consider the fact that not everyone wants to program using C++ or Qt.

As one of the developers involved in the development of Evolution, neither C++ nor Qt were tools that would have helped to solve our problems. First off, Evolution was a GNOME program (thus making Qt useless) and C++ was plagued with problems in those days. I'm also not sure that the C++ bindings for Gtk+ were even mature enough to use at the time. Even had these not been problems, none of us wanted to use C++ anyway.

Even today, with the surviving members of the original Evolution team now working on Moonlight (Chris Toshok, Larry Ewing and myself) which is partially written in C++, we have stuck with a very minimal subset and have gotten frustrated with a number of idiosyncrasies in C++ that were not a problem in C.

As a contributor to the Mono project (along with MonoDevelop and Moonlight), I feel that the Mono detractors are woefully uninformed and seem unwilling to educate themselves, but I guess that's their loss. The Mono Project will continue whether they call us traitors or not, whether they approve of the project or not, and whether they go on making fools of themselves across the internet or not.

We're not interested in childish popularity contests, we're interested in making great cross-platform development tools and making the Linux Desktop more inviting to a wider audience of both users and developers.

And we are succeeding.

QuakeLight in Moonlight

As we approach Moonlight 2.0 beta, more and more cool websites are starting to work under Moonlight. This week the team got QuakeLight working!

Here is a screenshot of QuakeLight under Moonlight in action:

Please note that there appears to be a bug in the version of Cairo that we embed into Moonlight which prevents the graphics from displaying on some NVidia and ATI cards (at least depending on which drivers you use?). It works fine on my Intel i965 graphics chipset, though.

There's also a bug where it runs out of file descriptors after a while (which I'll be looking into shortly since it crops up for DrPopper as well).

Stay tuned for more exciting updates!

Note: More information about QuakeLight (and GPL source code!) can be found at http://www.innoveware.com/quakelight.html

The Faux-pen Source Fundamentalists

I was just reading Linux-Mag's interview with Linus Torvalds with regards to Microsoft's latest GPL'd contributions to the Linux kernel.

In it, I found this fabulous quote from Linus which I think echoes David "Lefty" Schlesinger's latest blog posting about the The Real FLOSS Community and the "Faux FLOSS Fundamentalists":

I may make jokes about Microsoft at times, but at the same time, I think the Microsoft hatred is a disease. I believe in open development, and that very much involves not just making the source open, but also not shutting other people and companies out.

There are ‘extremists’ in the free software world, but that’s one major reason why I don’t call what I do ‘free software’ any more. I don’t want to be associated with the people for whom it’s about exclusion and hatred.”

It is good to see such prominent FLOSS contributors speaking out against the "Faux-pen Source Fundamentalists" that go around attacking the real FLOSS community members, even going so far as trying to get FLOSS developers/contributors fired.

These zealots may think they are "helping" the FLOSS community, but they are only having a negative effect. A destructive effect.

These people are not interested in improving Linux, they are only interested in stroking their own egos. They want power more than anything else. Power over other people. Power to destroy anyone or anything that does not do what they demand.

These people claim that they are protecting our Freedoms, but they are only trying to become dictators. They have no interest in Freedom unless it is their own version of Freedom, where they reign as supreme dictator and where anyone who disagrees with them is labeled as a "shill" or otherwise demonized.

As Linus puts it, these people are about "exclusion and hatred."

This is not Freedom.

Re: Let's All Say It Together.

I wasn't at the Gran Canaria Desktop Summit 2009, so I'm learning about this second hand from people like David Schlesinger, Natin Yellin and a number of people I know personally who attended the conference. It is important for us to respect all of our peers no matter their skin color, their religion or other beliefs, their gender, or any other factor. And that goes for respecting people outside of our community as well.

Because of this, I am casting my vote:

STOP sexism by Casey West. License:

"I want the [...] open source [...] communities [I participate in] to be a dignified, respectful, inclusive, and welcoming place. … We’ve all been witnesses to off-color jokes, misogynistic back channel chatter, questionable imagery and unnecessary, trolling comments. I pledge to do better to stand up and call this behavior out when I see it in conferences, online and other public settings. I don’t expect it to go away but I’m not going to tacitly condone it any longer."

(From Nick via Luis via David)
Update: As Natan Yellin has commented below, he was not actually at the conference - it was my mistake in thinking he was.

I am not afraid

Making GMime Even More Awesome

I've started working on GMime 2.6, which unfortunately will need to break API with 2.4 in order to achieve the next level of awesome.

If you use GMime (or are thinking of using it) in your project and have some suggestions on how GMime can improve, don't hesitate to fire an email off to gmime-devel-list@lists.gnome.org (preferably after subscribing to the mailing-list first).

These are my current plans:

• Replace all uses of g_signals with my own event stuff. None of this needs to be public and my events are a lot more performant. [ DONE ]
• Need to add a Changed event to GMimeHeaderList so that GMimeMessage can listen to changes in the toplevel mime_part's headers. When they change, we need to unset the cached header stream on the GMimeMessage. (see the "Note:" comments in message_write_to_stream and message_get_headers, while this hack works, it'd be nicer if we did it based on event callbacks)
• Get rid of GMimeSession and replace it with GMimePassphraseRequestFunc or something. See GpgMe's passphrase request callback signature for ideas. [ DONE ]
• Consider optionally using GpgMe so that we can support S/MIME?
• Consider GCancellable and GError for GMimeStreams and GMimeParser
• Add GIO-based GMimeStream and bump glib dep to 2.16 [ DONE ]
• Add a g_mime_part_get_best_content_encoding()? [ DONE ]
• Rename GMimeBestEncoding enum to GMimeEncodingConstraint? This might be a better name for the enum to reflect what it's actually meant for. Maybe also move it from gmime-filter-best.h to gmime-encodings.h?
• How about a g_mime_part_get_best_charset()? This one could be awkward since it depends on the content being UTF-8 text
• Should either rename g_mime_filter_best_encoding() to get_encoding() or else make sure that GMime.metadata 'fixes' the method name to be GetEncoding so that it will appear as a C# property getter.

Follow me on twitter

Over the past few months I'm having an even harder time motivating myself to actually make blog posts due to the convenience of microblogging on twitter.com, so this is just a note to say that if you are interested in the things I do or say, you might want to consider following me on twitter.

Building GMime in Visual Studio

Installing the Necessary Dependencies

First, install GNU's iconv library for Windows. You can get a nice msi installer from http://gnuwin32.sourceforge.net/packages/libiconv.htm. Unfortunately, they only offer a Win32 installer, so hopefully that's the platform you intend to target.

Next, you'll want to grab the GLib headers and libraries for Windows. The easiest way to do that is to go to http://www.gtk.org/download.html and download the All-in-One pre-built bundle for Win32. Once downloaded, extract the zip file (the docs suggest not using WinZip due to a bug) and place them wherever you want (I put mine into C:\Users\jeff\Documents).

Configuring Visual Studio

Now that the libiconv and glib headers/libraries are installed, you'll want to configure Visual Studio to know where to find those headers and libraries.

First, go to the Tools menu and select Options...:

In the Options dialog, expand the Projects and Solutions tree item and then select VC++ Directories.

Make sure Win32 is selected in the Platform option menu and then select Executable files under Show directories for:, like so:

Scroll to the bottom of the listbox and add the bin paths for your installed libiconv and Gtk+ bundle just like in the above screenshot.

After you've added the bin paths, you'll need to add the #include paths. Select Include files under Show directories for: and, like you did for the Executable paths you added above, add the paths to the include files.

Next, you'll need to ad the library paths. Under Show directories for:, select Library files and add the appropriate paths to the bottom of the list.

And that's it! You are now ready to start building GMime!

Note: I've been using Microsoft Visual C++ 2008 Express Edition which you can download for free from Microsoft.

GMime Ported to Windows

The other day someone asked me about GMime on Windows and I didn't have anything to tell her other than that I thought people had built it successfully on Windows but beyond that, I didn't have any sort of VS project files or anything.

Then, last night, she poked me again asking for advice about some of the problems she was having building on Windows (which were mostly removing extraneous unistd.h includes from files that didn't need them and dropping source files that required them).

After a short while of back and forth, I decided I'd just boot into Windows myself and she helped me get my system setup (installing GNU Libiconv, grabbing the Gtk+ Windows dev packages, configuring VS to know where to look for those headers/libs, etc) so that I could more easily get instant feedback as to whether my source changes fixed the compile errors.

After a few hours of #include fixage and slight reworkings of some unix-specific code, we had a successful build of GMime.dll, woohoo!

Taking Over the World

I've just been informed that Moonlight has made it into the following distributions: openSUSE (obviously), Mandriva, Ubuntu, Debian, Gentoo, and FreeBSD.

These are exciting times. One of the things that keeps me hacking on Free Software is the joy I feel when other people use my software because I know I'm helping to improve their Linux computing experience, even if only a little bit ;-)

On that note, Moonlight 1.0.1 has just been released the other day with fixes for the bugs people reported to us about the 1.0.0 release.

Jo Shields has also done the work to port Moonlight to ARM:

Update: Dieter has just informed me that Arch Linux also provides Moonlight packages in their distribution! Awesome, guys!

Text Layout Engines

As many of my loyal followers know, I wrote a really fast text layout engine for Moonlight 1.0 which was able to layout text in more-or-less a single pass over the string. Hard to do better than that, especially with my superbly (I'm allowed to stroke my own ego, right?) designed font/glyph caches.

That said, the code had also been superbly disgusting and unmaintainable. Made worse when I had to add hacks to render text selection (Silverlight 1.0's TextBlock is like a GtkLabel in that it just renders text, but Silverlight 2.0's TextBox supports editing and selection and so is therefor more akin to a multi-line GtkEntry widget).

Well, Thursday night, as I was watching House on Hulu, I had one of those "House moments" where he suddenly realizes what the patient is suffering from and how to solve the problem (usually when his friend, Wilson, is talking to him about something random).

I spent all day yesterday (and I mean all day, until 11pm last night) putting together my thoughts for a new design and working out the details and I think I now have a vastly improved solution that not only uses less memory in all but the pathological cases (I now use a UTF-8 string instead of a UCS4 string), but also doesn't require:

• a pass over the text to break on CR/LF to construct a list of text runs which were what the old TextLayout engine I wrote used instead of a char* (because the layout engine now handles CR/LFs)
• a whole new set of text runs every time selection boundaries change in a TextBox (because selection is no longer represented by text runs)

Of course, the same brilliance of the old design still apply: no need to re-layout when most text properties (underline, foreground, background, etc) change (obviously we still have to re-layout if font properties change because they change the metrics).

With my new design, my TextLayout class has a Select() method which allows the consumer to change the selected region of text. When you change the selection, my new logic can simply clear the cached glyph clusters for the affected area(s).

A "glyph cluster" is a cached (sub)run of glyphs in a particular text run. A "text run" is a substring of text that share all the same text attributes which does not span across line boundaries.

To break it down, a layout contains a list of lines. Each line contains a list of runs. Each run contains a list of glyph clusters.

Normally, a run will consist of only a single glyph cluster unless it overlaps the selection.

For example, if the first half of the run is within the selection, then the run will contain 2 glyph clusters (one for the selected portion and one for the non-selected portion). However, if the selection is fully contained within a single run but doesn't span the entire run, then it's possible to have up to 3 glyph clusters for that run: pre-selection, selection, post-selection.

The brilliance of doing it this way is that it simplifies keeping track of kerning between selected regions, so that as you drag your selection across some text, the text following your mouse cursor doesn't appear to "jump" to the left or right as you move between characters that are kerned.

More Exciting Updates on Mono/Android

Looks like Koushik Dutta has been kicking butt getting Mono onto Google's Android platform:

• Compiling Mono under the Android Build Environment
• Microsoft's DLR and Mono bring Python and Ruby to Android
• Mono/Dalvik Interop

Keep up the awesome hacking, Koushik!

Also of interest is his article on why JNI sucks compared to doing the same thing in .NET: JNI in Android (and a foreword about why JNI sucks)

I never actually used JNI back when I was doing Java development in school, so when people told me it sucked I just took their word for it, but always wondered just how bad it was. Now I know. All I can say is: Ugh.

Hopefully the Java community replaces JNI with something as clean and elegant as what we find in .NET.

Mono 2.0 Wins Developer.com's Product of the Year Award

I'd just like to congratulate the Mono team on their Product of the Year Award and for a job well done!

Congratulations guys, you deserved this award! You guys kicked ass this past year and we all get to benefit from your awesomeness.

Epic Weekly News for the week of Feb 8th

A lot has happened this week, in particular:

• Moonlight 1.0 goes live!
• Female FBI Agent Used Sex to Torture Mumbai Attack Suspect. Anonymous sources have suggested that video stream evidence will become available this weekend.
• Announcing Moonshine, the project never formerly formally known as Pornilus.

For those in the Cambridge/Boston area, we now give you a word from our sponsor:

Alleyoop 0.9.4 released

It's been ages since the last release of Alleyoop, but an update has finally arrived. I've just fixed up Alleyoop to build on openSUSE 11.1 (some libbfd stuff has changed, apparently) and so I've dropped the need for libbfd and libiberty completely. The code that used those libraries didn't really gain us any extra information that Valgrind wasn't already giving us anyway, so it as rather pointless.

It looks like a year and a half or so ago I fixed some parser bugs too and just never made a new release with those fixes.

So now Freedom Lovers who prefer a GUI can once again Valgrind their applications 'til their heart is content.

You can download the new Alleyoop 0.9.4 package here.

Oh, also, if there are any bored web developers out there, I'd appreciate it if someone could make a less-ugly website than what is currently at http://alleyoop.sourceforge.net. In case you couldn't tell, I'm horrible at website design.

As another fabulous example of my webdesign prowess, take a gander at GMime's website. So yea, that site could also use a make-over.

Update: Thanks to Akos Kemives for his improved website design for Alleyoop!

Epic Weekly News

A lot of cool stuff happened this past week:

• Mono 2.2 was released with the new SIMD and LinearIR optimizations
• Moonlight 1.0 was released
• Obama sworn in as the US President, streamed live via Moonlight
• ...and Linus Torvalds switches to GNOME

Watched Obama via Moonlight

Found out about Larry's, Aaron's, Rusty's, and Geoff's work at making a Moonlight 1.0 release that could view the Obama Inauguration this morning, so I absolutely had to use Moonlight today to watch it and it was great. Flawless.

Way to go guys!

Once again proving that the Mono team is unstoppable!

GO MONO! GO!

Moonlight TextBox

This past week I've been furiously hacking away on my reimplementation of the Silverlight TextBox control for Moonlight. I never realized just how much work goes into writing such a simple text-entry widget before this past week, even after having written Moonlight's text layout and rendering engine for the 1.0 release.

Keyboard input, keyboard navigation, keyboard selection, mouse selection & cursor positioning, key repeat, cursor blink, etc. The list goes on.

Most of it isn't hard, it's just time consuming.

At the same time, it's also fun in the sense that it's a new challenge for me to overcome (I love a good challenge). It makes you think a lot about designing for performance because you just don't know how much text you'll be rendering. It could be a short sentence or it could be an entire document, and the way you design your layout/rendering engine could mean the difference between taking 5 minutes to render or a fraction of a second.

GNU/Emacs font-lock suckage

For months now, my GNU/Emacs has decided to sometimes not syntax highlight my source or ChangeLog files and I didn't know why.

The other day, emacs' failure to syntax highlight xaml.cpp was the final straw. I decided enough was enough with having to M-x font-lock-fontify-buffer everytime I opened a handful of source files, especially ones that I often find need to edit and/or to refer to.

A little digging later and I discovered that GNU/Emacs must have added a feature that disabled font-lock (even if you've specified (setq font-lock-support-mode t) in your ~/.emacs) if the buffer was over some arbitrary size. Either that, or they lowered the arbitrary size to something ridiculously small.

The solution seems to be to add the following line to your ~/.emacs file: (setq font-lock-maximum-size 1000000)

Feel free to append a few more 0's to that number if you find that Emacs still fails to syntax highlight any of your source files.

Update: Another Emacs annoyance can be turned off by adding (setq inhibit-startup-message t) to your ~/.emacs file. I'm not sure why this isn't inhibited by default.