Stephenson’s Rocket – the new name for Ye Olde SteamOSe

I’ve made a new release of my curiously popular SteamOS derivative, and given it a new name: Stephenson’s Rocket.

Stephenson's Rocket

You can download the new release from here.

Release highlights:

  • Updated to alchemist_beta 93
  • Support for pre-HD5000 Radeon cards
  • Support for motherboard-based “FakeRAID”
  • Video tutorial series – about an hour of instructional material for all competency levels

Dear Fake Debian Developers, shoo.

Another post about the Valve/Collabora free games thing. This time, the bad bit – people trying to scam free games from us.

Before I start, I want to make one thing clear – there are people who have requested keys who don’t meet the criteria, but are honest and legitimate in their requests. This blogspam is not about them at all. If you’re in that category, you’re not being complained about.

So. Some numbers. At time of writing, I’ve assigned keys to 279 Debian Developers or Debian Maintainers – almost 25% of the total eligible pool of about 1200.

I’ve denied 22 requests. Of these 10 were polite requests from people who didn’t meet the conditions stated (e.g. Ubuntu developers rather than Debian). These folks weren’t at all a problem for us, and I explained politely that they didn’t meet the terms we had agreed at the time with Valve. No problem at all with those folks.

Next, we have the chancers, 7 of them, who pretended to be eligible when they clearly weren’t. For example, two people sent me signed requests pointing to their entry on the Debian New Maintainers page when challenged over the key not being in the keyring. The NM page showed that they had registered as non-uploading Debian Contributors a couple of hours previously. A few just claimed “I am a DD, here is my signature” when they weren’t DDs at all. Those requests were also binned.

Papers, Please screenshot - denied entry application

DENIED

And then we move onto the final category. These people tried identity theft, but did a terrible job of it. There were 5 people in this category:

From: Xxxxxxxx Xxxxxx <xxxxxxxx.xxxxxx@ieee.org>
Subject: free subscription to Debian Developer
8217 A205 5E57 043B 2883 054E 7F55 BB12 A40F 862E

This is not a signature, it’s a fingerprint. Amusingly, it’s not the fingerprint for the person who sent my mail, but that of Neil McGovern – a co-worker at Collabora. Neil assured me he knew how to sign a mail properly, so I shitcanned that entry.

From: "Xxxxx, Xxxxxxxxx" <x.xxxxx@bbw-bremen.de>
Subject: Incoming!
Hey dude,

I want to have the redemption code you are offering for the Valve Games

mQGiBEVhrscRBAD4M5+qxhZUD67PIz0JeoJ0vB0hsLE6QPV144PLjLZOzHbl4H3N
...snip...
Lz8An1TEmmq7fltTpQ+Y1oWhnE8WhVeQAKCzh3MBoNd4AIGHcVDzv0N0k+bKZQ=3D=3D
=3Du/4R

Wat? Learn to GPG!

From: Xxxxxx-Xxxx Le Xxxxxxx Xxxx <xx.xxxxxxxxx@gmail.com>
Subject: pass steam
Hey me voila

Merci beaucoup

valve

2069 1DFC C2C9 8C47 9529 84EE 0001 8C22 381A 7594

Like the first one, a fingerprint. This one is for Sébastien Villemot. Don’t scammers know how to GPG sign?

From: "Xxxxxxxxx Xxxxxxx" <xxxxxxxx@web.de>
Subject: thanks /DD/Steam gifts us finally something back
0x6864730DF095E5E4

Yet again, a fingerprint. This one is for Marco Nenciarini. I found this request particularly offensive due to the subject line – the haughty tone from an identity thief struck me as astonishingly impertinent. Still, when will scammers learn to GPG?

From: Sven Hoexter <svenhoexter@gmail.com>
Subject: Valve produced games
I'm would like to get the valve produced games
My keyring: 0xA6DC24D9DA2493D1 Sven Hoexter <hoexter> sig:6

Easily the best scam effort, since this is the only one which both a) registered an email address under the name of a DD, and b) used a fingerprint which actually corresponds to that human. Sadly for the scammer, I’m a suspicious kind of person, so my instinct was to verify the claim via IRC.

