Author: admin

The 2e or 3th of december I will be doing a talk about tinymail at T-Dose. T-Dose is a new conference event in the Netherlands that aims at bringing the FOSDEM conference formula to their country.

I don’t know the schedule myself yet, so I don’t know (yet) which day nor at what hour I will do the talk.

You remember this one? It’s Evolution’s current Camel downloading 30,000 headers from IMAP:

This one was a first hack that I did that drastically reduced memory consumption. You remember it?

Ok, so this one is what tinymail will do today (all graphs show the same folder, the same amount of headers being downloaded, indeed):

That’s indeed four times less memory than the original Camel as shipped by Evolution. What you don’t see in the graph is that it also uses far less bandwidth and the implementation is a lot less complicated and mostly because it transfers less data, faster (You don’t believe me about the complexity? Compare with the original here).

Memory consumption, speed and bandwidth consumption are extremely important for mobile & embedded appliances (both GPRS traffic and memory are expensive, being online often consumes battery, the CPU of the devices is often slower). Mobile & embedded appliances are the (current) focus of the tinymail framework.

You don’t have to believe me. Go ahead and try it yourself with what is current in tinymail’s repository. There’s a test account available: mail.tinymail.org, u:tinymailunittest, p:unittest. If people are now going to abuse this account, the account wont be available anymore (I do measure traffic and directory size frequently, indeed).

Camel (a library being used by Evolution and a heavily hacked version of it by tinymail) does something like this when you for the first time downloaded 30,000 message headers from an IMAP service’s folder:

The Camel in tinymail does something like this (after this patch, as I have to hack a few other providers to support this hack first):

Anyway, this hack together with the mmap one (which has already been applied to tinymail’s camel) makes it possible to use very large folders (more than 20,000 headers) on devices with ~10M RAM. Like maybe the cellphones of tomorrow?

How? Simple: I dumped the headers to the summary file that will be mmapped each 1000th header, store some status and continue fetching more headers from the IMAP server.

This also improves canceling. Because it now dumps each 1000th header, you can cancel the operation yet not lose per 1000th header the ones that were already received (like what happens if you would cancel such a download in Evolution).

Another significant milestone has been reached for tinymail. I finally achieved getting the non-mmap memory consumption for the folder summaries lower than the amount of data being mapped using mmap.

These are averages but since all messages where spam, probably meaningful. You can read the source code of and compile and run this test to reproduce the tests yourself.

Loading 50,000 headers used to consume something like 30M. More typical numbers where the 10M for 15,000 headers. The idea was that not much people want to view 50,000 headers on a mobile device. Boy, I can come up with lame excuses for abusing your memory don’t you think?

Nevertheless, I improved the situation. 50,453 headers now consume 15.9M, 30,264 headers now consume 10M and 15,000 headers now consume 4.7M. At around 3,000 headers tinymail goes below the 1M barrier. Most people use their mobile device to view less than 5,000 headers. Making tinymail a cheap E-mail client infrastructure when it comes to memory consumption.

How did I do this? Well, I don’t yet support threaded sorting of messages. Therefore I removed that from the Camel that I’m using. This, for example, has cut 7% of the allocated memory usage. I also removed a few other pointers in the struct that is allocated per such summary item. Each pointer is of course 4 bytes on my test system. When dealing with 50,000 instances, it indeed becomes more significant.

Me and especially Matthew Barnes have also been upgrading some of the e-d-s infrastructure being used by Camel to modern glib functionality. Like GSlice in stead of EMemChunk (if done correctly, reduces heap admin a little bit it seems), GMutex in stead of EMutex, GThread/GAsyncQueue in EMsgPort and killing EThread. I also removed something called “tracing” and this debug-only “magic” checking from the CamelObject type (the magic stuff added 4 bytes to each CamelObject instance) and many other micro improvements. Most of the memory savings, however, happened by removing a few pointers from the CamelMessageInfoBase structure (the summary item structure in Camel). That structure is indeed a major contributor to why your Evolution is consuming a lot of your RAM.

