The Pantheon

He's alive! A.J. Quinnell, among the finest adventure novelists I've ever read, recently emerged in public on a fan's web site. AJQ is a pen name. Many of the other hard-core Quinnell fans figured he had passed on, since his most recently announced book ("The Scalpel") never made it to print and had been scheduled for release years ago.

You may know Quinnell from the popular movie Man on Fire. But the book has been out for more than twenty years. It introduces Creasy, the quiet and deadly ex-mercenary with a penchant for serious revenge. A whole series of Creasy books exist, but are mostly out of print in the U.S. A six month effort of international purchases over the web brought me the entire collection of both Creasy and non-Creasy books.

So imagine my surprise when I read this on Tony's site:

After having maintained this web site for 8 years and never having heard a word from A.J. Quinnell himself, imagine my surprise and excitement, when I received what appeared to be an email, with an attached letter from him. I have done some research and am satisfied that this is a genuine letter from A.J. Quinnell. The letter is reproduced below...

I was greatly interested to read Quinnell's book recommendations:

...American writer Charles McCarry whose 2 books 'Tears of autumn' and 'The secret lovers' I regard as masterpieces. Of course they are out of print, but if you can find them I urge you to do so. I also like Len Deightons early books, particularly 'Funeral in Berlin' and 'Horse under water'...

I was also excited to read that a new Creasy book is (hopefully) coming out soon. The working title is Priests of a dead God. There will also be a Creasy preqel, covering his experiences in Korea and Vietnam.

If you're wondering why myself and the other Quinnell fan-boys are so excited, it's simply this. With C.S. Forester, Raymond Chandler, and Lee Child, A. J. Quinnell ranks at the pinnacle of "The Pantheon". Those are the novelists who have never failed to write exquisite works of action and adventure. You can't go wrong with your purchase of any of their books *.

Quinnell

* And, no, Vince Flynn, we booted you out of the Pantheon with your release of "Executive Power".

Return-codes vs. Exceptions, Part 228

Pete's blog had a good critique of my last blog entry on return-codes versus exceptions. The examples were quite accurate, though...

I guess I'm beating a horse that's not only dead, but is already sleeping with the fishes (and Big Pussy) in the Hudson river... but,

I had comments inserted (the "// log" lines) where logging and instrumentation would go... the idea being that we could reconstruct a series of faults from the lowest level as we audited or unit-tested the code. I'm not sure how we would do that in Pete's examples - feedback?

The idea is that we end up with a log like this:

11:01:00 TableDebits.Lock failed for table 'ade1201' (layer 3)
11:01:00 Table 'ade1201' update failed - locking fault - rolled back (layer 2)
11:01:00 "Transfer failed, please try again later" (layer 1, the UI)

Again, this is a highly simplified example, but hopefully that indicates the kind of detailed logging/instrumentation I'd like to see at every step of the way.

Return-codes vs. Exceptions, Part 129

There's been an ongoing debate in the software development world regarding whether return-codes or exceptions should be used. Here's a brief recap.

Joel lists several good reasons why return-codes are preferred over exceptions:

#1 "They (exceptions) are invisible in the source code" - thus, they are difficult to maintain ("...even careful code inspection doesn't reveal potential bugs")

#2 "They create too many possible exit points for a function" - effective cleanup code is predicated upon predictable unwinding of state as a method or function terminates

Joel continues, "...I consider exceptions to be no better than "goto's", considered harmful since the 1960s, in that they create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's..."

Sergio states (regarding Joel), "His stance against exceptions as a method for handling abnormal program behaviour is just plain wrong. Joel recommends using error return codes, and dealing with them immediatly. There are two big problems with this approach:

It places abnormal behaviour treatment inline with normal execution. It hurts code readability.

Without exceptions, dealing with code transactions and rollbacks produces an imense tangling of ifs or procedure calls.

There is a valid discussion open on whether exceptions should be checked or unchecked, but the mechanism itself is, for me, proven..."

Ned agrees with Sergio, "Exceptions keep the code clean". At least he provides some examples.

And, in a recent interview, James Gosling had some interesting things to say. He wasn't speaking directly about exceptions versus return-codes, but he had some salient points that relate to the mission-critical software world.

"You talk to people in banks, where large quantities of money get lost if there's a problem. They take failure very seriously. The spookiest folks are the people who have been doing real time software for a long time. I've spent a certain amount of time with that crowd. By and large these folks are very conservative and very careful. A lot of them know what it's like to go visit the family of the deceased and explain the bug to them. There are a number of places that have policies that if a test pilot augers in, then once it's all figured out what happened, the people who engineered the thing that failed have to go explain it to the family. I've actually only met one person who has ever actually had to do that. That would change your attitude about dealing with failure really quickly"

Here's my take: Joel is dead-on. I'll tackle Sergio's item number one first. Look: we (the software development community) have a problem with software quality. I don't think I'll get much disagreement on this fact. Software quality, in general, sucks. The reason for this is that many developers are too lazy to instrument, monitor and and respond to all sorts of strange conditions.

