A slower O(nlog(n)) but IMO much simpler algorithm is to just using a rolling hash[1]. With linear time precomputation you can compute the hash of any substring range in constant time.
Then for each position, you can just binary search for the longest palindrome centered at that position.
People, please. This presents a problem poignantly and provides a pleasant programmatic solution - the precise point of "hacker news". Be not so butt-bothered about non-apparent algorithm applications.
Based on time-stamps, at the time you posted there were 4 comments, of which 2 complained about the lack of applications and 2 engaged seriously with the material. That seems too early in the discussion to be accusing the community (as opposed to 2 individual posters) of being "butt-bothered".
On the other hand, there were no further such comments after your post, so maybe one could say that it worked. :-)
Wording is a bit sloppy: "Extending R (the inner while loop) takes at most a total of N steps, and positioning and testing each centers take a total of N steps too. Therefore, this algorithm guarantees to finish in at most 2*N steps, giving a linear time solution."
What he means is that the total time taken by ALL executions of the inner loop combined is at most N, not that each run of the inner loop takes at most N steps (otherwise it would become quadratic).
Then for each position, you can just binary search for the longest palindrome centered at that position.
[1]http://en.wikipedia.org/wiki/Rolling_hash