I’m using a lot of conjecture in this first paragraph because the “news” about the decision appeared on the blogosphere before anywhere else. The first many Banshee or Tomboy developers read about it was reading a flurry of activity on the Tweetosphere from the anti-Mono activists declaring victory.

So first, a word on the cited reasoning.

Banshee works fine on ARM, since Mono works fine on ARM. Xamarin, the company behind most upstream Mono work, earns their income almost entirely from ARM versions of Mono, running on the varied ARM implementations found in smartphones. Every major Banshee release is personally tested on my Genesi EfikaMX, an ARM system with a Freescale i.mx51 processor. I’ve also demonstrated Banshee running in an Ubuntu chroot on my HP Touchpad, an ARM-based tablet. What is known is that Banshee has some problems running on Texas Instruments OMAP4 processors – the target ARM platform for Canonical’s ARM work. None of the Banshee upstream developers, Mono upstream developers, or Mono Ubuntu team has ever been able to reproduce the cited problems, since problems specific to an exact ARM chip are impossible to reproduce without the requisite hardware – and none of us owns an ARM system matching Canonical’s target.

That Banshee is still a GTK+2 app is true. A port to GTK+3 is almost complete, but blocking on a single technical bug deep within GTK#’s guts, which could be fixed by someone with sufficient knowledge of GTK+ semantics. Nobody with the required GTK+ knowledge has stepped forward with a fix at this point in time.

As for the final point, that Banshee is not well maintained, this seems like a directed personal insult against the active and responsive Banshee maintainer, Chow Loong Jin, and upstream bug triager David Nielsen, in addition to the immeasurable hours contributed free of charge for the benefit of Ubuntu users by various other members of related Mono app and library teams, including myself.

I need to stress at this point that my annoyance with this decision has nothing to do with the actual app changes. Keeping Tomboy and gbrainy, at a cost of about 25 meg of unsquashed disk space, is a hard argument to make compared with those two plus Banshee for 40 meg. Dropping gbrainy and Tomboy, and switching to Rhythmbox, will save about 30 meg of unsquashed space, all told.I’m unconvinced that Rhythmbox is a technically superior app to Banshee – several features which were gained by the first app swap will be lost again – but that’s another long tedious argument to be had. No, what has me deeply angered is the shambolic way the changes were made and announced.

Significant accommodations were made by Banshee upstream in order to make life easier for Canonical to integrate Banshee into their OS. For one thing, that’s why the Ubuntu One Music Store support is a core Banshee feature, not part of the third-party community extensions package. If Banshee was being considered for replacement due to unresolved technical issues, then perhaps it would have been polite to, I don’t know, inform upstream that it was on the cards? Or, if Canonical felt that problems specific to their own itches required scratching, then is it completely beyond the realm of possibility to imagine they might have spent developer resources on bug fixing their OS and sending those fixes upstream? Or even – and call me crazy – providing access for upstream to specialized hardware such as a $174 Pandaboard to empower upstream to isolate and fix unreproducible bugs specific to Canonical’s target hardware?

And here’s where it gets more astonishing for me – Canonical paid money to ship one of the community-based packagers responsible for the stack, Iain Lane, to Orlando for UDS, and didn’t think it was worth bothering to perhaps inform him “hey, the stuff you work on is in danger of being axed from the default install, maybe you should go to this session”.

So I’m not cross that the stuff I work on has been removed from the default install. I intend to continue working on it as I have for the last 4 years, through my work in Debian. No, why I’m cross that I heard about it from fucking Boycott Novell.

Regardless of your opinions regarding Banshee or its stack, if you read the above and don’t see it as an abysmal failure of community engagement by a company whose community manager wrote a book on the damn topic, then there’s something seriously wrong with your understanding of how community labour should be seen as a resource. Maybe someone at Canonical should try reading Jono’s book. It’s not a first-time offence, and this mail from a PiTiVi developer regarding changes in 11.10 makes for useful further reading.

[edit] There is some worthwhile discussion going on on the ubuntu-desktop mailing list covering the technical issues surrounding the decision, I would suggest it’s a good place for ongoing technical discussion.

