This is really sad because it took us a long time to find and train these people, and they would be massive assets if the future looked better. Although they will be greatly missed, I am at least reassured that they will have no problem finding new jobs. I do hope that they don’t settle for work that is anything but worthy of their experience and enthusiasm.

This downsizing happened because we are now finally losing the customer work we had from Nokia, as expected since their February 11th 2011 decision to kill MeeGo. Nokia are not our only customer, but they are by far our largest. That gave us the opportunity to diversify, and we tried, but without much success. That failure is mine. On the one hand, it’s unfortunate that we have been so dependent on one customer. But, on the other hand, we would never have been so big for so long without them. I would do the same again without regrets.

I view the last few years of Openismus very positively:

• We gave several young developers their first chance to prove themselves as professionals.
• We trained new developers. They are now established as respected and experienced developers.
• We made a few contributions to our favorite projects. For instance, natural layout in GTK+ 3.

Personally, Openismus has allowed me to work part-time, so I can spend time with my children. My first child was born soon after the company was founded, and for the first year, I worked from home, contrary to the myth that founding a company means working all hours of the day and neglecting your family. The tech industry is excessively male, with little understanding for men who want to share in the work of child-rearing, so I’m glad I had the freedom to work part-time. I am highly motivated to keep this freedom.

This has been a disadvantage, of course. For instance, I strongly suspect that I could win more customer work by traveling more to conferences and to customers on site. That has given good results when I’ve managed to do it. But this is simply an impossibility for someone who needs to take care of kids. I think the custom of business travel might be one of the greatest obstacle to women reaching top executive positions. It’s one of many things that won’t improve until men are forced to share more of the burden.

So, Openismus goes on, with some uncertainty. Our specific expertise in the Maliit input methods, in the QtContacts and EDS contacts systems, and in DLNA via Rygel should be very attractive, but time will tell. If you need help with GTK+ or Qt on Linux, from people who really know how, and are not afraid to tell you how, then we are still here and still ready.

6 0

Michael Hasselmann and Jon Nordby are both giving talks about the Maliit input method framework, as seen on the N9. We are eager to find customers who need our help to integrate and improve this only real choice for an open-source on-screen keyboard. So we hope that some people of influence take the opportunity to get to know the project and its excellent developers.

Jens Georg is also giving a talk about Rygel, used in the N9 to support UPnP and DLNA. For German speakers, there are already video and slides online of a recent talk that Jens did about Rygel in Berlin for Deutsche Telekom’s Developer Garden. I was amused to discover that DLNA had specified themselves into a situation where a minimum certified server and a minimum certified receiver were only able to share a small resolution JPEG format. Apparently it’s getting better, and Rygel can deal with it all.

6 1

As always, I’m proud of our Maliit developers at Openismus. We believe that excellent developers must be communicators, or their work is for nothing. That log shows why.

4 2

Maliit is the only open-source input system that offers the features real products need, allowing on-screen keyboards for all the world’s languages. It is mature but it needs more work. This is the right project at the right time for various desktop projects to work together instead of having separate hacks that don’t please users.

Everybody loves the virtual keyboard on the N9, which Openismus worked on. That is the Meego Keyboard, which is built on the Maliit framework. It performs. It’s largely open-source, but it is fine-tuned for the N9′s MeeGo 1.2 Harmattan. It has an unfortunate dependency on libmeegotouch, which few developers love.

The newer Maliit Keyboard does not depend on libmeegotouch, though it does depend on Qt and QML. With enough effort, the Maliit Keyboard could be as good as the MeeGo Keyboard.

The underlying Maliit framework API has been thoroughly tested and iterated by these keyboards and by other input methods, both open source and proprietary. It has had many contributors, has gained many regression tests, and is run by people who care deeply about quality.

Note that Maliit is not trying to be an on-screen keyboard for accessibility.

GNOME

We’d like GNOME to allow use of Maliit so people are not forced to use the current Caribou keyboard that only works with GTK+ applications and doesn’t offer features such as CJK or word prediction. We know that GNOME doesn’t want a hard Qt dependency. Of course that would be silly. We do want cross-platform compatibility. We also think that this is a large problem space that GNOME cannot tackle alone.