Note that tinymail also uses an mmap. The size of this mmap is, at this moment, near the size of the allocated memory consumption. Does this mean that you need to double its memory usage in your mind? Not exactly. (On Linux) An mmap uses on-demand paging which is implemented in the kernel. Especially on devices with few remaining memory resources wont a tinymail based E-mail client consume a lot. The kernel will probably page-out most until you restart using the application.

I created a second memory analysis report for tinymail. You are hereby invited to reproduce the test and results. Feel free to add more memory reports and measurements yourself if you are interested in doing that.

Today I added a huge amount of code examples to the tinymail API reference documentation and fixed its Python bindings.

It would be nice if some native English speakers could point me to spelling fixes and/or make suggestions for the documentation. What is missing? What documentation do you people need more than what is available now? How can I improve it?

An overview of the available documentation:

• The API reference documentation which (now) includes (a lot) code samples;
• A few standalone tests that can probably also function as code samples;
• The development pages contain a lot interesting pages. Like pages with information about memory usage, library sizes, to do items and a listing of unfinished features, a listing of implemented features, class diagrams (they are already outdated after a week, but I’ll fix that soon), development tips, gdb debugging tips, refdbg reference counting debugging tips, how to implement a type and a unit test and how to inherit an existing type, how to perform memory testing, detailed per platform building information and finally documentation about how to write documentation for tinymail.

Yet I still feel like something critical is missing. From the webstats I noticed people are also looking a lot at the source code of tinymail. That, by itself, is definitely good. However, is that because it lacks documentation? Please do tell me. Please do express your criticism. I want to know it. The target is, indeed, to implement the project better than perfect.

I moved “the saving of mime parts” out of the tinymail framework. Examples of mime parts are the attachments of an E-mail.

I did this because the user interface for “saving them” will be application specific: your E-mail client might want to use a popup menu for telling the user “this is how you save this attachment”. But this other E-mail client might use the menu invoked by the left-top button on your cellphone. You know, the one above your “call” button.

If tinymail would implement a TnyMsgView by using a popup menu for this, it wouldn’t be possible for (for example) a vendor like Nokia to use that component on cellphones. Unless of course they would hack a gtk-type like the menu. Else they would be forced to fully implement a message view. While that, because everything in tinymail for that reason is an interface, is perfectly possible, it’s not as cool as allowing the developer to inherit mine.

To prefer things like strategy and decorator (delegation) over inheritance is one of those design pattern principles. Imagine I have just received a spreadsheet file in my E-mail box. Not having a viewer for that, my phone obviously can’t view that file. Ahhh .. maybe some phones have a viewer?! But I bet those phones are more expensive. Tinymail wants to be usable on both types of phones. Tinymail is for all phones, for all mobile devices, for all embedded appliances and soon for all web applications that expose E-mail functionality. If not, that’s a design bug which you can report.

Say there would be no good reason to save it on the phone itself. Maybe the phone will someday support a virtual filesystem? I doubt that, and if it will it might not be (at all) like our gnome-vfs. In my opinion, gnome-vfs definitely isn’t the right tool for that.

I made “the saving of a mime part” a strategy that the application developer can implement himself. I have a default type for saving, implemented using gtk+. It can be inherited of course. The interface of it can, however, also be implemented. For example an implementation that does nothing or one that saves it on “myspace” in stead of on the phone. You know, by using the secret GPRS service of this “myspace” vendor.

It’s not my business how they, the phone- and this “myspace” vendor, will agree on a feature like this. This is exactly why tinymail is LGPL, not GPL. They are encouraged and allowed to keep their stuff closed. They are equally encouraged and will get my assistance to open it. But one thing is a certainty: that it’s not my business nor a decision of some opensource community to make for them.

Soon tinymail will have language bindings for programming environments like D, Java and .NET. Programming with tinymail while using these environments will look like this. Feel free to CamelCase and fix coding style yourself (it’s just an example). The links point to the tinymail framework API pieces being used. I did that just in case somebody still believes that tinymail isn’t documented.