31-01-2014 16:52:48 > directhex: Hoaxter, have you started using gmail without updating your GPG key? (note: significantly more likely is someone trying to steal your identity a little to steal valve keys from collabora)
31-01-2014 16:54:51 < Hoaxter!~sh@duckpond6.stormbind.net: directhex: I do not use any Google services and did not change my key

So… yeah. Nice try, scammer.

I’m not listing, in all of this, the mails which Neil received from people who didn’t actually read his mail to d-d-a.

I’m also not listing a story which I’ve only heard second ha… actually no, this one is too good not to share. Someone went onto db.debian.org, did a search for every DD in France, and emailed every Jabber JID (since they look like email addresses) asking them to forward unwanted keys.

All in all, the number of evildoers is quite low, relative to the number of legitimate claims – 12 baddies to 279 legitimate keys issued. But still, this is why the whole key issuing thing has been taking me so long – and why I have the convoluted signature-based validation system in place.

Enjoy your keys, all 279 of you (or more by the time some of you read this). The offer has no explicit expiry on it – Valve will keep issuing keys as long as there is reason to, and Collabora will continue to administer their allocation as long as they remain our clients. It’s a joint gift to the community – thousands of dollars’ worth of games from Valve, and a significant amount of my time to administer them from Collabora.

Dear Debian Developers, lrn2gpg

For some strange reason, I’ve been receiving a lot of GPG-signed mail from Debian Developers and Maintainers lately. In response to each of these mails, I need to send a GPG-encrypted reply. The rate at which I’m able to send replies has been significantly hampered by the poor state in which many DD/DM’s maintain their GPG keys. Here are a few common mistakes, so you can consider correcting them.

Ensure you have a UID for the email address(es) you use

When I send an encrypted mail, I need to be sure that the recipient is legit. This means any decent mail client should refuse to send an encrypted message to foo@bar.com unless that email address is known somehow to GPG. In many cases, someone with a valid key for foo@bar.com would send their signed mail from foobar@gmail.com without that being a valid UID. In some cases, foo@bar.com isn’t even a valid email address anymore (i.e. the bar.com mail server says no such mailbox).

You should have a UID for each address you use.

Signatures are per-UID

You may well have a valid UID for foo@debian.org, foo@bar.com, and foobar@gmail.com – but the PGP trust model doesn’t automatically trust every UID as much as its peers. Each individual UID needs to be trusted (i.e. signed/uploaded) by others. What if you added billg@microsoft.com as a UID – should that automatically be trusted? Clearly not. Just because you have foo@debian.org doesn’t mean it’s trusted for encryption without some signatures.

Make sure you actually have an encrypting subkey

GPG sucks, and as a result, it reports “Skipping unusable pubkey” when the issue is a lack of valid encrypting subkeys. If you have revoked all encrypting subkeys, or allowed them to expire, then I cannot send you encrypted mail.

Exact naming matters

“Bob Bobbertson <foo@bar.com>” and “Böb Böbbërtsön <foo@bar.com>” are different people. Check your mail client’s “From:” setting, to ensure it matches your UID. If not, fix one of them.

Check your webmail plugin isn’t shit

Some people use third party plugins to integrate GPG into their webmail client (e.g. Hotmail or GMail). Make sure this actually works.

Don’t use Enigmail

Enigmail is a popular plugin to integrate GPG into Mozilla Thunderbird. It doesn’t work, in most cases. Almost every single BADSIG in my inbox is due to Enigmail. Thunderbird will insert spurious line wraps and escape characters into your mail after signing, resulting in invalid signatures.

It’s mostly okay if you never quote mail, and restrict messages to about 70 characters.

I know plenty of Debian Developers don’t care about GPG other than for package signing – but please, for the sanity of the rest of us, take an occasional moment to care a little.

I should note that the worst offenders for keys which don’t “just work” were Developers with 1024D keys – the best behaved were Maintainers of all stripes.

Here Ye, Here Ye

Valve Software’s Steam is the number one digital game distribution service, with more than 65 million registered accounts. Steam runs on Windows, Mac OS, and Linux x86/amd64 computers, and provides access to several thousand games, at varying price points – an enormous growth from less than a dozen games for Windows only about a decade ago. Valve’s latest endeavour has been to bring their storefront into the living room, with a three-pronged attack: a new game controller, a programme of licensed x86 “consoles” to plug into the family TV, and an OS to run on the “Steam Machines” to tie it all together.