This happens because every version of Mono on your system has what’s called a Global Assembly Cache – a location where all system-wide assemblies lives. So when you run an app like Tomboy, it loads its libraries such as GTK# from the GAC belonging to the Mono runtime being used. Ordinarily, this is in /usr/lib/mono/gac on a Debian/Ubuntu system.

When you have your parallel Mono, it doesn’t share a GAC – as a result, libraries in your main distro GAC are not available in your DIY GAC, as they were never registered in there.

Typically, the advice is to either start compiling every lib you need into a non-standard place too – however, here’s a better idea. Why not make Apt take care of not only your system’s GAC – but additional GACs too? We actually have structures in place to handle this, so it’s not as hard as you think (merely relatively unknown). This guide does NOT take startup scripts into account – it’s your problem to ensure you’re using the correct “mono” command to run your copy of MonoDevelop or Tomboy or whatever. You should probably learn about update-alternatives and $PATH for this. Oh, and this guide will BREAK HORRIBLY if you try to uninstall system mono completely. Don’t try it.

Setup step 1: preparation

Don’t install parallel Mono into /usr/local. I don’t care what happens to you if you do. Use some random folder in /opt, usually a per-build prefix like /opt/mono-2.10

Setup step 2: duplicating existing magic

Open a terminal, and copy /usr/share/cli-common/runtimes.d/mono to a new filename, e.g. /usr/share/cli-common/runtimes.d/mono-2.10

Setup step 3: tweak duplicate magic

Open your copied file in an editor, and change the name value on line 27ish (e.g. from “Mono\n” to “Mono (parallel 2.10 install)\n”). Then change the two places in the file, on lines 64ish and 120ish, from “/usr/bin/gacutil” to “/opt/mono-2.8.2/bin/gacutil” or equivalent.

Setup step 4: apply magic to existing packages

Run “/usr/share/cli-common/gac-install mono-2.10″ (or whatever filename you picked for your runtimes.d entry) as root. This will instantiate your parallel GAC(s).

From now on, every GAC library you install or uninstall will happen to every single runtime in runtimes.d.

To go back to how things were before, with only a single Mono runtime:

Uninstall step 1: empty out parallel GAC

Run “/usr/share/cli-common/gac-remove mono-2.10″ (or whatever filename you picked for your runtimes.d entry) as root. This will remove all packaged entried from your parallel GAC(s).

Uninstall step 2: remove magic

Delete your file from runtimes.d

It appears, unfortunately, that the community of “Free Software Advocates” don’t actually understand what Free Software actually IS. That explains an awful lot, but should surprise nobody. So here’s a lesson on what, exactly, is being advocated for.

The Free Software Foundation defines four Software Freedoms – these are the minimum criteria required for something to be considered “Free Software” by the FSF:

• The freedom to run the program, for any purpose (freedom 0).
• The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help your neighbor (freedom 2).
• The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Other groups have their own variants on these, but those are really just clarifications on the FSF definition - for example, the Debian Free Software Guidelines mostly line up, but have some additional clauses such as clause 4 which allows software to be considered Free if source code may be redistributed without modifications, as long as patches may be shipped alongside.

These four freedoms are offered to you by the software’s copyright holders only, and apply regardless of their choice of license – any “Free” license, from a lengthy legal tome like the MPL to the completely-Free WTFPL, will offer you these four basic freedoms as a minimum, and any additional clauses in their licenses cannot seek to restrict these freedoms.

These four freedoms represent the beginning, and end, of whether a piece of software is Free or not.

Software does not need to be developed in the open, in a community-responsive way, in order to qualify as Free – projects such as Google’s Android, which are developed under a “throw a final release over the wall, bugs and all, and expect people to thank you for it” model, are still free, even if contribution is difficult. Actually, on a related note, software does not need to solicit upstream contribution of any kind in order to qualify as Free – as long as you personally can redistribute the code with changes, then that’s enough.

Software does not need to serve a fully or even partially legal purpose in order to qualify as Free – the favoured tool for causing distributed denial of service attacks, Low Orbit Ion Cannon, is Free Software, even though realistically it serves no legal purpose. DeCSS, the code initially used to allow DVD media to play on Linux (by breaking the CSS encryption mechanism) is Free Software.

