The bad things keep sticking around and irritating us, whereas the good things are quickly taken for granted. The bad things are often easy to describe, whereas the good things are sometimes just the absence of a bad thing — the absence of some irritation.

This is a fundamental asymmetry, and it has lots of implications, big and small. For example, a big implication is the development of human society and technology. Because we are more prone to noticing bad things, and bad things keep bugging us, we try to fix bad things and make them go away. So humans invented tools (to stop hurting their fingers), agriculture (to stop hunger and laborious hunting/gathering), medicine (to stop their family members from dying), writing (to stop forgetfulness) and the internet (to stop the slowness of paper communication). Over history, humans have continuously taken stuff that is bad, and tried to make it better. Now that we have all these good things (tools, agriculture, medicine, writing, internet), we mostly take them for granted and don’t think about them any more.

(Some things that humans invented turned out to have bad side-effects besides their intended good effect. Take weapons as an example: intended to stop the hungry neighbours from stealing our food, but the idea got taken a bit too far. But that’s a different story.)

There are also other, less grandiose consequences of bad things being more noticeable. For example, when I was writing music and song lyrics, I found it comparatively easy to write about themes like conflict, struggle and sadness; writing about good things, however, was much harder. It would often just sound trite, banal and uninteresting.

How do you articulate those things that are good? Part of the point of this very essay is to see if I can write about things being good without just being incredibly boring. And what do I do? Complain about the fact that it’s hard to express things that are good. I complain. I am irritated that bad things are easier to write about than good things. And so I write about that irritation, thereby locking myself in a self-referential loop.

How annoying. Let’s talk about the good things again.

An observation. If bad things are much more noticeable than good things, that means that it’s very easy to lose sight of all the good things. In fact, it probably means that we are surrounded by lots of wonderful things that we’ve simply forgotten about. It might even be that the vast majority of things around us are good, and we are just failing to notice them!

We need to consciously remind ourselves of the good things from time to time, to avoid getting too bogged down in the bad things. That cannot mean getting complacent; it just means enjoying and appreciating life.

For example, I am writing this essay on a mobile phone (good) connected to the internet (good) while sitting in the sunshine (good) in a park (good) in San Francisco (good). I am wearing comfortable clothes (good) and don’t have any stones in my shoes (good). I live in a peaceful age (good) in a peaceful society (good). I am educated (good), healthy (good), don’t need to worry about being able to afford the rent (good) and I have a wonderful family (good). I look forward to sending this essay to Rita (good) to see what she thinks. (Hopefully it’s not too bad.)

He could recognise me because we had exchanged emails, and he had therefore seen my photo in Rapportive next to my email.

This is our social future. We’re busy creating it.

The interview is for the Startup Success Podcast, a series of shows providing a wealth of useful information and inspiration for startups. In this episode, Patrick Foley talks about his visit to the Microsoft Professional Developers Conference (PDC), and I talk about Go Test It – what it is, how it works, why we built it, where it is going in future. There’s even a special discount in there! :)

Head over now to the Startup Success Podcast and listen to the episode! (The interview with me starts at about 15 minutes in.)

This might come as a surprise, so please let me explain. It is something which has been tempting me for a long time. I have always loved working independently and getting deep into a project which I find cool, and a PhD (in computer science at least) seemed to me the ultimate manifestation of this independence: three years in which you can learn about and figure out an interesting topic, and invent new ways, with hardly any constraints other than that you’re supposed to write up something vaguely insightful at the end. (I’m sure this is an overly idealised notion of what a PhD entails, but please bear with my dreamworld for now.)

On the other hand, I have started a company and I’ve had an incredibly experience-packed two years so far doing that. I would be a completely different person now if I had gone directly into a PhD after graduating. Running a start-up has made me less risk-averse, more dynamic, more outgoing and confident, more pragmatic, more focussed, and has given me a much better understanding of how the world works.

You might think that returning to university is a cop-out, a return from the harsh winds of a start-up into the safe haven of academia. Let me assure you that this is not the case, for two reasons.

• Firstly, I will keep my company going on the side. Obviously I won’t be doing it full-time any more, but I am keeping all of my active clients, and I will continue the high level of service they know from me. It won’t be a return to student lifestyle for me; if anything, my focus will get sharper.
• Secondly, the research proposal I have written is not just any proposal. It is aimed squarely at what I (and many others) believe will be the most influential technologies of the next decade or two: technology which deals with the vast amount of data on the web, filtering, processing and mining that information such that it becomes a source of useful insight. Machine learning and computational linguistics.