DotNetters: #define extends :\n #define implements ,\n #define super base

public
class MyOwnMsgView extends TnyGtk.MsgView implements Tny.MimePartSaver
{
        private Button save_button;
        private Tny.MimePartSaveStrategy saver;

        public MyOwnMsgView () : base () {
                this.save_button = new Button ();
                this.save_button.Clicked = new EventHandler
			(on_save_button_clicked);
        }

        public void on_save_button_clicked (object s, ...) {
                this.perform_save (super.get_msg ());
        }

        public Tny.MimePartSaveStrategy get_save_strategy  () {
                if (this.saver == null)
                        this.saver = new TnyGtk.MimePartSaveStrategy ();
                return this.saver;
        }

        public void set_save_strategy  (Tny.MimePartSaveStrategy s) {
                this.saver = s;
        }

        public void perform_save (Tny.MimePart part) {
                this.get_mime_part_save_strategy ().save (part);
        }
}

ps. Showing and explicitly linking to i.e. its documentation is indeed my personal technique for both forcing myself to do it, and proving that I did it. Unlike most libraries and projects, tinymail is documented. Its documentation, flexibility, design and testability are the top priority of the project. And … If I say that I’ll do it, I do it. Period.

A month ago I had this funny idea that the tinymail 1.0 API was not going to change significantly.

Strange that I have these ideas.

Anyway. I changed something significant. I changed the entire concept of viewing mime parts like attachments, pgp signatures, e-mail bodies and other mime parts.

There have been two to do items on the tinymail development pages. One about integration with Dates and one about having PGP support using for example Seahorse.

Both Dates and Seahorse are of course optional and probably will have to be changed to another something on your specific device. Don’t worry, I know that; Maybe indeed you have a in-house calendaring software installed on the mobile devices? Maybe you simply don’t support it? Maybe you want to upload meetings to a service on the Internet in stead of registering them with the calendaring tool on the device? I don’t know. Nor will tinymail know. But you will make it know about that.

I do know that there are a lot people, a lot devices and a lot possible situations to support. I also know that we have this one certainty in the IT industry: the simple fact that everything is going change sooner or later.

So the idea is to let you implement your own TnyMimePartView types. Possibly by inheriting mine but definitely not necessarily. You can, as with all tinymail types, implement using just interface and don’t care about whatever I cooked for you. Maybe you want to implement it using ASP.NET by letting it render a web page?

Tomorrow some stupid company x invents a new mime part that it uses for … I don’t know, calendaring or whatever. Adding support for this new mime part is simply going to be as difficult as implementing a new TnyMimePartView and registering it with the TnyMsgView.

I will soon create a TnyMimePartView implementation that will ask you whether or not you want to store an attached meeting request in Dates and another one that will verify a PGP key using, probably, Seahorse. They will, as usual, serve both as examples and as the implementations that will probably also be used by Modest on the Nokia 770.

One step closer to having an integrated PIM on your cute Nokia 770.

Oh btw. Bart reassured me he is still working on the .NET bindings for tinymail. Like all of us, he’s busy with his daytime job and building his house and stuff like that. I guess we will have to exercise some patience. The Python bindings are of course still functional.

I’m so lucky the people at VMWare created a great virtualisation platform that integrates well with the (Windows) desktop. Being a consultant, for my current/new project, I have to use a laptop provided by the company/customer for who I will do the project. I’m allowed to install any software on it. But I’m not allowed to replace the Operating System (Windows XP), as they have some strange agreement with Microsoft. Something like: your staff ‘has’ to use Microsoft software to do their jobs, so all company laptops ‘must’ be installed with Windows XP. Hrmm, strange Microsoft sales people with their strange monopoly strategies. Do they really think to win popularity contests this way? Do they really believe that this way, software developers will consider Microsoft to be a serious company?

