Diary and thoughtspace of Rune B. Broberg

Menu

Post navigation

From the early days of palm-top devices, through early smartphones like the Nokia Communicator, and up to all the iPhones, Androids and BlackBerrys of today, what the serious users have been looking for has always been PIM: Personal Information Management. They are looking to have their email, calendar, contacts and notes available at all times, on a small portable device. Indeed, as am I. I have been using my Nokia N95 for a couple of years now, and there really is something to be said for having my calendar with me at all times, just by the virtue of carrying my phone.

So what have Google done with Android? They’ve put Google Mail, Google Calendar and a Contacts synchronization to Google Mail in their fine mobile operating system, which goes some of the way. They have also, I am told, put in a regular IMAP client, for those people who don’t use Google Mail, for instance for corporate email. But, it seems, the fun ends there.

There’s no direct support for SyncML, and nothing, it seems, for Exchange. Sure, you can go through Google Calendar for your calendar syncs, and I presume you can forward your mail to Gmail – if your corporate policy permits that. But when it comes to direct sync for third party providers, no luck.

It’s starting to look a bit like what some of us have criticized Apple’s software for doing: If you don’t use it like Steve Jobs does, you’re out of luck. In this case though, even more so: If you don’t buy into Google’s services, no luck with Android’s default apps.

So someone could just develop a sync adapter for the built-in calendar. The source is available under the Apache license, so why not? Here’s why: Google have stated that the API for the built-in Calendar is not public and not going to be for 1.6 or 2.0, which leaves a worrying question: Are Google only going support their own services from the base OS?

It’s certainly not completely unthinkable, as Android has been hailed as an open platform, so anyone can just code a Calendar app, right. Right? Well, maybe. But selling smartphones with no proper PIM solution for anything else than a single provider doesn’t seem like a viable business to me, and I really do hope Google make up their mind to do things differently, and support direct over-the-air synchronization with SyncML, CalDav or even Exchange systems.

Finally, an update for the blog! Well, what has been going on with me? I’ve been busy at work, and perhaps even busier with my studies. I’m currently doing a course on Concurrency, which got me started on a bit of lovely threaded java programming again. It’s nice to be back to writing a bit of code, and boy have things gotten better over the few years since I last did anything major with it.

In other news, a couple of friends have bought themselves new Android phones, the HTC Hero. More and more of them are coming now, and it really looks like a wagon I’m liable to jump on any day now. They just need to release a new revision of the hardware, preferably something with one of the new Snapdragon CPUs in it …

So what could be more logical than to do a bit of programming for the Android platform? I struggled for a short while to figure out anything worthwhile to write, but then I came up with this: How nice would it be to get the status of your monitored systems direct on your phone? No more needing to browse to the hobbit Xymon system now, just a look at the phone to see how everything you care about is doing. Well, in theory. Except I don’t have the phone yet. Slight flaw in the plan.

None the less, I’ve made the software, in a sort of early beta version, and it’s available on a webpage of its own: Xydroid. Feel free to have a look .. if you want to actually use it, you should probably get in touch, and I’ll be sure to work on it enough that it will actually work properly as well.

After I’d started writing the software – actually, after I’d gotten quite far in the process – I found out that other’s have actually done the same as well, in the form of Xymon Monitor, for which they charge €2.99. Well, at least this might end up as the slightly cheaper alternative 🙂

The directory server we use at work is a Fedora Directory Server installation, running 4 nodes in a multi-master setup. We’ve been looking into migrating it to a Sun Java System Directory Server Enterprise Edition (sic) for a while, since I returned from the course in the US, but I haven’t had the time to get a proper test installation running yet. With Beehive 1.5.1 out, and given my enthusiasm for that, I decided to try and see if it would work with the Fedora Directory Server, even though it wasn’t supported.

I went with the template for synchronizing a Sun directory, as my sources had told me the two were very similar, in fact originally from the same source tree. The templates are pretty readable, but have manual handy for checking what some of the stuff means. One caveat: The attributes in the template are generally written like this:

<profile_name><enter profile name here></profile name>

What they expect you to write, is something like this:

<profile_name>Test profile</profile_name>

The extra angle brackets are just put there to confuse us 😉

My main concern at this point was that while I could define specific attribute values to mean external mail or not, it didn’t seem like this could be set merely by the presence of absence of attributes. I may have to re-think the directory structure slightly to address this.

When I added the profile using beectl, it turned out not to validate. Beehive was unable to find the directory server changelog. As it turns out, Beehive relies on an “old-fashioned” approach to synchronization between directory servers, and in fact one that can be enabled using a “Retro Changelog Plugin” for the Fedora Directory Server. So, if you’re on Google, trying to figure out how to make Beehive work with Fedora Directory Server: Use the Retro Changelog Plugin!