We are rapidly moving towards a world where everything which can be digitised and put on the web will be. Blogs, social networking sites, Twitter and many other services increasingly become expressions of a person’s identity. Already now I find that if, for example, I receive an email from somebody I don’t know, often the first thing I do is to look up them up on LinkedIn, find their blog or Twitter username, look up their company or affiliation and find out what they do. This allows me to quickly judge the context of their enquiry, gauge the level at which I should reply, or detect whether I need to be cautious for some reason. If it is somebody I have dealt with before, I have a private database of contact history which helps when I don’t remember details of conversations months or years back. (It’s nothing particularly secret, it’s just an extended memory.)

Identity on the web further manifests itself in social interactions with others. This can be a powerful source of insight: for example, if I don’t know somebody, but I see that they publicly communicate with somebody I already know and trust, I will immediately be more inclined to trust them too. This is not a rigorous decision, but a useful first guess in the absence of other information.

However, gathering the pieces of a person’s identity from across the web is currently a time-consuming manual process.

My own digital identity, for example, is spread all over the interwebs. It manifests itself in my blog (which you are currently reading), my LinkedIn profile, my undergraduate dissertation, my open source projects, my company, my tweets, my Facebook profile, my photos and my taste in music, not to mention the many other fragments scattered about other sites, in the form of press articles about me or my projects, my archived emails to mailing lists, my comments on other people’s blogs, etc. They are all there, and Google has indexed them all (apart from the small number of things behind logins), but at the moment they do not come together to form a coherent whole. They are scraps of data, but without further analysis they don’t mean much.

In a nutshell, my PhD proposal is to gather that publicly available data together and make it useful. For me, that means to map out the graph of connections between different people, and relationships between people and topics. Who is interested in what, and who discusses what topics with which people?

Consider an example to see why this might be useful: say you are new to a particular field of specialism (whatever it may be), and you attend a conference to find out more about it. The programme of the conference is a long list of sessions with names of speakers and titles of talks. Someone who has been in the field for a while will know many of the speakers’ names and will immediately know which sessions will be worth attending and which people to talk to. But a newcomer will have no idea, and has no way to find out other than by spending years getting to know the community. Why can’t you just visualise the relationships between the various speakers and topics, so that you can immediately see who the most influential presenters are and whose interests are closest to your own? Or even discover which attendees of the event would be most worth talking to? At the moment we rely on personal referrals, serendipitous meetings and crude markers (like First Tuesday‘s “green for start-up, red for investor, yellow for service provider”); why can’t we have a more direct way of finding the people we should be talking to?

There are two steps to making this work: firstly identifying which two bits of information on the web belong to the same person (even if they are on different websites, using a variant spelling of the name or pseudonym-like username, and without confusing two people who happen to share the same name), and secondly mapping out the relationships between the people and the topics they talk about.

Google’s success rests, amongst other things, on the PageRank algorithm which calculates a ‘quality’ rating for each page on the web. Their core innovation was to realise that links between pages, not just the pages’ content, were the measure which determined how useful a search result would be, and implementing PageRank allowed them to achieve much better search results than the other search engines at the time.

A lot has been said about the next big thing post-Google. I wouldn’t want to make predictions, but let’s put it this way: I would not be surprised if the next core innovation is to realise that individual people, and the connections between people, are even more powerful than pages and links between pages. The marriage of social web and semantic web, to be fully buzzword-compliant.

This is a difficult and multi-faceted problem, which is why I want to take it on within the framework of a PhD rather than try to develop it as a product straight away. There is a lot I need to learn, from the mathematical details of the best machine learning techniques to the linguistic techniques needed to extract structured information from natural language text and small clues on the web.

There is a lot of existing research on which to build. Stephen Clark, my proposed PhD supervisor, is one of the authors of the C&C parser, which is maybe the finest statistical natural language parser out there; also in the Computer Lab’s Natural Language and Information Processing Group, Simone Teufel and others’ work on citation analysis is likely to be relevant. And I hope to collaborate with the lovely people at the Cambridge Engineering department’s Machine Learning group, including Zoubin Ghahramani who is recognised as one of the top researchers worldwide in the machine learning field. Very good reasons to be in Cambridge.

Please note that this is not at all certain yet — I have applied, but I may not get accepted, I may not get funding, and the Board of Graduate Studies may lose/forget my papers. But all going well, this is the general direction in which I’d like to head.