That would need gnome-shell (or its St toolkit) to support GtkIMContext as Maliit uses it. However, the gnome-shell developers currently feel that any on-screen keyboard (or input method UI, I think) must be part of gnome-shell’s own source code, and can’t be a separate process. Even if caribou could be made to work with non-GTK+ applications, a gnome-shell dependency is an even bigger block to cross-desktop adoption than Qt. So I really hope that this hard problem can be solved, though I do recognize that it’s hard.

The IBus implementation in gnome-shell seems to be hitting several similar issues (1, 2, 3), impacting CJK users even without a virtual keyboard. When they are fixed, maybe Maliit will work better. Note that, though Fedora has replaced SCIM with IBus, neither are really an issue for the on-screen keyboard, because IBus doesn’t let you show windows such as keyboards. However, the non-UI engines in the IBus plugins could (and probably should) be used in Maliit plugins.

I have some more notes about the current gnome-shell virtual keyboard here.

Unity (Ubuntu)

We’d like Ubuntu to use Maliit. We don’t know of any problems with that now, though I guess this depends on the GtkIMContext support in Unity’s nux toolkit library. We will do some tests on the WeTab soon.

Update: We published some Maliit packages for Ubuntu Oneiric in our PPA and we were pleased to find that nux seems to support GtkIMContext so you can, for instance, use the Maliit keyboard in the Dash’s search field. There are a few problems (1, 2, 3) but they seem fixable. There are also some generic GTK+ problems, but these are not blocked by anything fundamental in Unity.

Update 2 much later: That must have been with Unity 2D, using Qt. Nux doesn’t have an input method abstraction as of right now, though it could.

Ubuntu currently ships Onboard, though that’s apparently just for accessibility.

KDE and Qt

We’d like KDE to use Maliit for their tablet efforts. The Maliit keyboards work today in Qt and KDE applications, though I don’t know if that means that they work in Plasma too. They have a Plasma keyboard (source code) already, and there seems to be interest in using Maliit instead of, or as a base for that. That would give it features that it apparently lacks, while also sharing the maintenance workload.

5 1

Recently, MeeGo switched to GNOME’s Evolution Data Server for storage of contacts, calendar, etc, though not for the API, which remains QtContacts, via the qtcontacts-eds backend. To help with that, Openismus has been making e-d-s performance improvements for Intel. For instance, to avoid unnecessary transfer of data across D-Bus.

Tristan Van Berkom is doing the work, excellently as always, using upstream bugzilla, the mailing list, and upstream’s git.gnome.org. It’s gradually all going into the master branch. There are some special patches only for Meego’s branch, because it is based on the gnome-2-32 branch, whose API is partly deprecated in master. But we are taking the time to make equivalent changes in master’s new API.

We had worked on Maemo 5 (Fremantle)’s e-d-s fork, which used similar techniques to achieve the N900′s performance. But the developers weren’t given time to submit changes properly upstream. Also, some improvements were spread across other modules, some proprietary, though with hindsight the developers generally feel that many changes would have been better in evolution-data-server itself. It’s great that Intel are pushing for it to be done properly now.

Meanwhile we are also working on the qtcontacts-tracker backend alternative, which we like too.

SyncEvolution

At the same time, MeeGo switched to SyncEvolution for synchronization of contacts, calendar, etc with online services (via SyncML and other protocols) and with bluetooth phones. We are helping Intel with that too.

Chris Kühl has done some code cleanup which should hit the master branch soon and he is now letting SyncEvolution identify some phones via their Bluetooth Device ID profiles, where they exist. That could make configuration easier because the user won’t need to tell SyncEvolution what the phone can do or what quirks it has. Again, this is all via bugzilla, the mailing list, and gitorious, targeting the master branch.

Lastly, I’ve done some cleanup of the syncevolution.org website, simplifying its structure, and updating some text so it makes sense as a whole. I am still not fond of Drupal. David King wrote and updated the website’s documentation about the syncevolution command-line and GUI.

5 0

However, several Openismus people will be there to represent us: Ekaterina Gerasimova (Kat), Michael Hasselmann, David King, André Klapper, and Chris Kühl.

I will instead be taking my family to visit my side of the family in North Berwick, Scotland, where I’ll meet my nephew from New Zealand for the first time.

2 4

Hardware

