Shallow Thoughts : : Nov

Sportsmanship and temptation

A recent episode of the Freakonomics podcast What Do Skating Rinks, Ultimate Frisbee, and the World Have in Common?, talked, among other things, about Sportsmanship in Ultimate Frisbee versus other sports.

Ultimate Frisbee is self-policing. It has no referee: if someone on the field thinks they've been fouled, they call it out, and the two players reach a consensus.

Why don't the players cheat and take advantage of the lax rules and the lack of a referee? Because sportsmanship and honesty is part of the culture of the game, in a way that isn't true in refereed sports like soccer, basketball, tennis or nearly any other sport played professionally. The Ultimate players they interview talk about the culture of the game, the longtime attitude that every player is "morally bound to abide by the rules. The integrity of Ultimate depends on each player’s responsibility to uphold the spirit of the game."

And that's great. But I submit that there's a more important reason: because there's not much at stake in Ultimate Frisbee, compared to football, soccer or basketball.

Ultimate is still a chiefly hobby sport which is only barely starting to get sponsorships and professional teams. I'm not up on the Ultimate scene, but I bet there aren't a lot of millionaire players yet, or a lot of poor kids practicing their frisbee throws as their way out of the ghetto.

To make my point, let me tell you a tale of two autocross classes.

Autocross, if you're not familiar with it, is miniature car racing. You race against the clock, one car at a time, on a course delimited by traffic cones on a large parking lot or airstrip.

There are lots of different classes, so cars race against similar types of cars. The classes cover different preparation levels, starting with Stock classes, where you can't make any modifications beyond tires, shocks and a few other carefully specified items. Next above stock is Street Prepared, where the cars are still more or less street legal (many are still daily drivers), but they have lower, stiffer suspensions, wider wheels, sometimes headers or high-flow mufflers or fancy intake systems. Then above that are Race Prepared, for cars prepped to road racing standards, and Modified, for purpose-built race cars like formula cars.