After setting this up, things seemed to just work. Now, there’s another little caveat: Beehive works with a concept of “principals”, that are your login credentials; In the default case your email for login and for instant messenging, and your phone number for voicemail. I changed the mail principal to be the user’s UID, but left them for IM and voicemail – meaning some users weren’t imported into Beehive, as it insists on the attributes used for this (mail and telephoneNumber) being unique in the directory. We have people who rightly have the same telephone number, for instance sharing an office, and Beehive doesn’t seem to like that. My idea of how to handle it: Make seperate attributes for voicemail-principals and instant messenging principals if you’re going to need those things, or disable them in the sync profile.

I would rather like for all our users to have an instant messenging principal that’s their UID @ some domain. I haven’t been able to find the option for it yet, and I’m not sure if it exists at all … if you know it doesn’t, and you’re a Beehive developer: Go fix this! 😉

Oracle released version 1.5.1 of their new-ish collaboration product, Beehive, on Friday. I’d been waiting for it ever since returning from the course in the US, and I was eager to try it out this morning. My setup was this:

All machines are Dell SC1425 with a single 3GHz Xeon CPU

Database server with 4G RAM, 250G disk for the database and some swap, and another disk for the OS

Beehive server with 4G RAM and just a system disk

Enterprise Manager server with 1G RAM: Don’t do this at home, it needs a lot more than 1G. Slooow.

I had preinstalled Database 11.1.0.6, as this was the latest recommended release for Beehive 1.4.3. The Enterprise Manager was set up with this. I hadn’t done any patching at all, since I just wanted to try it out from a clean install.

Not surprisingly, looking at the track record for Beehive, the first install with a vanilla database didn’t work. Some of the schema deployment failed, which was the same sort of error I got with 1.4.3 when I first tried installing that. Main problem: Oracle hadn’t released the documentation for 1.5.1 yet. I decided to try patching the database up in the same way required for 1.4.3, ie. with patches 6168363, 6708565, 6750049 and 6526468. At first, it seemed to do the trick – the installation worked way past the schema bits – but during the framework deployment, starting the beemgt service failed, and the installation stopped. Retrying the step didn’t seem to make any difference, and that’s where I left it at work.

Tonight, though, Oracle have released the documentation – linked above – with a few more interesting notes in it. There’s two more patches mentioned for 11.1.0.6, but those aren’t actually available to us regular users through Metalink. More importantly, Oracle seem to now support version 11.1.0.7 of the database, and from the Oracle Forums I understand that it’s actually the prefered version. You just have to apply a few patches – 12 to be exact, at the time of writing.

I’d better upgrade the database when I get back tomorrow. Check that all the table parameters are set correctly, install that dozen of patches, clear out the old Beehive database and set up a new one – and then see if that makes the install sail through. Somehow, I doubt it. Beehive is a nice product, but the installation and making all the bits fit together seems to hinge on having everything set up in exactly the way they have over in Redwood Shores – and maybe that’s just too much to ask for.

Update – 5 May 2009:

Clearing out the database didn’t make much of a difference. However, after trying that, I tried going over the client side, making sure it was absolutely pristine before I started – and again I checked the database, creating it exactly as was specified in the manual for 1.5.1. Et voila; suddenly I had a Beehive 1.5.1 installation. At least, it got a lot further – so long that I actually had to leave my office before it finished, so I won’t know the details until I get back tomorrow.

I happened to arrive rather early at the first day of the course, having gotten up very early due to a bit of jetlag. I’d met some of the other course participants in front of the hotel that morning, and we quickly got to talking about the course and our expectations. As it turned out, a large portion of the participants were from academia, either universities or in one case a research institution. There were a few people from real businesses as well – and over the course of the week, quite a few people from Oracle who were either in the course, or just popped in to say hi.

The location was a decent, not very conspicuous building on the edge of the Oracle campus – in fact, across a bridge over a small stream from the main Oracle campus. Free drinks and snacks were provided, which is always a nice bonus 😉

The course itself consisted of 20 lessons in all, ranging from architecture overview and installation tasks over how to use the system as an end-user, to system administrator tasks and backup. Most of the course lessons featured a practical exercise in addition to the traditional classroom slides and lecture-presentation. After going through the initial presentation of the course structure and the Beehive architecture, we proceeded to trying to install Beehive ourselves on our prebuilt OVM-machines. This turned out to be a bit more of a challenge than we had first expected.