The phone’s physical design has some fatal flaws. It has the four standard Android buttons at the bottom – Return, Menu, Search, and Home. But they are touch buttons instead of real buttons, and they are just as super sensitive as the main touch screen. Because the whole phone is so slippery smooth, that makes it incredibly difficult to use the main interface without touching one of these “hardware” buttons. Either the Return button, at the left corner, or the Home button, at the right corner, will typically close the current application. I find it very difficult not to trigger these buttons with my palm.

The on-screen keyboard is already awkward, but this makes it even more important to tap in exactly the right place and not a pixel lower. So it requires your full concentration and gives you the general feeling that you are defusing a ticking bomb hidden in a bar of wet soap. I didn’t have this problem with my older HTC Hero. If I was a regular user, who didn’t care about the Android software getting out of date, I would return the Nexus S.

The older Galaxy S doesn’t seem to share this problem completely. It appears to have a thicker bevel that should be easier to grip and it has less buttons at the bottom, in a slightly safer arrangement. However, two of them are touch buttons, so I guess it’s annoying too.

I generally feel that multi-touch ability is not worth the over-sensitivity of the capacitive screen, as it’s not used much in Android anyway outside of Fruit Ninja. I preferred the N900′s need for a very slight finger press.

Software

I’ve used an HTC Hero with Android 2.2 and the HTC Sense UI, and this is not very different, though regular Android lacks a consistent visual personality. However, I’m surprised that I miss some things from HTC Sense, such as:

• I love HTC’s clock and weather widget, with the full-screen animations of rain, frost, snow or fog that appear momentarily over the whole desktop. It’s useless but it’s charming. Regular Android 2.3 has just an ugly little analogue clock widget. Its weather widget is boring.
• My HTC Hero could upload photos and videos to Flickr, even integrating with the Accounts and Sync Settings, but regular Android 2.3 can’t.
• The HTC Camera application lets you focus on a point by clicking the picture. I don’t know if it really worked, but I liked the idea. I do like that the regular Android 2.3 camera app lets me click the button to focus and then release later to actually take the picture quickly.

These can be replaced imperfectly by apps from the Android Market, but that’s a frustrating experience of choosing between hundreds of similar apps, with no help to judge their quality.

Nexus S versus HTC Hero

This is a rather arbitrary comparison that’s of little use to anyone, but it’s the hardware that I’ve had.

I prefer the HTC Hero hardware because of the above-mentioned hardware problems, and because the chin stopped me from holding it upside-down so often. However, the HTC’s camera was terrible, while the Nexus S takes bright clear pictures and videos.

Android Versus the N900

Before I switched to the HTC Hero, I had used my Nokia N900 for almost a year.

I still miss:

• Contacts aggregation: The N900 combines contacts from Google Talk, Skype, Facebook, and others into one contacts list and presents communication with them in one Messaging application. It lets your Contacts list be your main start point for communication. Just start Contacts and you’ll see immediately who is online, by whatever protocol, because you can show them at the top of the list. Then click on a contact to call, send email, SMS, instant message, skype, etc. You don’t need to think much about what system you are using.
  Android does some of this, though a) You can’t show online people first, b) Its contact merging (“Join”) UI is clumsy, c) It often leaves the contact listed under the cryptic IM or Skype username instead of the real name and d) The Messaging application is only for SMS, e) the Talk application is only for (GTalk) jabber, f) There is no aggregated message history, so you need to go to the individual apps.
• GPodder: This podcast client has a sane, usable, uncluttered UI that made my life better. I’m currently using DoggCatcher on Android – It’s the best of several poor choices, but it’s still a mess that gets in my way.
• True multi-tasking: Multi-tasking in the N900 is truly useful, though it does indeed complicate the UI. Android does pseudo-multitasking – Apps store and restore their state, but they don’t actually do any processing while you are using a different application. But occasionally you do want to use another application because you really are waiting for the current application. This is most noticeable in the browser, for instance. Page display can be slow due to no fault of the browser and it would be nice if the phone let me do other things while waiting.
• The Camera hardware button. It’s very awkward to take a picture by holding the phone (trying not to touch those Back or Home buttons) and then clicking the small button on the touch screen to take a picture. With the N900, I just pointed the phone and pressed the button on the top side.

I do not miss:

• The N900′s chunky hardware. I used both the HTC Hero and Nexus S even more than my N900 because they are easier to carry around.
• The default to landscape mode. Consuming large amounts of text (newspaper content) or lists (twitter or facebook posts), is easier in a portrait layout. That’s why newspapers have columns – they know what they are doing.
• Non-flowing text in the browser. Android’s browser reflows text so you can read it. The N900′s browser often expects you to keep moving left and right on every line so you can actually read a paragraph. It respects the layout of the original page, but that’s little use on a small screen when I just want to read the content while ignoring the surrounding chaos.
• Difficulty answering phone calls. On the N900, when the phone rings, I would unlock the screen, at which point the display would rotate from landscape to portrait, just a little to slowly. So my finger would move towards the Answer button, but when my finger reached the screen, the Cancel button was where the Answer button had been.
• The N900 losing the cell phone signal and not getting it back without a restart or hacky GSM mode switch. I stopped using the N900 during our second pregnancy.

Overall, I feel that an updated N900, with thinner hardware like today’s phones, and slightly updated software, would compete very well with the current generation of Android phones. It would be way more attractive than a Symbian phone, though that’s not saying much. Of course, I enjoy several apps that are only available on Android, but I am not surprised that developers are not writing software for an API that Nokia declared dead before the N900 was even on sale, and for hardware that Nokia never tried to sell. Developers will even learn Objective C if it means reaching an audience.

4 2

My company, Openismus, provides bugmasters to corporate open source projects such as maemo.org. We know how to make the best use of outside contributions, so enthusiasts stay loyal, and we know how to manage bug databases for the long term. See the overwhelmingly positive feedback for Andre and Karsten, maemo.org’s bugmasters. They acquired these skills while establishing  GNOME’s bug squad, working on GNOME’s huge bug database.

I have linked to some Qt bugs as anecdotal examples of poor interaction with bug reporters. I am not interested in a discussion here of the technical aspects of these bugs. They are not meant to be technically critical. Also, half of them are for QtMobility, whose developers are generally very helpful, but even they haven’t learned the best bug-tracker habits. I don’t think I have seen enough Qt bug reports to have a fully representative sample, but my short experience does suggest that there are serious problems. I don’t mean to exaggerate or be unfair.

Awkward UI

Let’s look at a random bug. This view (not this particular bug) will be the first look at the bug-tracker for many people, as they follow a link to an existing bug. But it does not seem designed for humans. There are some particular problems:

How do I add a comment?

Typically, I’ll read the comments on a bug report to see what’s happening. But then there’s no obvious way to add my own comment. If I look around then I finally see a “Comment on this issue” link nestled among other less important action at the left hand side. I believe that many people won’t find that link, or will be discouraged by the awkwardness. I much prefer just writing a comment right into a bugzilla page.

Noise

The “all” page is too complicated, with lots of machine-generated noise. Instead of fixing that, there are tabs that show reduced views: All, Comments, Work Log, Change History, Transitions. This makes the whole page seem even more complicated.

The all page is so nasty that many people will switch to the comments page. But then comments lose their context. For instance, here (bug 7303) the Qt employee seems to be blaming the reporter though he is really just talking to someone that he has assigned the bug to. I’d rather just see a single page, as in bugzilla, without so much noise. The notification emails are similarly padded with irrelevant details.

Rush to close

We notice a strong tendency for the Qt employees to close bugs at any cost for any arbitrary reason as quickly as possible. Presumably they are under pressure to reduce the simple number of open bugs. But a bug-tracker exists to collect information that can gradually be used to improve software. If you think of everything as short-term and rush to ignore that information then you will not make the improvements and customers will assume that you don’t care.

Hard to check the fix

When I close bugs, I mention at least the commit message that I used. Sometimes I link to the commit’s web page on our gitweb or gitorious. But Qt bugs are often closed with a mention of the git commit ID (such as d65d3becc292523f0962aac9d2bf7b96d9c47c04), with no link. For instance, bug 8865 and bug 5729. I am thankful for the fixes but, particularly for documentation fixes, it’s best if I can verify it and reply quickly.

Viewing the change for a particular commit ID is awkward, requiring lengthy use of the command line outside of the browser. Even the gitorious web site doesn’t let me search for a commit ID, so I have to browse through pages of recent commits using the browsers find-on-page feature.