On a final note, it will also be interesting to explore the ethical aspects of identity on the web. I believe that both open sharing of personal information and automated mining of that information will increase massively in the coming years, and exploring the ethical and social consequences, as well as protecting the rights of the individual, should be a part of the research in this area.

PS. My favourite techy buzzword so far is “maximum entropy supertagger” (one of the components of the C&C parser). Just say that out loud. Maximum Entropy Supertagger. Doesn’t it sound awesome? Before my inner eye, there is a sci-fi film of a group of heroes fighting off an alien invasion. The tentacled beasts from outer space are everywhere, but the good guys are just managing to keep them at bay. But then… ominous music in the background… a huge towering construction appears from behind a hill in the distance. Silence falls. Everybody stares at the terrifying thing brought by the aliens. The guy who later will be in charge of single-handedly saving the world turns around, and in a brief close-up shot he says to his colleagues in a perfect Hollywood manner: “Oh my God. They’ve got a Maximum Entropy Supertagger.”

Then, before we all went off to the pub, I gave a quick update on our progress on setting up a coworking space in Cambridge under the name of “CamCow”. Here are my slides (on SlideShare):

If you’re interested in looking around the new coworking space or want to find out more, please get in touch.

Purpose of the application is to help people who want to give up smoking. Users can enter the date when they stopped smoking, and get updates on how much money they have saved, display a box on their profile, get support messages etc. The application was launched now because many people try to give up smoking as their new year’s resolution.

The application is hosted on Google App Engine, marking my first real-life use of GAE. It has been a bit frustrating at times, and I may post some more comments about my App Engine experience at some later stage.

Just over 3 days until Bid for Wine goes online! It’s great to see this massive project, which I’ve blogged about before, finally complete. We will launch on Friday 31 October, the first lots for sale are already lined up (including a remarkable bottle – a unique item from a private bottling of the famous Guigal Family, and probably the only bottle of its kind on the open market!), some big wine magazines are going to be reporting, and everybody is getting very excited.

The application is deployed to the servers (we are running on Engine Yard), the DNS is updated, the load balancers are configured, the holding page and contact form are already getting a fair bit of traffic, everything seems ready. We just need to flick a switch and users will start hitting the site.

Hold on. How do we know that the site won’t just immediately collapse under the load of (hopefully many) visitors hitting the site at the same time? The last thing we would want to do is to put them off by going down straight after launch. Some load testing is in order.

That said, we don’t want to spend much time and money on it either. It doesn’t need to be an enterprise-grade solution. All I want to do is check that we won’t fall over and die if we get lots of nice people coming to visit us.

I’m aware that with load tests, you need to be quite careful that you end up actually testing the server; it can happen easily that the bottleneck is actually somewhere on the client’s side. So part of this experiment was actually to test the load testing tool, not just the target application!

The tool I used here is ApacheBench; there are others, like http_load and siege, which I may try another time. I booted up an EC2 instance specifically for running ApacheBench, to provide a clean ‘laboratory’ environment without processes contending for CPU and I/O. I ran a variety of tests using different URLs, sending cookies (to simulate a logged-in user), with and without keep-alive etc. These parameters all changed the results a bit, but the general shape was the same, so here’s some data for one particular page (the auction listing view).

ApacheBench lets you set the level of concurrency, i.e. the number of connections it tries to make to the server at the same time. We have two EngineYard production slices (virtual machines), each running three Mongrels (the single-threaded server daemons which run the application), so I expected that we should be able to handle six concurrent connections without any queueing of requests.

The first graph is for a test with four concurrent connections, i.e. the server should be pretty relaxed. It shows which proportion of pages were served in less than a particular time (i.e. the percentiles). The graph is generated from timings of 10,000 page views.

How to read this graph: e.g. see that the red line crosses 0.16 seconds at about 80%; that means that the client (ApacheBench) reported that 80% of requests were served in 0.16 seconds or less. The highest point at 100% is the longest time which it ever took in the test.

I measured four quantities: the time per page view reported by ApacheBench (the client), the total time per page view reported by the server, and the values for rendering time and database time reported by the server. (The blue line is the sum of the green and the orange lines.) I would call this pretty well-behaved: 84% of page requests are received by the client within 200 milliseconds, and 95% within 300ms; rendering time is quite variable while database time hardly ever exceeds 100ms. And the client times are just a constant amount above the server times, to account for the fact that the request and response have to go across a network, through a proxy/load balancer etc.