So I will install the “software” VMWare player and I will add the software’s configuration data “a Ubuntu Dapper image” to that VMWare “software”. The dudes at IT, at my customer, agreed with that setup. I will be using NAT so that they will not have to care about the Linux OS asking for an IP address nor will they see a new MAC address in their super cool Windows firewalls.

And since the integration with that Windows desktop works smooth, it will not block me a lot from working. The task is upgrading some custom software that was created for Solaris. Can you imagine software developing for Solaris using Windows tools like notepad? At least now I will have GNU gcc and stuff like vim and gmake, heck I’ll even have Anjuta available in that Ubuntu VMWare image. That’s a lot better than having to install a bunch of crazy Windows tools or having to develop on an aged Solaris 2.6 where installing a modern GNOME on is more like a three week adventure than something you do in a few hours.

Thank you VMWare team. Great product. The product ‘really’ makes me much more productive. Yet you guys don’t market bullshit this a lot (like the VS.NET sales guys at Microsoft did and are still doing).

You have lies, damned lies and you have statistics like daily website usage statistics. I sometimes try to use these statistics to measure whether or not people are actually interested in this tinymail thingy.

In the graph you often see peeks. Especially in the blue and green colored bars which represents things like the hits and the amount of requested files on the web server. These peeks, not surprisingly, happen each time after I blog about tinymail.

More interesting are the visits (yellow and orange). Obviously the amount of visits peek a little bit the same day the blue and green bars peek. The good news is that the amount of visits stays relatively high a few days after the blog, whereas the amount of hits don’t. You can see this the 6th day of September and the 4th day. Same happened the 29th day of September.

Interesting is also that the amount of sites (unique IP addresse) are not very different from the amount of visits. Does this mean that companies do a lot visiting, whereas people do a lot hits? It’s a vague statistic indeed.

Maybe it’s just me interpreting the results the way I want them to be (the typical psychological mistake most people make when looking at statistical data). I believe it’s important to keep this psychology in mind. It’s the first full month that I measured this, I will of course measure it more often and try to identify both true trends and my psyche-mistakes.

I’ve been surprised by the interest in the project. I hope this will soon translate to project members, contributors and contributions. Chances are high there’s going to be very interesting announcements in future. Chances are equally high there wont be such announcements. A lot depends on how much competent people will invest time in the project. A lot depends, they told me, on my own availability and willingness to partly invest my own career in the project. If more people join the project, pressure on me will be less but interest in the project will be more.

A lot people told me that the future is web E-mail. For desktop, yes probably. Or maybe? I’m not even certain. For all mobile devices and embedded appliances, I’m less certain about that. I will also steer tinymail to be a framework for web E-mail application development. Not everybody will be using G-, Hot- and Xmail if E-mail will or would always be accessed using HTML. A lot companies might be interested in having their own E-mail appliance in their own company rack. Maybe E-mail services on devices like wifi routers? A lot companies hate having to deal with setting up both E-mail servers and clients like outlook.

A lot of today’s HTML E-mail services and websites suck on most, if not all, mobile devices. A trend or an unavoidable fact for mobiles? Is everything to become a website? Or is that just silly Web 2.0 marketing activity?

Too much people, including me on occasion, think black/white: they like their GMail thing and now think it’s simply impossible that there are other possibilities for E-mail, other then their own focus-idea about it.

I say, let us get some software built on top of tinymail. A lot people are waiting for Modest. Modest will happen. But I’m also interested in other users and cases. The API is going to be like this. That is a certainty. Yes, things are still going to change. But not as drastic as the last few months. It’s more or less becoming what I wanted it to be. Change is good, it means that you can request it when building your software with it.

But tinymail is designed with this change in mind. It’s flexible and adaptive. This means that change doesn’t necessarily mean API change. It means extending. Adding. Keeping it adaptive and flexible is what required the massive refactoring of the last months. Next time this happens, the major version number will flip and a new API directory and branch will be made. My plan is to guard API and ABI per major version.

Hey guys, howcome nobody told me about this one?