December saw the first public release of their “SteamOS” – which, as it turns out, is basically just a preconfigured desktop Linux. Specifically, it’s a Debian Wheezy derivative, comprising a subset of 502 source packages from Wheezy; 8 of Valve’s own source packages; and 51 source packages which have been either patched compared to Wheezy, backported from post-Wheezy, or both. For example, the compiler used by default is gcc-4.7 (rather than Wheezy’s 4.6) and the libc version postdates Wheezy too.

Valve’s official instructions and installer release concerned quite a few people who had planned to try SteamOS on an older PC, by mandating a large (500GB) hard disk and a PC with UEFI firmware. Very quickly a number of instructions started appearing from people trying to fix what people felt were real issues – specifically provision for BIOS-based computers, and installation from optical media.

After being assured that redistribution of derivatives of SteamOS were entirely authorized (and, in fact, encouraged) I decided to produce my own variant, calling upon my own experience with debian-installer modification from past and present jobs, as well as calling upon the skills and experience of the UK Debian community as needed.

The end result is Ye Olde SteamOSe.

SteamOS on VMware Workstation 10

This weekend saw the third release of Ye Olde SteamOSe, a derivative designed to greatly widen the pool of computers capable of running Valve’s OS. And unlike the first two releases, the public response this time has been crazy. Like, totally crazy. Combined score across several subreddits totals about 1700. 7 pages of Google search results. Hundreds of tweets. Mentions in dozens of blogs around the world. Coverage on the Linux Action Show. Unilaterally added to Softpedia’s list of distributions. Almost 2000 views of a video installation walkthrough I posted on YouTube. Crazy.

Sadly the idea to try and track visitors to the page didn’t occur to me until long after the initial rush subsided, but 1000 visitors on Tuesday for a news story which landed on Sunday is still pretty hot in my book.

It’s also interesting to observe the demographics of site visitors – the #1 referrer on Tuesday was Dutch PC site Tweakers.net, and StumbleUpon outranks reddit for referrals. About 66% of visitors interested in installing my Debian Wheezy derivative derivative came using Windows (20% using Linux), which suggests there’s a lot of potential Linux users out amongst the Windows gamer masses.

So what’s the purpose of this self-congratulatory blog post? Just dick-waving? Well, there’s an element of that (I’m only human), but I think it might be nice to alert the audience on Planet Debian/Ubuntu, many of whom are not big gamers, to the “next big thing” in “embedded” Linux – except this time a real GNU/X.org/sysVinit distribution, not some NIH thing like Android.

So now you know!

The directhex! In an Adventure with MIPS

We’ve been trying to build Mono on MIPS in Debian for a long time. Just under a decade, in fact. Mono 0.29.99.20040114-3 was the first attempt, back when the Mono source was 10 meg, not today’s ~80.

It never worked though. Not once. At the end of 2004, 10 upstream versions later, we gave up, and turned off mipsel as a target architecture in the package.

When I became a Debian Developer in 2009, one of the first things I did was try again with Mono on various previously unsupported architectures, by running a build on the Debian porterboxes. Supposedly MIPS support was there, as evidenced by all the MIPS-related files in the source tree. But I’d try it, and it’d fail, and upstream would say “works for me”. I repeat the process every major release or so, to see what’s changed.

The breakthrough

Spurred by the removal of two bitrotted architectures (IA64 and SPARC), I decided to try again, this time investigating more deeply into the reason for the failures, with the help of upstream developer Alex Rønne Petersen. A couple of hours of IRC-driven gdb and test program disassembly later, a seemingly innocent comment flagged something in my brain:

09-07-2013 15:10:11 < alexrp!~zor@baldr.rfw.name: TIL that mul and mult are not the same thing on mips

Why is this notable? Well, MIPS processors lack a whole bunch of instructions which are commonly used in assembler. MUL is one of them – it’s valid MIPS assembler, which is expanded to MULT/MFLO when compiling. Call it a macro, or a mnemonic, or shorthand – the preferred term is “pseudoinstructions”. So what’s the issue?

