Typical Liberal Junk

You may just have picked up that I am neither a liberal, nor much enamoured of liberals. If you haven't picked this up, I suggest you take a long, hard look at the title of this blog. Anyway...

Spotted this on Slashdot: Blogger Launches 'Google Bomb' At McCain. The gist of it is that some liberal blogger has decided to manipulate the Google PageRank system to make Google searches for John McCain return negative news stories. What had me particularly disappointed in human nature was this quote from the blogger in question:

Obviously, it is manipulating, but search engines are not public forums and unless you act to use them for your own benefit, your opponent's information is going to get out there. [As cited here.]

I hope we can all spot the rather blatant, cynical hypocrisy here. "Search engines are not public forums," he writes; then why do you consider them forums for spreading your own views? And, rather more disturbingly, "Unless you act to use them for your own benefit, your opponent's information is going to get out there." Right, OK, sorry for thinking that informed, respectful debate was important to our society. Yes, sir, I'l just shunt myself off to the gulag right now. No more spouting about those infamous right-wing ideals, like freedom of speech, or respect for people with differing ideas.

I think, funnily enough, that I am right about most things in life. I daresay I am actually wrong about a number of things, but I haven't been convinced of it yet; if I thought I was wrong, then I'd change my mind. I am so convinced that I am right, that I don't mind others hearing the other side of the story; I think that an informed debate will get us nearer the truth. I might even learn a thing or two from the other side. But this guy doesn't seem to think like that. His campaign is not to convince people that he is right, but to silence opposition: "Unless you act ... your opponent's information is going to get out there."

I guess I shouldn't be surprised; from the French revolution to the Stalinist purges, the idealism of the left wing has always turned to violent repression of anyone who disagrees. I don't say my side of politics is guiltless; Hitler is the right wing's skeleton in the closet. I think most on the right wing would agree that he was wrong, though; we would disagree with both his repressive actions and the motivation that lay behind them.

Pilate asked the rather excellent question, "What is truth?" Is truth that which is real? or that whiich you can convince someone to believe, even by such crass means as manipulating Google search results?

And Another Thing...

When filling out a passport application for said four-week-old child, they ask for her height. Do they think this will be useful in identifying her?

Like Pulling Hens' Teeth...

Ever tried taking a passport photo of a four-week-old child? The documentation says the child must be:

• Directly facing the camera;
• With both ears in view;
  
• Holding her head square on her shoulders;
• With her mouth shut;
• And her eyes wide open, so the colour can be seen;
• Not frowning;
• Not smiling;
• On a plain, light-coloured background;
• With no hands in view (mine or hers);
• Not too light;
• Not too dark; and
• Not too out of focus.

Sigh. There are maybe one or two here I can use.

Cricket and Why We Play It

Disclaimer: Americans can stop reading now. You will not understand. In fact, it might be best if everyone except Australians stopped reading now.

I am an Australian. If there is one thing that Australians are truly passionate about, it is not Vegemite, or Holdens, or Outback, but Cricket.

Opinion varies from Australian to Australian on why exactly we play cricket. There are two theories:

1. We play cricket to beat the English.


2. We play cricket to beat the New Zealanders.

I am a subscriber to both these theories, in the inverse order of that given above. The principal reason for playing cricket is to beat New Zealand at every opportunity available.

So you might understand if I am a bit tender at losing a one-day cricket series to New Zealand 3-0. I have a couple of things to say about this.

Any New Zealanders who read this will no doubt accuse me of sour grapes (especially when they get near the end). They are right. But they are therapeutic sour grapes.

Cricket and How To Lose At It

If Michael Hussey ever captains Australia again it will be too soon. Much too soon.

One of the fundamental characteristics of a good captain of a cricket team is that he knows how to create pressure. Some captains have it, some don't. The ones that don't will not last long. Hussey does not have it. Michael Vaughan has it. Andrew Flintoff is learning it. Ricky Ponting is pretty good at it. Steve Waugh was legendary. Michael Hussey couldn't create pressure in his car tyre, let alone on the cricket field.

It is absolutely critical that a team in the field be able to put pressure on the batsmen and dry runs up, at least for a little while. This is how wickets are taken - by pressuring the batsmen into taking risks.

