Installing and getting Battlefield 2 (an EA game from 2006) to work on Windows 7 is not as easy as it could be. For that reason I wrote this howto to get BF2 and Project Reality installed and running.

• Install Battlefield 2 from DVD
• Start the game (it will crash)
• Fix the crash by changing the display refresh rate in the profile
  • Goto C:\Users\YOUR_USER\Documents\Battlefield 2\Profiles\Default
  • Open Video.con with Notepad
  • Change VideoSettings.setResolution from 1600x1200@85Hz to 1600x1200@60Hz
  • Goto C:\Users\YOUR_USER\Documents\Battlefield 2\Profiles\001
  • Open Video.con with Notepad
  • Change VideoSettings.setResolution from 1600x1200@85Hz to 1600x1200@60Hz
• Start the game (it should work now) and quit
• Add missing key in registry for update
  • Run regedit
  • Goto HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Electronic Arts\EA Games\Battlefield 2
  • Edit -> New -> String Value, Enter: Version
  • Right click on Version -> Modify, Enter: 1.0
• Download and install Battlefield 2 Patch v1.41:
  • http://www.battlefield.com/battlefield-2/downloads
  • http://largedownloads.ea.com/pub/patches/BF2/1.41/BF2_Patch_1.41.exe
• Download and install Battlefield 2 Patch v1.5:
  • http://forums.electronicarts.co.uk/battlefield-2/799373-battlefield-2-v1-50-download-links-official.html
• Download and install Project Reality 0.97 Part 1, Part 2, Part 3:
  • http://www.realitymod.com/downloads
• Start the game and play

Last night I wanted to buy an album on Amazon and I couldn't do the checkout as the site required me to install the Amazon MP3 Downloader to make the purchase and download of the album. The downloader is not needed for a single song though, but buying each song separately would be more expensive and more work. The good news is that it automatically offered me packages for different Linux distros: Ubuntu, Debian, Fedora and OpenSUSE instead of telling me off for using Linux and leaving me behind with a Windows only download. But here comes the catch, all offered packages are only for the Intel 32-bit architecture.

Now this is a showstopper for me, as I am running an AMD64 Debian which is a 64-bit architecture. I first tried to download and run the 32-bit debian package nonetheless as there was some hope with the ia32-libs and ia32-libs-gtk package. But this was not working as the application needs gtkmm libraries like libglademm and bailed when I tried to run it. So I filed a wishlist bug report against ia32-libs-gtk for inclusion of gtkmm and possibly other needed libraries to run the Amazon MP3 downloader on AMD64.

So I bought the album using MusicLoad instead which simply puts all songs in a single archive on-the-fly and let me download that archive.

When I tweeted my frustration on Twitter I was hinted by Jo Shields and also by Gabriel Burt that there would have been a much simpler solution to this issue by using Banshee which includes an Amazon MP3 Store plugin:

This plugin allows you to log into your Amazon account browse their store like the regular Amazon store, plays the song samples directly, purchase songs, downloads the songs and imports them into Banshee's database so you can play them right away. And as if this wasn't good enough yet, with the the purchase of MP3 songs on Amazon using Banshee automatically makes a donation to the GNOME foundation.

As I am the only one who forgot or wasn't aware of this awesome solution this deserved some blogging.

Update: some people pointed out that clamz is also available to make MP3 purchases on Amazon.

Most probably haven't noticed yet but I finished the Mono 2.10.1 debian packaging effort of the past 3 months and uploaded it to Debian/Experimental.

With Mono 2.10 I had to make the biggest changes in Mono packaging since the big Mono 2.0 upload. The runtime no longer supports the 1.0 and 2.0 runtime profile, instead it now supports the 2.0 and 4.0 runtime profile. This meant I had to drop all libmono*1.0-cil packages and add libmono*4.0-cil packages. This sounds like a lot of s/1.0/4.0/ work but it actually wasn't. Mono 2.10 ships a lot of new libraries over 2.6 and I had again to decide where they should go. "Where should this $library go?" I have been playing this game for the past 7 years maintaining Mono and I finally gave up on it... What, where, when, why? I could give now a 2 hours talk of the issues behind the current packaging approach (keeping the number of library packages low) but instead I will do something else. Please, just take a look at this picture for a second:

If your browser crashed, your eyes hurt or your brain simply melted, I think you have got the idea.

The Big Split