Actually, the person fixing the bug often cannot provide a gitorious web link at that time because that commit isn’t even public yet, because Qt’s gitorious repository is just a mirror, updated approximately daily from a secret repository. Things would be easier if they just worked in an open repository. In the meantime, Qt’s bug tracker should be hacked to recognize and link commit IDs, showing a “try tomorrow” page if the commit is not yet public.

Not supported. Not public

If the Qt developers decide (after the fact) that something in Qt is not supported then the bug may be closed, instead of leaving it open for someone to fix. But if something is not supported then it shouldn’t be in the release. For instance, bug 7334.

There’s also lots of Qt API that is used widely but not documented. Bug reports about the lack of documentation may be closed instead of leaving it open for someone to fix. But all API should be documented for the sake of implementation quality, regardless of whether it is public. And if API shouldn’t be used then its documentation should say that it shouldn’t be used.

Closing bugs because they require work

Bugs are sometimes closed because they would require effort to fix them. This makes no sense to me. Even if no Qt employee plans to fix them, they should stay open so others can fix them, and so that the information is kept in one bug report, with repeated reports being marked as duplicates. For instance, bug 5915.

Sometimes the idea of necessary work seems to be invented just as a way to close a bug. For instance, in bug 5729, a simple patch is not enough. The reporter is told that he must test it on multiple platforms, ignoring the possibility to test the harmless change widely during regular unstable releases.

For non-employees, the page even has some probably-unintentional machine-generated “You don’t have permission to work on this issue” at the left, just in case the reader didn’t feel unwanted enough already.

Out Of Scope

Likewise, if the Qt developers don’t personally see a problem as their priority then they will sometimes close it as “Out Of Scope”, regardless of whether the reporter cares about it or whether he might provide a patch.

Sometimes (bug 5729 again) this happens without the Qt employee even writing a comment explaining why. This is the bug-tracker equivalent of “Go away. We don’t want you to use our software”. Stopping this should be a top priority.

I’ve also seen one case (bug 6074) where this was used when the Qt developer meant “already fixed”. Until I asked for clarification (most people don’t) I assumed that they just didn’t care.

Can’t reopen bugs.

If a fix is not good enough, or the Qt employee has misunderstood the problem, I can’t reopen the bug. That is very frustrating. Most people will not beg for the bug to be reopened or even bother continuing to comment on the closed bug. Luckily we do have the option to submit gitorious merge requests when our bug has been incorrectly closed. For instance, bug 11496.

Can’t close bugs

There’s also no way for external contributors to close bugs. So Qt gets no outside help with bug triaging. This arbitrary separation between employees and external contributors is an obstacle to open development.

8 0

As far as I can tell, you must do it like this:

Create a remote clone

You can do that via the project’s top level web page. For instance. Then you need to “checkout” that clone on the command line.

Or reuse an existing clone, though you’ll have to rebase against the original, probably fixing some awkward conflicts from previous commits to your clone if you haven’t used branches for everything as I suggest below. It looks like people often create new clones for each merge request.

Create a branch in your remote clone

For instance:

• git branch mr_dosomethingtofooforgoo master
• git checkout mr_dosomethingtofooforgoo
• Make your changes, add and commit them.
• git push origin mr_dosomethingtofooforgoo

Request a Merge

Click the “Request Merge” button at the right, when looking at your clone’s top-level. For instance. There is no “Merge Request” button when looking at an individual commit, or even when looking at a branch. This would make it far easier to submit small changes.

Then you must copy/paste the first-line and details from your commit message into the two text fields on the Request Merge form.

You must also choose your branch name from a drop-down list and choose the commit from that branch that you want to use.

Then you can finally click “Create Merge Request”.

4 5

Autotools Tutorials

Years ago I wrote some popular introductory web pages showing how to do the obvious important stuff. David King has updated them and put the examples in git. They are now even simpler, because autotools got even better in the meantime. I think they will be useful.

Autotools with Qt Creator

Some of us like the Qt Creator IDE. So we asked Peter Penz to create a qt-creator plugin that provides some autotools support making it easier to use qt-creator with lots more existing projects. For instance, you can now have some code-completion in qt-creator with autotools-based projects, and you can run the whole build cycle from inside the IDE. Looking at the code, it seems fairly easy to create these plugins once you know how.