Of course, every player in the field plays his part in creating pressure. But it is the captain who is responsible for it. He uses his bowlers. He uses his field. He creates pressure and he gets batsmen out.

During the debacle witnessed today, the New Zealanders only took risks because they got bored. There was not a moment of pressure applied to them at any stage of the game. The captain has to take responsibility for this.

Now some captains are really good and can defend almost any total, but these are few and far between. It helps to have a great team, of course. Only a very few captains will successfully defend 130 runs. There are some captains who can defend 220 pretty consistently. Most captains in international cricket can defend 290 without too much trouble. But any idiot with a team taken from the Dubbo animal shelter ought to be able to defend 346.

Fair enough, once you might have been unlucky. Sometimes the luck goes against you. Sometimes the other team just play blindingly well and there's nothing you can do. But losing two games in a row, one defending 336 and the other defending 346 is utterly inexcusable. No captain ought to keep his job after such a scandal.

Now there will undoubtably be some nancy-boy out there who wants to defend Michael Hussey, who will point out that New Zealand lost four wickets for forty runs in the first ten overs. Isn't that a sign that he can find wickets? No no no no no no no. That is a sign that there are some good bowlers in the side who can take wickets with the new ball. The failure to capitalise on that start is the truly staggering thing about today's performance. Anyone with a team from the Tanami Desert Home For Geriatric Persons Who Have Lost Everything Below Their Navals ought to be able to defend 346 from a start of 4/40 from ten overs.

Michael Hussey has got to go.

A Plea to the Australian Broadcasting Commission

The other thing to say about today's game is that the ABC needs to lift its game and get some commentators into New Zealand games.

Every cricket-plaing country on earth has produced commentators of a reasonable level of proficiency and professionalism, except New Zealand, it seems. India has produced the excellent Harsha Bhogle and Sunil Gavaskar. Pakistan of course has their own batting legend, Wasim Akram. Allan Donald very respectably represents South Africa. Jonathan Agnew of course is among the very best from the BBC.

Even our very own K.J. O'Keefe, despite being a one-eyed lunatic (one-eyed in the metaphorical sense) with a snort for a laugh, at least has insight into the game, realises that he's one-eyed, is self-deprecatingly humorous about it and gives the other side a fair go.

The best New Zealand can produce is Bryan Waddle. The best Bryan and his fellows can produce is six hours of theorising on how New Zealand might still win the match, no matter how dim it might look. I just want to go and be sick after the first innings of it, even when Australia have put on 336 and look unbeatable (not a typo, I didn't get to listen to the first half of today's game).

Even the pretence of even-handed commentary is absent, as made all too plain by the rather-too-audible wild cheers from the back of the commentary box during the last two overs of today's game. This, it seems, is the height of New Zealand professionalism.

A Piece of Prose from Yesterday

There comes a time on a Thursday afternoon, before Friday is imminent and when Saturday is as yet only the first blush of dawn on the horizon; when no email is arriving, when the notice board has nothing new; when the internet has been read and re-read, but the American and European news sites have pulled the covers up tight and gone to sleep for the night; when the investment made at lunch brings its drowsy return, and you realise that there are only so many cups of tea that can usefully be drunk in one day; and then you enter the long, dark tea-time of the soul.

Credit, of course, to Douglas Adams for the idea.

It's Been a Long, Long Time...

I know it's been a while since I've blogged. So I'm about to post a couple of articles to keep you going, and this one is really just to pad it out and make it look like three. There may be more coming soon...

What's Required

This post is probably not interesting to many people. Only to certain specialisations of engineers, in fact. But I think it is an important document nonetheless.

One of the things we engineers are required to do, from time to time, is to write a requirements specification. For those who aren't engineers, this is a document that tells you what a particular thing is supposed to do. Everyone who hears about this for the first time always thinks, "So how hard can it be?" Well, it turns out it is very easy to write a requirements specification, but very difficult to write a good one.

I am currently working as a test engineer. What that means is that I take a requirements specification, and a system that has been built to meet the specification, and I devise ways of prooving that the system does or does not do what the specification says it does. I am, in this role, a consumer of requirements specifications. And I am fed up with what I'm seeing. There are far too many engineers who have no clue about how to write a good requirement, let alone a good requirements specification, and an almost equal number who have no idea how to take a requirement specification and design or test a system based on it.