09-07-2013 15:18:27 > directhex: mono isn't trying to use a mul instruction, right? i mean, that instruction doesn't exist as far as the cpu is concerned, it's a macro the compiler does things with

See where this is headed?

09-07-2013 15:23:59 > directhex: mini/mini-mips.c:#define USE_MUL 1 /* use mul instead of mult/mflo for multiply */

Argh.

See, the thing about MIPS pseudoinstructions is they may be real instructions on a given CPU implementation. Strictly speaking MUL isn’t a standard instruction, but a given CPU might have it anyway, to make multiplication a little faster (by using only one instruction, not two, for multiplication). In this case, the Debian MIPS infrastructure is based around ICT Loongson-2E processors which don’t have that extension – but the upstream Mono developers were building and testing on an extended CPU, never seeing the issue themselves.

Flipping that define to 0 (and amending the instruction length setting in another file) fixed the build. Mono was running on MIPS for me for the first time ever.

Digging through the history in git showed just how annoying this implementation quirk was. USE_MUL was added in late 2008 – replacing a previously used “#if 1″. The mult/mflo version of the code existed in the Mono source since the first time the full MIPS port was committed in 2006, but we never saw it.

The breakage

So, with that patched to work, I added mipsel to the Experimental build of Mono… which still failed. The runtime would build fine, but the class library build would fail at random times, with random meaningless stack traces. Unrepeatable. Some kind of race condition. The build would eventually succeed if I hammered “make” a few times, but that’s no good for the Debian build daemons. Back to square one…

… except I had an epiphany yesterday. I have heard more than once that Loongson processors are missing a few instructions. What if one of those was being hit, intermittently? I started doing a search in places that might need to work around that kind of issue, and found this. A patch to binutils in 2009, replacing one no-op instruction with another, when /usr/bin/as is fed the -mfix-loongson2f-nop flag.

Turns out NOP is another pseudoinstruction on MIPS. Well, more of an alias. The opcode 0×000000 is “Shift Left Logical” with 0 registers and 0 data, which is a no-op. But on all but the latest generation of Loongson-2F chips, that opcode can, under heavy load, fail – causing inconsistent state in the CPU registers. The flag to “as” replaces “sll 0,0,0″ with “or $at,$at,0″, which is also a no-op instruction, but doesn’t trigger the failure on Loongson-2F chips (and 2E chips, although that’s not stated in the documentation).

As long as ALL your programs get fed through “as”, you don’t have a problem, since it uses the replacement opcode… but what if you use a JITter to generate your own opcodes? Oh fuck, it couldn’t be…