It currently works with the stable qt-creator 1.3 (ignore the uneven version number) though you’ll need to build it from source yourself for now. There is some interest from the qt-creator maintainers, so we hope to find time to update it for qt-creator’s master branch, which uses Qt 4.7 (currently unstable, but eventually stable with the same uneven version number), and then make a proper gitorious merge request.

By default, qt-creator uses qmake, though I think there is some CMake support. qmake is a time-wasting copy/paste-encouraging feature-lacking broken failure, so anything that helps people to avoid it must be good.

12 2

After they have settled down, they will be studying hard and probably looking for easy ways to help real-world projects such as gnome-love, with our assistance. It won’t be long before we start thinking of them as junior developers instead. I don’t envy them the hard work but I do wish I’d had the same opportunity.

3 5

This means we are still looking for an extra Qt developer to work in our Berlin office, so please do email me.

3 5

Please email me if you are looking for work and can show me some public involvement. I like having URIs for blogs, ohloh, git/svn, mailing lists, etc, to see your personal sense of code quality and your ability to communicate. We ideally need people who can work in Germany, probably moving to Berlin.

(We do GTK+, gtkmm, and Qt development, and we like really knowing them all. These days Maemo/Meego developers need a wide range of experience.)

8 2

These were our overall aims:

• Familiarity with the programming languages, toolkits, and tools, beyond the average.
• Good quality habits – documentation, ChangeLogs/commit-messages, bug filing, simple code.
• Good communication – politeness, precision, knowing who/where to contact, tracking progress and following up.

And this is the stuff that we checked off along the way:

Knowledge of C

• Respect for memory. True understanding of pointers.
  • Understanding of the many ways to use * and & and [], declaring and dereferencing.
  • Understanding of state (Such as a widget’s data, or a user_data struct, or a C++ class’s member variables.)
  • Understanding function pointers, including their weird syntax, made easier by use of typedefs.
• Basic understanding of object-orientation – Write functions that have a namespaced prefix and that take a first self/this parameter.
  • Write init and free functions where appropriate.
  • Don’t use a prefix that is used by an existing library.
• Use of enums (or defines if necessary, or static constants if appropriate) instead of magic numbers/strings.
• Breaking code up into small blocks, separated by empty lines, with pseudo-code comments above each block. In small functions, of course.
• Initializing local variables, even if you don’t think it’s necessary.
• The GTK+ coding style, which is common for C.

Knowledge of GTK+

Familiarity with GTK+, to the level of implementing new widgets.

• Reference-counting: Conventions and special cases (gstreamer and tinymail use a different convention, for instance).
• Child widgets don’t really use reference-counting. They are destroyed by parents regardless.
• Glade and GtkBuilder
• Implement a new widget, doing some custom drawing and/or containing some child widgets. Make sure that you understand what the various construct/init/finalize/destroy/etc vfuncs do.

Other C stuff and basic tools

• Tools: gdb, valgrind, svn, git, diff, patch.
• Writing ChangeLog entries or commit messages (mentioning files and functions, and what changed in them and why).
• autotools
• gtk-doc syntax, and knowing what developers need to see in the documentation. Mention the what, when, why, how, and “see also”.
• Familiarity with Clutter, to the level of implementing new actors. See the Openismus Clutter tutorial.
• Fix some GNOME bugs, submitting patches. Maybe work with the gnome-love group.

Communication

• Join the relevant GTK+, GNOME, Maemo, and Qt mailing lists.
• Add Openismus employees to your GNOME bugzilla Users To Watch list. Someone will watch yours too.
• Be repeatedly told to file bugs and patches, and to follow up on them. File bugs about documentation too.

Familiarity with C++ – at least the parts used by gtkmm and Qt

This takes more time than anything else, but its doable with motivation and mentoring from our experts.

• Read a full book, such as Accelerated C++, cover to cover.
• Understanding of classes, constructors, inheritance, polymorphism.
• Understanding of references.
• Understanding of const and mutable.
• Templates. And template specializations.
• Use of std containers.
• Familiarity with gtkmm (easy because they know GTK+ already.)
• The gtkmm coding style, which is common for C++.
• The doxygen/javadoc syntax.
• Wrap some new GTK+ API for gtkmm.
• Fix a Glom bug. For instance, there are some simple Glom gnome-love bugs.
• Familiarity with Qt. Understand what moc does. Do something real-world with it’s (quasi) model/view widgets. Understand QString historical oddities.
• Maybe find a bug to fix in KDE.

