A couple of months ago, I upgraded an old PowerPC machine from OpenBSD 4.2 to 4.3, and I discovered that the new version of pfctl in 4.3 would segfault when reading my old pf.conf file. Some brief poking around with GDB revealed the root of the problem, an uninitialized variable in the new configuration file parser.

If you’ve been bitten by this as well, here’s a patch with the minor change that solved the problem for me:

--- sbin/pfctl/parse.y  Sat Feb 23 15:31:08 2008                                          
+++ sbin/pfctl/parse.y  Thu May 15 08:55:38 2008                                          
@@ -3487,9 +3487,11 @@                                                                    

 qname          : QUEUE STRING                          {                                 
                        $$.qname = $2;                                                    
+                       $$.pqname = NULL;                                                 
                }                                                                         
                | QUEUE '(' STRING ')'                  {                                 
                        $$.qname = $3;                                                    
+                       $$.pqname = NULL;                                                 
                }                                                                         
                | QUEUE '(' STRING comma STRING ')'     {                                 
                        $$.qname = $3;

To apply this patch, perform the following (assuming that you have the OpenBSD 4.3 source code tree at /usr/src on your system):

# cd /usr/src
# patch -p0 </path/to/above/patch
# cd sbin/pfctl
# make && make install

My ISP blocks outbound SMTP traffic, unfortunately, and I didn’t feel like setting up Sendmail relaying just so I could submit a sendbug report, so I couldn’t open a ticket for the bug. I did send this patch to the bugs@ mailing list, but it was unable to generate any interest there; if someone stumbles across this who has a functional sendbug on their system, I’d be grateful if you could submit this patch in a proper bug report.

The segmentation fault doesn’t occur on the i386 port of OpenBSD (as far as I can tell), nor does it occur on the macppc port unless you use the “queue ( qname, pqname )” ALTQ syntax, so it’s easy to see why the hordes aren’t exactly beating down the OpenBSD folks’ doors about this one. So I figured I should post this here, where people might find it, until someone gets around to committing an official fix.

I finally got around to trying the Linux version of Opera 9.50, the newest version of the Opera web browser. Here’s what I think of it after a couple weeks of using Opera 9.50 as my main web browser, particularly how it compares to Firefox 3.0.

Things I like in the latest Opera:

• Tab management, particularly the “Create Follower Tab” feature: You can make a new tab in which any links from the current tab will be automatically opened. This can be great for reading the news.
• Site preferences: Manage cookie, JavaScript, and other preferences on a site-by-site basis from a single location.
• The new rendering engine has better CSS compliance than Firefox, and it seems to handle poorly-designed sites with much greater grace than in previous versions of Opera.
• Plugins such as Adobe Flash appear to be handled using a child process and IPC, making the browser resilient against Flash crashes. This can be done with Firefox too, but it requires the separate nspluginwrapper program, which isn’t installed by default on 32-bit versions of Ubuntu.

Things that I still prefer about Firefox 3.0:

• I initially loathed it, but the Awesome Bar has really grown on me. I miss it when I’m in Opera.
• Firefox automatically scales large images to fit within your browser window; if there’s an option to do this in Opera, I haven’t been able to find it.
• Firefox offers spell-as-you-type spell checking in text entry fields, whereas Opera (on Linux, anyway) only provides a “click here to check spelling” type of functionality.
• Firefox lets you preview RSS and Atom feeds before subscribing to them.
• Extensions: In some shape or form, Opera can perform the basic functionality provided by Firefox’s NoScript, Cookie Monster, Firebug, and Foxmarks extensions, but cannot match these addons’ full feature sets. Other Firefox addons, such as Live HTTP Headers, Adblock Plus, Unplug, and CustomizeGoogle, appear to have no analogues in Opera.
• Opera does not obey your local QT theme for the positioning of its scrollbar buttons, so you can’t easily use NeXT-style scrollbar buttons in Opera on Linux. (Firefox 3.0 obeys your GTK+ settings in this regard.)
• Opera’s stability has gotten much, much better since 9.26 and the 9.50 betas, but it still crashes every so often. Meanwhile, Firefox 3.0 has yet to fail me.

So that’s my little mini-review. If you haven’t given Opera a try yet, now would be a great time to do so. But if features and flexibility are of the utmost importance to you, you’ll probably end up sticking with Firefox.

I’ve tired of manually pointing my browser at http://www.phys.ufl.edu/weather/ each time I want to check the conditions on campus, so I made a small widget to bring the campus weather report to my NetVibes home page:

Fellow Gators can use this widget too – just click here to add it to your NetVibes home page, or here to add it to iGoogle. Or copy the widget’s URL to manually add it to any other UWA-aware application:

http://markshroyer.com/code/uwa/uf-weather/widget.xhtml

I’ve been waiting for this since I was a kid: MacGyver is headed for the theater! And better yet, the show’s original creator, Lee David Zlotoff, has obtained the movie rights and will be in control of the film. This is going to be amazing.

I have to assume right off the bat that Richard Dean Anderson will be reprising the role of Angus MacGyver… just don’t skimp on the mullet, ok guys?

Returning home from an errand today, I was driving north on Tower Road when I saw a faint gray wispy thing growing above the sidewalk, next to one of the residential lots along the street. I smelled burning wood through my open car windows. “Strange time of day to be having a bonfire,” I thought. “And that’s a really bad spot for a fire, too: it’s way too close to that brush and those pine trees. In fact, if I didn’t know better I’d think… oh.”

It took a moment, in the heavy afternoon traffic, to make the two illegal U-turns needed to get back to what I now recognized as a small brush fire. By the time I arrived, a lady in a Dodge pickup had pulled up along the property too, and she was already on the phone with the fire department. (One of the causes of my hesitation was the fact that so many other people were driving by the smoke without stopping or even seeming to notice: one of those degenerate cases of human behavior that can prove highly amusing when it can be appreciated outside the context of imminent property loss.) I climbed over the chicken-wire fence and into the yard (those “Beware of Dog” signs are just for show, right?) and began clearing unspent leaves and branches away from the flames while said lady talked to the dispatcher.

Once Truck Lady got off the phone she ran up to the house to see if anyone was home; there was no answer at the door, but she did spot a garden hose attached to the side which looked long enough to reach the fire. I pulled it across the yard and drowned the flames.

At this point the homeowner finally stepped outside: an elderly yet lively woman with a cast on her right leg. She thanked us both profusely for doing our part to put out the fire. My first thought was that this was a generous but silly reaction: of course we would stop and help; what kind of people would that make us, if we ignored the smoke and kept on driving? But then I recalled all those other cars on Tower Road, their drivers unmoved by the smoke, through which I had weaved as I committed my particular egregious moving violation of the day. And I realized that the reason these people kept going was (probably, for the most part) not some appalling moral failing, or really even laziness: they merely assumed that Someone Had It Covered, just as I nearly did. And what better evidence that the situation was already under control, than the fact that nobody seemed to be reacting to it?

At the risk of being overtly moralistic (wait, when has that ever stopped me?), it really is an object lesson in initiative. Or maybe not initiative, but something like that… autonomy might be a better word for it. It’s so easy – for me, anyway – to let the behavior of others dictate situational norms. I guess that’s a large part of what makes us human, but it can also be a hindrance to doing what’s right or necessary. Learning how to overcome this, and when it is necessary to overcome this, is important.

Anyhow, Truck Lady went on her way, and I watched over the soaked heap of branches and stray wind-blown leaves with the homeowner until the fire department’s brush fire truck, whose sirens we could already hear, finally arrived. She and I mulled over what could have ignited this; Truck Lady’s guess of a stray cigarette seemed the most likely, despite the fire’s distance from the road. (As though I needed to really cement my hatred of smokers who toss cigarette butts out their car windows.) I showed the real firefighters to the ex-fire and then I went along my way, satisfied to have discovered that my own firefighting skills do not completely suck.