The installation procedure for Oracle Beehive is quite simple – at least if you already have the database set up and preconfigured, which Oracle had kindly done for us. It’s a lot of clicking “next” and typing in well known information, such as your database server, and which system passwords you would like. You also have to decide on your “enterprise name” at this point, which seems to be a quite static and somewhat exposed parameter, so it’s probably something one would want to have thought about beforehand.

The actual installation process starts after these few windows of clicking “next” – and it’s quite a long procedure. Granted, we did run the databases and the Beehive instances on the same virtual machines – you might not want to do this, for several reasons – but it took about half a day. This would have been okay, if the installation had been just that – okay. But for a small number of the course participants, it didn’t go quite well – and for one, the one sitting next to me, it took several tries over the next days to get a working installation.

This experience of installations failing was not a new one for me – I had the same problem back in December, when I tried installing 1.4.1. We were running an internal 1.5.0 beta, though, and both the course lecturers as well as the visiting Oracle product managers ensured us that this was because we were running on low-spec uncertified Oracle Virtual Machines.

At first, the curriculum seemed very basic – the first chapters were installing the software itself and the management software, Beekeeper, which wasn’t very complicated. However, it quickly picked up on the second day, with in-depth coverage of areas like LDAP synchronisation and logging. We had a lot of material to get through, but the schedule was loose enough that we were allowed a full hour for lunch, frequent breaks and time to spare for when the several different product managers for parts of Beehive popped in to say hi.

A few of the lessons were not accompanied by practical exercises, in particular the Exchange coexistance part. While the theoretical coverage was good, anyone wishing to implement this should probably arrange for some hands-on practice in addition to this course before attempting. Most of the practical exercises were good, though they all had very explicit instructions, and didn’t require much on the part of the student to complete. Still, they allowed a good feel of how to work with Oracle Beehive.

In conclusion, I was very happy with the course, but in particular with the amount of contact with the product managers and developers – something that’s not likely to make it into the final curriculum 😉 Still, I wouldn’t hestitate to recommend this course to anyone, and I would also recommend taking a good look at Oracle Beehive when choosing your next collaboration software. More about the product itself in a later post.

I’ve been on a bit of a roll with my IPv6’ing the last few days, getting reverse DNS up and running, the mail server set up properly and so on. So by now, you should be able to reach me at mihtjel@mihtjel.dk – if you have IPv6.

The last thing that really bothered me was that despite having the IPv6 Google as my start page in Firefox, all my searches were still IPv4. That is, until I found out how to create an “Open Search Description”-document. If you want, you can add Google IPv6 search – or view the file yourself before doing it.

A discussion popped up this morning on one of the major Danish newspaper’ website (in Danish): Should the television license paid in Denmark be a part of the tax, instead of as it is now, paid separately? The idea was aired jointly by the culture spokespersons of both the largest government party, Venstre, as well as the largest opposition party, Socialdemokraterne, in a rare display of complete agreement on a previously controversial subject by the two parties.

However, it quickly turned out it wasn’t actually an agreement. The political leadership of Venstre quickly issued a statement that the views of the culture spokesperson were not the official views of the party, and that the idea had not been discussed in the party leadership. Bummer. At least the idea got some airtime, and hopefully started some discussions.

The television license in Denmark is in fact known as the media license, since it no longer covers just television and radio, but also computers capable of playing online media content, or mobile phones with such capabilities. It is estimated that 99% or more of all Danish households should pay the license fee, yet only around 93% do. The fee is currently set at 2190 kr/year, and is in effect a regressive tax, in that practically everyone is liable to pay it, but for a low-income individual the percentage of income paid is higher than for high-income individuals – for a student on government allowance, the license fee sums up to 3.6% of his or her income.

I’m fully in favour of changing the current system, and I’m sure most of the population are as well. The main beneficiary of the license fee however, Danmarks Radio, is not. One reason may be that all the current license fee collectors would be made redundant, which is of course a concern. More likely is it that they fear too much government involvement, should their money have to come from the taxes rather than from direct collection. While I sympathise with such fears, the system works for many other organisations without evidence of government involvement, and the board of Danmarks Radio are politically appointed, 2/3 by the parliament and 1/3 by the minister of culture.

In all, I hope this brave outspokenness of the culture spokespersons pays off, and that we get a renewed debate in this country about the social imbalance of the current system. Or, if not in this country, then on this blog. 😉

Over the last 7 years or so, I’ve played with IPv6 from time to time. I’ve had tunnels set up several times, and they’ve fallen over again due to kernel upgrades, or just because I didn’t really use them. Now I’ve set up another one, but this time, I have found some actual uses for it – sort of, anyway:

1) My web server runs IPv6, and DNS works for it. This blog now works with IPv6 access. I’ve already had a couple of hits on that connection, but not very many. From earlier experiences, I know that this means some people will have a hard time getting to it, due to having a non-working IPv6 setup, and browsers prefering IPv6. Well, if that’s you: Get with the programme, and get your IPv6 fixed.

2) I made my phone – a Nokia N95 – work with IPv6. Actually, I’m bragging where I shouldn’t be: I figured out how to get my wireless network to accept the phone, and as soon as that worked, the phone picked up an IPv6 address, and I could access the test site I’ve been using, http://ipv6.beijing2008.cn/.

I was a bit surprised at how easy it was, but it seems that the consumer end of electronics is really getting ready for IPv6, even though various routers and ADSL-modems aren’t. Next step must be to convince the boss to let an IPv6 VLAN close to the servers so people can start using it for something.

When you have colleagues like mine, taking a photograph of the tiramisu before it was eaten isn’t a suggestion that’s likely to be accepted – so you will have to contend with a picture of what was left:

They did all enjoy it, and all my hard work yesterday wasn’t entirely wasted.

Recipe

The amounts are for about 12 people, and they can probably be multiplied. You could probably halve it as well, but making much less than that is an affront to the recipe! 😉

Ingredients

8 dl espresso (or strong coffee)

2 dl amaretto or marsala – I like amaretto

500 grams lady fingers (savoiardi) (or more or less, depending on the tray you use)

200 grams sugar

8 egg yolks, pasteurised

8 egg whites, pasteurised

750 grams Mascarpone cheese

Vanilla

Cocoa powder

I used 750 grams instead of the 1000 grams recommended in the book I adapted it from (Spise med Price, DR Forlag 2008). I liked the result, though some more of the cheese might be nice. It wouldn’t have fit in the tray I used anyway.

Method

Brew the coffee, mix it with the amaretto and leave it to cool.

Mix the egg yolks, sugar and vanilla – I just added more to taste later – and whip until light and fluffy. This will take a while. Mix in the Mascarpone. Whip the egg whites and fold them in, to make the mixture lighter.

Pour the coffee mix in a flat-bottomed container, and dip the savoiardi sugar side up, so the mixture almost reaches the sugary bit – lift them up right away, and place sugar side down in the tray. Cover the entire bottom of the tray this way.

Cover with a layer of the egg-cheese mixture, about 1 to 1.5 cm thick. Use about half of the amount you have. Add another layer of savoiardi, and another layer of the mixture, making sure to level it out nicely.

Cover, for instance with aluminium foil, and refrigerate for at least 6 hours – I had mine in the fridge for 18 before serving.

Right before serving: Dust with cocoa powder – not the sugary stuff used for making drinks, but pure cocoa. Enough should be added that it looks like a dry layer on top of the tiramisu (in my opinion, anyway).

Probably stores well, but there’s not going to be much left anyway 😉

Depending on how long you dip the savoiardi, the tiramisu will taste more or less of coffee, and be more of less mushy. Finding the right balance can be a pleasurable job, as you need to make a new tiramisu each time 😉 There’s a bit of work in making a tiramisu, but it’s lots of fun, and it tastes great. It may not be too healthy to eat it all oneself, though.

I’ve been looking to make some tiramisu, and for that I’ve decided on a recipe. It’s from “Spise med Price”, a Danish cookbook made to accompany a TV show of the same name. This recipe uses – for 6 persons – 4 egg yolks beaten with 100 grams sugar, with Mascarpone mixed in (500 grams), lightened with 4 beaten egg whites. Easy.

However, when I went to get the ladyfingers to use for the recipe, it had a different recipe. This called for – for 5 persons – 3 egg yolks, sugar and only 250 grams Mascarpone. Still the same with the egg whites.

Curiosity now piqued, I looked at my new Joy of Cooking for a recipe – and lo: 12 servings needs 5 egg yolks, half a cup whipped cream(!), and about 400 grams Mascarpone. This is quite different, since it uses whipped cream instead of the egg whites – and doesn’t seem to need as much amount of filling as the others.

I decided to press on and look at my Italian cookbooks, namely one called “Culinaria Italia” and one called (in Danish) “Italy – temptations of the Mediterranean”. The first calls for 4 egg yolks, a cup whipped cream and 500g Mascarpone, while the second (for 4 people) uses 2 egg yolks and whites and 250g Mascarpone – same proportions as the original one I looked at.

To sum up: To make tiramisu, you need a number of egg yolks and some Mascarpone, between 30 and 80 grams per person, and either whipped cream or beaten egg whites to lighten it with. And I haven’t even started to look at whether to use Marsala, Amaretto or other sorts of liquor for the ladyfingers…