Optimization work

• Understanding processing, memory, and IO costs.
• Avoiding premature optimization while avoiding obvious performance errors.
• Using Oprofile, SysProf, system tap, etc.

Debian/Ubuntu packaging

• Package a new version of an existing package, such as Glom, in the Openismus PPA.
• Package something new for Ubuntu.

Embedded Linux

• Use of Scratchbox with Maemo.
  • Port something to Maemo.
  • Package it for maemo-extras.
• Using a BeagleBoard:
  • Set up the BeagleBoard and get something running.
  • Try to install Mer.
  • Putting a self-built distro on generic hardware (BeagleBoard), using Poky or OpenEmbedded.
• Be aware of differences/pros/cons between Poky and OpenEmbedded.
• Document how a customer might prepare and maintain a custom debian (or Ubuntu) distro for their embedded hardware project. For instance, how to install and use an autobuilder for packages.

12 0

So we need some more people to repeat our success. Here’s the text from the first time:

If you are smart and enthusiastic but you lack experience then we can provide the opportunity. You would work mostly on existing open source projects instead of customer projects, just to get experience with C, C++, GTK+ and Qt. Our developers would provide technical guidance and encourage you to work and communicate in a structured way, creating software that’s actually usable and useful.

This is also a great opportunity to move to Berlin – a wonderful city for young people. Munich may also be a possibility if necessary.

I’d also like to point out that we are very much an equal-opportunities employer. We get almost no applications from women or minority groups and that’s not good enough. We are a small company so every new person can make the place more like themselves.

Please send us an email telling us about yourself. Show enthusiasm and show us anything you’ve done in the open source world already. As before, I will filter out the least suitable candidates by expecting you to find the appropriate email address yourself. Unfortunately, as before, it’s unlikely that we’ll want to deal with visa paperwork if you are not already working in the EU.

Update: We think we have chosen our new trainees already. Stay tuned. Do bug me if I have not replied to you.

14 1

That means that we will be flying in an airplane on Friday to Helsinki. I’ll be around for work stuff on Monday and Tuesday too. Most afternoons are planned out already, and evenings are generally difficult with a child, but I hope to see random Nokia/Maemo people, maybe at lunch. I shall be pinging you.

We are looking forward to seeing old friends who we don’t get a chance to see often enough.

Kat, David, Mathias, and Daniel will be around too.

11 3

Obviously Peter will help Openismus as we gain experience with Qt for Maemo 6 (Harmattan) in addition to our continued use of GTK+ and gtkmm.

Peter will work from home in Linz, occasionally visiting the office in Berlin. I like the idea of another office in Linz though.

10 0

However, massif’s behaviour has changed and those graphs are no longer generally appropriate. But they were nice. So I hacked a copy of the current ms_print perl code, producing massif_grapher. Forgive me for my perl code.

I used perl’s GD::Graph module. It worked but it’s a little eccentric. The image size is hard-coded and needs to be increased in the code when Gd::Graph complains that the vertical or horizontal space is too small, if you have too many data points.

massif_grapher.pl outputs a massif_pretty.png file:

• There’s a simple graph (the default) that just shows the stack and heap allocations, splitting the heap up into useful and extra (allocated as an optimization) . It doesn’t mention any functions. See this example.
• And there’s a detailed graph (via –detailed) that tries to show the old-style cumulative graph, with color for each allocating function. See this example. I won’t put it directly in my blog because their’s some obviously weird stuff happening at the top. Also, the legend needs to be reversed so it’s easier to associate the functions with the blocks on the graph. Patches welcome. You’ll get weird results if you don’t specify–detailed-freq=1 to massif.

Time will tell if this is useful.

Other useful massif tools:

• Eclipse Linux Tools’ valgrind support: Scroll down to see the video for their massif support. This allows you to jump right to the code. Useful if you are using Eclipse.
• massiftool: A Qt-based application for navigating massif snapshot data.

12 2