Skip navigation

Category Archives: Mozilla

With the help of tBunnyMan’s post, I managed to get the Chef DK running inside a jail on my FreeBSD box.

After you’ve done your initial setup in the jail, you’ll want to also setup sudo in your jail and allow anybody in the wheel to have password-less sudo (you can modify the file by hand if you want to see what it’s doing):

# pkg install sudo
# sed -ie 's/#\(%wheel ALL=\)/\1/' /usr/local/etc/sudoers

Now, create the user that will run the setup:

# adduser
Username: chef
Full name: chef
Uid (Leave empty for default):
Login group [chef]:
Login group is chef. Invite chef into other groups? []: wheel
Login class [default]:
Shell (sh csh tcsh nologin) [sh]:
Home directory [/home/chef]:
Home directory permissions (Leave empty for default):
Use password-based authentication? [yes]:
Use an empty password? (yes/no) [no]:
Use a random password? (yes/no) [no]: yes
Lock out the account after creation? [no]:
Username   : chef
Password   : 
Full Name  : chef
Uid        : 1001
Class      :
Groups     : chef wheel
Home       : /home/chef
Home Mode  :
Shell      : /bin/sh
Locked     : no
OK? (yes/no): yes

We need an older version of devel/gecode, so now we have to downgrade it. This step will take a while if you have a CPU that isn’t very fast.

# su chef
# cd ~
# sudo pkg install portdowngrade
# sudo portdowngrade devel/gecode r345033
# cd gecode
# sudo make deinstall install clean

We are not yet done with gecode, however. A pull request to dep_selector added a dependency on GECODE_VERSION_NUMBER, which isn’t properly defined in /usr/local/include/gecode/support/config.hpp, so we have to fix it.

# sudo sed -ie 's/\(#define GECODE_VERSION_NUMBER\)\s*/\1 300703/' /usr/local/include/gecode/support/config.hpp

Almost there! No we can install our other dependencies and checkout the git repo.

# cd ~
# sudo pkg install ruby rubygem-bundler git
# git clone
# cd chef-dk
# USE_SYSTEM_GECODE=1 bundle install --without development

This will at least let you build the Chef DK. As I go further down this rabbit hole, I may end up putting up more posts on how I got Chef setup on FreeBSD.

Dietrich recently posted about the memory usage of social plugins, and I found the results rather surprising because, at least in the case of Facebook, I didn’t think it ever loaded enough code to consume 20+MB of memory.

When I first learned about social plugins, I thought that they were a really cool idea and thought that they had a lot of potential. If they use a ton of memory though, I feel like it’s a bit of a deal breaker to using them. So, being the curious engineer that I am, I decided to test this out myself. I conducted these tests in a new Firefox profile and I was not signed into Facebook (to try and replicate the experience Dietrich had).

One Like Button

For my first test, I had a very simple page for the default like social plugin pointing to my site.

like page result

One like button doesn’t seem to add much, which is good!

Two Like Buttons

The next test I tried was duplicating the like button so it showed up twice. This code is a bit naive since I duplicate a <div> element with the same id and don’t need to include the JavaScript twice. However, it shows what someone who would just copy and paste will end up with, which I think is valuable.

like page (two button) result

As you can see, memory usage nearly doubled. This is a bit surprising since the exact same JavaScript is included. I would expect there to not be any additional shapes, but that nearly doubles. scripts and mjit-code also all double, and I would expect that at least the latter to not.

A more interesting version of this test would be to not include the JavaScript twice, and just add one additional <fb:like> button that doesn’t like the same url.

two like button test results

Interestingly, memory usage did not change significantly from the duplicate resource case! So, what exactly is going on here? This page ends up loading four additional resources:

File HTTP Status Size Mime Type
all.js 304 143KB application/x-javascript
login_status.php 200 58b text/html
like.php 200 33KB text/html
like.php 200 33KB text/html

That is 209KB of HTML and JavaScript that is being sent for two like buttons. Something tells me that part of the problem here is that Facebook is sending more than it needs to for this (I did not look into exactly what was being sent). The good news is that 143KB comes from the browser’s cache.

Send Button

The last test I did was the send button pointing to my website.

send test results

Given that the like button test includes a send button as well, I’m not surprised to see that this used even less memory.