Cool. Thanks for the article Dirk-Jan.

No RedBull this time. Somebody more or less asked it. Poor you guys.

Returning a doubly linked lists is going to put your library at odds with higher programming languages like Java and .NET that don’t really have a corresponding type that can rapidly be converted in two directions from and to C and the higher programming language.

But who said that first of all, you need to return it. And second of all, that you can’t wrap it up in a GObject or GTypeInterface? I for sure didn’t.

So that is what I did for tinymail. I created both a TnyList and a TnyIterator interface. I’ve let my GtkTreeModel implementations also implement TnyList and created TnyIterator implementations for them.

The methods that give me a list of things, simply ask for the TnyList instance to fill up. Rather than return it (it could of course also return the one that it got from the parameters).

If now a language binding language binds the TnyList and TnyIterator API, just like other GTypeInterfaces and GObjects, everything will works just fine. Most language binding code generators do this automatically. If the proxy type being used by that binding implements the higher programming language’s list and iterator interfaces, the typical foreach and iterator patterns will work with it.

It’s one of those simple solutions for simple problems that very few people seem to tackle. Most people simply return a doubly linked list and that way burden the language binding creator with the task of supporting the method somehow in a typical C way internally in the proxy type.

A GObject really doesn’t consume a lot bytes. And you gain the freedom of how you’ll implement the list. You can still use a GList or GSList internally and enjoy the performance of that. You can also implement it as a btree or a skiplist perhaps. Depending on your mood, performance needs and the change that is a constant in the IT industry. Abstracting the list and iterator types using GTypeInterface makes your software more adaptive to changes. More flexible.

Oh and Jason, you are hereby kindly invited to join the development of tinymail. A framework for rapidly creating E-mail clients for mobile devices, embedded appliances and soon also web applications.

It having a focus on these targets doesn’t mean that with one extra developer, I can’t focus its development toward a framework (also known as the beginnings of) for a desktop E-mail client. In fact, Modest, a E-mail client being build on top of tinymail by Nokia, is probably going to be a desktop E-mail client for a lot people. After that (being under NDA with Nokia I can’t tell you more), the plan might be (hehe), who knows, to bring it to the Maemo platform too.

It’s likely (grin) that somebody is fixing it to work with the recent API changes which I have been introducing the last few months. These changes and my commitment not to release until all obvious API changes, documentation, unit testing and at least Python language bindings are fully working have been delaying such a release. A Modest release is also delaying that release, as the current idea is to in parallel with Modest, release the first tinymail version.

But then again, people tell me I code tinymail faster than my shadow. I even think that’s a direct quote from Florian (or it was something like that). I guess getting at a first version faster is therefore not really healthy for me anymore. By that I mean: I can use your help (especially if you want it faster).

The development pages of tinymail go in detail about what can be done and what should be done before a first release. They even explain development techniques and details. They also explain how to debug and measure memory usage correctly. In other words, there’s no excuse possible like: “but but, there’s no information about the code”. Lots of such information has been added recently. I often add more.

Oh and if you like Sylpheed, maybe you and me can investigate whether or not it’s doable to extract a libsylpheed out of Sylpheed and use that for implementing a libtinymail-sylpheed as a replacement for the libtinymail-camel? That would indeed be possible, yes. Or maybe a libtinymail-akonadi?

I stopped at a gaz station while I was in a traffic jam, bought myself a can of RedBull, and cause of that I basically opened my laptop and started hacking like a nut. Again.

Another consequence of the RedBull is this blog item.

Whenever we design or redesign a platform, be it a development platform or a user platform, both what GNOME is all about, we should always take into consideration that we aren’t really doing it for just ourselves. Nor are we doing it for just the current generation of people who are active as user or developer.

When redesigning or thinking about a new platform, we are also (and probably mostly) doing it for the next generation of people. The dudes and dudettes who are at this moment adolescents and who will in a near future (or have already) started to create a passion for computers and software development.