So this post is a short(ish) guide to how to write and interpret a good requirements specification.

Writing a Specification

There are a lot of different attempts to explain what makes a good specification floating around, and there seems to be a lot of variance between them. I am going to present a selection of characteristics of a good specification. It is a not an exhaustive selection. I suspect most of the lists around reflect the pet hates of their authors, and this one is no different. For the most part, the advice in this document is the direct result of bad experiences I have had.

So, a requirements specification must be:

Clear

This is absolutely critical. When someone reads a specification, they should be left with no doubt about what is required. There is a good way to judge clearness: Ask yourself, "If I gave a subcontractor this specification and nothing else and told them to go away and build it, what is the likelihood that I would get what I wanted?" Be appropriately cynical about your subcontractor when you make this assessment, ie. assume they are idiots. They may not be, but make the assumption anyway (note that this does not form the basis of a good relationship with your subby; it is only for the purposes of the exercise).

There is a well-established dialect of the English language used in specifications, and you should stick to it strictly. This can hardly be emphasised enough. If something is a requirement, then shall is a verb that must appear in the sentence. If something is not a requirement, then shall is a verb with no place in the sentence. Requirements must all be assigned a unique identifier, and you must not renumber your requirements at any stage of the project.

There are a few ways to achieve clearness. Some important ones include:

• Get the spec reviewed by someone who has had minimal contact with the project. If they are left with questions, your spec is not clear.
• Use notes and non-requirement text to give context to the requirements and help your reader get in the right frame of mind. Care is needed here, because the requirements must still stand on their own. But because requirements are usually brief, and phrased in fairly formal language, it can be hard for the reader to understand them without some help. I find that I generally write every requirement twice in the spec: Each section of the spec starts with some non-requirement text that explains what the section requires in general, non-binding language. Then the requirements restate that in formal language. The formal requirements are there to be tested against; trying to test against informal language is impossible. The informal text is there to help the reader understand what's going on, how the requirements interact with each other and with the wider context of the system.
  

Concise

This is not so critical as clearness, but still important if the project is going to come off well: The spec must be concise. What's that mean? A few things:

• Don't include things that reflect your opinion on the system, but aren't really requirements. This limits the creativity of your design team, who are paid to be creative and to find creative solutions. You will often prevent them from finding the best solution by imposing unnecessary requirements.
• The phrasing of individual requirements should be as concise as possible. The more wordy they are, the more room there is for ambiguity, errors, contradictions and misunderstandings.

An interesting subset of non-concise requirements are ones such as this: "The system shall allow calibration of all equipment that can be calibrated." This is not concise; in fact it says nothing at all. If the system does not allow calibration, then the equipment can't be calibrated, and falls outside of the scope of the requirement. It is impossible to fail this requirement, and therefore it adds nothing to the specification to include it. This looks like such an obvious problem, yet this very month I have encountered two such requirements on a project; the example above is lifted almost verbatim from a specification I am testing against.

What the author meant, of course, is, "For all equipment that provides a method of calibration, the system shall make that method of calibration accessible to a user," or something like that. But that's not what he wrote, and now I have the job of explaining to the customer, not only why our equipment really does do what this requirement says, but also why the requirement doesn't really mean what it appears to say.

Consistent

A requirements spec must not contradict itself. This sounds blindingly obvious, but it's actually pretty easy for it to happen. Contradictions usually creep in where one engineer writes the initial draft of the spec, then another engineer comes along to update it with new information. He doesn't realise that another part of the spec already deals with the aspect of the project he is concerned with, and he introduces a contradiction.

Again, independent peer reviews are critical to getting this right.

Complete

This is the corollary to conciseness. A spec must cover everything you really require. Otherwise you will be delivered a system that meets your requirements specification, but does not meet your real requirements. Of particular help in this regard are the several standards out there that provide template document layouts, such as the older (now mostly obsolete) MIL-STD-498 and the newer IEEE-1220 series of standards. They provide a whole bunch of headings that requirements might fall under, and at least prompt you to think about them.

Functional

Where possible, the requirements specification should not tell the designers how to design the system. It should only tell them what the system needs to do, not how it should do it.