The cure? cli-common-dev! This is a package that contains 2 extremely important debhelper packaging tools for packaging Mono/CLI related packages called dh_makeclilibs and dh_clideps. If you don't know these, they do exact the same thing as dh_makeshlibs and dh_shlibdeps do. dh_makeclilibs generates library dependency tracking information and dh_clideps consumes that information to automatically generate the package dependencies for you. So each library of the 4.0 runtime profile has now it's own package, simple as that, the rest does cli-common-dev for me and you.

"Hey, that Mono packaging bastard is polluting the Debian archive because of his laziness!" No, I am not. This packaging change not only has the advantage of simplifying the packaging and with that bringing new Mono versions faster to you but also reduces the typical install size for applications as they will only pull in the really used libraries of Mono instead of groups of them. I don't have any numbers handy right now as none of the applications are built against Mono 2.10 (yet), but when the transition starts we will get numbers.

New Features

There is also a new SGen flavor of Mono available called mono-runtime-sgen which is no longer using the conservative non-generational Boehm's garbage collector but SGen which is a simple generational garbage collector with promising advantages.

And here some more Mono 2.8/2.10 news from /usr/share/doc/mono-runtime/NEWS.Debian.gz:

• SGen Precise Stack Scanning
• Enhanced SIMD with new methods for Vector data type conversions and swapping elements in vectors
• ASP.NET MVC 3.0 (not included, only supported)
• The C# Interactive Shell can now be used as shebang: #!/usr/bin/csharp
• .NET 4.0 runtime
• C# 4.0 compiler
• ASP.NET 4.0
• Managed Extensibility Framework (MEF)
• System.Data.Services.Client (OData)
• glib was replaced with eglib
• Removed .NET 1.1 runtime

Architecture Regressions

With the initial upload of Mono 2.10.1 to Debian/Experimental the architecture world broke apart and it regressed on all Mono architectures except for i386 and amd64 There is a reason it's called experimental isn't there?

In mono 2.10.1-3 I could solve all regressions except for kfreebsd-* and armel. Jo Shields fixed the remaining regressions and the world started to look good again in mono 2.10.1-4! He also took care of mono-basic, mod-mono and xsp, but mod-mono and xsp are still waiting for the translation call deadline to pass by so they can also be uploaded to Debian/Experimental.

Planned Transition

As mentioned above, there will be a Mono 2.10 transition needed when the packages hit Debian/Unstable. There is no ETA yet on this when it will happen as I have to coordinate this with debian-release first. But as things are not showtime ready in experimental anyhow, this will not happen too soonish. The Mono 2.10 transition plan will be covered in a following post.

GIVMENOWPLX

OMG, all this rumbling about Mono 2.10 and I still haven't said a word on how to obtain it, sorry about this, just do this and I will shut up now:

echo "deb http://ftp.debian.org/debian experimental main" >> /etc/apt/sources.list
apt-get update
apt-get install -t experimental mono-complete
apt-get install libmono-addins0.2-cil libmono-addins-gui0.2-cil

(this is the easiest way of getting only mono 2.10.1 from experimental)

Update: mono-addins 0.4 breaks with mono 2.10.1 so you need to make sure you have the 0.6 version from Debian/Unstable installed!

Yes, it's that time of the year: I am blogging. I was using Jaws as my blogging tool and CMS for the past few years more or less and I am finally switching to something new.

I was running a SVN snapshot of Jaws and haven't updated nor maintained that one for about 3 years. This reduced my abilility to blog a lot as I had to look after bugs and jumping through the hoops to make a post. At some point I wanted to replace Jaws with something better that fits my needs but didn't find anything.

I have been keeping an eye on Joey Hess' ikiwiki for quite some time, but never felt the desire to blog something important and thus postponed solving my website mess.

For those who don't know ikiwiki yet, it is a wiki compiler based on a version control system like git which generates the website when you push your commits to the git repository. The wiki uses the markdown syntax but also supports other engines. ikiwiki is written in Perl which is not my favourite language, but I have seen worse.

When I wrote the Debian packaging tools for the Common Language Infrastructure, which are based on debhelper, I had to study code written by Joey Hess. Putting the syntax aside (I mean it's Perl, it can't be beautiful because of that) he does well designed and implemented software and this is the reason ikiwiki is a great candidate despite the used language.