Each of those page views involves about 11 SQL queries and 10 partials being rendered; we can’t get much below that, since the page content is fairly complex. My guess is that you can’t do much better than these timings with Ruby on Rails out of the box; at the end of the day, it is a pretty slow platform. (I’m not saying that other languages/frameworks are any better — most likely, they are not.) When we find that this site needs to scale further, we will simply have to add more mongrels, database read slaves, and plenty of memcached to the system.

By the way, in this test the 1-minute load average reported by the Linux kernel reached a maximum of 1.6 — not very much at all.

Now, what happens when we hit the site harder? In the next test I increased the concurrency parameter to 16, more than twice the number of mongrels. Now I would expect all mongrels to be busy all the time (saturated with requests), and response times to go up. And this is the graph we get:

Ignore the red one for now. The shape of the three server-side curves is still pretty much the same as before, and overall they are taking 50% to 100% longer to respond compared to the test above. That is simply because the CPU is now fully occupied with all three mongrels, whereas previously there might only be one or two mongrels wanting CPU at the same time. When I ran further tests, increasing concurrency of the client to 64 (more than ten times the number of mongrels), these server curves stayed exactly the same, and server-side times didn’t increase any further. This is good news: although the server is overloaded, this doesn’t cause any loss of throughput (which might be the case if there were inefficiencies).

For a saturated server, the kernel load average was between about 3.0 and 4.0, no matter how many concurrent clients there were. This makes sense, since the load is determined by the length of the scheduler’s run queue, and if you only have 3 server processes (mongrels) plus a few of background housekeeping processes with small requirements, there’s no reason why it should go any higher.

The combined throughput of the mongrels in this test, and in those with higher concurrency, was pretty constant at 33 requests per second. Since that is across 2 CPUs, we must be taking 60ms of CPU time per request, or an average of 180ms wall-clock time (1 CPU is shared between 3 mongrels). The average request time (DB + Render) reported by the server is 164ms, so we have only 10% overhead somewhere which is not being accounted for. Nice to see that the numbers add up quite well. :-)

Now turn your attention to the red line, which is now completely different from before. There are still some page views which happen very quickly, but some are taking up to a whole second. What is happening here is that requests are getting queued up — if they are lucky, the queue is empty and they get served right away, but if it’s their bad day, they might have to wait in line after several other requests until they finally get to talk to a mongrel. The mongrels work at the same pace, no matter how long the queue is (think post office workers), so obviously waiting times will increase the more people/requests try to get in the door at the same time.

With 16 concurrent clients, the median response time was 0.45 seconds, and 99% of requests were served within 1.3 seconds. However, with 64 concurrent clients, the median was 1.8 seconds and the 99% percentile was a whopping 6.2 seconds. (This is the point where users get rather impatient.) I’m not sure exactly what the relationship between concurrency and waiting time is; maybe with some more experiments and some theory I can work it out. (I took a course on queueing theory at university, which covers exactly this kind of system, but I can’t remember much of it. If I have time I’ll dig it out again and see how I might be able to model traffic to a web application with lots of nice maths…)

The thing which struck me in this graph is quite how straight that red line is; I had expected the response times to be less widely spread. This prompted me to have a look at the actual distribution/histogram of response times as reported by the client.

Another thing I wanted to check was how good ApacheBench’s concurrency setting actually was — how could I trust that it really keeps the server as busy as it claims to? And maybe it makes requests in certain regular patterns which might skew the results. So I ran the following 3 tests in a side-by-side comparison:

1. One ApacheBench process set to make 64 concurrent requests, running on an EC2 instance, no keep-alive, making 10,000 requests.
2. Four ApacheBench processes, each set to make 16 concurrent requests, running on the same EC2 instance, no keep-alive, each making 2,500 requests.
3. Four ApacheBench processes, each set to make 16 concurrent requests, each running on its own EC2 instance, no keep-alive, each making 2,500 requests.

The server-side statistics for the three tests, including the total throughput, were identical. However, interestingly, there was a noticeable difference between the distribution of response times reported by ApacheBench in the three cases. I have plotted them below:

(This diagram is what you get if you flip the one above by a diagonal axis and then differentiate the function by response time. Note also that the colours now have a different meaning.)

I don’t quite know yet what to make of this. Ok, the behaviour doesn’t differ too drastically, so if you just want a rough idea of the performance of your application, it seems like ApacheBench’s concurrency option is perfectly fine. I am just a bit intrigued by the differences.