This can be hard, because many engineers writing requirements secretly wish they were designers instead, and have all these great ideas about how the system should be designed. They are often sure that their ideas are the best ones, and that the designers haven't really got a clue. If this is you, go get a job on a design team and stop stuffing up requirements specifications. You will make the world a better place in this way.

There are a few exceptions to this rule:

• The requirements specification should completely specify the external interfaces of a system. These need to be expressed in concrete, design-like terms. It's no good, if your system has to have an RS-232 interface, saying, "The system shall interface to system XYZ via a TTL-compatible serial protocol with handshaking," just because you don't want to dictate the design. If it needs an RS-232 interface, the requirements should specify an RS-232 interface. If the cable for that interface has already been decided, then the requirements spec should specify which connector the interface will use, too.
• If there is some external (ie customer, environmental etc) reason for using a particular piece of equipment in the design, then it should be included in the specification. If your customer wants Windows on Intel x86-64, it is no good putting in a requirement for a 'modern operating system on a 64 bit architecture,' because you will get Open Solaris on an AMD architecture, sure as eggs.
• If there is a good commercial reason for limiting the design, then that should go in the requirements spec too. For instance, if you have a special deal with Intel where you get processors and chipsets at 25% of retail, then you should specify Intel processors and chipsets. Some people will complain about commercial factors dictating design, but if you don't turn a profit then you don't have a job for long.
  

Feasible

It must be possible to construct a system that meets the requirements. Here 'possible' is a loosely defined term. It depends a lot on how much money you spend. However, if you are building a network between Sydney and London, for instance, it is no good having a requirement that says, "The network shall have a latency of less than 1ms." At first glance it might look reasonable, but the distance from Sydney to London and back is somewhere close to 140ms at the speed of light, and the information can't travel faster than that.

Verifiable

It must be possible to prove, in a controlled test, that a requirement is met. Some examples of non-verifiable requirements:

• "The system's processing load shall never exceed 40% of available processing capacity." This is impossible to demonstrate in finite time, because it always might go over 40% just after the demonstration finishes. It might, in certain circumstances, be possible to prove this by analysing the code run on the processor, and showing that it will never consume more than 40% of the available capacity. However, in almost all systems the complexity of the code running prevents this. A better requirement: "During a ten-minute demonstration run of the scenario described in Annex A, the system's average processing load shall not exceed 40% of the available processing capacity." This demonstrates another couple of important points: You should already be thinking about how to test the system as your write the spec, and you should not be afraid of putting supporting data in annexes to the spec.
• "The system shall allow the temporary fitment of any test equipment required for developing future modifications to the system." Another example lifted almost verbatim from a project I am working on. How do I know what equipment might be required for future modifications? How do I know what modifications might be considered in future? Do you really want me to go buy a specimen of every piece of test kit available in the world and make sure we can fit it? This is actually an example of a real requirement that is quite difficult to express in a verifiable way; a requirement for a certain type of test point, or something of that nature might be more useful.
• There are plenty more of these; google for "unverifiable requirement example" and you'll get a selection.
  

Interpreting a Specification

Another tendency I have noticed among test engineers is a certain degree of cluelessness when it comes to interpreting requirements. This is particularly so when there is a badly written spec which has ambiguities. Often I will state the plain meaning of a requirement, only to have some git reply, "Ah, that's what it appears to mean, but you could interpret it to mean..." Fill in your own pointless, stupid, senseless interpretation here. I feel like responding, "Yes, you, could, if you were a retarded beetle, but this is the real world." That's no way to treat a colleague, but it's what I feel like saying.

It's late now, and I don't want to put as much effort into this section, but here are a few tips on interpreting requirements:

• If there are two possible interpretations of a requirement, and one of them makes no sense, then the one that makes sense is the one to choose. The ambiguity is a defect in the spec, but that's no reason for you to compound it by choosing perverse interpretations.
• The scope of a requirement should be limited by what makes sense. For instance, if a requirement states that, "The system shall provide calibration points for all COTS items in the design," then that should be limited to those COTS items that actually have some aspect that can be calibrated. The requirement is badly written, but that is no reason to require a mountain of work of the design team to provide "calibration" points for their power supplies, because that was the only candidate you could think of for calibration points.
• Where a requirement is ambiguous and neither of the above principles applies, the obvious interpretation should be the one chosen. This is just a logical extension of the previous points.
• The meanings of words should always be controlled by the context of the project, and especially by the surrounding context of the requirements specification. I go wild when a spec contains an ambiguous requirement, and a note explaining how to interpret the requirement to resolve the ambiguity, and some loser who just wants to make work for themselves says, "Ah yes, it says that in the document, but it's not a part of the requirement, so you shouldn't take too much notice of it." Sigh.
• It can be a useful exercise to analyse a requirement in detail. This can seem pedantic, but often helps you see what you need to demonstrate in your test. For instance, the requirement, "The system shall provide calibration points for all analog signals in the system's external interface," can be broken down into several points:
  • The requirement's scope includes only signals in the system's external interface.
  • The requirement's scope is limited to analog signals.
  • The system must provide calibration points for those signals that fall within the scope of the requirement. This is interpreted to mean that a suitably qualified user with appropriate test equipment must be able to measure the value of the signal as defined by the relevant interface specification to an accuracy sufficient to satisfy the calibration specification for the equipment.
    
  Thus you need to decide what signals fall in the scope of the requirement, using the criteria listed above, then show that for each one you can identify the value of the signal from the interface spec, and what accuracy is required by the calibration spec, then show that you can actually measure that value to that accuracy.

That's enough for now. I'm sure there is other stuff, but I've at least worked off some steam.

Makin' Music

I have just bought one of these:



It is a Fender BXR-60, which I bought second-hand for AU$220. The BXR-60 stands for Bass eXtended Range, 60W RMS. Pretty much says it all.

Although I've been playing acoustic guitar for about ten years now, and bass for about five, this is the first amp I've ever bought. I know, slow off the mark, aren't I?

So far I've only tried playing my acoustic through it. Of course, it's not meant to be a guitar amplifier, so I wouldn't be surprised if it sounded awful, but it actually sounds OK. The tone starts to get a bit hairy as the volume goes up, but that could be because I'm playing it in a fairly small room with solid brick walls - not exactly an ideal acoustic.