If we are going to decide now that a GNOME 3.0 should be as API stable with GNOME 2.x as possible, we are going to give them what is current today. Not what will be current when their tomorrow happens. Therefore I disagree with Johannes a little bit that we shouldn’t make (big) API changes.

We should make the platform of tomorrow. If that means breaking things, well, that’s why we need to increase the major version number. That way, people know that it’s different. Does this mean that we need to change everything like a nut would? No. However, in my opinion it also shouldn’t mean that we should be careful about not changing any API. If existing API is wrong or even a little bit suboptimal, then a GNOME 3.0 should fix that.

(In my opinion) The GNOME platform shouldn’t be called 3.0 for marketing reasons. If nobody is yet thinking about the platform of tomorrow, it’s my opinion that we should stick to the 2.x naming. I don’t think nobody is. Let those people use that 3.0 as place where they can put their experiments and innovative ideas. Let us not block them for another x years. The GNOME platform does need this young and innovative talent.

Let us keep GNOME young. And do as much as possible to attract young fresh minds and ideas. Of course, mix theirs with the existing experience. It will be a win-win situation. Which is, in my opinion, what free software is all about: sharing and passing knowledge. Experimenting. Etc.

I have very few to say about the quote. Except that any country that sends out such messages, is being ruled by sick individuals. That out of principle, I refuse to visit it.

I remember Mr. Bush recently told a reporter something like: “Men … my job is to protect you, to protect America”. What a piece of bullshit. “US bombs the world”, “To protect America”.

Maybe should the US start to “listen” in stead of “bombing”, “to protect America”. But don’t count on them listening to this advise. Words don’t sell, weapons do. Lives don’t matter, money and power does. Let’s make sheep people afraid of the damn damn terrorists! And call every country that isn’t 100% pro us, the terrorists. The so-called axis of evil! What a piece of bullshit.

In the eyes of Mr. Bush, I’m probably a terrorist. I blog terrorist things. Let’s bomb me. Terrorist terrorist terrorist. Everwhere terrorist. Ridiculous. I call the way how Mr. Bush calls everything and everybody a terrorists, a pure disrespect for the victims of for example events like 9/11. As if their death can be used to sell his agenda to frightened people. It’s actually embarrassing for many of the fine people who have to live under his rule.

Fear, it’s your only God. Don’t let some dude easily feed it. Don’t let some dude abuse your fears to gain more power. Teach your friends and family to independently think. To vote intelligent, in stead of steered by fears.

I would like to mirror a comment on my previous blog entry so that people in the US would at least see how their “democratic” decisions are having serious consequences on non-US peoples lives.

I wouldn’t agree if the commenter meant that US citizens are indeed fully responsible. I would, however, agree if he meant that US citizen are at least partially responsible for what is the result of US foreign policy.

It’s easy to throw the guilt at your government. But you are the people who should protest; You are the people who shouldn’t have voted for this government; You are the people that, while very few non-US people on this planet believed that it was possible, reelected this absurd current US government; You are the parents, brothers and sisters of soldiers that agree to fight absurd wars on behalf of their equally absurd governments; And YOU mister US-solder, are the person who pulls the trigger. In this case it where the Israel proxy soldiers pulling that trigger. I don’t see a significant difference. Both types of soldiers are murderers. Both get or got their highest orders from US politicians (don’t tell us the US had nothing to do with it, we are not idiots).

The comment:

As a Lebanese and an Arab having to deal daily with the results of the US foreign policy, I totally appreciate and salute your stance.

However, I feel that the US citizens (GNOMErs or otherwise) are responsible for the US foreign policy killing hundreds of thousands of people. They are responsible in the sense that they brought the current or previous governments to power and they have the power to change or protest their government’s actions since they live in a so called democracy.

Venezuela’s leader Hugo Chavez, said Mr. Bush promoted “a false democracy of the elite” and a “democracy of bombs”. I agree. Hugo Chavez said “He (Mr. Bush) came here talking as if he were the owner of the world”, I agree. “The UN in its current form doesn’t work”, he said. I agree.