The green line is most like what I expected, because it most resembles an exponential distribution, which is what queueing theory predicts in many cases. Interestingly, this is the setup in which the four ApacheBench processes are most likely to get in each other’s way, contending for I/O on the EC2 instance — maybe this causes some jitter, blurring an otherwise regular pattern. In the two cases with one ApacheBench process per machine (blue and yellow lines) the distribution is more flat between about 1 and 3 seconds response time; in particular, the blue and yellow setup are noticeably more likely to see 2-3 second response times than the green setup.

If anybody has ideas on how to interpret this, please let me know. I should probably also repeat those experiments with a larger sample size and work out if the differences are actually statistically significant, but I don’t have time for that at the moment.

SCRIPTS

In order to produce these statistics, I wrote a few simple shell scripts to gather and process the data. I’ll put them here in case somebody finds them useful (and so that I can find them again when I need them next time!).

First I have two scripts which run on the servers with the mongrels. In our setup, each virtual machine has its own logfile, so the scripts need to be run on each virtual machine. They select the portion of the logfile which was written during the duration of the test, and also log load averages from the kernel. Set an environment variable like export LOGFILE=/path/to/my/production.log before running these scripts. The first is called before-test.sh and should be run before the test starts:

1
2
3
4
5
6
7
8
9
10
11

#!/bin/sh
if [ ! -f "$LOGFILE" ]; then echo "LOGFILE not found"; exit 1; fi
echo "time,1min,5min,10min,running,procs,lastproc" > /tmp/loadavg.csv
( while true; do
    ts=`date '+%Y%m%d%H%M%S'`
    load="`cat /proc/loadavg | tr ' /' ','`"
    echo "$ts,$load" >> /tmp/loadavg.csv
    sleep 1
done ) &
echo $! > /tmp/loadavg.pid
wc -l $LOGFILE | awk '{print $1}' > /tmp/skip_log_lines

And after-test.sh should be run when the test has ended:

1
2
3
4
5
6
7

#!/bin/sh
kill `cat /tmp/loadavg.pid`
echo "total,render,db,url" > /tmp/requests.csv
skip=`cat /tmp/skip_log_lines`
tail -n +`expr $skip + 1` $LOGFILE | grep '^Completed in' | \
    awk '{print $3 "," $8 "," $12 "," $17}' >> /tmp/requests.csv
rm -f /tmp/loadavg.pid /tmp/skip_log_lines

As you can see, it filters the processing times reported by the server out of the logfile and formats them as CSV for post-processing in your favourite spreadsheet application.

To execute the test (potentially with several processes at the same time), I ran something like the following on an EC2 instance:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

apt-get update
apt-get -y dist-upgrade
apt-get -y install apache2-utils
mkdir loadtest
cd loadtest
TESTS="list1 list2 list3 list4"
COOKIE="-C _session_id=12345678901234567890"
HOST="http://staging.example.com/"
AB="ab -n 10000 -c 16" # 10,000 requests, concurrency 16 per process
$AB -g list1.log $COOKIE "${HOST}/path/to/test" &
$AB -g list2.log $COOKIE "${HOST}/path/to/test" &
$AB -g list3.log $COOKIE "${HOST}/path/to/test" &
$AB -g list4.log $COOKIE "${HOST}/path/to/test" &
wait
for test in $TESTS; do
    awk -F '\t' "{print \$4 \",\" \$5 \",\" \$6 \",$test\"}" < $test.log | tail -n +2 > $test
done
echo "dtime,ttime,wait,test" > bench.csv
cat $TESTS >> bench.csv

Then copying and aggregating all the logs onto my machine for making pretty graphs:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

TEST=test7
CLIENTS="ec2-75-101-204-213"
KEYFILE="path/to/private/key/file/for/ec2/instance"
for host in prod1 prod2; do
    for file in loadavg requests; do
        scp "ey-$host:/tmp/$file.csv" "$file-$host.csv"
    done
done
for client in $CLIENTS; do
    scp -i $KEYFILE root@$client.compute-1.amazonaws.com:loadtest/bench.csv client-$client.csv
done
mkdir $TEST
paste -d ',' loadavg-prod1.csv loadavg-prod2.csv > $TEST/loadavg.csv
cat requests-prod[12].csv > $TEST/requests.csv
cat client*.csv > $TEST/clients.csv
mv loadavg-prod[12].csv requests-prod[12].csv client*.csv $TEST

