Skip to the Main Content

Note:These pages make extensive use of the latest XHTML and CSS Standards. They ought to look great in any standards-compliant modern browser. Unfortunately, they will probably look horrible in older browsers, like Netscape 4.x and IE 4.x. Moreover, many posts use MathML, which is, currently only supported in Mozilla. My best suggestion (and you will thank me when surfing an ever-increasing number of sites on the web which have been crafted to use the new standards) is to upgrade to the latest version of your browser. If that's not possible, consider moving to the Standards-compliant and open-source Mozilla browser.

October 30, 2003

Dark Matter Flowchart

The experimental situation in cosmology has undergone a mini-revolution in recent years. But, theoretically, many things remain as murky as ever. Hence the continued relevance of the Dark Matter Flowchart, which should be committed to memory by all serious students of the field. [Tip 'o the hat to Aaron Bergman.]

Posted by distler at 9:34 AM | Permalink | Followups (2)

October 29, 2003


Henrik Gemal updated his Acronym plugin for MovableType, to version 0.5. So I, in turn, had to update my patch, which adds support for abbrs and other righteous aspects of marking up abbreviations. It sounds like Henrik may roll my changes into a future version of his plugin, obviating this little waltz.

Apache 2.0.48 is out, fixing a number of bugs.

No, I haven’t installed Panther yet. Most likely, next week …

Posted by distler at 11:13 PM | Permalink | Post a Comment

October 28, 2003


Blogging has been light over here at Musings. But I have not forgotten about y’all.

Dvali and Kachru have a new paper out on their New/Old Inflation proposal. I’ve been engaged in discussions with them about my previous complaints. I’ll post something when we’ve converged on some sort of quasi-consensus. Suffice to say that the constraints can be satisfied by taking (in the notation of my previous post) λ 1λ 310 64\lambda_1\sim\lambda_3\sim 10^{-64}, λ 2O(1)\lambda_2\sim O(1) and m iM plm_i\sim M_{pl}.

Shamit has been busy on other fronts, with a paper with Gukov and collaborators attempting to revive an old proposal of Rohm and Witten for stabilizing the moduli in compactifications of the heterotic string with HH-flux. The new wrinkle, they argue, is that the HH-flux can be fractional, rather than integral, which, if the fraction is small enough, leads to an AdS vacuum with small cosmological constant (in the approximation that supersymmetry is unbroken).

MovableType Comment Spam continues to be a problem elsewhere in the blogosphere. But not here at Musings, where some simple anti-spam manoeuvres have proven remarkably effective. Since my mt-comments.cgi script has not yet disappeared from Google’s listings, I still see an average of a two attempted robo-postings a day. But all that does is land the chickenboners in my IP Ban List.

Posted by distler at 9:40 AM | Permalink | Followups (2)

October 20, 2003

If It Ain’t Broke …

An innocent attempt to “improve” the Comment-Entry form had the effect of disabling comments over the weekend. This was not an anti-spam tactic.

Should be fixed now.

Thanks to Thomas Dent for bringing my clumsiness to my attention.

Posted by distler at 9:36 AM | Permalink | Followups (1)

October 18, 2003

Camino and MathML

As previously announced, Dave Haas’s MathML-enabled build of Camino is out and works with this blog (as well or poorly as any current Mozilla build on MacOSX). You need the Mathematica Fonts installed and you should add

user_pref("font.mathfont-family", "Math1, Math2, Math4");
user_pref("font.mathfont-family.\u2212.base", "Math1");

to your ~/Library/Application Support/Camino/user.js file.

Update (10/18/2003): Dave Haas writes:

FYI — I changed the default all-camino.js pref file to include the fonts listed on your blog. On my next build, it should display (presuming the fonts are installed) as “correctly as one could hope” without any additional effort on the user’s part.

Posted by distler at 7:23 PM | Permalink | Post a Comment

October 17, 2003

Peas, Carrots, Beans

My daughter brought home the following problem from her 2nd grade math class:

You have 10 pots in which to plant vegetables. You can plant either peas, carrots or beans in each pot. You could plant 7 peas, 2 carrots and 1 bean plant, or 3 peas, 5 carrots and 2 beans, or … as long as you have at least 1 plant of each type and a total of 10 plants. How many different combinations are there?

This is a wonderful problem … for a slightly older child. My daughter’s answer, “more than 10,” was arrived at by a really noble attempt at brute-force enumeration. For 2nd graders, who have not yet mastered division, the actual solution is tantalizingly beyond their grasp.

Let’s solve a simpler problem first. Say we just want to plant two vegetables: peas and carrots. Line the 10 pots up in a row. We’ll plant all the peas on the left and the carrots on the right, and we’ll put a cardboard divider between them. There are 9 places to put the divider, so there are 9 different combinations of 2 vegetables that can be planted in the 10 pots. For 3 vegetables, we need to put in 2 dividers (peas on the left, carrots in the middle and beans on the right). There are 9 places to put the first divider and 8 places to put the second divider (since we’ve already taken one of the slots it could go in). That sounds like 9×8=729\times 8= 72 possibilities. But we’ve overcounted, since swapping the locations of the two dividers gives us the same configuration of plants. So the correct answer is 9×8/2=369\times 8/2=36 combinations. [More generally, with NN pots and kk types of vegetables, there are (N1 k1)\scriptsize{\left(\array{N-1\\ k-1}\right)} combinations.]

Maybe next year, I could actually explain this solution to her. Maybe, when she’s older still, she could come up with this solution on her own. But not this year …

So what does the teacher have in mind with this exercise?

Posted by distler at 11:59 PM | Permalink | Followups (2)

October 15, 2003

Software Monoculture

A lot of the blogs I read have been deluged in recent days with robots posting comments.

I got a couple of robot comments posted over the weekend, before I took steps to deal with the problem. Since then, I have not gotten any (though I have seen numerous attempts).

The problem is simple. All MovableType blogs have a comment-entry CGI script mt-comments.cgi and — by default — the comment-entry template makes no attempt to prevent Search engines from indexing it. The result? If you go to Google and search for mt-comments.cgi, you’ll get millions of hits of MT comment-entry forms. Write a 'bot to post comments to that form and sit back and enjoy watching your Google PageRank explode. How could any spammer resist?

This needed fixing and, after the first shot over my bow, I wasted no time in taking the following steps to put a stop to it.

  1. Add a
    <meta name="robots" content="noindex,nofollow" />
    line to the comment-entry template, so they don’t get indexed in the future.
  2. Change the name of the CGI script so that the previously-indexed one is inaccessible and spammers can’t go after the new one with a shot-in-the-dark URL.
  3. Point to the new script in mt.cfg:
    CommentScript somenewname.cgi
    and rebuild your blog pages.
  4. Sit back and enjoy watching spammers hammer away, attempting to access the old location of the comment-entry CGI script (adding their IP addresses to your IP Ban List).

But what of the future?

Once spammers tire of this little game (I give 'em another month, maybe), there are several directions they can go. Needless to say, I think I’m ready. But I’m not going to give the game away just yet. Check back in a few months to read about the next stage in the arms race.

Update (10/16/2003): Ben Trott weighs in:

We’ve all seen that comment spam is becoming a serious problem. Particularly on Movable Type weblogs, where the generated pages are all very similar in structure and semantics, …

Yeah, Ben that’s the problem, which is why content-based filtering is not really the solution. The real solution is to make robot-posting (regardless of content) infeasible. The above suggestions are the first step in that direction. I’ve implemented some further safeguards on this blog (which can be revealed by some assiduous viewing of source) and I’ve a few more tricks waiting in reserve for when the chickenboners wise up.

Update (10/16/2003): In a comment to this entry, I wrote “I, personally, prefer the CGI script to simply go ‘404’.” That, of course, is silly. What I really want is for the CGI script to go “410” (permanently gone). That’s a one line addition to the mod_rewrite rules for the MovableType CGI directory (which have been modified to reflect the new comment script location):

RewriteRule ^mt-comments - [G]

Update (11/17/2003): One month later, and still spam-free. Read this followup article for some further thoughts.

Posted by distler at 10:02 AM | Permalink | Followups (51)

Viva Camino!

The official Camino project seems to be more-or-less moribund. But Dave Haas has picked up the baton and is providing weekly builds of his efforts. But what’s exciting is that his builds are MathML-enabled and — as of the 10/17/2003 build — work with this blog. So go out and download Dave’s build this weekend and start enjoying all the MathML goodness in a genuine Cocoa-based browser (nudge to the other Dave).

Thanks, Dave, and good luck with this project!

Posted by distler at 7:49 AM | Permalink | Post a Comment

October 12, 2003

Nature Fumbles the Football

A while back, I noted that some people are taking seriously that the WMAP data on fluctuations in the CMBR show “too little” power in the low multipoles (l=2,3l=2,3). As an explanation. they’ve advocated the idea that the universe has nontrivial spatial topology.

Most likely, this is just foreground junk, and once the foreground subtraction is done better, these two datapoints will cease to stand out, and the apparent lack of isotropy at large angular scales will go away.

If the data are real, the original paper suggested the most obvious possible explanation: replace a spatially-flat, simply-connected, universe, 3\mathbb{R}^3 with 2×S 1\mathbb{R}^2\times S^1 (or T 3T^3 — it doesn’t much matter), with the size of the S 1S^1 somewhat smaller than the current horizon.

There are, of course, other possibilities for nontrivial spatial topology. Some will be ruled out because they would predict deviations from the observed spectrum at smaller angular scales (l4l\geq 4), others because they would predict too strong a departure from Ω 0=1\Omega_0=1. But, surely, these two data points (which may go away in any case) are too little information to decide between the remaining possibilities.

So, imagine my surprise when Sonia pointed out to me that Nature’s cover story for the October 9 edition was Universe Could Be Football Shaped, flogging a paper advocating the “Poincaré Dodecahedral Space” as the model for the spatial topology of the Universe.

Since the paper provides neither a coherent explanation of why they focus on this particular space, nor a decent explication of what the space is, I thought I’d provide a public service and fill in the blanks. En passant, I hope we can forestall a flood of copycat papers, each one focussing on the authors’ favourite choice of spatial topology.

Posted by distler at 4:26 PM | Permalink | Followups (6)

October 10, 2003

Browser Stats

I know the readership of this blog is not exactly a typical cross-section of blog readers generally, let alone of web-surfers as a whole. But I thought I’d share with you the past 10 days (5600 page retrievals, after eliminating robots, RSS newsreaders and other crud) of stats for this blog.

First, the breakdown of page accesses by browser:

Pie chart of browsers accessing this blog

As you can see, Mozilla and Internet Explorer are neck and neck, with 40% each. Safari is next with 5%, and everyone else trails well behind.

The breakdown by operating system was also interesting:

Pie chart of OS use

Windows was tops at 52%, followed by Unix (almost exclusively Linux) at 22% and MacOS at 18%.

But, as I said, maybe the readership of this blog is not all that representative. To get a more representative sample, I decided to look at the subset which arrived here via a google search (700 searches). Their browser breakdown looked like this:

Pie chart of browsers from google searchs accessing this blog

They were 67% IE, 13% Mozilla and 10% Safari users. And their OS breakdown:

Pie chart of OS use of google searchers

was 72% Windows, 15% MacOS and 12% Unix (again, almost exclusively Linux).

Several things surprised me here.

  1. I didn’t expect that the overall percentage of IE user among my readership would be as high (40%) as it is. Reading this blog in IE seems like an exercise in masochism. Until I saw the numbers, I was sure I had fewer masochist-readers.
  2. I didn’t expect that the percentage of IE users among the google searchers (a more-or-less random cross-section of web surfers) would be as low (67%) as it is. I’d swallowed whole the propaganda that 98% of web surfers are using IE. But try as I might: eliminate all searches involving Macintosh-related keywords, focus only on users running Windows, … I could never come even close to 98%.
  3. The Mozilla figure includes Firebird, but not Camino, which is counted separately. Frankly, I was surprised at how few Camino users there are. I got more hits from Lynx users than from Camino. I think this is bad news for the Camino project.
  4. Linux is bigger on the desktop than most people seem to think. And the Macintosh ain’t doing so bad either.

I don’t know whether any of this means anything to those fretting over the fallout from the Eolas Patent Suit, but it makes me want to hum Don’t worry, be happy!

Posted by distler at 2:02 AM | Permalink | Followups (13)

October 8, 2003

Skyrme Fun

A while back, I wrote about the possible discovery of an exotic baryon state, Φ +\Phi^+, with mass m=1540MeVm=1540 \mathrm{MeV}, width Γ<22MeV\Gamma\lt 22 MeV and flavour quantum numbers uudds¯u u d d \overline{s}. Truth be told, this was but one of several observations of the same resonance.

What I didn’t say was that this flurry of experimental work was actually the result of a theoretical prediction of the existence of this state on the basis of Skyrme model calculations by Diakonov, Petrov & Polyakov. They found a set of states in the 10¯\overline{10} of SU(3)SU(3). By fitting the masses of two of these excitations to the observed N(1710) and Σ\Sigma(1880) resonances, they predicted that the lightest member of the 10¯\overline{10} would be the Φ +\Phi^+, with a mass and width (m=1530MeVm=1530 \mathrm{MeV}, Γ<15MeV\Gamma\lt 15 \mathrm{MeV}) extremely close to the (now) experimentally-observed values.

Recently, Itzhaki, Klebanov, Ouyang, and Rastelli have looked a little more closely at the large-N cN_c Skyrme Model. They argue that, in the “bound state” approach of Callan & Klebanov (Nucl. Phys. B262 (1985) 365), this resonance does not appear — unless you do something rather artificial, like crank up the SU(3) symmetry-breaking (m s>1GeVm_s \gt 1\mathrm{GeV}).

I don’t know what to make of this. Diakonov et al’s “rigid rotator” approximation results at N c=3N_c=3 are way too good to be dismissed out-of-hand. It would be sad if there weren’t a clean way to derive them from large-N cN_c.

Posted by distler at 12:40 AM | Permalink | Post a Comment

October 5, 2003

Perl 5.8.1 and MovableType

You may have noticed the mess on this blog on Thursday/Friday. It was caused by my upgrading the Perl installation to 5.8.1 (from 5.8.0).

Perl 5.8.1 has an unfortunate interaction with the way MovableType applies global filters. MT stores the global filters in a Hash . With Perl 5.8.0 and earlier, the order in which they would get executed was, if not predictable, at least consistent between invocations. Not so with 5.8.1. Now the order of execution is truly random, differing from invocation to invocation.

Consider an MT container tag

<MTEntryBody process_tags="1" safe_urls="1">

with content

... <a href="<MTBlogURL>archives/000121.html"> ...

Sometimes the process_tags filter will get executed first (expanding the MT tag into a full URL), but sometimes the safe_urls filter will be applied first, yielding

... <a href="&lt;MTBlogURL&gt;archives/000121.html"> ...

The only solution is to enforce the execution-order using Alexei Kosut’s MTBlock plugin:

<MTBlock safe_urls="1"><MTEntryBody process_tags="1"></MTBlock>

Anyway, between that and the inevitable pain associated to switching from Apple’s “let’s throw everything helter-skelter into /Library/Perl” to a more standard perl setup, with separate directories for standard and site-specific modules, organized into subdirectories by version-number, things were pretty rocky here for a while.

Should all be back to normal now…

Posted by distler at 2:10 PM | Permalink | Followups (1)

October 1, 2003

OpenSSL Vulnerability or Opportunity?

On the sidebar of my blog, you can read the latest CERT Advisory. This time, it’s OpenSSL that’s vulnerable. You can download the source to the new version (either 0.9.6k or 0.9.7c) from there. If you use fink, you can update that way.

If you’re hoping for an official Apple patch, the Advisory helpfully states:

Apple: Vulnerable. This is fixed in MacOSX 10.2.8 which is available from

If you follow that link, you’ll find that 10.2.8 is currently unavailable. And if you happened to have previously downloaded the 10.2.8 update to fix vulnerabilities in Sendmail and OpenSSH, you might be deluded into thinking it covers this vulnerability as well. Of course, it does not, as the 10.2.8 update (the “old” one, not “new” one, which hasn’t appeared yet) was yanked from the Apple web site long before the release of the new OpenSSL.

And if you didn’t download that update while it was fleetingly available, you are out-of-luck fixing those other vulnerabilities, unless you’re willing to compile your own. Why can’t Apple do a better job of putting out security updates in a timely fashion? Probably because they desperately need to hire someone. Oh, wait. That’s what they’re trying to do (click on Search, and enter the Job ID: 2025671).

Posted by distler at 11:14 PM | Permalink | Followups (3)