Musings

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.]

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 …

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) $\lambda_1\sim\lambda_3\sim 10^{-64}$, $\lambda_2\sim O(1)$ and $m_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 $H$-flux. The new wrinkle, they argue, is that the $H$-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.

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.

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.

My daughter brought home the following problem from her 2^nd 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 2^nd 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\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\times 8/2=36$ combinations. [More generally, with $N$ pots and $k$ types of vegetables, there are $\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?

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.

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!

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,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, $\mathbb{R}^3$ with $\mathbb{R}^2\times S^1$ (or $T^3$ — it doesn’t much matter), with the size of the $S^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 ($l\geq 4$), others because they would predict too strong a departure from $\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.

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:

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:

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:

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

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!

A while back, I wrote about the possible discovery of an exotic baryon state, $\Phi^+$, with mass $m=1540 \mathrm{MeV}$, width $\Gamma\lt 22 MeV$ and flavour quantum numbers $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 $\overline{10}$ of $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 $\overline{10}$ would be the $\Phi^+$, with a mass and width ($m=1530 \mathrm{MeV}$, $\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_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 \gt 1\mathrm{GeV}$).

I don’t know what to make of this. Diakonov et al’s “rigid rotator” approximation results at $N_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_c$.

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…

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 http://www.apple.com/support/

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).