Wednesday, October 31, 2007

Happy All Hallows Eve

The short paper Halloween Is an Economist's Biggest Nightmare looks at the deadweight loss of Halloween:

Economists haven't adopted the vainglorious practice of physicists and applied numbers to their laws, but if they did, the first law of economics would be that lump-sum transfers are more economically efficient than in-kind transfers. If you are going to give a gift to somebody, you should just give them the money. They will be a better judge of the best way to spend it.

If instead, you give them a specific good, then you make them worse off, unless you somehow miraculously anticipate what the recipient would purchase if he received the money instead.

Now if you know someone well, perhaps you can anticipate the type of gift they might like. But Halloween is no time for thoughtful, targeted gift-giving. At Halloween, each house on a typical American block picks out one type of candy, and they give that exact same candy willy-nilly to everyone who shows up at the door. It's an economic nightmare.

Fear not, a solution:

So let's do something to reform Halloween. The first step would be for Halloween donors to give kids money instead of candy. Kids could then go to the supermarket the next day and binge on the candies they really like. That solution would get an A-plus in economics.

Such coordination is, unfortunately, unlikely. It would also distort the holiday's demographics: An in-kind transfer of candy ensures that (for the most part) only children trick-or-treat and the marginal value of candy guarantees that, eventually, the kids all stop and go home.

In conclusion, the article provides a more pragmatic step toward reducing the inefficiency:

I am not optimistic that Americans would be so enlightened. So other solutions should be sought. Many schools prohibit children from taking Halloween candy onto the premises. That is exactly the wrong policy. Schools should encourage all children to bring their entire haul to school, and allow them a lengthy period to trade candies among themselves. That way, the Take 5s and the 100 Grand bars will find their way to individuals who cherish them.

The efficiency of each transaction is likely much lower for Halloween than for Christmas, but the aggregate size of Christmas gifting assuredly makes that holiday's deadweight loss exponentially worse.

OS Statistics

OS Statistics for this Blog

And Google Analytics does operating system statistics, too:

In the noise are FreeBSD, Solaris, NetBSD, Wii, and Playstation 3, in descending order, each with a tenth of a percent or less. Two surprises, here. First, people actually use Solaris? As a desktop? And, second, folks browse the web with a Wii?

These results are obviously not representative of the overall web, but it is less skewed toward Linux than one might expect.

Browser-as-a-function-of-OS is interesting. Half of the Windows users sport Firefox over IE. Slightly more than half the Mac Heads opt for Firefox over Safari, which begs the question why? Nearly all Linux users go with Firefox.

In addition to the aforeposted bias, these statistics exhibit another effect: People browse the web during the day, at work, where they might be forced to use Windows. Analyzing operating system usage as a function of day and time could prove fruitful, but it would introduce another bias toward enthusiasts. Ultimately, however, what matters is what people use and not why they use it.

Browser Statistics

Browser Statistics for this Blog

Tip of the hat to Google Analytics, uncluttered in presentation, amazingly useful in result, for producing these browser statistics for my blog:

Interesting how technically-skewed my readership is, given that in these statistics Firefox holds a comfortable lead on IE when, in the aggregate, IE continues (sadly) to command a majority of the browser market. Also unexpected is that people use Mozilla SeaMonkey (via AOL, perhaps?).

Not surprising is the lack of niche browsers such as Epiphany, Konquerer, and Camino—the latter of which has a quarter of a percent, actually—given the relative low penetration of their operating systems and the strong allure of Firefox and Safari.

Note that the statistics are biased as they are generated only from page-views and not via the feed. This bias likely manifests as a tendency away from enthusiast platforms and their browsers and towards IE on Windows.

Monday, October 29, 2007

Leopard Review Notes

A couple of notes on the aforeposted Ars Technica review. Mr Siracusa writes:

Apple's focus is on system-level performance, not micro-benchmarks. The kernel team's job is to make the software at the higher levels look good. If improving the performance of some tiny aspect of the kernel tenfold does not provide a measurable performance increase for some user-visible feature or task, it's not an effective use of development time, benchmark bragging rights be damned.

I do not believe that this explains OS X's relative sluggishness compared to, say, Linux. To wit, it is great if Apple's kernel team's metrics are overall performance and not some microbenchmark. But at the end of the day, microbenchmarks can point to where the bottleneck lives—is just process creation a bear or do all system calls have awful overhead? Thus I just have to disagree with the following:

Apple's decision to measure kernel performance "from the top" by looking at the behavior of the real applications running on the full OS dictates which aspects of the kernel get the most attention.

Because poor performance "at the top" does not tell you anything about where to focus your attention; it suggests a problem and then you start drilling down, first by profiling the offending application and then likely followed by so-called microbenchmarks and other mechanisms for pinpointing the issue. Indeed, poor performance "at the top" may not even live at the kernel level—I would blame every component of the stack before I faulted the kernel for lackluster performance.

I enjoyed the discussion on OS X's equivalent of inotify:

Apple has chosen [to limit the number of filesystem events you can buffer, accepting that sometimes the buffer will fill up and you'll have to drop events]. The kernel buffers are a fixed size, and if they fill up because of a slow client, events get dropped. This means that one badly behaved client can ruin it for everyone.

Inotify suffers the same fate, as Nat's idea to make a queue overflow! t-shirt attests. At least inotify's queue size is run-time configurable. I am pleased to read here and elsewhere about Apple's fsevents and conclude that inotify is the same or superior.

I do think the idea of having an early-begot and long-running daemon arbitrate and manage filesystem events makes sense; the daemon can start earlier than, say, Beagle and continue running even after it consumes all of your available memory—joking, Shaw—asking the daemon "what did I miss?" when it starts up.

Friday, October 12, 2007

Pay Off This Wolf Pelt

With a market capitalization of $47 billion, EMC Corp's valuation less their 90% stake in VMware Inc. is, with today's market cap of $39 billion, only $12 billion. With a trailing-twelve-month EPS of $0.61, EMC's current share price prices the non-VMware portion of their business at just 9.6 times earnings (and only 8.3 times earnings using an estimated 2007 EPS of $0.70 and 7.1 times earnings using an $0.82 2008 EPS estimate). Compare that to similar-growth companies in the same industries and it is, well, quite low.

Perhaps EMC is undervalued, incorporating too small a valuation of VMware into its stock price. Maybe VMware is overvalued, what with a trailing-twelve-month P/E of 281.45 and all. Possibly both. Whatever the case, the spread ought to converge.

Relative value play: Short VMW, long EMC.

Saturday, October 6, 2007

La Brique.

Mark Pilgrim, fellow Googler, swears that he has nothing to say about the iPhone that hasn’t been said before, but his comments on the iPhone are rare words that echo my own thoughts.

The iPhone is nice, but let's stop acting like Apple just invented the smart phone.