I think there are are two problems here:

  1. Firefox should create less shapes and do a better job of not duplicating the same JavaScript code in a given compartment.
  2. Facebook needs to send less data down for their social plugins. I have a hard time believing that that much JavaScript is needed in order to display a like button, a share button, and a faces of your friends who have liked a page.

It’d be interesting to see how these numbers change when you are logged in, but I don’t have time to do that analysis. I’ve provided all the code and steps I used to get these results, so it shouldn’t be too hard for someone else to come along and do that if they are interested. Another interesting test would be to see how the Twitter and Google+ integrations break down too (but I leave that as an exercise for the reader).

I’m going to write something that will probably surprise you. I say this because it sure surprised me when I realized I was even considering what I’m doing a possibility. I’m going to be moving on to something a bit different in the mobile space, and it’s going to be a different kind of challenge for me.

June 1st will be my last day at Mozilla. I’ve learned so much over the years working there, and choosing to leave was the hardest decision I’ve had to make. I do not intend to disappear from the project, however, but my activity level will decrease. Feel free to continue to send review requests my way and cc me to bugs you want my opinion on, and I’ll do my best to reply in a timely manner.

So long, and thanks for all the fish.

I handle a lot of code review and code feedback requests these days. However, it’d be great to get more people doing this for a number of reasons:

  • More people exposed to more parts of the code base
  • More review bandwidth so more work can be checked into the tree
  • Less dependence on a small set of people

In order to get more people doing this, it would be good to document to look for, and how to make sure the code is sound. I’m sure every reviewer does things a bit differently, but I’m going to share my process. There are two types of review I do these days: feedback and review.


Feedback is pretty simple to do, and I can usually fly though any patch (even large ones) quickly. This isn’t very thorough (in fact, I tend to keep it to general comments), but I look for the following things:

  • correct API usage (XPCOM, jsm, whatever)
  • internal invariants are not violated
  • any new APIs created make sense and aren’t confusing
  • code style matches what’s there, or follows the style guide


Review is more important because once a patch gets r+, it can generally land in the tree. Consequentially, I tend to spend a lot more time on any given patch. In addition to all the things I do for a feedback request (which are looked at more closely for a review), I’ll also look at the following:

  • evaluate how well tested is the code that is being added/modified. If it isn’t well tested, I’ll generally suggest a set of test cases that I feel are the bare minimum this needs to land.
  • evaluate how this might impact other work going on in this area of the codebase
  • ensure this doesn’t add any I/O on the GUI thread
  • apply the patch and run the tests
  • if the patch looks like it might regress performance, ask for the author to verify that it does not

Note that a number of these things may not be done if I know what the patch author has already done to ensure the patch is safe.

I’ll assert that one of the biggest pain points of getting a patch in the tree is getting review. This is largely a problem because it can often take a very long time to get that review from the limited set of people who are allowed to review your patch. Even a veteran contributor who knows his way around the system can have his patches sitting in somebody’s review queue for weeks.

I’ve decided I’m going to do something about this by setting a good example, and hope that others follow. For the past two weeks, I’ve been driving my review queue down to zero almost every day. This sounds like a lot of work (especially for anyone who gets a lot of review requests), but I’ve found that in practice, it isn’t so bad. I usually start out every morning by going through all my bugmail before I dig into my days work. I’ve simply added a step after this where I do code reviews until about noon. This doesn’t often take that long as most patches I get aren’t terribly large, aren’t terribly complicated, or there aren’t many to review. If I happen to not get through all of the review requests, I then set aside an hour at the end of my day to go through the rest. In theory, this means my turn-around time for review requests is one business day. In practice, it has come out to be closer to a two or three days due to a number of large patches that I’ve had to review.

You might say “well, that’s easy to do if you don’t get many review requests!” This is very true, but it’s not like I get a small number of requests. Over the past two weeks I’ve done review and feedback requests for 24 bugs, many of which required more than one review iteration. I don’t think that’s a small number of reviews (at least two per day).

I have one caveat with this though; I don’t want to have the quality of my reviews to degrade. For most patches, I’ve found that if I do any more than five or six a day I start to miss things because I’m too mentally drained at that point. If I have some really large patches I’ll review less, and if it is a bunch of small patches, I’ll review more. Sacrificing code quality for the sake of fast turn-around times isn’t ideal, in my opinion.

I would love it if more people tried this out to see if it works for them. The people requesting review from you would really appreciate it!