August 2008 Archives

Sunday, August 10th, 2008, Jean-Patrice Chiasson, my father's dad, "grand-papa" to me, passed away, at the venerable age of 95.

I was able to attend his funeral this Friday. It was a very nice event, tons of people showed up, and I even saw some family members I hadn't seen in years.

To me, he was this mythical man, this doctor that cured the sick, and kept working for free until he was close to 80. Not a man of many words, but often always knew the right ones. Even if I don't think he never really understood what I do for a living, he was always able to provide me with amazing insight into my life. I remember many occasions where I was giving him an update on what's hapenning with me, and he would listen carefully. Then, almost without fail, he would ask a question, or make an observation that was always spot on. He was a very generous man, and ended up, almost secretly, financing all of his grandchildren studies, mine included.

I have so many memories of the itme I spent in their Sutton home as a kid (and later, as a grown up). The gigantic hill behind the house we loved to slide down in winter. The cold creek we build barrages in, with the woden overlooking bridge. And the maple forest where they made maple syrup every year. Every year, my grandma would drink a whole glass of the first batch they made, still warm.

La Tribune, the Sherbrooke local paper, even did a nice article on him this week, quoting my uncle Louis, among others.

It's strange to be back home like this. I was driving around town, running some errands, when I heard his name on the radio (Radio-Canada). They were talking about his passing and had interviewed a few folks about the work he did during his practice. It made me realize that, had I not moved back to Quebec, I probably wouldn't have heard it on the radio. Made me proud of my grandpa, that's for sure.

Oddly enough, he doesn't have a Wikipedia entry. I think he should.

From the great c0t0d0s0 blog comes the news that Sun is working on an amazing upgrade to eLOM based systems, like the Sun X4150 we are using. Soon I'll be able to upgrade them to a real Lights-out-manager solution: iLOM.

iLOM is what's running on their Opteron-based systems, like the Sun 4500 (aka Thumper), and it's miles ahead of eLOM. Can't wait to have iLOM everywhere, instead of the current mixture of eLOM and iLOM.

Unfortunately, to perform the upgrade, you need to take the servers down... Can't have it all, I guess. Fortunately, since we are already fully redundant, it shouldn't cause visible downtime at all. All our build machines will just pause for a few seconds, and reappear on a different VM Host. Stay tuned, I'll blog about how the upgrade actually goes when it's finally available.

First, that's only on OS X, sorry for folks running it on a different platform. Second, it's a bit of a lie, as I am talking about bug 448003.

Since we switched over to building from Mercurial, the code size tests we run were somewhat off on OS X. These tests basically measure the size of the code included in the product. For instance, right now, on Linux, it's reported at 15.7MB.

However, on OS X, they had been reporting 1.56GB! Obviously, this was a bug somewhere in the computation of this number, not the actual code size, so that's why the subject of this post is appropriately misleading.

Various hypothesis were put forward, including the fact it looked like it was off by precisely 100, so possibly a unit conversion problem, or something similar.

I've finally gotten around to it, and after some investigation, turns out it's more interesting than that. On OS X, we don't directly build universal binaries, but instead build once for i386 and once for ppc, then lipo the 2 builds together to form the final product.

To determine code size in this case, it would be misleading to count both architectures, so instead we pick one and size up that one. In our case, for historical reasons, that's the ppc version, even though our build boxes are Intel by now. Determining code size is done by parsing the output of /usr/bin/nm, an object dumping tool that nicely dumps the symbols list out of libraries and executables. Unfortunately, it dumps positions in the code, not size. So, to determine code size for a given function, just make sure addresses are sorted, then subtract the address of the previous function to the address of the current function, and you'll get the number of bytes that it takes up in the object file. Simple, right ?

Well, for some reason, not yet explained, on ppc, there is a strange symbol called trampoline_size that exists first in the list of symbols and sits at address '0'. However, right after it is the next symbol, strangely sitting at the address 0x20000000. That's 536870912 bytes further, if we believe what this is telling us. Of course, this is bogus. I am not entirely certain what this about, but if I could venture a guess, I'd have to say it has to do with the ppc executable format, OS X, and their ability to transparently run ppc binaries on Intel. Anybody that knows OS X/PPC better than me, feel free to correct me on this.

libnspr4.dylib: 00000028 a trampoline_size
libnspr4.dylib: 20000000 t __mh_dylib_header
libnspr4.dylib: 20001a7c t dyld_stub_binding_helper



Now that the problem is somewhat understood, it was a simple matter of teaching the code size stuff to ignore symbols like that on OSX/ppc and start at the next one. As you can see from the Tinderbox boxes, it was still pretty impressive to see such a large code size decrease! Oh, and SeaMonkey got the same drop in size, for the same reason.

Recently, we started receiving nightly logs of the Thunderbird start page hits. It now comes to us nightly, and I also got some historical data back to June 2008.

For the time being, I've just been feeding them all to webalizer, for lack of a better idea. There is not yet a complete plan as to what to do with all that data. Right now, it goes straight to infinite storage every evening. There is a lot of it, averaging at around 8 million hits a day, The included graph is the average traffic per hour of the day. That's in the 300k-500k hits per hour! I am glad that this traffic is being served by the mozilla.org hardware.

I know folks have already started to think of ways we could mine that data to learn useful things about Thunderbird and its user base, but it's only beginning. So, for the time being, I'd like to hear from anybody who can think of a questions that could be answered by all that data. Of course, respecting our users privacy is important, so I don't want anybody to know anything about specific individuals, just about trends. Are Russians users checking e-mails more often than us Canadians, for instance? (Not so sure that's a very useful thing to know)

Got a cool idea ? Have something you'd like to know ? Please, let me know.

<gozer at mozillamessaging dot com>