Software does not need to be useful or tasteful in order to qualify as Free – the Last Measure Operating System, a minimalist OS primarily designed to loudly display the famous shock site images from goatse and related, is Free Software. Even in somewhat less clear-cut cases of taste, your personal opinion of software has no bearing on whether it is Free Software, as long as the four freedoms are guaranteed by the author(s).

Software does not need to have only Free dependencies to qualify as Free Software – it is entirely permissible to write software which relies upon a non-Free framework or library, and release your code under a Free license. It is the downstream recipient’s problem to provide the dependencies, including their choice to craft a Free replacement for any non-Free code you make use of. Debian has a special repository called contrib, where Free software which only works with non-Free data, lives – for example, Free game engines which require the insertion of proprietary game data in order to operate. You could write Free addons for expensive proprietary software such as Matlab, and as long as your code is Free, your responsibilities are met.

Software does not need to avoid patents – software, algorithmic, or otherwise – in order to qualify as Free. The Freetype font library was still entirely Free Software when Apple were slinging threats around regarding font hinting data. FFmpeg, the Swiss Army knife of media codec libraries, is Free Software regardless of the number of codec patents it breaks.

Software does not need any third party approval to be Free Software – the rights of Free Software can only be offered by the copyright holders, and the opinion of third parties is an irrelevance as to whether software is Free. The GPL’d clone of Blizzard Entertainment’s Battle.net servers, bnetd, is Free Software, regardless of legal takedown notices.

Third parties cannot influence whether or not a piece of software is Free. They can influence tangentially related topics, such as whether the software can be legally used, but that’s the limit. And even within a given piece of software, where copyright is shared by contributors, the author of one component has no say on other components. And you can’t make code which is already released as Free, suddenly un-Free – you can, if you hold all the copyrights, close up future versions, but your existing code remains Free forever. Reasonably, you can opt to avoid using a piece of software because you have requirements beyond it merely being Free Software – Cdrtools has been avoided in Debian for a long time due to the upstream author’s legal threats and rambling – but that is a side issue as to the question of whether or not the software is Free.

Patents are simply not involved in the question of whether or not something is Free Software, except for one narrow case: where Free Software is released by somebody who also holds related patents, and uses a license such as Ms-PL or Apache 2.0 or GPLv3 which requires them to also release those patents to those using/distributing the software. Outside that narrow situation, patents do not relate to the question of whether something is Free Software – even if a company releases some source code under a license like BSD then demands patent fees from end users.

So, on to the original topic of Mono. Every piece of Mono’s source code is released by its authors under a license which guarantees the FSF’s Four Freedoms. Whether or not you find Mono useful or tasteful does not affect that Free status. Whether or not Mono infringes upon any laws or patents does not affect that Free status. That Mono contains some libraries whose upstream author is Microsoft does not give Microsoft even the remotest claim to a single line of code outside the code they wrote – and even then, it wouldn’t be an issue, since the licenses they use are Free. In fact, both the licenses used in the Microsoft portions of the source base make patent grants to all users, in addition to guaranteeing the FSF’s Four Freedoms – and any license contamination would decrease, not increase, any risk of legal attack from Microsoft. There’s even plenty of Microsoft code available for re-use at a lower level than the currently re-used libraries: The Microsoft.NET Micro Framework (for use on embedded platforms direct to the metal) is under the Free Software Apache 2.0 license, and would provide access to some of Microsoft’s runtime and class library code, complete with a patent grant, if it were desired.

Please try to keep your thought processes straight. If you want to argue that you’re all for Free Software, please remember that there’s plenty of Free Software you might not approve of – and don’t claim to be a “Free Software advocate” then use bogus arguments to claim that Free Software is not Free. Free Software includes LMOS and LOIC and Mono, whether you like it or not.

Not that I’m ungrateful, mind. Looking after big iron at the University of Oxford has been pretty awesome – more blinky lights than you can shake a stick at – but there comes a time when you need to think about your career, and move on to pastures new. I’m fairly sure six and a bit years is WELL past that point.