Autocross, when I was actively racing (and I doubt it's very different now), is almost entirely an amateur sport. There are some sponsorship programs, called "contingency programs", where you can earn a few hundred dollars if you win a big race using the right car, the right tires, the right shock absorbers. Some races throw in modest amounts of prize money, so that at a big national level event a handful of winners might be taking home a few thousand dollars over their travel expenses, maybe ten thousand at the absolute top end. Most class winners don't even make enough to pay their travel expenses.

Curiously, the best contingency money isn't in the superfast, exciting Modified classes; it's in Stock. Why? Because the money comes from manufacturers hoping that someone will see your stock Miata winning the class and say "Wow, maybe I should buy a Miata too!" or "Maybe what my Miata needs is those tires/shocks/whatever."

I ran my Fiat X1/9 in D Street Prepared. DSP is seen as a class for old clunkers -- some of the winning cars besides the X1/9 included the Mazda RX3, VW Rabbit, Datsun 510, Datsun Roaster, and CRX HF. They're all old cars, no longer on the market -- so manufacturers weren't very interested in offering contingency money for them. That was okay -- our cars were fast and fun to drive, we had great competition and a lot of fun. Everybody was friendly with each other -- sure, we were all out to win, but if someone had car trouble, you could bet that everyone would be gathered around the car trying to help. If the problem wasn't fixable, another competitor would offer a ride in another DSP car. I saw that happen even at Nationals -- everybody was intensely competitive, but in a friendly way.

That's not to say nobody ever cheats. Sure, occasionally somebody wanted to win badly enough that they'd make some illegal modification to their car. Sometimes they even got away with it for a year or two before anyone figured it out. But cheating was relatively rare ... at least until contingency money started to edge up into the thousands of dollars instead of just a few hundred. Then you started to see a lot more protests, a lot more engines and suspensions turn down, and a lot more cars found illegal and disqualified. And most of the protests happened in the stock classes.

And then one year at Nationals, I really learned how those big contingency prizes changed the sport. I was running my old Fiat in DSP as usual (actually DSPL, the parallel class for women drivers). A friend of mine was there in a stock car she'd bought just the year before. She'd worked really hard all year, was driving exceptionally well and was widely thought to have a good chance to win her class. (I'm deliberately omitting her details like name, make and class.) We were all rooting for her.

And then one morning, a day or so before her class was scheduled to run, she discovered that one of her brake lines had been cut.

Her brake line! On her daily driver car that she was going to drive 1,500 miles home after Nationals was over!

Fortunately, she found it in time, and lots of people pitched in to help her get the brake line fixed. But it was pretty terrifying to know that something like that was even possible in what I had always seen as a friendly, fun, amateur sport.

I don't know if anything else like that happened in other classes. It wasn't widely talked about; you might not have known about it happened if you didn't know someone involved. They never found out who did it, as far as I know. But there were a lot of protests in the stock classes that year, too -- nobody trusted anyone, everybody assumed their competitors were cheating, and there were engine and suspension teardowns. It all made me glad I was in unassuming (and fun!) old DSP and out of the money.

So, getting back to the Ultimate referee question. Yes, sports that have a friendly, sportsmanlike culture are terrific. But I think -- though I wish I didn't -- that the Ultimate players may find, as their professional league gets off the ground and they attract more sponsors, that the moral code they've taken for granted is partly due to not having much at stake.

Money, or the prospect of it, does something to people. And I'm not sure money and stand-up honest sportsmanship make very good bedfellows.

Dinosaur Doggerel

I woke up thinking about dinosaurs.

Specifically, Pachycephalosaurus, the bone-headed dinosaur, and her long-crested cousin Parasaurolophus (pictured at right).

The previous night, I had been reading The Know-It-All, A. J. Jacob's entertaining account of his adventures reading the whole Encyclopedia Britannica. I'd left off in the Ps, which included a very short entry on Pachycephalosaurus (A.J. is not particularly into dinosaurs).

Drifting along in a typical insomniac "I wish I could get back to sleep" haze, I couldn't help noticing that Parasaurolophus was six syllables -- in fact, it was a double dactyl.

And that meant it was a prime candidate for my favorite verse form, double-dactylic doggerel, a form with fairly strict rules which require, among other things, that the second line be a double-dactylic proper name. And as double-dactylic junkies know, once you've noticed a double-dactylic name, you can't rest until it's turned into a poem.

So now I couldn't sleep because I was thinking about Parasaurolophus. Now, even aside from its mellifluous name, Parasaurolophus and the whole Hadrosaur family are pretty interesting. The biggest puzzle is why they had those elaborate bony crests. Decoration for mating purposes? Fighting, like horns and antlers on modern hoofed mammals? But in the late 1990s, CT scans of hadrosaur fossils revealed long air passages inside the crests of many Hadrosaurs, including Parasaurolophus ... and those air passages were connected to the nasal passages. That led to suggestions that the crests might have been tuned for sound production -- a built-in wind instrument.

In Scientists Use Digital Paleontology to Produce Voice of Parasaurolophus Dinosaur a team at Sandia made computer models of the air passages, and you can even listen to sound files of what Parasaurolophus might have sounded like. The sound is wonderful, like a trombone. Sandia's pages use a, <embed> tag that didn't work for me in Firefox, so if you have trouble with their links, I've separated out the wav file URLs: songLQ.wav (588k) and a higher quality version, song2.wav (2.7M).

Anyway, I never did get back to sleep, but I did end up with some insomniacal doggerel:

Dinosaur, schminosaur
Parasaurolophus
How do you use that
Magnificent crest?
"I play trombone in the
Dinosaur orchestra
All hadrosaurs play, but
I am the best."

Signed up for a California Exchange plan (I think)

I signed up yesterday for a health care plan on California's health insurance exchange, CoveredCA. It wasn't pretty, but I signed up for a plan in the end. Or at least, I think I did.

The process was full of hilarity, a several hour haul involving pages that didn't work, pages with mistakes on them, and of course, timeouts and restarts.

Brief thought before I begin: California's healthcare site is CoveredCA.com. That's dot com. I keep seeing articles in the newspaper warning people not to get confused by imitator sites, as there are several with names similar to the official site (Update: see, for example, Kamala Harris shutters 10 fake Covered California websites and State shuts down bogus health care websites) , and I always wonder -- why don't government sites take advantage of dot gov domains? You see the same thing on the national credit-report-check website: there's a dot com website where you can get your official government-sanctioned free credit report, and then there are about twenty imitator sites with names that any normal person would confuse with the real site, which are basically scams that try to suck you in to paying for various products in the guise of giving you your free credit report.

Government folks: the whole point of dot gov is to tell us it's a government-sanctioned site. Please use it.

Anyway, back to CoveredCA.com. I had already been on the site a few days earlier. CoveredCA says that you can browse plans without signing up for an account. That's sort of true -- but that's not really true. You can browse plans, sure ... but you can't find out any useful information about sorts of subsidies you might qualify for. The site asks you questions about your location, your income and the age of everyone in your household, then deposits you on a page that chirpily informs you "You may be eligible for ..." a list of every possible type of plan, from Medi-cal (California's version of Medicaid) to regular exchange plans to ... aid to mothers and infants? When I've already filled out a form saying that there are no children in the house?

At the bottom right is some small print saying that you have to create an account to find out what you're actually eligible for. Then why ask those other questions?

Okay, so I guess I need to sign up even to browse. With trepidation I began the sign-up process.

Signing up

The first hurdle came only a few screens in, when I typed in my address. 123 Mystreet Ave, San Jose, CA, 91234. I got an error screen.

Confirm Your Mailing Address

The address you've entered is different from those on file. Please confirm which is correct.

The address you entered
•	123 Mystreet Ave,
	San Jose,
	CA,
	98765
Possible Address 1
	123 Mystreet,
	Ave,
	San Jose,
	CA,
	98765

See the difference? It took me a minute, but they have a comma between my street name and "Ave".

I don't normally put a comma there, and I don't think most people do. So I left "The address you entered" checked. I probably shouldn't have: later in the process, it asked me my address again (don't they have, like, you know, a database, so people don't have to enter the same address multiple times?) and it showed me the exact same screen.

I stubbornly stuck to my guns and continued to insist on the version without the spurious comma, whereupon the site stopped responding at all, and fifteen minutes went by without any pages loading. I tried reloading, going back, etc. but I finally had to give up and reload CoveredCA.com. Fortunately, it had saved at least some of my work so I didn't have to start from the beginning.

Accepting the commaed version might not have helped, anyway. These 10 or 15 minute delays were fairly common throughout the process. Two or three times, while I was waiting for a page to load, I got an amusing (I just accidentally typed that as "abusing" -- talk about a Freudian slip!) popup saying that my session was about to time out, did I want to continue?

Garbled pages

The next snag (aside from timeouts) I hit was the Household Authorized Representative Information page. I was out of the room when it loaded, since it took many minutes to get from the previous page to that one, so I didn't see it load, but when it did, this is what I got:
(click on the image for the full screenshot). Um? Did we time out and only load a partial page?

I crossed my fingers and hit the browser's Reload button. I watched a page full of questions come in -- whew! Except that about a second after the page finished filling with questions, they all vanished, to be replaced by the same thing I'd seen before.

I'm not entirely sure what this screen is for. Of course I would want my husband authorized. But I can always give him the password I used to log in, and I'm not sure he isn't automatically authorized anyway. Maybe this screen is for authorizing someone else. Anyway, let's just hope the default is okay and I'm not agreeing to anything I don't want, and click Continue.

And the end of the process was a statement to read and sign, under penalty of perjury. It included this amusing paragraph:

I know that I must tell the (Co-Brand Application Name) if anything changes from (and is different than) what I have provided on this application.

I'll be sure to notify (Co-Brand Application Name). I promise. Meanwhile, do you have anything to tell me about Lorem ipsum?

Choosing a plan

I finally got through the signup process, about two hours after I started. Whew! It said I could now choose a plan. But when I clicked on that button, no page loaded. I waited 15 minutes, gave up and clicked Reload, waited another 15 minutes, and then had to leave for a meeting. So I clicked Stop, hoping that the site had saved all my info and I'd be able to look at plans later that afternoon.

When I returned to the computer, of course my attempt to click on the button to choose a plan took me to a Server Error page. I expected that, after letting the computer sleep for several hours. So I loaded CoveredCa and logged in again.

This time I was able to get into the "Find a Plan" part of the site. (Less traffic in the afternoon? Or was the button from the signup page taking me to the wrong place? I'll probably never know.)

The user interface on the plan comparison page is horrifying. You're shown three plans at once (no, resizing the browser window doesn't increase that number). Then there are two nested scrollbars: the outer one scrolls the page that includes the names of the three plans, while the inner one only scrolls the part you can see below the big rectangle describing each plan. Assuming there is anything you can see below that part: I had to maximize my browser window to my 1680x1050 monitor and scroll the outer page to where I could just barely see the names of the plans, and then I still could only see a tiny fraction of the available details at once. To really compare plans, you have to expand all the categories, then scroll up, down, up, down, up, down, taking notes on paper since you can't see more than half a category at once (and of course, only for the three plans you're currently viewing). Don't even bother trying this on a laptop.