In other words, many of us are undisciplined. We're more worried about "readability" (and I disagree with that contention as well - but I'll get to that) than whether or not or software will kill anyone, debit the wrong account by a million bucks, or screw up the actuarial table for 83 year-old transvestites.

Like it or not, dealing with aberrant conditions is a contract we agree to when we decide to be professional and responsible software developers. Treating "abnormal behaviour inline with normal execution" is a misstatement. We need to deal with the unexpected. And the best place to do it is the place where you can "unwind" the logic that's gone bad.

My guess is that Sergio never wrote a database engine or other mission-critical, system-level code. This is the kind of logic you'd implement (it's a simplified example only, so please don't send me syntax error, faulty logic, or "you coulda used diagnostic macros" messages):

do { try { if ((rc = tableCredits.open()) != OK) { // log break; } bUnwindTableCreditsOpen = TRUE; if ((rc = tableCredits.lock()) != OK) { // log break; } bUnwindTableCreditsLock = TRUE; if ((rc = tableDebits.open()) != OK) { // log break; } bUnwindTableDebitsOpen = TRUE; if ((rc = tableDebits.lock()) != OK) { // log break; } bUnwindowTableDebitsLock = TRUE; if ((rc = ::IntegralTransaction(tableCredits, tableDebits, curAmount)) != 0) { // log break; } } catch (...) { // catch miscellaneous exceptions here } } while (0); if (bUnwindTableDebitsUnlock) { tableDebits.unlock(); } if (bUnwindTableDebitsOpen) { tableDebits.close(); } if (bUnwindTableCreditsLock) { tableCredits.unlock(); } if (bUnwindTableCreditsOpen) { tableCredits.close(); } return (rc);

Can you imagine trying to unwind these kinds of "abnormal events" outside the scope of the method that was orchestrating this sort of activity? It wouldn't be fun.

And my take is that readability isn't compromised here. No one is espousing tons of nested if's or other convoluted logic to keep track of state. Do it the easy way. If you have to throw an exception, do it. Right to the bottom of your method. Or, if you can't, hit the "break" (pun intended). Either way, you can start unwinding based upon your current state without compromising the integrity of an 84 year-old transvestite's term-life premium.

Trust no one. Check everything. Log everything. Go forth and prosper.

A bald-faced bug

Any developer has their "toughest bug they ever cracked" story. I'm no different.

Those of you who know me know that I'm hair-challenged. Thinning on top. Approaching cleanhead status. Alright, I'm basically bald. This is the story of how I got bald over the period of two days. Ripping out clumps of hair in frustration. Cats and dogs, sleeping together. Total chaos.

I had this small utility program I'd created in ANSI C running on a mid-range HP/UX server. Mid-eighties. The program was no more than five or six hundred lines in length. It read some input files and did some calculations for motion control. I think it created pre-planned routes for a high-speed turning machine that cut specially shaped pistons for Cadillac. Either that or it was routing air traffic over LaGuardia.

Anyhow, the program would do some complicated calculations and run for a while. Most of the time it would work. In fact, it might work perfectly forty times in a row. But on the forty-first run, it would crash. And it was completely random. It might work forty times, crash twice, work another five times, crash, then work fifty times.

I threw in printf's to isolate the location of the crash (no IDE's available on the HP/UX back then, Jimbo). It was crashing in RANDOM FRICKING LOCATIONS every time. WTF?

I analyzed the time-of-day of each crash. Nothing. It didn't seem to be time-based.

I analyzed the input data. The same data file would crash sometimes and not crash other times.

Exasperated, I started stripping out large chunks of code. The math calculations got stripped out, over several iterations, until there were no calculations whatsoever. Still crashed. Cheezus. What in the...?

I excised the up-front error-checking. Nada. Same results. And it was crashing in random locations!

Now all I had the was the loop that read the input file and pre-processed the data for calculation. Ripped out the pre-processor part. ARGGHHHGH! It still crashed.

All that remained was a loop and an fscanf that read the raw input data into the initial data variables. I removed the fscanf.

It worked. Well, it better, given that the whole damn program was just a freaking loop now. Something in the fscanf was toasting something else, given the random location of the crashes.

Long story short: one of the data items was overranging fscanf's load of a variable. Just one in a series of eight or nine. And since HP/UX's I/O subsystem was handling the fscanf (to give time back to the system)... the subsystem was occasionally blowing away my process - randomly, just to ratchet up the fun factor.

So... the I/O subsystem was randomly crashing the application code. Hey, HP/UX designer! Nice separation of process and system code! Okay, that's my frustration talking, it really wasn't their fault.

Lesson learned: separate steps wherever possible. For example, read input data into a buffer, _then_ sscanf it. Don't mask too many operations in the interest of "more elegant" code. You might end up, ahem, hair-challenged.

Paranoid, anal, whatever

I was talking with M today about a billing problem he encountered with his mobile phone. Seems there was a not-so-slight bug in their minute-tallying code. If you dialed a number, hung up, and then dialed again... both calls were charged. And the first call generally would get billed 30 or 40 minutes. Uhm, that's not right. Enough people complained that they not only retroactively repaired the bills... but they even fixed the billing software. Go figure.

As we discussed this problem, one of my most disastrous software screwups popped into my head. All of the intentional mental blocks I'd thrown up had failed. And even the fail-safes had failed. It was all coming back to me... all the pain, adrenaline shock, and pure horror. The reason why almost anyone who's ever reviewed my source code has said one thing.

"Damn, you are one anal SOB."

Ah, pull up a chair, youngster, and let me tell you a story of why I check every error condition, log every bizarre, impossible situation, and even alphabetize my class members and methods with perfect tab alignment throughout. Maybe that last part is going overboard a bit. Nonetheless...

I was still at my first job, at the O Corporation (see previous blog entry for more mundane, pointless detail). I'd been there a year or two, and was getting pretty good at all sorts of real-time, assembly level hacks. One of our products needed to be able to communicate over a dialup line. This predated the Internet. Hell, it predated modems. All we had available for data communications were Anderson-Jacobsen (click for picture) acoustic couplers.

Basically, the A-Js were the precursors of modern dialup modems. You could get a blistering 110 to 300 baud transfer rates out of 'em. We were like, "300 baud? NFW! That's awesome!".

One of our products had been deployed in Chilicothe, Ohio. Way too far to drive on a regular basis. So one guy rigged up the product to accept dialup calls using his A-J. His system would wait for a call, bundle up some data and send it back to the caller.

I wrote the management side. Created a serial "driver" to talk to the A-J (we didn't have no stinkin' COM ports then, biatch, we're talking raw UART control code). Then added a layer to harness the awesome power of the A-J through the equivalent of control strings (similar to Hayes AT codes). And lastly, added the scheduler and control logic that would dial up the remote system, request the data, and save it into a text database for my batch reporting tools.

Oh, this was going to be sweet. It was too damn cool. A couple of tests later, I was ready to rock. It looked like it was working perfectly. This was a Friday, so I scheduled a collection job and took off for the weekend.

Came in Monday. Wow, it had worked. We'd collected all the data. I was pumped! I hardly noticed that the modem was still connected. Hmmm. That's weird. Just a fluke. I'll just recycle it, no problem.

A week later, the receptionist called. "Do you realize one of your phone lines had a long-distance charge of $2,100 on it?".

"Well, I didn't do that. Sounds like a problem with the phone company."

I hung up and four gallons of adrenaline got pumped into my stomach as I realized that the modem had been on that entire weekend. The VP of Engineering was walking over. Oh s**t. This wasn't going to be good. He'd obviously heard the news.

"What the heck happened to your phone bill, Ross?"

"Uh, not sure, sir. I think... I think... my software neglected to hangup the A-J."

"Well, you're damn lucky." Huh? Why? "Because the receptionist sweet-talked the Bell customer service people and convinced them they had a problem with their billing. They reversed the charge." Wheeeeew. That was quite a relief.

So call me Paranoid. Anal. Whatever. That debacle forced me to be ultra-careful. All of those "that can't happen" conditions? I check 'em and log 'em. I don't want the equivalent of a four-figure phone bill on my watch.

Encyclopedia of Wireless Telecommunications

First Job
My first job -- after graduating with a degree in Computer Science -- was at the O Corporation. O is an abbreviation that protects both the guilty and the innocent. My title was "Systems Programmer", but my real role was to find and fix bugs in the company's mainstay product: an Intel 8080-based process measurement and control system.

The systems themselves varied from single-processor with maybe 8K of RAM to multi-processor (Multibus-based) with two or three processors and perhaps 24K of RAM. 4K of RAM was used as global storage, accessible to all of the processors.

The advanced models, of course, used the multi-processor configurations. The extra processors were there to support a CRT (black and white, with 320 x 240 pixel resolution, I think) display of the process. Those were the really expensive models, so often customers opted for the base units that displayed the key metrics using seven-segment displays on the front panel.

To develop, we used Intel MDS-80 development systems (arguably, the first personal computers) running the ISIS Operating System. We would modify the 8080 assembler source code (using 8" floppies), run an assembler on the code, then swap in a linker floppy and create the final image. The end result would get burned onto an EPROM (erasable, programmable read-only-memory for the hardware-challenged). Had a bug in the code? That's where the fun came in.

Debugging on some of these systems (especially those without CRT's) was - uhmmm - entertaining. One of the sharp hardware guys had come up with a device called a CAM box, which strapped into the bus and allowed you to read memory addresses onto a seven-segment display. You could even change the contents of RAM.

Bob Frantz, I believe, was the original (very smart) software designer who had come up with much of the architecture. As an aside, he bequeathed all of his original Dr. Dobb's Journals to me -- which I still have -- upon his retirement. But he had written the system's original real-time OS (pre-emptive, multitasking and fit in perhaps 1K or so of code) and designed much of the architecture. Another sharp developer, Dave H., was also a key contributor. One of the clever aspects of the system involved a call table placed into RAM. The major tasks and services all vectored through the call table.

Using the CAM box, if you placed a C9 (a "return" instruction) in the right place in the call table, you could disable a misbehaving service. Putting a C3 back (a "jump", followed by the address) turned the service back on. You could also write some debugging values to the minimal amount of spare RAM and then inspect the values through the CAM box. Let's just say that debugging through the CAM box on the plant floor was... not quite as smooth a user-experience as using Visual Studio's integrated debugger. But it worked. And, boy, did I learn a lot.

I ended up leaving the company for technology-related reasons. Shortly after I joined, they acquired a division of another company that also developed high-end process control software. Their entire architecture was based on DEC PDP-11's. The new guys convinced management to develop the next generation products using DEC hardware (e.g., MicroVAXes). I wrote memo after memo espousing a PC-based architecture. When I didn't get my way... I resigned and moved on to another company.

The original company is still in business and, to this day, cranks out process control equipment. Albeit as a division of a much larger company. I think, in retrospect, the PC decision impacted their ability to remain independent. But that's just my opinion and I could be wrong.

Amazon.com: Books: Microcomputers and Microprocessors: The 8080, 8085, and Z-80 Programming, Interfacing, and Troubleshooting (3rd Edition)

Stupid White Man

Fat and stupid is no way to go through life, son.

Perhaps the most serene irony to be found in Hollywood is that the most phony, disingenuous person in the whole town is the avowed outsider, the self-righteous everyman. It’s impressive to see one man be so heroically ridiculous, a man who manages to be

1. A radical socialist who lives in a palatial New York apartment and sends his daughter to one of the most expensive private schools in the country.

2. A blowhard who pretends to advocate the views of the average American despite holding opinions that the majority of Americans find absurd.

3. A polemicist against President Bush for manufacturing “fictitious elections” who makes fictitious “documentaries,” lies pathologically in his writing and interviews, and actively doctors his past statements to avoid looking silly.

Stupid White Man

The Seven Stages of Targeted Marketing

The seven stages of targeted marketing are described in this brief and compelling article directed at those of us who are marketing-stunted.

"The 7 stages, involving a mixture of tele-research, direct mail and telesales, are listed below. Each stage will be described in more detail later in this article:

Selection of key target market sectors: identifying what types of customers you want to do business with.

List research: compiling lists of potential customers.

Telephone research: to ensure that the information gained from the lists is accurate, and to get any supplementary information not included in the mailing lists.

Prospect selection: based on the lists and telephone research, to eliminate any inappropriate prospects and / or to produce a smaller, manageable sub-list for this particular mailing.

Mailshot: sending out a letter and appropriate sales literature to the selected prospects.

Telephone follow-up: this is where you really go for whatever it is you are wanting - a sales meeting, a trial order, the opportunity to quote... whatever is your objective.

Recording, measuring, monitoring: so that you know what has worked, what has not, what actions you need to take next."

Targeted marketing: how to do it

The Beale Codes
"It was in the month of January, 1820, while keeping the Washington Hotel, that I first saw and became acquainted with Beale. In company with two others, he came to my house seeking entertainment for himself and friends. Being assured of a comfortable provision for themselves and their horses, Beale stated his intention of remaining for the winter, should nothing occur to alter his plans, but that the gentlemen accompanying him would leave in a few days for Richmond, near which place they resided, and that they were anxious to reach their homes, from which they had long been absent. They all appeared to be gentlemen, well born, and well educated, with refined and courteous manners and with a free and independent air, which rendered then peculiarly attractive. After remaining a week or ten days, the two left, after expressions of satisfaction with their visit. Beale, who remained, soon became a favored and popular guest; his social disposition and friendly demeanor rendered him extremely popular with every one, particularly the ladies, and a pleasant and friendly intercourse was quickly established between them.

"In person, he was about six feet in height, with jet black eyes and hair of the same color, worn longer than was the style at that time. His form was symmetrical, and gave evidence of unusual strength and activity; but his distinguishing feature was a dark and swarthy complexion, as if much exposure to the sun and weather had thoroughly tanned and discolored him; this, however, did not detract from his appearance, and I thought him the handsomest man I had ever seen. Altogether, he was a model of manly beauty, favored by the ladies and envied by men. To the first he was reverentially tender and polite; to the latter, affable and courteous, when they kept within bounds, but, if they were supercilious or presuming, the lion was aroused, and woe to the man who offended him. Instances of this character occurred more than once while he was my guest, and always resulted in his demanding and receiving an apology. His character soon became universally known, and he was no longer troubled by impertinence.

"Such a man was Thomas J. Beale, as he appeared in 1820, and in his subsequent visit to my house. He registered simply from Virginia, but I am of the impression he was from some western portion of the State. Curiously enough, he never adverted to his family or to his antecedents, nor did I question him concerning them, as I would have done had I dreamed of the interest that in the future would attach to his name.

"He remained with me until about the latter end of the following March, when he left, with the same friends who first accompanied him to my house, and who had returned some days before.

"After this I heard nothing from him until January, 1822, when he once more made his appearance, the same genial and popular gentleman as before, but, if possible, darker and swarthier than ever. His welcome was a genuine one, as all were delighted to see him.

"In the spring, at about the same time, he again left, but before doing so, handed me this box, as he said, contained papers of value and importance; and which he desired to leave in my charge until called for hereafter. Of course, I did not decline to receive them, but little imagined their importance until his letter from St. Louis was received. This letter I carefully preserved, and it will be given with these papers. The box was of iron, carefully locked, and of such weight as to render it a safe depository for articles of value. I placed it in a safe and secure place, where it could not be disturbed until such time as it should be demanded by its owner. The letter alluded to above was the last communication I ever received from Beale, and I never saw him again. I can only suppose that he was killed by Indians, afar from his home, though nothing was heard of his death. His companions, too, must all have shared his fate, as no one has ever demanded the box or claimed his effects. The box was left in my hands in the Spring of 1822, and by authority of his letter, I should have examined its contents in 1832, ten years thereafter, having heard nothing from Beale in the meantime; but it was not until 1845, some twenty-three years after it came into my possession, that I decided upon opening it. During that year I had the lock broken, and with the exception of the two letters addressed to myself, and some old receipts, found only some unintelligible papers, covered with figures, and totally incomprehensible to me...

"According to his letter, these papers convey all the information necessary to find the treasure he has concealed, and upon you devolves the responsibility of recovering it. Should you succeed you will be amply compensated for your work, and others near and dear to me will likewise be benefitted. The end is worth all your exertions, and I have every hope that success will reward your efforts."
...

Lynchburg, Va., January 5th, 1822. Dear Mr. Morriss. - You will find in one of the papers, written in cipher, the names of all my associates, who are each entitled to an equal part of our treasure, and opposite to the names of each one will be found the names and residences of the relatives and others, to whom they devise their respective portions. From this you will be enabled to carry out the wishes of all by distributing the portion of each to the parties designated. This will not be difficult, as their residences are given, and they can easily be found.

...
The two letters given above were all the box contained that were intelligible; the others, consisted of papers closely covered with figures, which were, of course, unmeaning until they could be deciphered. To do this was the task to which I now devoted myself, and with but partial success...

To enable my readers to understand the paper "No. 2," the only one I was ever able to decipher, I herewith give the Declaration of Independence, with the words numbered consecutively, by the assistance of which that paper's hidden meaning was made plain:

...By comparing the foregoing numbers with the corresponding numbers of the initial letters of the consecutive words in the Declaration of Independence, the translation will be found to be as follows:

I have deposited in the county of Bedford, about four miles from Buford's, in an excavation or vault, six feet below the surface of the ground, the following articles, belonging jointly to the parties whose names are given in number "3," herewith: The first deposit consisted of one thousand and fourteen pounds of gold, and three thousand eight hundred and twelve pounds of silver, deposited November, 1819. The second was made December, 1821, and consisted of nineteen hundred and seven pounds of gold, and twelve hundred and eighty-eight pounds of silver; also jewels, obtained in St. Louis in exchange for silver to save transportation, and valued at $13,000. The above is securely packed in iron pots, with iron covers. The vault is roughly lined with stone, and the vessels rest on solid stone, and are covered with others. Paper number "1" describes the exact locality of the vault so that no difficulty will be had in finding it.

The following is the paper which, according to Beale's statement, describes the exact locality of the vault, and is marked "1." It is to this that I have devoted most of my time, but, unfortunately, without success...

The Beale Codes

Quine = Self-Reproducing Code

I received a note from AG regarding self-reproducing code. "I presume by now you have seen a kazillions of these"...

...quine: /kwi:n/ /n./ [from the name of the logician Willard van Orman Quine, via Douglas Hofstadter] A program that generates a copy of its own source text as its complete output. Devising the shortest possible quine in some given programming language is a common hackish amusement. Here is one classic quine:

((lambda (x)
(list x (list (quote quote) x)))
(quote
(lambda (x)
(list x (list (quote quote) x)))))

This one works in LISP or Scheme. It's relatively easy to write quines in other languages such as Postscript which readily handle programs as data; much harder (and thus more challenging!) in languages like C which do not. Here is a classic C quine for ASCII machines:

char*f="char*f=%c%s%c;main()
{printf(f,34,f,34,10);}%c";
main(){printf(f,34,f,34,10);}

For excruciatingly exact quinishness, remove the interior line breaks...

The Quine Page

Van.. Hell... zing...

The Filthy Critic has posted a priceless review of the new movie Van Helsing. Enjoy it for the obscene language. Revel in the outrageous metaphor. Hell, just read it.

What a f**king turd. F**k you, Hollywood. How the f**k can you release something so soulless, witless and pointless? How f**king greedy do you need to be?

Van Helsing is as crappy, loud and stupid as the Harelip at the Arvada City Hall Open House's free hot dog barbecue. It's all disorienting squealing and howling and shoving hands down uneasy city firefighters' pants.

Van Helsing is the kind of movie that people who hate movies make. It's not a good movie, it's not even a bad one that somebody cares about. It's just a steaming pile of s**t, a mass-marketing stunt dressed up like entertainment. It'll be a blockbuster, but no for reason other than sheer force of will and heavy marketing that keeps telling us it's an event. If this is an event, so is the time I ate too many sulfites at the Soup Plantation and sat on the can wringing my bowels like a handtowel...

Van Helsing - The Filthy Critic

Francis Bacon's Steganography

The whole world is still buzzing over the controversy: was Francis Bacon really the author of Shakespeare's works? Uhm, well, perhaps that's an overstatement. Anyhow, came across a very intriguing series of articles on Bacon's supposed use of steganography (hiding an encrypted message within another message). It begins with Mark Twain's description of a barely literate Shakespeare.

There is also considerable doubt about the facts of Shakespeare's own life. Let us read what Mark Twain had to say about that (From Is Shakespeare Dead?, 1909):

He was born on the 23rd of April, 1564.
Of good farmer-class parents who could not read, could not write, could not sign their names.
At Stratford, a small back settlement which in that day was shabby and unclean, and densely illiterate. Of the nineteen important men charged with the government of the town, thirteen had to "make their mark" in attesting important documents, because they could not write their names.
Of the first eighteen years of his life nothing is known. They are a blank.
On the 27th of November (1582) William Shakespeare took out a license to marry Anne Whateley.
Next day William Shakespeare took out a license to marry Anne Hathaway. She was eight years his senior.
William Shakespeare married Anne Hathaway. In a hurry. By grace of a reluctantly granted dispensation there was but one publication of the banns.
Within six months the first child was born.
About two (blank) years followed, during which period nothing at all happened to Shakespeare, so far as anybody knows.
Then came twins--1585. February.
Two blank years follow.
Then--1587--he makes a ten-year visit to London, leaving the family behind.
Five blank years follow. During this period nothing happened to him, as far as anybody actually knows.
Then--1592--there is mention of him as an actor.
Next year--1593--his name appears in the official list of players.
Next year--1594--he played before the queen. A detail of no consequence: other obscurities did it every year of the forty-five of her reign. And remained obscure.
Three pretty full years follow. Full of play-acting. Then.
In 1597 he bought New Place, Stratford.
Thirteen or fourteen busy years follow; years in which he accumulated money, and also reputation as actor and manager.
Meantime his name, liberally and variously spelt, had become associated with a number of great plays and poems, as (ostensibly) author of the same.
Some of these, in these years and later, were pirated, but he made no protest.
Then--1610-11--he returned to Stratford and settled down for good and all, and busied himself in lending money, trading in tithes, trading in land and houses; shirking a debt of forty-one shillings, borrowed by his wife during his long desertion of his family; suing debtors for shillings and coppers; being sued himself for shillings and coppers; and acting as a confederate to a neighbor who tried to rob the town of its rights in a certain common, and did not succeed.
He lived five or six years--till 1616--in the joy of these elevated pursuits. . .
When Shakespeare died in Stratford it was not an event. It made no more stir in England than the death of any other forgotten theatre-actor would have made. Nobody came down from London; there were no lamenting poems, no eulogies, no national tears--there was merely silence, and nothing more. A striking contrast to what happened when Ben Jonson and Francis Bacon, and Spenser, and Raleigh and the other distinguished literary folk of Shakespeare's time passed from life! No praiseful voice was lifted for the lost Bard of Avon; even Ben Jonson waited seven years before he lifted his.
So far as anybody actually knows and can prove, Shakespeare of Stratford-on-Avon never wrote a play in his life.
So far as anybody knows and can prove he never wrote a letter to anybody in his life.
So far as any one knows, he received only one letter during his life.
So far as anyone can know and can prove, Shakespeare of Stratford wrote only one poem during his life. This one is authentic. He did write that one--a fact which stands undisputed; he wrote the whole of it; he wrote the whole of it out of his own head. He commanded that this work of art be engraved upon his tomb, and he was obeyed. There it abides to this day. This is it:

Good frend for Iesus sake forbeare
to digg the dust encloased heare!
Blest be ye man yt spares thes stones
And curst be he yt moves my bones.

Who wrote the Works?

Shrugs and the Cervical Spine

I never realized what toll the years of lifting were taking on my spine. Now, after having had a disc fusion surgery, I see this terrific article on reducing strength training injuries. Just in time! Sweet! It really is one of the best I've ever seen. What I'm guessing is that years of heavy shrugs, deadlifts and rows -- all with the head tilted forward -- conspired to make the trauma I received while playing basketball worse. I reiterate my recommendation: never have 180 lbs. land on your head. It really doesn't feel very good at all. Anyhow, for anyone training with weights of any significance, do yourself a favor and check this out.

...Exercises in which the head is allowed to nod or protrude forward may contribute to cervical spine injury by either promoting the postural defect... or by predisposing the athlete to cervical disc problems. The tendency to jut the head forward in exercises such as shrugs..., behind the neck presses..., behind the neck pulldowns, lateral shoulder raises..., triceps extensions, curls, incline leg presses, and abdominal crunches promotes the development of the rounded shoulder, forward head posture. This posture is associated with abnormal mechanical function of the cervical spine...

Minimizing Weight Training Injuries in Bodybuilders and Athletes

Because you just can't get enough self-reproducing code...

Tobias from PHPwizard wrote me regarding an earlier blog entry on self-reproducing code. He uses a printf to achieve the necessary recursion for self-reproduction. Way, way more elegant than the clunky approach I wrote over lunch one day. Anyhow, here 'tis:

I used these as signatures back in 1999 or 2000:

<?$p = '<?$p = %c%s%c; printf($p,39,$p,39);?>'; printf($p,39,$p,39);?>

Another self-printing signature:

<?printf("<?".$a='printf("<?".$a=%c%s%c,39,$a,39);?>',39,$a,39);?>

This is unrelated, but cool: :)
Mandelbrot, takes less than a second with PHP 5.0, took 3.5 seconds to execute with PHP 4.0.1 and 13.5 seconds with 3.0:

<?$c=$s=0;$a=$t=$x=$y=$b=-2;for(;$b-=$a>2?0.1/($a=-2):0,$b<2;
$s.=chr(30+$c),$a+=0.0503)for($x= /* Tobias Ratschiller */
$y=$c=0;++$c<90&$x*$x+$y*$y<4;$y= /* http://phpWizard.net */
2*$x*$y+$b,$x=$t)$t=$x*$x-$y*$y+$a;print(chunk_split($s,80));?>

MSDN opines on network security... and it's pretty good!

Looking for a good overall picture of network security? Not sure you've had enough formal coverage of all the threats in the wilds of cyberspace? MSDN, of all places, has a pretty good backgrounder on the topology of network security.

Web Security Threats and Countermeasures

Fast Track: How To Implement Web Application Security

Have been engaging in a good email discussion with B regarding Larry Abraham's articles (see a prevous blog entry entitled "The clash of civilizations and the great Caliphate"). His comments:

> I read the Larry Abraham stuff you cited and, while I found the thesis
> to be interesting, I have to say the guy's off the deep end. His focus
> on the Judeo-Christian/Western viewpoint greatly reduces the relevance
> for me. While I come from that tradition, one needs to remember that
> there are over 2+ billion people that just don't give a s**t. We only
> care and may be alarmed because we hold some religious views very dear.
> It is these same 2+ billion folks that will end up eating our economic
> lunch in the coming 20-30 years.
>
> What we in the US face is an inability to even start thinking and
> planning for energy independence. It's that simple. With that, 90% of
> this religious jihad bulls**t falls away. Combine that with a sane
> policy toward the middle-east and Larry's scenario fails to have any
> plausiblity...not that there is much there to begin with.
>
> Sure, I think his analysis might be indicative of the state of radical
> areas of Islam. Sure, there is history here that goes back a thousand
> years. Why do you think Bush's handlers reacted so strongly when he
> called the War in Iraq/Afghanistan a "Crusade"?
> However, Larry's so partisan with respect to his views of U.S.
> politics that it's clearly a cry from his political perspective.
> Further, he is allowing the jihadists to frame the situation. They want
> us to see it that way and to be very frightened about it. I may have
> bought Larry's thesis were it not for the crazy alarmism and the
> pot-shots at the non-GOP politicians involved. Any article that calls
> out "Liberals" or "Conservatives" loses credibility quickly with me.
>
> The problem with the US is that we live in a pseudo-representative
> oligarchy. Without fundamental change in our system, things will
> continue forward regardless of the stuffed suits that reside in offices
> in DC. Big money (esp. Oil) and special interests drive what's
> happening. We're at "War" because we have too many foreign
> entanglements based upon our need for energy. That won't change until
> those in power change. Invading another couple countries won't solve
> the problem (though I do agree that Pakistan would have been a better
> choice than Iraq). The scary thing for me is that there are people,
> like the bulk of the current administration, that think in black and
> white terms. They have no second thoughts about using words like
> "crusade", "evil-doers", or "new world order". I'm sorry, but reality
> isn't like that. I also have little respect for the academics that want
> to change facts based upon what the definition of "is" is. There must
> be some balance.
>
> What we need to do is attack the problem at it's source. If we
> weren't such gluttons for oil, the middle east and people like Bin Laden
> wouldn't have the $$ necessary to mess with us. You take out Osama or
> the heads of other terrorist groups and three more people will step up
> to take their place. Attack their captial pipeline and they become a
> nuisance rather than a threat. That pipeline should be attacked at the
> source. We are its largest source and hold within our power the ability
> to change.
>

My response was:

Good note. I don't disagree with a thing you've said. But the timeframe for
the type of fundamental changes you've described extends well beyond our
lifespans (IMO).

Reduce our dependence on foreign oil? Sure. Eradicate the influence that
special interests have on law-makers? Absolutely.

But if we started today, we're looking at 20+ years to implement just those two
keystone tenets. Let's start the education process today to show Americans that
really don't need to drive Hummers and Land Cruisers. But that's gonna take a
while.

And, in the mean time, do we tolerate a potential nuclear or WMD threat to our
cities and our families? And what's to say that the religious fanatics would
stop their shenanigans even _if_ we reduced our dependence on their oil to zero?
My guess is they wouldn't stop for a second.

I don't put this in religious terms at all. I put this in terms of:

Capitalist sons-of-bitches vs. Insane, suicidal, murderous sons-of-bitches

I don't give a s**t what their religion is. I do know they want to kill
everyone that isn't like them. Who do _you_ want to win that battle?

Self-Reproducing Code

I was reading the Green Hills commentary on Linux insecurity (see one of yesterday's blog entries). There was a reference to Ken Thompson's classic article ACM Classic: Reflections on Trusting Trust. In it, he discusses why compilers -- written in the language they compile -- can't be trusted.

As an exercise, he proposes the following programming challenge: ...the problem is to write a source program that, when compiled and executed, will produce as output an exact copy of its source. If you have never done this, I urge you to try it on your own. The discovery of how to do it is a revelation that far surpasses any benefit obtained by being told how to do it. The part about "shortest" was just an incentive to demonstrate skill and determine a winner....

Strangely enough, I don't think I'd ever attempted such an exercise before. So after a longer programming session than I'd originally envisioned, I created the following self-reproducing PHP script which I release to the world with all the caveats and limitations of liability specified by this agreement.

Anyhow, here it is. I'd be interested to find out other languages in which this has been attempted (and I'd be happy to publish source here and credit the authors). Email me if you've got a candidate. My lessons learned for PHP are:

- Automated variable expansion in double-quoted strings can be a hindrance in an exercise such as this
- Escapements, escapements, escapements!

<?php

function Esc($s) { return (str_replace(chr(0x27), chr(0x5c).chr(0x27), $s)); }

$aSrc = array(

'echo("<?php\r\n");',

'echo(\' function Esc($s) { return (str_replace(chr(0x27), chr(0x5c).chr(0x27), $s)); }\'); echo("\r\n");',

'echo(\' $aSrc = array(\'); echo("\r\n");',

'for ($i = 0; $i < sizeof($aSrc); $i++) {',

' echo(chr(0x09).chr(0x09)."\'".Esc($aSrc[$i])."\',".chr(0x0d).chr(0x0a));',

'}',

'echo("\t);\r\n");',

'for ($i = 0; $i < sizeof($aSrc); $i++) {',

' echo(chr(0x09).$aSrc[$i].chr(0x0d).chr(0x0a));',

'}',

'echo("?>\r\n");',

);

echo("<?php\r\n");

echo(' function Esc($s) { return (str_replace(chr(0x27), chr(0x5c).chr(0x27), $s)); }'); echo("\r\n");

echo(' $aSrc = array('); echo("\r\n");

for ($i = 0; $i < sizeof($aSrc); $i++) {

echo(chr(0x09).chr(0x09)."'".Esc($aSrc[$i])."',".chr(0x0d).chr(0x0a));

}

echo("\t);\r\n");

for ($i = 0; $i < sizeof($aSrc); $i++) {

echo(chr(0x09).$aSrc[$i].chr(0x0d).chr(0x0a));

}

echo("?>\r\n");
?>

Email me if you've got another one like this. Remember, its output must produce an exact copy of its source without using the file-system or other intermediate storage. It has to generate the source on its own!

This is one clever little hack. Looks like classified documents should go back to Courier New...

Illuminating blacked-out words

The CEO of Green Hills has posted some new content regarding Linux insecurity. He has a point (at least, for embedded applications) and the Linux community needs to address the basic issues he raises. For instance: why has Windows been certified to EAL4 while Linux remains at EAL2?

Before most Linux developers were born, Ken Thompson irrefutably proved that an open source process couldn't find clever subversions, no matter how many people of whatever competence looked at the source code...

"Many Eyes" - No Assurance Against Many Spies - Green Hills Software

The Ross Large Enterprise Technology Stock Report *

Quote	Technology Area	Change	Description
90	Java, J2EE	Unch	Sun’s deal with Microsoft yielding uncertainty; open-source still a ?
72	.NET	+2	NOVL open-source Mono project gains momentum;
70	Web Service Architectures	+2	Still plenty of momentum along all platforms; security still a ?
70	ERP	Unch	Tactical projects still making headway, albeit on limited scale
63	Oracle	-2	Core business hurt by SQL Server and MySQL
60	Business Intelligence	+1	Data warehousing, OLAP on everyone’s radar screen
57	Security	Unch	Security situation is still high-risk area, additional $$ not forthcoming
54	Linux	+2	Despite suits, more enterprise usage of low $ infrastructure
45	MySQL	+3	SAP, other deals, license pricing hurting Oracle, SQL Server
45	SQL Server	-1	Momentum hampered by open-source progress
27	Data mining	+1	Lack of experts and business understanding limit capability
27	DB2	+1	Big Iron and product range drives increased usage
27	Enterprise messaging	Unch	Web services, complexity, security hamper adoption
24	VoIP	+3	Lots of hype, lots of offerings, but integration issues remain
21	B2B	+1	XML, EDI, BizTalk, still hot areas
21	CRM	-1	Plethora of bad implementations leave bad taste in mouths
18	PHP	+2	Oracle and Sun both providing integration with popular web language
18	SFA	Unch	Hosted solutions lack of integration hamper adoption

* These are strictly my opinions based upon what I read and what I see. If you want to quibble with me, start your own blog and get your own seven readers.