Obviously these scripts are still pretty rough around the edges, but they did the job of being simple and telling me what I wanted to know.

Maybe this way of decision making is strongly underrated.

In that context I was told that I had to read a certain article by Sir Hermann Bondi (Physicist, 1919–2005) entitled “Arrogance of certainty”, because it apparently forms the basis of every discussion of the topic. I was given a copy of the article on paper, and I liked it because of its lucid and clear writing style. I kept it, even though the paper got quite crumpled in my bag at some point. 

Recently I was looking for the article again and searched for it on Google. To my great surprise, I couldn’t find any trace of it, let alone the whole text. Therefore I want to re-publish it here so that others may find it online in future. Unfortunately I have no idea where and when it was originally published — all I have is a crumpled photocopy of a photocopy of a newspaper cutting. If you have any further information, please let me know.

I neither fully agree or disagree with this article, but I think it is well worth reading. Without any further comment, here it is.

Hermann Bondi

Arrogance of certainty

I am a non-believer in any revealed religion and a scientist. In my acquaintance with scientists I find both belief and non-belief. I know sufficient numbers of scientists of each persuasion to be willing to classify two statements as both being stupid and palpably untrue prejudices, viz, that a person, being a scientist must accordingly be a believer in a revealed religion, or the opposite statement.

Any thinking person must be struck with awe and wonder on contemplating the mystery and complexity of our universe. We scientists have somewhat enlarged our modest island of understanding that is surrounded by a huge ocean of ignorance. Some feel that there must be an intelligence, an architect of all this grandeur, an architect that may be called God, but without ascribing to this unknown entity any interest in our human affairs or in our prayers. (If I rightly understand, this was Einstein’s view.)

There are also people who believe, as a generalized feeling, that this entity, this God, in some undefined way responds to their trouble and their prayers without claiming that they have any describable or communicable knowledge of this their God. Again, there is revealed religion, the belief that God in some way, different for different religions, revealed himself in some precise communicable manner conveying some absolute truth.

I have no quarrel with the first three stages, but I regard the widespread human tendency to have firm faith in a revealed religion as one of our most negative traits. Indeed, I do not call myself an atheist, but an anti-revelationist. To call myself an atheist would mean denying an entity so differently defined by different people that the denial is meaningless. Some say God is love. I would certainly not wish to deny love. Some say God is nature. I am not so absurd as to deny nature. But the certainty involved in revelation horrifies me, and the historical record of the deeds done in the name of such revelations bears me out.

If one looks at religiosity, the immediate staggering fact is that different people believe firmly and fervently in different and, in many respects, contradictory religions. The very variety of faiths is remarkable, yet each can claim adherents of the highest integrity, sincerity and honesty, utterly convinced of their belief. How anyone can have the arrogance to think that their own belief is right and anybody who thinks differently is wrong passes my comprehension. Surely the overwhelming evidence is that the human mind has the tendency to believe firmly but incorrectly, since at most one of the many competing revealed religions can be right.

Nor am I much impressed by what some regard as threads common to different major religions as regards their theory. What has a non-theistic faith like Buddhism in common with a theistic one like Islam? Why are we to stress likenesses now when people have fought to the death over minute differences in their religions?

There is indeed a common morality among all of us humans, enshrined in the golden rule that one should do to others only as one would have done to oneself. I see this founded in our common humanity, which is why I call myself a Humanist. I see this common morality sometimes supported by religion, sometimes perverted by it. Above all we need to strengthen all that unites us with other humans, where religion so readily divides us. This division by faiths, so often pursued with the utmost cruelty, is what surely we should strive to heal, by relegating religion from the public domain to that of individual belief or non-belief.

What I abhor about revealed religion is its supposed absolute certainty. It is here that I see the real conflict between science and religion. In science we know that our understanding, our theories are only provisional, and liable to be upset by experiment and observation. On this basis, so well described by Karl Popper, science has indeed acquired universality with people of different cultures, ideologies, races etc able to cooperate. Science is so successful in this because it is attuned to the basic human characteristic of fallibility. It is the inhuman certainty a believer feels in revelation that is so obnoxious and harmful and unacceptable as a basis for morality.

Of course we must recognize the great role religion has played in history but need not support it. Being an anti-revelationist is in no way arid. It allows one to enjoy freely all that human genius has produced; it allows one to engage untrammelled in the search that is the real joy of living.

Sir Hermann Bondi, FRS, was Master of Churchill College, Cambridge.