If you want to see more than the first three plans, there are the amusing scroll tabs. On the left of the three plans is a tab with a symbol that looks like an equal with dots above and below it: that scrolls left (if not already at the first plan). On the right is a tab with the symbol alpha; that scrolls right. Why those symbols? I have no idea. Maybe the UTF-8 codes correspond to right-arrow and left-arrow in some Windows-based design tool.

It took me quite a while to figure out how to tell which plans cover which doctors. It's under the Summary category, My doctors, Search.

Eventually I gave up on trying to compare plans intelligently, and just picked the silver plan from our current provider which I was pretty sure would cover our current doctors. Amazingly, it let me sign up, and told me we were enrolled -- though it wouldn't be official until the provider had contacted us about billing and we'd made the first payment. It said we should expect them to contact us by November 15. (Checks calendar) ... Why ... that's tomorrow! And it was about 2:30pm already. That seems awfully quick. It's the 17th as I'm writing this ... maybe there'll be something in tomorrow's mail.

And in case you're counting, the deal we'll be getting through the ACA is stupefyingly better than the individual plan we were paying for before. Like $10,000 a year better, with a $500 deductible instead of the $4000/person deductible we had before. So don't get the wrong idea from this snarky blog post -- I'm a big fan of health care reform. It's just badly done websites I object to.