diff --git a/mono/arch/mips/mips-codegen.h b/mono/arch/mips/mips-codegen.h
index dc4df7d..1dbd1c6 100644
--- a/mono/arch/mips/mips-codegen.h
+++ b/mono/arch/mips/mips-codegen.h
@@ -334,7 +334,7 @@ enum {
 /* misc and coprocessor ops */
 #define mips_move(c,dest,src) mips_addu(c,dest,src,mips_zero)
 #define mips_dmove(c,dest,src) mips_daddu(c,dest,src,mips_zero)
-#define mips_nop(c) mips_sll(c,0,0,0)
+#define mips_nop(c) mips_or(c,mips_at,mips_at,0)
 #define mips_break(c,code) mips_emit32(c, ((code)<<6)|13)
 #define mips_mfhi(c,dest) mips_format_r(c,0,0,0,dest,0,16)
 #define mips_mflo(c,dest) mips_format_r(c,0,0,0,dest,0,18)

Oh yes it could! Mono was using sll 0,0,0 (the recommended no-op instruction from the MIPS instruction reference manual), causing failures in my tests, because Debian’s build and test infrastructure just happens to use defective silicon. And, again, upstream were unable to reproduce a problem because they use better silicon than we do.

So what now?

Well, last night I uploaded mono_3.2.3+dfsg-3, which includes the above patch to force the replacement no-op instruction. It test built fine on the porterbox, and it should (when the damn experimental buildd gets around to it), just work.

Finally.

After just under a decade, Mono packages will be available on MIPS in Debian.

And after all this time, all we had to change was 4 lines to work around 7 year old Chinese knock-off processors.

The edit

So, things are finally built.

It turns out that despite everything, the replacement NOP opcode is not enough.

If you re-read the post to the binutils list, pay close attention to:

In theory this is still not enough to fully eliminate possible hangs, but the possiblity is extremely low now and hard to be hit in real code.

It’s a filthy lie. It’s easy to hit the issue in real code: just do a from-source build of the whole Mono class library. With the replacement instruction it builds .NET 2.0, 3.0, 3.5, 4.0, and most of 4.5, before dying in the same way as before – an improvement on failing early in the 2.0 build, but not enough.

Thankfully, 2 out of the 5 Debian mipsel build servers are not Loongson 2 – they’re 11 year old Broadcom SWARM developer boards. Not fast – but also not broken. Luck smiled on me, and caused my build to go to one of these Broadcom machines. As a result…

(experimental_mipsel-dchroot)directhex@eder:~$ mono --version | head -1
Mono JIT compiler version 3.2.3 (Debian 3.2.3+dfsg-3)

It’s been a long time coming.

Viennese Whirl

A week or so ago, I made my way to Vienna for the .NET + GNOME Hackfest 2013 – a chance to link up with my fellow developers and help shape the future of Mono apps as part of desktop Linux.

The trip was far from simple, nearly missing my outgoing flight thanks to obstinate Heathrow security staff – and my suitcase not making it to Vienna with me. However, despite those little “teething issues”, it was good to get a chance to meet my counterparts elsewhere in the desktop space.

My time at the hackfest was mostly concentrated on getting a bundle of the core frameworks packaged, bugfixed, and uploaded – a majority of developers use Debian or Ubuntu, so providing them with up to date tooling is important. Over the few days I was there (I arrived late & had to leave early) I got all the core Mono framework and related updated, including a new MonoDevelop release. It was also a good chance to discuss best practice with various binding maintainers, to ensure that the final release of GTK# and related libraries is in an easy-to-package form.

And perhaps more importantly, I found a seller of Red Bull Simply Cola and was able to shove a dozen cans in my suitcase for the return journey.

More than anything else, I think it gave upstream hackers a chance to observe the distribution maintainer’s job up close – and a chance to see how much work is involved, beyond just running “make install” – I hope they found that interesting!

Thanks to the event sponsors:

Collabora Ltd, Open Source Consulting

Norkart AS, Norway’s premier supplier of Geographic Information Systems and related consulting

Hotel Schottenpoint, our hotel partner

Novacoast IT, Professional Services and Product Development

The GNOME Foundation, providers of the GNOME desktop

 

The University of Vienna and the Institute for Theoretical Chemistry, our venue sponsors

Windows 8: Blood from a Stone

Ordinarily, I’m a big believer that it is important to keep up to date with what every piece of software which competes with yours is doing, to remain educated on the latest concepts. Sometimes, there are concepts that get added which are definitely worth ripping off. We’ve ripped off plenty of the better design choices from Windows or Mac OS, over the years, for use in the Free Desktop.

So, what about Windows 8, the hip new OS on everyone’s lips?

Well, here’s the thing… I’ve been using it on and off for a few months now for running legacy apps, and I can’t for the life of me find anything worth stealing.

Let’s take the key change – Windows 8 has apps built with a new design paradigm which definitely isn’t called Metro. Metro apps don’t really have “windows” in the traditional sense – they’re more modeled on full-screen apps from smartphones or tablets than on Windows 1.0 -> 7. Which is fine, really, if you’re running Windows 8 on a tablet or touchscreen device. But what if you’re not? What about the normal PC user?

As Microsoft themselves ask:

How do you multitask with #windows8?

The answer to that is, well, you sorta don’t.

Metro apps can exist in three states – fullscreen, almost fullscreen, or vertical stripe. You’re allowed to have two apps at most at the same time – one mostly full screen, and one vertical stripe. So what happens if you try to *use* that? Let’s take a fairly common thing I do – watch a video and play Minesweeper. In this example, the video player is the current replacement for Windows Media Player, and ships by default. The Minesweeper game isn’t installed by default, but is the only Minesweeper game in the Windows 8 app store which is gratis and by Microsoft Game Studios.

Here’s option A:

Unusable Windows 8 option 1

And for contrast, here’s option B:

Unusable Windows 8 option 2

Which of these does a better job of letting me play Minesweeper and watch a video at the same time?

Oh, here’s option C, dumping Microsoft’s own software, and using a third-party video player and third party Minesweeper implementation:

Windows 7 flavour

It’s magical – almost as if picking my own window sizes makes the experience better.

So, as you can see above, the “old” OS is still hiding there, in the form of a Windows 8 app called “Desktop”. Oh, sorry, didn’t I say? Metro apps, and non-Metro apps, are segregated. You can run both (the Desktop app can also be almost-fullscreen or a vertical strip), but they get their own lists of apps when multitasking. Compare the list on the left with the list at the bottom:

Needs moar task lists

And it’s even more fun for apps like Internet Explorer, which can be started in both modes (and you often need both modes). Oh, and notice how the Ribbon interface from Office 2007 has invaded Explorer, filling the view with large buttons to do things you never want to do under normal circumstances.

So, that’s a short primer on why Windows 8 is terrible.

Is there really nothing here worth stealing? Actually, yes, there is! After much research, I have discovered Windows 8′s shining jewel:

win8multitasking-004

The new Task Manager is lovely. I want it on my Linux systems. But that’s it.

Evil, or why Douglas Crockford is harmful to Free Software

Yesterday I received a new serious bug report against Mono in Debian. For those not in the know, “serious” severity is release critical, and can trigger removal of a package from the distribution in order to make a shipping release (e.g. if Debian is in deep freeze, as is the case right now). Bug 692614 relates to a single source file, ./mcs/class/System.Web.Extensions/System.Web.Script.Serialization/JsonDeserializer.cs, which is part of the System.Web.Extensions assembly. This file was written in 2008 by an upstream Mono developer, and is based on some code from json.org – specifically JSON_parser.c and JSON_checker.c

json.org code carries a non-standard license. Specifically, it’s MIT/X11 with an added clause: “The Software shall be used for Good, not Evil.”

I’ve had some discussions with Mono upstream, and they believe that they have resolved the matter to their satisfaction – their solution will make its way into Debian soon. But in the meantime, let’s talk about the clause.

The Free Software Foundation’s Freedom 0 reads:

A program is free software if the program’s users have the four essential freedoms:

  • The freedom to run the program, for any purpose (freedom 0).

The Debian Free Software Guidelines and Open Source Initiative’s Open Source Definition clause 6 reads:

No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

It’s fairly clear that the JSON.org license clause goes against both of these, making any piece of software using that license neither Open Source nor Free Software. It is not distributable by any organization which mandates Freedom for its users – not in Debian, not in Fedora, not on Google Code. Anybody who cares about their users will reject a clause like this, because it has awful chilling effects.

Think it’s funny? It really isn’t. Who can use the code without being at risk of a lawyer knocking on their doors? Can the Catholic Church? The ACLU? Republicans? Democrats? Military contractors? Genetic engineers? Big pharma? Petrochemicals firms? Communists? Fascists? Mono developers? WikiLeaks? Without a clear definition of “good” and “evil”, people need to seriously consider whether they are safe to use the code – because if the developer and users’ interpretations of the terms differ, there could be hell to pay. Would you want to ship a hardware device – let’s say you’re making a smart TV – and have some developer of a library send his lawyers around to tell you “sorry, TV rots kids’ brains, it’s clearly evil” to get your entire distribution channel shut down by injunction?

It’s not an oversight, kids. Upstream are well aware of the pain this childishness causes anyone who takes software licenses seriously. They giggle about it at conferences, like tweenagers who think they’ve one-upped the adults in the room.  This non-Free license is intended to mock people who take licensing seriously. In fact, one could easily categorise efforts to pollute the Free Software ecosystem with fake, non-Free software as evil, which would mean all JSON.org code fails to comply with its own license, due to shipping with its license (Inception, anyone?).

Before the jokers in the room claim that this kind of problem is deserved by Mono, let’s take a look at all the software in Debian which Douglas Crockford endangers with his childishness. PHP? OwnCloud? jQuery? You think Debian serves its users well by pulling jQuery from the next release in order to serve the ego of a man behaving like an eleven year old?

It is also interesting to note that the author of this “do no evil” clause works at PayPal. Read that twice, go and repair your irony meters, then come back.

In conclusion: thank you so VERY much Doug Crockford for making the world of Free Software measurably worse.

How to build a bungalow… begin with the chimney

Whilst nobody was looking, Mono became the most important framework in the world of games.

And I mean that with only a smidge more than my usual levels of hyperbole. It really is fantastically important, as far as game development goes.

I blogged a long time ago about its use inside EA’s multi-million-selling The Sims 3. And the massive performance gains in Second Life when they switched from their in-house scripting language to Mono are well documented. But I’m not talking about those, I’m talking about the now, the recent stuff.

First up is Unity 3D. Not to be confused with the Ubuntu user interface, Unity 3D is a proprietary game development tool which began life for Mac, and has now managed to become the single most popular game engine amongst smartphone developers. It targets a bunch of new platforms – not just Android and Windows and iOS, but in the new 4.0 release, Linux too for the first time. And every Unity 3D game is a Mono game – the core of Unity is a fork of Mono, which enables it to have the performance and ease of development which it does. A reasonably large percentage of the cross-platform games on Kickstarter, such as Wasteland 2 and Super Retro Squad, are cross-platform because Unity 3D makes it easy – and each of those games is powered by Mono.

However, I have better things to do today than gush about a proprietary tool. No, far more important are the Free ways to develop games. So today I’m going to talk about MonoGame.

MonoGame is an implementation of Microsoft XNA – a high level framework for developing in .NET languages, originally designed to allow indie developers access to the Xbox 360. XNA covers many of the bases covered by SDL – sound, graphics, input, and so on, but can go onto platforms where SDL isn’t an option, such as the aforementioned Xbox 360. And with MonoGame, any game written for XNA is a game which can not only run on Microsoft’s approved platforms – Windows, Xbox 360, Windows Phone – but also on other platforms such as Mac OS X, iPhone, iPad, Android, and Linux. Cross-platform is good. More games are good. And MonoGame enables every Xbox 360 indie developer to throw a Linux port out of the door with a relative minimum of fuss. There are 2,521 games on the Xbox Live Indie Games store (games by individuals or small groups, with no major publisher) and each of those can become a game for Debian and Ubuntu with very little work. Not to mention the games with actual publishers (some portion of the 492 games on XBLA), not to mention the mobile games written for Windows Phone, Android and iOS. All of these developers have an easy route to Linux releases, as long as the effort remains low.

And with today’s publishing in the Debian archive of MonoGame 2.5.1, the effort is as low as can be.

Anyone who purchased the recent Humble Indie Bundle 5, and played Bastion, has seen MonoGame in action – Bastion began life as an XNA game for Xbox 360, and the Linux port was made possible only by MonoGame. Bastion’s 100+ industry awards should indicate the possibilities open to a creative mind with decent developer tools.

MonoGame is Free Software, built on top of other Free Software, with an active upstream development team genuinely responsive to the needs of Linux distributions. It’s well worth a look not just for porting, but for new projects too. And I’m delighted that it will be available to all users of Debian 7.0, as well as Ubuntu 12.10.

Enormity

(This blog post is a more firm version of a series of tweets and forum posts I made a few weeks ago. This should also be considered a refresh of this post by Mirco Bauer a few years ago)

It has been said that Mono is bloated, and that people should use “lighter” frameworks that don’t pull in “hundreds of meg”.

How much basis in reality is there for those comments?

Well, let’s do a little thought exercise. How much space is the minimum space needed for several languages to work?

For this experiment, we will be looking at the required installation size on disk of several language frameworks, each time installing the bare minimum for a command-line “hello world” app in that language to run. For example, the Ruby result is the minimum install required to run:

puts 'Hello world'

and the Mono result is the minimum install required to run the following code, which has been compiled on a different machine using “dmcs”:

public class Hello1
{
   public static void Main()
   {
      System.Console.WriteLine("Hello, World!");
   }
}

Obviously, for dynamic languages like Ruby and Python, there is no compiler step needed. For languages like C# and Java, it is fair to compile these on a different machine as end-users of packages running these frameworks receive binaries, not source – they do not need a development environment.

So, on to the test environment. This is a bare bootstrapped AMD64 Debian Unstable system, as of today (i.e. “debootstrap sid /tmp/badger”). Its install size is 275MB. So… how much space?

Read more…