Universal Postgres

It turns out that nobody seems to know how to build a Universal version of PostgreSQL for OSX. This turned into a problem for me when I was trying to build a version of PHP with support for postgres — I needed Universal (four-architecture) libraries.

The following seems to work (I’m running an Intel Leopard):

1) I have the following variables set in my .bashrc — I build everything Universal. If you don’t have these variables set, you should set them now.

export CCFLAGS='-arch ppc -arch ppc64 -arch i386 -arch x86_64 -pipe'
export CFLAGS='-arch ppc -arch ppc64 -arch i386 -arch x86_64 -pipe -no-cpp-precomp'
export CXXFLAGS='-arch ppc -arch ppc64 -arch i386 -arch x86_64 -pipe'
export LDFLAGS='-arch ppc -arch ppc64 -arch i386 -arch x86_64 -bind_at_load'

2) ./configure --with-the-options-of-your-choice

3) LD=gcc AR=libtool AROPT='-static -o' LDREL='$(LDFLAGS) -nostartfiles -r' make -e

4) sudo make install

Step 3 was the tricky bit 😉


The Annihilation of Angkor Apeiron

In February of 1975, I read The Annihilation of Angkor Apeiron by Fred Saberhagen in Galaxy magazine. This not-so-recent news story reminded me of it.

Perhaps I need to explain. The resolution of AoAA hinges upon a point of intellectual property protection, i.e. how would a publisher of dictionaries or encyclopedias protect themselves against profiteers making unauthorized copies? In the future, imagines Saberhagen, it would be possible to take a reference work, fiddle with the verbiage with a computer, and produce a derivative work that wasn’t exactly a copy. How would the original authors unmask such villains?

The solution, of course, is to introduce “bugs” on purpose — imaginary words in dictionaries, or places in encyclopedias. As a reference work, it’s OK, since nobody would have a reason to look up such imaginary words or places. Nobody reads through such a work. But any derivative work that would happen to contain the identical “bugs” would clearly be derivative.

Back to the present. Affinity Engines sues Google over Orkut. It is a derivative work, they claim, because it has the same bugs.

In addition to nearly identical text found in similar features in orkut.com and Affinity Engine’s social-networking products, the suit cited several identical software problems in each company’s service.

How long before all software products design in bugs for bizarre use cases, designed specifically to track plagiarism? Or does this help explain the so-called “bugginess” of so many software products?

It's gaining in popularity….

Recently, I found myself in the San Francisco airport. As I always do, while waiting for the flight, I started juggling. A few minutes later, this guy walks into the waiting room. “Is this the juggling area?” he asks. “Yup”, sez I. And he proceeds to grab five balls out of his carry-on, and starts juggling.


“Where did you learn to juggle?” he asks.

“From friends and family” I explain. “My wife teaches the circus arts.”


“SUNY Purchase.” [Note: This year at Circus Arts Camp]

“Really!” he says. “I taught the circus arts last summer at SUNY Purchase.”

Small world.

Even smaller if you juggle in public places.

Would you like mustard on that?

There’s a lot of talk these days about software factories. And books about software development borrowing from practices and processes used in automotive manufacturing. This is based on the premise that developing and delivering an application or functional enhancement is as complex as building an automobile, or locomotive.

When one is working in an IT department, however, many of the work requests that arise are actually fairly simple. If one then takes these simple requests, and treats them as if they were complicated, they become complicated. And this complication leads to extended delivery times, and large expenses, and increased risks of failure.

Here’s the analogy. When one orders an automobile — and they can manufacture it to order and deliver it in only a few days — that’s impressive. But when one orders a pastrami and provolone on rye with roasted peppers and a pickle — that estimate of “only a few days” starts to seem a trifle excessive.

We don’t have methodologies — even “agile” methodologies — that model application delivery in an IT department (or even a part of it) like a delicatessen. Every sandwich order may not require baking the bread, smoking the beef, growing the peppers. Inventory management in a delicatessen is not quite as structured as in an automotive factory. So when somebody from “the business” requests an application from IT — and gets something within the day — it is cause for astonishment.

I’d like to think that with the proliferation of modern tools, libraries, frameworks, and environments, that we could be as responsive — sometimes — as the counterman at the deli.

History teaches us …

I was on a conference call with a group of IT application architects, and, with a few minutes left until the end of the scheduled hour, the summary of the meeting began with that phrase: “History teaches us …”. As an amateur historian, my interest was immediately piqued. The end of the sentence was “that a three-tier architecture is the best architecture.”

Had it not been for that three-word preamble, I would have let the assertion stand unchallenged. But Clio had been summoned — and I had to disagree.

Frederick Lanchester, was the first person to try to apply mathematical modeling techniques to warfare. In the early part of this century, he developed the Lanchester equations to model armed conflict. I came across an article of his as a child in a collection of books ( © 1956), still available today, The World of Mathematics.. Lanchester looks at the tactics of Napolean in the Italian campaign against Austria and Lord Nelson at Trafalgar to illustrate his point. The lesson that I learned from that history (although there are others to be learned) is that the most effective tactic is to split one’s opponent into two nearly equal halves. The reason for that is related to the effectiveness of the fighting forces being proportional to the square of the size.

Software complexity, also being proportional to the square of the size could very well learn this lesson of history; in which case the correct number of tiers might well be two.

William of Ockham (who lived in the fourteenth century) is famous for Occam’s Razor (also known as the “law of parsimony”):

“Entia non sunt multiplicanda praeter necessitatem” (“Entities should not be
multiplied unnecessarily.”)

This is often simplified to “keep it simple, Simon”.

Although famous today for the Razor, in his own time, William was famous for being a nominalist. Nominalism holds that there is no underlying “truth” to be discovered — rather, things mean what we all agree that they mean — and we can choose to agree differently — which will change our perception of reality. In other words: That word does not mean what you think it means.

So, when someone asks the question: “Do you agree that a three-tier architecture is the best architecture?” some people might think that a “tier” has some divinely-inspired (if they are Medieval) or expert-defined (if they are contemporary) meaning, and that the question was meant to elicit a discussion around the variable “three”.

But a nominalist, who has read Lanchester’s article in The World of Mathematics might know that the number is a constant; that that constant is “two”; that the variable is “tier”; that the question is wrong; and that the correct question is “What is the meaning of “tier” for which a two-tier architecture is the best architecture?”

Aha!, the discerning reader exclaims. Why not assert a priori that “three” is the correct number — having attended Catholic school, this seems perfectly reasonable — and the correct question is “What is the meaning of “tier” for which a three-tier architecture is the best architecture?” Then, I would have agreed a priori with the initial premise, and we would have all move forward unanimously. But this line of reasoning springs the trap laid by William with his nominalist Razor.

For if it is true that there is a definition of “tier” for which a two-tier architecture is the best architecture, and there is a definition of “tier” for which a three-tier architecture is the best architecture, then by choosing “three” a priori, you have multiplied an entity (entia multiplicanda) needlessly.

Therefore, history teaches us that a two-tier architecture is the best architecture.

The lessons of history are not easy to identify, interpret, or internalize. I love the fact that I work at a place where we try to learn them.