Survey: How are we doing?

Finally done! Wahoo! And at the end, there was a chance to fill in a little survey about my experience on CoveredCA. Of course, I wanted to tell them about the problems I'd encountered, so I clicked the button. I filled out the survey and clicked Submit.

You know how if a form on https directs you to a non-SSL page, Firefox gives you a warning about it? I got that warning here. But it didn't concern me -- I'm not worried about whether my survey results are encrypted when I'm sending them. So I clicked Continue.

And got this: you must use ssl to access this resource. I about died laughing. A fitting end to hours of hilarity.

So as you read coverage of the problems with the national healthcare exchange, and all the chirpy reports about how the states with their own exchanges, especially California, are doing so much better, keep this in mind. Especially when the articles mention things like not having gotten much negative feedback or heard about problems their users are having. (Is this a good time to mention the helpful "Online chat" link at the top of the CoveredCA site that just reloads the main page?)

You have to admit, a survey page that doesn't work is a great way to reduce the amount of negative feedback you get!

Update: it's half a week later now; no word from the insurer. I went back to CoveredCA and logged on to verify that I'm really enrolled. On the main screen, it shows me a timeline with six steps: Summary - Household - Personal Data - Income - Eligibility - Enrollment. The first four have blue squares with checkmarks in them; Eligibility has a blue square but no checkmark, and Enrollment is white and un-checked. I have no idea what this means, but it doesn't look good. The squares with checks are clickable; the others aren't.

Clicking around in desperation, I discovered by accident that if I clicked on "Income" (the last clickable step), on the Income page it added a checkmark under "Eligibility" in the timeline at the top, making it clickable. If I then clicked on Eligibility, it didn't add a checkmark for Enrollment, but it did give me a "Choose a plan" button at the bottom, so I clicked on that. That took me to a page titled "Household Enrollment Summary" which showed me the plan I'd signed up for. There's a link over the "Carrier Website Address" but it goes to a nonexistent page on v.calheers.ca.gov. Meanwhile, in the top timeline, Enrollment is blue though it still isn't checked.

So am I really enrolled in a plan? Wish I knew.

Does scrolling output make a program slower? Followup.

Last week I wrote about some tests I'd made to answer the question Does scrolling output make a program slower? My test showed that when running a program that generates lots of output, like an rsync -av, the rsync process will slow way down as it waits for all that output to scroll across whatever terminal client you're using. Hiding the terminal helps a lot if it's an xterm or a Linux console, but doesn't help much with gnome-terminal.

A couple of people asked in the comments about the actual source of the slowdown. Is the original process -- the rsync, or my test script, that's actually producing all that output -- actually blocking waiting for the terminal? Or is it just that the CPU is so busy doing all that font rendering that it has no time to devote to the original program, and that's why it's so much slower?

I found pingu on IRC (thanks to JanC) and the group had a very interesting discussion, during which I ran a series of additional tests.

In the end, I'm convinced that CPU allocation to the original process is not the issue, and that output is indeed blocked waiting for the terminal to display the output. Here's why.

First, I installed a couple of performance meters and looked at the CPU load while rendering. With conky, CPU use went up equally (about 35-40%) on both CPU cores while the test was running. But that didn't tell me anything about which processes were getting all that CPU.

htop was more useful. It showed X first among CPU users, xterm second, and my test script third. However, the test script never got more than 10% of the total CPU during the test; X and xterm took up nearly all the remaining CPU.