When I started looking at work, I had only a few mandatory criteria – a sysadmin job, working with Free Software, without any significant decrease to my monthly income. Beyond that… well, in this economy, who am I to argue?

What I hadn’t accounted for, however, was a job whose awesomeness can’t be contained. A job with a dedicated Free Software company whose entire staff roster, top to bottom, is filled with the most talented, smart, and generally awesome people you could hope to work with. Such a job would be a fevered dream, the mere ramblings of a madman. Yet, somehow, for the second time running, I find myself in an enviable job, working exclusively on Free Software.

Being able to show off root access to a box with 256 cores and a tibibyte of RAM is pretty cool. But you know what’s even cooler? A job where I never need to worry about openSUSE 10.1 administration ever again. A job where several of my colleagues are fellow Debian Developers, with all the prestige and knowledge that comes with such a title. And somehow, by rolling proverbial twenties, I find myself in that position.

I am very, VERY proud to say that from the start of January, I’ll be joining Collabora Ltd as their new Systems Manager.

Download it from here as always.

Oh, and for good luck, I’ve also uploaded it to badgerports.org (which should now display okay on smaller displays), for use with Ubuntu 10.04, where support for authoring with Moonlight is included. It’ll be in the main Ubuntu 10.10 repository at some point in the future, also with Moonlight support.

Enjoy.

I know monodevelop-debugger-mdb is busted – it’s temporary (until this evening). Or you can install this package manually as a workaround until then. There’s still no support re-enabled in Monodevelop in Lucid for Mono 2.6′s Soft Debugger – this will happen at a later date, once I decide on how to do it.

It didn’t take me long to realise the most obvious way to develop such an editor: GRUB2′s canvas-based layout system has an awful lot in common with XAML, so the obvious choice was to develop using Silverlight (or, more specifically, Gtk.Moonlight). Larval’s internal theme format is XAML files, which are then exported to (and imported from) GRUB2′s simple text based files.

The biggest piece of work, to be honest, is the Managed implementation of a PF2 font reader/writer, so you can design a theme using the regular TrueType fonts of your choice, then have them automatically ported to PF2 format as required.

I look forward to plenty of community input on Larval, once it reaches a point where I’m sufficiently pleased with my (Ms-PL licensed) code to share it with the world. Until then, you’ll have to make do with the above screenshot!

[Edit: If it wasn't obvious, this was mostly an April Fool. Mostly. I DID knock together a Gtk.Moonlight UI, and I *DO* think it's a good idea. But there's no code, and no real desire to write the required amount of cruft]

I ended up speaking with the upstream GRUB2 team (which has certainly lead to a strange alliance in one case) about Colin’s GSOC themes, and as it turns out, the main reason there’s no theme supplied with GRUB2 is that Colin’s themes use non-Free elements (proprietary fonts like Helvetica are used heavily). Since I had learnt the theme format to a basic degree in doing my Ubuntu theme, I proposed making a genuinely Free theme – starting with a Debian theme, and moving on to a generic “GRUB2″ theme afterwards.

As I went along, I found a handful of bugs and feature oddities, which have almost all been fixed with incredible turnaround by Vladimir Serbinenko, the current maintainer of the “gfxmenu” code (there remain some questions regarding RTL support in themes, and how to gracefully deal with different aspect ratios) – and I want to extend my thanks to him for his help. However, at this point in time, I’m pleased to announce a theme I’d consider ready for public consumption.

It’s obviously not perfect, and it uses the old visual style from Debian Lenny, but it’s a fully Free starting point, which hopefully can be deconstructed by others seeking to make their own themes. It ought to scale fully to any 4:3 resolution. And it may explode and eat your disk on any version of GRUB2 Experimental other than r1499. Generally, the README is a good starting point.

Oh yes, an URL. Try http://retro.apebox.org/grubthemes/

I’ve been speaking with some folks on deviantART regarding using their Debian-themed wallpaper in future releases of my themes package, but for now, this should be enough for gfxmenu to get a little more exposure and a little more testing. And, hopefully, shift artist focus back from the theme-incompatible BURG fork to the real GRUB2 project.