Article posted on Nov 27
Not only am I Debian Maintainer #6 (not counting the original alpha testers), but I am the first Debian Maintainer to need a corrective update. I rock.
(In short, Debian Maintainers are a new class of people who can upload updates to their own packages, but still need a Debian Developer sponsor/mentor for uploading new packages. I happen to have three packages I maintain. The pecking order is basically: user, maintainer who uploads through a sponsor, Debian Maintainer, Debian Developer.)
Article posted on Nov 16
Yesterday I downloaded Firefox "Gran Paradiso" alpha 8, which I thereafter referred to as "Gran Turismo" (because I can), to test extension compatibility. As you may know, I have a little website where you can store your bookmarks. And that little website has a little Firefox plugin. And you should be using them, damnit. The Hampr extension worked fine with the Firefox alpha, but took some coaxing to actually get installed. It's a little difficult to explain everything, so I figured I'd blog it. Let's start from the beginning:
Writing a Firefox plugin
Not in this scope. Sorry.
Packaging a Firefox plugin into a XPI archive
Not in this scope either, but you should know one file within the XPI is "install.rdf", which will be relevant later.
Hosting said XPI archive so others may download and install it
At the very simplest level, you throw it on a web server somewhere, and people download it. However, unless you have your MIME types set correctly, the user will probably be prompted to save the XPI rather than install it. You'll most likely need this in your Apache configuration:
AddType application/x-xpinstall xpi
AddType text/xml rdf
That RDF entry will come into play later. OK, so now people can install your extension... as long as the XPI archive is not on a HTTPS site. Yes, you heard me right. If you try to host on a HTTPS site, Firefox will download the XPI, but then receive "Download error -228". This appears to be cache-related. Specifically, because HTTPS content is not cached by default, I'm guessing Firefox tries to find the content it just downloaded, and fails. Similarly, ALL remote XPI installations fail if you disable caching in preferences. Conversely, you can install XPI archives from HTTPS sites if you set "browser.cache.disk_cache_ssl = true" in about:config, but of course you can't rely on your users to do that. (Also, doing that opens up security issues.)
(One more detail to complicate things: XPI installation over HTTPS seems to work fine in Iceweasel. I have no clue why.)
"But but but! addons.mozilla.org links to XPI installers over HTTPS, and it works fine!" Look closer: the HTTPS URL actually redirects to an HTTP URL for the XPI archive.
So you can distribute Firefox extensions, but they're not "secure". It is possible to cryptographically sign an XPI archive, but it's a pain in the ass. I'd say live without it for now.
Automatic updates checking for your Firefox extension
So now you have an extension, but what happens when you want to issue updates? The process for enabling automatic updates is detailed here, but basically you put an "update.rdf" on your webserver, which contains information about the latest version of your extension, and put a reference to update.rdf in your XPI archive's install.rdf.
This has served me well for several years, but it looks like Firefox 3 will be mixing all that up. Specifically, Firefox 3 will refuse to install "insecure" updates, or even the original extension XPI if Firefox determines the update system to be "insecure" from the start. First, let's look at the criteria for install.rdf's reference to update.rdf:
* install.rdf must refer to update.rdf over HTTPS (yes, this works; only XPIs can't be installed over HTTPS), OR
* install.rdf can refer to update.rdf over HTTP as long as it also includes a key to verify the digital signature of update.rdf.
So you either have to have an HTTPS site to host the update.rdf, or cryptographically sign update.rdf, which is a pain. (Don't get me wrong, I'm all for digital signatures and encryption, but code signing for Mozilla specifically is very convoluted.) I'll assume you chose the HTTPS path as we move onto the criteria for referring to the XPI from within update.rdf:
* The XPI can be on an HTTPS site (which is basically impossible, as explained above), OR
* The XPI can be on an HTTP site as long as a SHA1 or better hash is included with update.rdf for verifying the XPI.
Now that's easy to do. For an example, see Hampr's update.rdf. FYI, if you ignore this requirement, Firefox 3 users will simply never see updates to your extension. It'll download update.rdf and immediately ignore it.
Let's review:
* You offer for installation an XPI living over HTTP.
* The XPI references an update.rdf living over HTTPS.
* The update.rdf references one or more XPIs living over HTTP.
I'd recommend migrating to this setup immediately and releasing a new bump version of your extensions (supporting a maxVersion of 3.0.0.*, assuming your extension is actually Firefox 3 compatible of course), because if you wait until after Firefox 3 is released, it's actually take the user 2 update cycles to upgrade to your new extension version.
Article posted on Nov 16
A few years ago I bought the Dell 2005FPW 20" widescreen LCD, the monitor famously known for having the exact same panel as the 20" Apple Cinema display, but for $600 instead of $1400. I even got an awesome deal on it, roughly $400. (Dell used to be heavily into coupon codes back then. Not so much now.)
Well, I'd been thinking about buying a second monitor for the desktop to complement the 2005FPW, and found the SP2008WFP. $300, same size, 2ms reponse, 2000:1 contrast. Oh, and a built-in webcam, and a very "Apple" feel to it. It did have a TN panel, which is not as good as the S-IPS panel in the 2005FPW, but I didn't think it would be that bad. I whipped out the credit card, and 2 days later it arrived (Dell monitors and some other Dell stuff ship from a warehouse 5 miles away).
Boy was I disappointed. I'm no designer, but even I could tell that the blue was overpowering, and everything looked horrible as a result. The colors distorted even further when viewing at an angle (which is a characteristic of a TN panel), in this case shifting to yellow, but it was quite noticeable even when I was slouched in my chair (watching a video, etc). In comparison, an S-IPS display has mostly even color and contrast from pretty much any angle.
I bought a Spyder2PRO for work (we've been wanting to get one at work for awhile anyway) and took it home to try to correct the color balance. I was able to get the colors balanced, but I later found out that full-screen games (particularly Valve games) did not use ICC profiles, and one of the main reasons I bought the monitor was the 2ms response for gaming. And of course it didn't help the viewing angle annoyance.
(By comparison, according to the Spyder, the 2005FPW was almost perfectly balanced out of the box in default settings.)
Hell, even the built-in USB had problems. Specifically, when you turn the monitor off, the built-in USB hub no longer receives power, whereas the 2005FPW's USB hub remains on even when the monitor itself is off. Because you, you know, may actually have stuff plugged into it. I will say this though: the webcam quality was pretty good. It supported various resolutions up to 1600x1200, and supported video up to 800x600 at 30fps, and 1024x768 up to 1600x1200 at 10fps. It even included a built-in microphone, for all your cybering needs.
But ultimately, I was disappointed. The 2005FPW was an awesome deal at $400 and still worth every penny, but $300 for a new sub-par monitor that I couldn't stand looking at was bad. I looked at their return policy, which was 21-day, 15% restocking, and you pay for shipping. Sucks a bit, but standard policy, and I called to return. I briefly thought about trading up to the $400 2007WFP, but ultimately I decided I really didn't need a second monitor. Being nice on the phone paid off: the woman dropped the 15% restocking fee, and even e-mailed me a return UPS label. And since I got free shipping on the monitor originally, I've lost nothing but time.
Article posted on Nov 4
On advice from a co-worker, this weekend I made real pizza crust, rather than relying on Boboli crusts. I've never had much luck with pizza dough, but it didn't go that bad this time. I used a little too much pizza sauce though.
(Sorry, no recipe this time, unless you count "dough + pizza sauce + cheese + pepperoni" as a recipe.)
I may also make chocolate oatmeal cookies tonight.
Article posted on Nov 4
The package tracking systems for both UPS and Fedex are down. CONSPIRACY!