Even with the xterm hidden, X and xterm were the top two CPU users. But this time the script, at number 3, got around 30% of the CPU rather than 10%. That still doesn't seem like it could account for the huge difference in speed (the test ran about 7 times faster with xterm hidden); but it's interesting to know that even a hidden xterm will take up that much CPU.

It was also suggested that I try running it to /dev/null, something I definitely should have thought to try before. The test took .55 seconds with its output redirected to /dev/null, and .57 seconds redirected to a file on disk (of course, the kernel would have been buffering, so there was no disk wait involved). For comparison, the test had taken 56 seconds with xterm visible and scrolling, and 8 seconds with xterm hidden.

I also spent a lot of time experimenting with sleeping for various amounts of time between printed lines. With time.sleep(.0001) and xterm visible, the test took 104.71 seconds. With xterm shaded and the same sleep, it took 98.36 seconds, only 6 seconds faster. Redirected to /dev/null but with a .0001 sleep, it took 97.44 sec.

I think this argues for the blocking theory rather than the CPU-bound one: the argument being that the sleep gives the program a chance to wait for the output rather than blocking the whole time. If you figure it's CPU bound, I'm not sure how you'd explain the result.

But a .0001 second sleep probably isn't very accurate anyway -- we were all skeptical that Linux can manage sleep times that small. So I made another set of tests, with a .001 second sleep every 10 lines of output. The results: 65.05 with xterm visible; 63.36 with xterm hidden; 57.12 to /dev/null. That's with a total of 50 seconds of sleeping included (my test prints 500000 lines). So with all that CPU still going toward font rendering, the visible-xterm case still only took 7 seconds longer than the /dev/null case. I think this argues even more strongly that the original test, without the sleep, is blocking, not CPU bound.

But then I realized what the ultimate test should be. What happens when I run the test over an ssh connection, with xterm and X running on my local machine but the actual script running on the remote machine?

The remote machine I used for the ssh tests was a little slower than the machine I used to run the other tests, but that probably doesn't make much difference to the results.

The results? 60.29 sec printing over ssh (LAN) to a visible xterm; 7.24 sec doing the same thing with xterm hidden. Fairly similar to what I'd seen before when the test, xterm and X were all running on the same machine.

Interestingly, the ssh process during the test took 7% of my CPU, almost as much as the python script was getting before, just to transfer all the output lines so xterm could display them.

So I'm convinced now that the performance bottleneck has nothing to do with the process being CPU bound and having all its CPU sucked away by rendering the output, and that the bottleneck is in the process being blocked in writing its output while waiting for the terminal to catch up.

I'd be interested it hear further comments -- are there other interpretations of the results besides mine? I'm also happy to run further tests.

Does scrolling output make a program slower?

While watching my rsync -av messages scroll by during a big backup, I wondered, as I often have, whether that -v (verbose) flag was slowing my backup down.

In other words: when you run a program that prints lots of output, so there's so much output the terminal can't display it all in real-time -- like an rsync -v on lots of small files -- does the program wait ("block") while the terminal catches up?

And if the program does block, can you speed up your backup by hiding the terminal, either by switching to another desktop, or by iconifying or shading the terminal window so it's not visible? Is there any difference among the different ways of hiding the terminal, like switching desktops, iconifying and shading?

Since I've never seen a discussion of that, I decided to test it myself. I wrote a very simple Python program:

import time

start = time.time()

for i in xrange(500000):
    print "Now we have printed", i, "relatively long lines to stdout."

print time.time() - start, "seconds to print", i, "lines."

I ran it under various combinations of visible and invisible terminal. The results were striking. These are rounded to the nearest tenth of a second, in most cases the average of several runs:

Terminal type	Seconds
xterm, visible	56.0
xterm, other desktop	8.0
xterm, shaded	8.5
xterm, iconified	8.0
Linux framebuffer, visible	179.1
Linux framebuffer, hidden	3.7
gnome-terminal, visible	56.9
gnome-terminal, other desktop	56.7
gnome-terminal, iconified	56.7
gnome-terminal, shaded	43.8

Discussion:

First, the answer to the original question is clear. If I'm displaying output in an xterm, then hiding it in any way will make a huge difference in how long the program takes to complete.

On the other hand, if you use gnome-terminal instead of xterm, hiding your terminal window won't make much difference. Gnome-terminal is nearly as fast as xterm when it's displaying; but it apparently lacks xterm's smarts about not doing that work when it's hidden. If you use gnome-terminal, you don't get much benefit out of hiding it.

