MEEBEY.NET the Project

Here some news from the Smuxi front. As you might already know Smuxi 0.6.2 was released. With the 0.6.2 release we have now German translation and Smuxi packages in Debian (Unstable) (as promised), Ubuntu (intrepid) and ArchLinux (AUR)! Now just OpenSUSE, Foresight Linux, Gentoo and Fedora are missing for world domination^W^Wconvering the major Linux distributions.

The upcoming 0.6.3 release will contain Spanish (thanks to Juan Miguel Carrero), French (thanks to Clement BOURGEOIS) and British English (thanks to Ryan Smith-Evans) translations. Besides bugfixes this release will contain the famous tray icon support and some other goodies! The release should be ready by this weekend... stay tuned.

I made a minor bugfix + minor feature release of Smux together with packages for Debian, Ubuntu and Windows. Big thanks for all the feedback I received from the users!
But at the same time I seek possible Smuxi contributors for things like artwork (logo, icons, theming, etc), translations, package maintainers for Linux distributions (OpenSUSE, Gentoo, ArchLinux, ForeSight, etc), patches, frontend and protocol developers are very welcomed and wanted
If you are interested in helping the project in any way, just join #smuxi on irc.oftc.net

Back to the topic, here are the release notes of Smuxi 0.6.1 and the downloads.

Just in time, at the end of my 3 week vacation, I released the first public version of smuxi!

For people who don't know smuxi yet: I have been developing over the last 3 years an IRC client that fits the needs I could not satisfy with irssi. I was using irssi over 4 years and it's the best the IRC client I used so far. Most annoying was that it didn't integrate at all into my desktop experience (such as mouse / clipboard / theming / highlight handling). Thus irssi inspired lots of features and commands seen in smuxi.

So here it comes, a flexible cross-platform open-source IRC client for the GNOME desktop, in action:
   

Smuxi is built using a great software development stack, composed of: C# / Mono, GTK{+,#} / GNOME(#) and MonoDevelop.

Interested in using or contributing to smuxi?
Head over to the official release announcement on the smuxi project website.

For the Debian users and developers among us:
Debian packages for smuxi are not available yet, but will be very soon.

This weekend I did a hack session with Alan McGovern on Monsoon. You don't know what Monsoon is? It's the sexy GTK# driven bittorrent client based on the MonoTorrent library developed by Alan McGovern.

I created debian packages for Monsoon and wasn't happy with some features and/or bugs so I thought I can contribute some love to it.

First thing I implemented was persistency of file priorities for torrents, so when you restart Monsoon it will restore all priorities. I also reported some bugs to Alan in MonoTorrent, like it was ignoring "do not download" flags, so it kept downloading all files of a torrent and the download progress of files were not correctly restored when it was resuming the torrent. He found and fixed the issues right away, great service
Then I implemented auto-start of torrents that were running when Monsoon is closed.
Monsoon will also now not flood your console with lots of debug stuff, as I added a -d / --debug parameter for that, which made my terminal unresponsible without it when downloading big torrents (~1000 files).

And this evening, I replaced the usage of Gnome.IconEntry and Gnome.IconSelection with Gtk.FileChooserDialog + a preview widget. Alan asked for this, as he wanted to drop the GNOME# dependency for memory usage reasons.

Allright, enough love for today! Now I am hungry....

PS: We have now an IRC channel for Monsoon: #monsoon on GIMPnet, if you are interested, please join!

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...
A minimal Python install takes 3.9MB to download and 13.4MB on the harddisk. Yes, that's almost double the size of Mono, I was surprised too.
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 Mono 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).