I will not visit the Boston Summit because I’m against its country’s foreign policy. Try again when you guys have real and good leaders in Washington. I know the people organizing the summit aren’t responsible for American foreign policy. Their non-guilt isn’t the point. The point is philosophical: I can’t visit a country that doesn’t respect human rights, is directly responsible for thousands of innocent dead and of which its politicians think that they own the planet. They don’t. For me, visiting the country wouldn’t feel right.

My apologizes to them who wanted to talk with me. At GUADEC I hesitated because the group of people representing GNOME are great. It nearly overruled the problems I have with visiting the US. Recent happenings in the world, however, convinced me I shouldn’t visit the country. I simply can’t.

Xen might be very promising, yet this type of features I simply haven’t seen or successfully used with it:

The thing is that someday I want to try porting Tors Win32 Gtk+ work to WinCE. It’s definitely not a promise. However, I did start installing the environments that I would need for this. Among them are, for example, Visual eMbedded C++ 4.0, Visual Studio Embedded 5.0 and because you often also need it a Visual Studio .NET.

Surprisingly Microsoft gives away some of these products. The eMbedded stuff, for example, is free (not free as in free speech, only free as in priceless). For the others, like the operating system and VS.NET, I have access to volume licenses from my employer. Lucky me.

I first did a clean Windows XP Pro install in a VMWare Workstation 5.5.2 virtual machine instance, I upgraded the thing with SP2 and let the “Windows update” tool run over it a few times. This is indeed a few hours work just to get this done. We Ubuntu (Dapper) users are spoiled indeed (enjoying the wonders of apt-get install gnome-devel). First thing I did after I was finally done, was to create a snapshot of the VM instance.

Then I created a linked clone and called the clone “Windows XP pro with VS.NET”. I rebooted the clone, renamed the hostname, and installed VS.NET in the new instance. I created another linked clone and called that one “Windows XP pro with 2003 mobile”. I installed a bunch of eMbedded C++ 4.0 related tools in it. Like an SDK for PocketPC.

The result? The result is that I now have a setup where it’s easy to clone a fresh copy of a virtual machine that has everything I’ll need for testing and building my WinCE stuff. I can experiment, rollback, snapshot and clone stuff. I can archive them. I can very rapidly suspend and unsuspend the virtual machines (not the operating system, the entire virtual machine and its full state). And what is really great, is that it’s not consuming a lot disk space! Only ~10GB for all these installations together. That’s mostly because I used the “linked clone” feature of VMWare Workstation 5.5.2.

Using a COW device with LVM, something like this is probably also doable with Xen. But let’s agree that we don’t have these fancy ChipX86 wizards that do all the dirty stuff for me, for Xen, right? I also wouldn’t have the nice desktop integration. A terminal server client just doesn’t always cut it. For example, I want to resize the VMWare window and the guest OS should automatically adapt its resolution. Click on a button and have my USB stick bridged to the guest OS. Same for bridging the USB cabled connection with my mobile device so that Ms. ActiveSync which runs on the guest OS finds it. All that just works in VMWare. It’s amazing.

Anyway. That’s why I have to thank the people who are working at VMWare for this great piece of software. The software has already been worth my money, and will be in future. Nevertheless I’m of course also following up on Xen and other virtualization technologies. So far, however, VMWare hasn’t been beaten at the level of desktop integration and taking care of the type of features a software developer needs from virtualization.

Lots of respect for you guys at VMWare. An amazing piece of software you guys have made. Really impressive.

New tinymail development documentation (that might also be useful for software developers who are interested in contributing to GNOME related technologies, as most of the documentation explains the GObject type system which is also being used by a lot GNOME softwares):

• How to implement a unit test for tinymail
• How to implement a type (an interface) in tinymail
• How to implement a type by inheriting an existing one in tinymail

These are wiki pages which means that you (yes, you) are allowed to improve them. You can find more of this stuff here.