I was surprised how slow the Linux console was (I'm using the framebuffer in the Debian 3.2.0-4-686-pae on Intel graphics). But it's easy to see where that time is going when you watch the output: in xterm, you see lots of blank space as xterm skips drawing lines trying to keep up with the program's output. The framebuffer doesn't do that: it prints and scrolls every line, no matter how far behind it gets.

But equally interesting is how much faster the framebuffer is when it's not visible. (I typed Ctrl-alt-F2, logged in, ran the program, then typed Ctrl-alt-F7 to go back to X while the program ran.) Obviously xterm is doing some background processing that the framebuffer console doesn't need to do. The absolute time difference, less than four seconds, is too small to worry about, but it's interesting anyway.

I would have liked to try it my test a base Linux console, with no framebuffer, but figuring out how to get a distro kernel out of framebuffer mode was a bigger project than I wanted to tackle that afternoon.

I should mention that I wasn't super-scientific about these tests. I avoided doing any heavy work on the machine while the tests were running, but I was still doing light editing (like this article), reading mail and running xchat. The times for multiple runs were quite consistent, so I don't think my light system activity affected the results much.

So there you have it. If you're running an output-intensive program like rsync -av and you care how fast it runs, use either xterm or the console, and leave it hidden most of the time.

Laptop-mode interferes with remote presenter

While practicing a talk the other night on my new Asus laptop, my Logitech remote presenter, which had worked fine a few hours earlier, suddenly became flaky. When I clicked the "next slide" button, sometimes there would be a delay of up to ten seconds; sometimes it never worked at all, and I had to click it again, whereupon the slide might advance once, twice, or not at all. Obviously not useful.

Realizing that I'd been plugged into AC earlier in the day, and now was running on battery, I plugged in the AC adaptor. And sure enough, the presenter worked fine, no delays or glitches. So battery was the issue.

What's different about running on batteries? I immediately suspected laptop-mode, which sets different power profiles to help laptops save battery life when unplugged.

The presenter acts as a USB keyboard, sending key events like PAGE DOWN, and on other distros (specifically Arch Linux) I've had problems with USB keyboard devices disappearing when laptop-mode is active.

So I moved /etc/init.d/laptop-mode out of the way to disable it, and rebooted. Tried the presenter again: no improvement.

But it was laptop-mode anyway. Apparently even though /etc/init.d/laptop-mode says in its header that its purpose is to start and stop laptop-mode, apparently laptop-mode starts even without that file. The key is the configuration file /etc/laptop-mode/conf.d/usb-autosuspend.conf, where I changed the line

CONTROL_USB_AUTOSUSPEND="auto"

CONTROL_USB_AUTOSUSPEND=0

In theory, I should have been able to do service laptop-mode restart to test it, but I didn't trust that since I'd just established that /etc/init.d/laptop-mode didn't actually control laptop-mode. So I rebooted. And the presenter worked just fine! I was able to give my talk that afternoon without plugging in the AC cord.

Ironically, this particular talk was on giving tech talks, and one of my points was that being prepared and practicing beforehand is critical to giving a good talk. I'm sure glad I did that extra practice run with the presenter and no power cord!

When the stores run out of pumpkins ...

We got started on Halloween a little late this year. It turns out that by the afternoon of the 31st, you can't buy a pumpkin any more -- the stores are all out of them.

We looked around -- what might we be able to use instead? And lit upon something round, a little too small but not by much:

We had to find smaller hole saw bits than usual to cut the eyes and mouth, since this was just a mini watermelon.

It turns out a mini watermelon has a very thin rind compared to a pumpkin. But the fruit is a lot easier to scrape out (and tastes and smells a lot better, too!) than pumpkin strings and seeds.

And the insides of the mouth are nicely red.

It comes out looking pretty good once it's lit, too!
Most years, we start with an actual pumpkin before we embark on our annual Pumpkin Trepanning operation (described in detail here).

In case you're curious, that stand we use for the pumpkins started life as a 4-1/4-inch homebuilt telescope that was supposed to be a mini model of the Hale 200-inch telescope at Mt Palomar. But we never finished grinding the mirror -- grinding a 4.25" mirror takes almost as long as grinding an 8" one, and when you're one what do you have? A 4.25" scope. But the micro-Hale does make a pretty good jack-o-lantern stand.

Alas, our efforts this year were mostly for naught -- it was one of those years when nobody's trick-or-treating. We only got one pair of kids all evening. Anybody want some extra candy?