Jo Shields suggested dogfeeding myself with a .NET based blog, but ASP.NET is just junk, but with Manos de Mono I am actually considering it! Manos is written in beautiful C# without any ASP.NET close to it, but is extremely new and has no blogging or wiki engine written for it yet. I was involved in Jaws's development and I didn't want to run into the same issue again for now (more hacking the tools, less using them).

So last night I finally made the decision, installed ikiwiki and made my first post with it, yay! The markdown syntax feels very naturaly to me. I usually end up searching for the syntax documentation every 2nd paragraph, but not on this one...

5 weeks after the 0.7.2.2 "Lovegood" release, I am very happy to announce the major feature release, 0.8 codenamed "Godsend". Major feature highlights of this release are desktop notifications (with full support of actions, icons, updates, append and sound), messaging menu / indicators (as provided by Ubuntu's Ayatana project) and working Twitter support with OAuth (basic auth was disabled by Twitter on 31st August). This version also fixes all bugs that were reported since the release of 0.7.2.2.

Desktop Notifications

Messaging Menu

Further on, Smuxi comes with the following improvements in its user interface:

• More distinct nick colors by using a combination of colors
• Use of nick colors for userlists
• Emphasis of own nick in bold, making it easier to distinguish sent messages
• Toggle-able menubar
• Full screen mode support for enhanced netbook experience
• Browse mode support
• Remembering of tab order when reconnecting to a smuxi-server
• Sound support by notification daemons which support this extension
• Display of IRC network name instead of hostname in the tab
• Addition of "Open Log" button for easy viewing of logs.

Smuxi provides better connectivity and security by supporting: HTTP and SOCKS proxies as well as secure connections to IRC servers by using SSL with optional certificate validation.

Last but not least, it comes with an enhanced Twitter experience by supporting the use of multiple Twitter accounts at the same time, reformatting tweets that contain newlines and showing the full retweet instead of a truncated version.

Updated languages includes: French (Clément BOURGEOIS) and German (Bianca Mix)

The #smuxi IRC channel can now also be found, in addition to OFTC, on other popular IRC networks such as freenode and GIMPnet. The messages on #smuxi are automatically relayed between the 3 IRC networks.

If you like Smuxi and want to support it by making micro-donations, Smuxi is available on Flattr.

There are also many other nice FOSS projects available on Flattr, see the Flattr-FOSS project.

Smuxi is available for download from here.

Binary Packages of Smuxi 0.8 are ready to be used by Debian/Experimental, Ubuntu/Maverick, Ubuntu/Lucid (via PPA), OpenSUSE, Foresight Linux, FreeBSD, and Windows.

Merry Christmas! Happy New Year! Yeah, it's that time of year again, I am writing a blog post . As some of you have probably already noticed I managed to get Smuxi 0.7 released a few days ago. Almost all of my Xmas vacation I was hacking on Smuxi. This is the best Smuxi release ever (guaranteed!). The most notable features I implemented in the 0.7 release are: Twitter support, handling for high latency networks (UTMS, WLAN, busy DSL) and an improved IRC experience through tweaks such as splitting oversized messages and new context menus. This release also contains very nice contributions from David Paleino ?2[] and Clément Bourgeois. Both joined the hackfest during my Xmas vacation and made the hacking sessions on Smuxi even more fun. Thanks for that guys! Here you can find a full list of changes.

As everbody likes screenshots and as screenshots say a thousand words, here they are:

Quick Connect
[][]

Twitter
[][]

User Menu
[][]

Which direction will Smuxi head in after the 0.7 release? For the 0.8 release, I plan to focus on making the IRC support feature complete. That means we will get DCC, SSL, IPv6 and logging support. Nothing of that sounds very special but I am already investigating how Smuxi can be integrated with the promising new Zeitgeist project. I interviewed one of the developers for potential communication between Smuxi and Zeitgeist.

Last but not least, I want to announce that I will be attending FOSDEM 2010 in Brussels. I also will give a talk about Smuxi there, scheduled on 2010-02-07 at 16:30. If you want to have a chat, a beer, do some GPG keysigning, or ask me any questions, I am available

PS: If you want more updates than once per year, just follow me on Twitter

?2: http://twitter.com/dpaleino

You are wondering if forgot my password of the blogging account? No I didn't, I just don't have much time to do blogging. I try to invest more time to just do things than to talk about what I have done or will do. Blogging needs time: you need a topic to blog about, you have to login, make a point, do spellchecking and so on. The result: you see about every 3 months a blog post from me. Don't get me wrong, I am doing geeky stuff every single day (except when I am on vacation maybe, but that was how many years ago, eh?).
Micro-Blogging to the rescue! You probably know micro-blogging ala twitter.com already, but for me thats something new You just post a single message with no more than 140 characters and you are done. So if you want to follow my activities, feel free to subscribe to my micro-blog found on twitter: http://twitter.com/meebey

Smuxi is doing nice progress now, I made 2 important changes to archive constant progress: switch from Subversion to Git and with that switch from Trac to Redmine. Now everything is kept in feature-branches and I can switch more often between features and bug fixes without messing all up. More details about this can be found in this Smuxi blog post.

Today I was checking how much diskspace is need when a small CLI (.NET) application like gfax is installed. The last 2 years I am optimizing the Mono packages in Debian to reduce dependency chains. Dependency chains can cause a small application to become very big (at least it looks that way) when they are installed, as modern Linux distributions automaticly install all required dependencies.

So first I worked against GUI dependencies for non-GUI applications, those are annoying for servers, you don't want to install a X server or other GUI libraries when you only serve webpages using ASP.NET.
Splitting CLI 1.0/1.1 vs 2.0 also seemed to be a very good candidate to split apart, as applications usually are target at 1.0/1.1 or 2.0.
Then I split Base-Class-Libraries that have dependencies on native libraries (via P/Invoke), as those packages must depend on those native libraries, like DB drivers.
Last but not least I split debug symbols in a different package, as those are not needed for normal production usage, and embedded systems don't have much diskspace. The mono-dbg package is 28.2MB in size when installed, that's alot.
The Mono source package in Debian is now building 67 binary packages, but thanks to APT nobody has to care for that, every part is installed when needed.

So today I was checking the results of it, how much will a small application download and install?
I am testing with a clean minimal Debian system, that way all dependency chains will show up very easily.
Installing GFax + required libraries today takes 43MB to download and 138MB on the harddisk. GFax is a small GNOME application, it uses libraries like: Mono, GTK#, GNOME#, Evolution#, GConf#.
So someone might say: "of course, it is based on that bloaty Mono virtual machine!", well let's check a different application.
What about a GTK# only application (no GNOME) like graphmonkey + required libraries? That will download 19.5MB and uses 56.4MB on the harddisk. That's alot less, isn't it? graphmonkey only uses Mono and GTK#.
So it's not Mono taking all no diskspace? Well after all my packaging optimizations, it's not Mono So how big is a install of a minimal Mono runtime + all required libraries then?
Minimal as in enough to run famous the "Hello World".
It's 2.4MB to download and 7MB on the harddisk, yes you read it correctly, the super monster bloaty virtual machine just needs 7MB. Mono only has glib as dependency which will be replaced by the eglib library some day.

After I had this great result, I wondered how big other runtimes in Debian are.... like.... Java and Python? The results are interesting...

Update: I got comments that Debian has a python2.5-minimal package available, which is true. So here the numbers of the smallest Python install you can get on Debian: 1.1MB to download, 3.2MB on the harddisk. So Mono is not smaller than Python I also noticed that I could reduce the minimal install size of Mono by 2.7MB if I put the I18N libraries into a different package. That would make 4.3MB for a minimal Mono install then.

So and Java? Here it becomes a bit unfair as SUN's license is not allowing to ship parts of a Java runtime. So the Java package in a distribution must be one package. 34.5MB to download and 95.2MB on the harddisk. Yes, that's alot, but thats the smallest install you can get when you want to run anything on it.
Update: Please be aware that the package size + dependency sizes are considered, not just the naked software size.

So, if you want to run Hello World on a virtual machine: use

Python! just kidding...
Small runtimes are important when it comes to acceptance and adaption of new technologies, as nobody wants to kill all his computer resources for it. And I often hear the replies on Linux IRC channels, when people ask which software they can use to do $task: "No I don't want o install 100MB just for $task" and they decide to try some other software with less dependencies and less resource usage.
Also for the embedded area, resources are very limited, every MB still counts there.

For the completeness of my report, here the naked numbers of other available Java runtimes packages in Debian: sablevm 22.0MB (63.2MB), kaffe 52.2MB (118MB), jamvm 28.3MB (65.4MB), cocoa 28.8MB (66.0MB).