For any interested, that is my acoustic guitar (which I've posted raved about before) in the background. It's beautiful. I love it.

Late Night Theology [101]

This is (as are many of my posts) a response to a post on Antique Song about the rights and wrongs of violence.

The questions raised boil down to:

1. Should Christians be pacifists?
2. Should I personally use violence in my dealings with other people?

Emma thoughtfully approaches these questions from a Biblical framework.

Let me first give my answers succinctly, then waffle about them for a while. No, I don't think Christians should be pacifists. Yes, I think it is sometimes appropriate to use violence in dealings with other people, with a large set of restrictions on when.

Now, the waffle. First, let me briefly cover some basics of Biblical interpretation, then some biblical data, then draw some conclusions.

As evangelical Christians we take as our starting point that the Bible is God's primary way of revealing himself to us. There are a variety of ways of justifying it, but for my purposes I will just assume that when God reveals something of himself that he is telling the truth. The implications of this that I think are important for this discussion (and many others) are:

1. All parts of the bible should be treated equally. So it is no good to build a framework from one part of the Bible, then use that framework to discount or seriously distort another part. Note that this is not saying we treat them all the same; different parts are treated in different ways. But no part can be used to the exclusion of another part.
   
2. Logic occasionally (not often) breaks down when considering the ideas in the Bible. This should not always mean that we don't accept what it says. Usually apparent contradictions in the bible result from the dual nature of God. God is both transcendent, all-powerful, all-knowing, outside of time and space and infinite, and yet at the same time is personal and relational, and relates to finite beings who are limited in space and time. These things are apparently contradictory, but we don't completely understand God, nor should we expect to; how can finite, contained, limited beings comprehend an infinite, transcendent being? Part of humility is to admit that we will not always understand God completely, and therefore we will not always understand his works completely.

On to Biblical data. The range is large, and Emma only covered a small fraction of it. I will by no means cover all of it. I probably don't have time to sort it all well or even properly reference all of it. Some relevant bits and pieces:

1. God judges. Examples: The curse of Genesis 3 is the beginning. At the tower of Babel, God judges the arrogance of men (Genesis 11). Saul (1 Samuel) and Solomon (1 Kings) are both judged for turning away from God. David is judged for taking the wife of Uriah (2 Samuel 11). Uzzah is judged for touching the ark of the covenant (2 Sam 6). Israel and Judah are both judged for turning from God (most of the second half of the OT). The Galileans whose blood Pilate mingled with their sacrifices, and those on whom the tower of Siloam fell, died in the judgement of God (Luke 13:1-4). Annanias and Saphira were judged for trying to deceive God (Acts 5:1-11). This is by no means a complete list.
2. God uses people to execute his judgement. The OT law is basically a long list of offences that should be punished by the state of Israel (OK, there's other stuff too). Israel is judged through the Assyrians, and Judah is judged through the Babylonians.
3. The fact that God uses one nation to judge another does not excuse either nation. Babylon, Assyria and Philistia will be judged for their arrogance and presumption, because they think they are greater than God (Is 14). They do not recognize that their victory comes from him.
4. God exclusively reserves the right to set wrongs right. "Vengenace is mine... for the Lord will vindicate his people..." (Deut 35-36). Paul applies this to mean that you should "never avenge yourselves" (Rom 12:19). Note that at times this is achieved through human intermediaries, but again that does not justify the intermediary.
5. God has a constant concern for the poor, weak and oppressed. The OT references are too numerous to cite. Of particular interest is Isaiah 1, "Cease to do evil, learn to do good; seek justice, correct oppression; bring justice to the fatherless, plead the widow's cause." Also Amos 5, "Hate evil, and love good, and establish justice... I hate, I despise your feasts... Take away from me the noise of your songs... But let justice roll down like waters, and righteousness like an ever-flowing stream." (Selectively quoted, and emphasis added).
   
6. Jesus instructs his followers to "turn the other cheek" (Mat 5:39 paraphrase). Even more explicit is the phrase preceeding that, "But I tell you, Do not resist the one who is evil." If we are sued for even the coat of our backs, we should offer our shirts, too. If we are conscripted to carry soneone's goods for one mile, we ought to volunteer to help out for another mile.
   
7. Jesus drives the money changers and animal sellers from the temple with a whip (Mat 21:12). Note that John emphasizes the considered nature of this action; when he saw the state of the temple, he went away and made a whip to drive them out (John 2).
8. Paul tells the Corinthians to prefer being defrauded to taking a brother to court (1 Cor 6:7).
9. Paul establishes the example of not demanding his rights, "But we endure anything rather than put an obstacle in the way of the gospel." (2 Cor 6, emphasis added)
10. God establishes authorities as his specific agents to restrain evil in the world. "[The one in authority] is the servant of God, an avenger who carries out God's wrath on the wrongdoer." (Rom 13:4)
    
11. There is probably much more, but it is late and I will limit it here.

A few points that I think arise from this data:

1. As an individual Christian, you are not to use violence (or indeed other means) to defend yourself or establish your rights. This is specifically reserved for God.
   
2. There is a strong imperative to defend those who are weak, oppressed or poor. This is primarily the responsibility of the state, but is also important for the individual. In some situations this will necessarily involve violence, but it should be restrained and by no means the first option, probably the last.
   
3. The love of God can not be used to "filter out" the justice and wrath of God. Both are true.
4. The state has a specific responsibility to create structures that restrain evil and to enact punishment on those who do evil. This implies both a civil responsibility, to enact and enforce law for the well-ordering of society, and a military responsibility, to restrain the evil of other states. I tend to the view that the military option should be a last resort, but I'm not actually sure that the Bible makes that distinction; we would certainly not say that law enforcement should be a last resort, and it is derived from the same Biblical responsibility.
5. The individual does not have a specific responsibility to create structures that restrain evil and to enact punishment on those who do evil. Defend the poor and weak, yes, but anything else, and even often that defence, is the specific duty of the state. Vigilantes are not justified Biblically (except perhaps where there is a total absence of a state). Note that a state going off the rails does not justify vigilanteism. God's agents are accountable to him who said, "Vengeance is mine; I will repay." Not to individual people.
   

Lastly, the primary concern of Christians ought not to be the rights and wrongs of wars, but rather the spread of the Kingdom of God. This is a kingdom that spreads not through war and conquest, nor through peace and stability, but in spite of war, in spite of peace. "You will hear of wars and rumours of wars. See that you are not alarmed, for this must take place," (Mat 24:6, emphasis added). War is inevitable in a world full of fallen, evil people. Where it is unjust we ought to have some concern to restrain it, but our principal interest ought to be the gospel of our Lord.

Freedom to Enslave...

Paul continues to provide thoughtful critique:

Tom,

Don't forget, in the free societies in which we live, people have a right to be wrong (from your perspective) about their religion. And they have a right to let their moral compass guide them.

Yet, as you stated earlier, head hunters aren't allowed, because their moral absolutes don't mesh with most other peoples morals.

So, I guess what puzzles me, and now confronts the Australian court system is how do free people decide which moral code to adopt?

I have spent several days considering a reply to this, and I don't think I really have an answer. However, I will make a few points.

What this comes down to is the right that has variously been called freedom of conscience, freedom of religion and others. Keep in mind that freedom of religion as it is in Western culture was not originally intended as freedom for any religion, but freedom for any Christian religion. It was a reaction to the European tendency for a state to select a church denomination and persecute anyone not in it. In England Catholics (and non-conformist protestants) were repressed, in France protestants (ie. non-conformist Catholics ;-) were repressed, etc etc. It is only since then that it has been extended to, at least in principle, include all religions.

But in practise no-one actually practices freedom of religion. The US will claim that it does, but this is laughable. It is trivial to disprove it by this example: Osama bin Laden's views are primarily theological (ie religious). No freedom of religion is extended to him.

Now, it is easy to say, and many do say so, that bin Laden misrepresents Islam for his own purposes. But that is the very height of arrogance. What you are then doing is deciding for yourself what the content of Islam is, and then imposing that definition on others. This is exactly what the framers of the US Constitution were trying to prevent; then it was Christianity they wanted freedom to interpret, now its Islam you are denying freedom to interpret. To deny bin Laden the right to his religion is unconstitutional and extremely hypocritical.

How does anyone get away with it then? Basically, our society has tacitly agreed that some things are beyond the pale, and we won't tolerate them, even if our constitution says we should. So there are some people's views which we will classify as terrorist ideologies instead of religions and ban them. The difference is often completely artificial, but we'll play along, because otherwise we actually have to think about things, and realise that perhaps freedom of religion isn't always quite so great.

Usually the media is the arbiter of what is a terrorist ideology and what is a religion. The procedure for determining what is what goes like this:

1. Find someone who uses violence to further their ideas.
2. Do we feel sorry for them?
3. If so, their ideas are religious in nature, and their use of violence is a brave fight for freedom.
4. If not, their ideas are a terrorist ideology and they are a menace to free society.
5. If anyone tries to suggest that we got it wrong, and that people we thought were a menace to free society are actually engaged in a brave fight for freedom, then we howl them down.
6. If we can't howl them down, then we jump on the bandwagon and pretend that we always thought that they were engaged in a brave fight for freedom.
7. If, on the other hand, someone tries to suggest that we got it wrong, and that people we thought were engaged in a brave fight for freedom are actually a menace to free society, then we write long editorials about how the poor are always oppressed in our society, and never get any help in their brave fight for freedom.
   

If you want an example or two, consider Osama bin Laden and Irish Catholics. The Irish Catholics are engaged in a brave fight for freedom from the British oppressors, so we are on their side, no matter how many bombs they plant or people they shoot, basically because we feel sorry for them. Osama bin Laden uses the same methods for roughly the same ends, but we don't feel sorry for him, so he must be, you guessed it, a menace to free society.

I am not suggesting that Osama bin Laden is in the right, by the way; I am just pointing out that his ideology is a theology in a very similar way to many other theologies that are accepted around the world. To reject his religion simply because it involves violence is hypocritical, since that is just using your own moral standard to judge someone else's moral standard, and your constitution says that's not on.

Rather than sticking our heads in the sand and letting everyone believe whatever they like, we should critically examine religious claims in the same way we examine any other claim, and discard those that are found to be false.

So in the end I suspect freedom of religion doesn't really work, and in practice no-one implements it.