The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Tuesday, February 01, 2005

Identity, Authentication and Trust

I'm reading about LID (first at Burningbird, then on Flutterby) and while a decentalized lightweight identification (with authentication and trust) system seems like a nice idea it comes across as being a bit clunky in actual implementation.

First, there is identity. Second, there is authentication. Third is trust. They're related, but not the same.

My identity is me. For instance:

Basic information about me that websites typically are interested in (but not all websites want all this information about me). This is the type of information that could be stored in the browser and if a website wants any of it, it can query the browser for it (of course, I can configure the webbrowser to, say, always serve up my name, URL and email address, but ask me if a website wants anything more, like shipping address or credit card number). But LID (and most other digital identity schemes) always place this data on a server somewhere. While LID is decentralized (I can run my own LID server) it's still information that needs to be protected on a server. I personally would feel a bit better if such personal information were “closer” to me, like on the computer I'm sitting in front of. Then again … having this information on a server elsewhere means I can use reference it (use it) from any computer I happen to be using (say, one at a library).

My authentication is something that others bestow on my identity. If I want to post to Slashdot (for instance) I have to present my identity (or only that portion of my identity that Slashdot actually needs) and they have to check to see if I'm allowed. Nothing outrageous here, but I still have to be checked out by each site I'm interested in, like kuro5hin, Techdirt, Flutterby and others, but once credentialed by each site, I can then use it without having to remember (or write down) scores of userids and passwords (like I have now).

Trust is a way of saying that the identity I presented above is me and not made up or the identity of someone else. When you get a secure certificate for a website from VeriSign or Thawte you present verifiable information to them, pay them quite a bit of money and they'll give you an electronic certificate that basically says “Yup, we trust that this is the company you are communicating with.” But LID is similar to using certificates from ACME. Who's ACME and why would I trust them? At least I've heard of VeriSign and Thawte so I'm more likely to trust them more than ACME. I haven't seen anything in LID that would enable me to confer trust; it just seems to be a way to keep the number of different userids and passwords to a usable number (like one pair).

The clunkiness I see partly comes from some of the URLs used to request various bits of information. A URL like;action=text/xml is normally not seen—semicolons are for path parameters, not query parameters. And checking the code I see:

# this is the list of all URL parameters that will be evaluated by this script.
# The CGI:: module messes up POST vs. URL args, so some of those are accessed as url_param
my $action     = $q->url_param('action');
my $clientid   = $q->url_param('clientid');
my $credential = $q->url_param('credential');
my $credtype   = $q->url_param('credtype');
my $help       = $q->url_param('help');
my $login      = $q->param('login');
my $meta       = $q->url_param('meta');
my $target     = $q->url_param('target');
my $ticket     = $q->url_param('ticket');
my $ts         = $q->url_param('ts');
my $path       = $q->url_param('xpath');
my $url = determineUrl( $q );

# this is the list of all URL POST arguments that will be evaluated by this script
my $username = $q->param( 'username' );
my $password = $q->param( 'password' );

To me, it looks like the author got confused as to how queries are passed to CGI scripts using the GET method (the name/values pairs are supposed to be separated by ‘&’, not a semicolon, which is used for something else in URLs). To me, this doesn't bode well.

Also, playing around and signing up (using the demo account provided) to the two sites that support LID wasn't smooth.

Given time though, this may work out.

Wednesday, February 02, 2005


Over the past few days there's been this almost near constant whirring noise in the office. It sounds like it's just on the other side of my cubicle with that neat Zen-like emptiness to it (and yes, it still has that neat Zen-like emptiness to it, dispite sharing it with a new tech support person).

Whirr. Whirr.

Finally, curiousity got the better of me, and I decided to track down the source of the whirring.

Whirr. Whirr.

The person on the other side of my cubicle with that neat Zen-like emptiness to it has what looks like a very short cattle prod but is instead a massage unit that is currently in use.

Whirr. Whirr.


Whirr. Whirr.

Back to work.

Whirr. Whirr.

At least it has a beat you can dance to.

Oh, it stopped.

URLs, Identity, Authentication and Trust

The other day I mentioned LID and the problems I saw with the URLs they were using as part of the processing. I wrote to Johannes Ernst, who is the principle architect of LID about the problem and after an exchange, I wrote the following, which explains part of the problem:

From: <>
Subject: Re: Question about the code for LID
Date: Wed, 2 Feb 2005 21:56:15 -0500 (EST)

It was thus said that the Great Johannes Ernst once stated:

Good catch. I recall we had a discussion on that and couldn't quite figure out which way was the right way …

If you are trying to send parameters both as part of the URL and with a POST, the URL should be of the form:;xpath=...;action=...

You seem to be the person to ask: where is it defined that URL parameters and POST parameters in combination should be used that way? I recall we looked and couldn't find anything, but maybe you would know?

Well, I've checked RFC-1808, RFC-2396 and RFC-3986, and as I interpret these, the general scheme of a URL is (and skipping the definitions of parts not germain to this—stuff in [] is optional, “*” means 0 or more, “+” is 1 or more, parenthesis denote groupings, etc):

<url>     ::= <scheme> ':' [<net>] [<path>] ['?' <query>] ['#' <fragment>]
<net>     ::= '//' [<userinfo> '@'] <host> [ ':' <port> ]
<path>    ::= <segment> *( '/' <segment> )
<segment> ::= *<character> *( ';' *<param> )
<param>   ::= *<character>
<query>   ::= *<character>

No structure is defined for <param> or <query> in the RFCs. By convention, the <query> portion is defined as:

<query>      ::= <namevalue> *( '&' <namevalue> )
<namevalue>  ::= +<qchar> '=' *<qchar>
<qchar>      ::= <unreserved> | <escape>
<unreserved> ::= <alpha> | <digit> | "$" | "-" | "_" | "." | "+" | "!"
                   | "*" | "'" | "(" | ")" | ","
<escape>     ::= '%' <hexdigit> <hexdigit>

(there are also some restrictions on what can appear in a <segment> and <param>, but those are covered in the various RFCs, but note that the semicolon needs to be escaped in the query string, fancy that!)

The upshot is that you can have a URL of the form:;1/to;type=b/file.ext;v4.4?foo=a&bar=b (note)

(note—when giving a URL in an HTML document, the '&' needs to be escaped to pass HTML validation)

where the parameters “;1”, “type=b” and “v4.4” apply to “path”, “to” and “file.ext” respectively (according to RFCs 2396 and 3986—as I read RFC-1808 it says that the <param> can only appear once, and that at the end of the <path> portion—but given that RFCs 2396 and 3986 are newer, I'll take those as correct).

Now, how this all relates to LID?

It's not pretty I'm afraid.

Apache doesn't parse the path params correctly [as I found out today in playing around with this stuff –Sean]—or to be more precise, it doesn't parse them at all and passes them directly through to the filesystem. So while what you have is a decent workaround, it will probably only work for the perl CGI:: module; I can't say for any CGI modules in other languages (and I know the one I wrote would have to be modified to support LID URLs).

I haven't had time to really look through the LID code to see all what it does, but as I have time, I'll do that. But feel free to keep asking questions—I'd like to help.

Basically, what they're trying to do is pass parameters as part of the URL, as well as pass parameters as part of a form (primarily using the POST method for certain actions). And what they're trying to do isn't so much illegal (in the “this type of stuff is not allowed in the protocol” sense) as it is unspecified. I created a simple test page of forms with various combinations of path parameters and query parameters using both GET and POST methods to see what information is passed through Apache to the simple script I was referencing. The results are mixed:

Results of URL parameters with <FORM> parameters
Method Script URL Paramters obtained from URL Paramters obtained from <FORM>
Method Script URL Paramters obtained from URL Paramters obtained from <FORM>
GET script.cgi;n1=v1;n2=v2 Requested URL script.cgi;n1=v1;n2=v2 was not found on this server
GET script.cgi/;n1=v1;n2=v2 YES, in $PATH_INFO as “/;n1=v1;n2=v2” YES
GET script.cgi?n1=v1;n2=v2 NO YES
GET script.cgi/?n1=v1;n2=v2 NO YES
GET script?n1=v1&n2=v2 NO YES
POST script.cgi;n1=v2;n2=v2 Requested URL script.cgi;n1=v1;n2=v2 was not found on this server
POST script.cgi/;n1=v1;n2=v2 YES, in $PATH_INFO as “/;n1=v1;n2=v2” YES
POST script.cgi?n1=v1;n2=v2 YES, in $QUERY_STRING as “n1=v1;n2=v2” YES
POST script.cgi/?n1=v1;n2=v2 YES, in $REQUEST_URI as “script.cgi/?n1=v1;n2=v2” YES
POST script.cgi?n1=v1&n2=v2 YES YES

I'm beginning to think that the way LID works is about the only way for it to realistically work across webservers, seeing how path parameters are rarely used and that mixing parameters from the URL and <FORM> is unspecified for the most part.


Thursday, February 03, 2005

Mozart was a Red

CARSON (quickly): That's all right. That doesn't matter. Your taste reveals your musical premises.

KEITH (puzzled): Oh? Well, I like Beethoven, Bach, Mozart, the standard …


CARSON: Keith, how could you? I, who know the depth of depravity to which most men sink, even I have to ask myself, how can they? Beethoven, Mozart, who reek of naturalism, whose whole work tramples on values, whose every note displays the malevolent universe premise.

KEITH (stunned): Malev … ?

CARSON: Oh, Keith, can't you see the hatred of life in every bar of their music?

Via the Mises Economics Blog, Mozart was a Red

I do like a good satire.

About a decade ago I read Atlas Shrugged because a friend of mine became enamored with her works and I wanted to understand what exactly happened to him (it was an okay book but could have seriously been edited). But the more I read about Ayn Rand and Objectivism, the more silly it became (and like any good religion, it split—into the Peikoffian and Kelleyist camps—and I am not making that up).

And what's with Ayn Rand's lucky gold watch?

Anyway, the one act play Mozart was a Red is quite the amusing read, especially if you know Ayn Rand and Objectivist history.

Friday, February 04, 2005

From Amazon—only $19,999.95

First eBay has a selection of odd items for sale (okay, technically “for bid”) but now Amazon? (link via InstaPundit) It looks like something from Jabba's sail barge, or something that would transport Daleks.

How odd!

Saturday, February 05, 2005

This is a HAMFest?

We got a good parking spot.

Not a good sign.

Kelly, Wlofie and I had gone to the 45th Tropical Hamboree and unlike previous years, we got an excellent parking spot near the front. And no, we did not show up at 7:00 am for this—no, we ended up pulling into the parking spot around 11:00 am. The parking lot was relatively empty this year.

Walking up to the main building, we saw something I hadn't seen before in my years of attendance—an outdoor flea market. Nothing huge, but as a sign goes, this could be good (way too many exhibitors inside) or bad (it's so bad inside these people didn't want the hassle of obtaining a table).

But our fears were confirmed when we entered the main hall.

It was practically empty.

This was worse than the previous two times (has it really been three years since the last trip? Wow … ). Worse, the number of booths dealing with cheap tools, crafts and leatherworks easily outnumbered the booths about HAM radios, computers or electrical components.

Sad really.

I'm beginning to think that the Miami International Map Fair may be in order next year.

Nothing more than asphalt and grass

On the way back from the non-event that was the 45th Tropical Hamboree, Kelly (who was driving) decided that it would be interesting to drive by what was once Andytown, Florida, but is now the intersection of US-27 and I-75.

[Nothing more than asphalt and grass] [It's not even listed in Kelly's in-car GPS]

Nothing else but asphalt and grass remains.

Sunday, February 06, 2005

Art of seeing without sight

So, we ask, how do you know how long these poles should be as they recede? I was taught, he says. Not by any formal teacher, but by casual comments by friends and acquaintances. How do you know about shadows? He learned that too. He confides that for a long time he figured that if an object was red, its shadow would be red too. “But I was told it wasn't,” he says. But how do you know about red? He knows that there's an important visual quality to seen objects called “colour” and that it varies from object to object. He's memorised what has what colour and even which ones clash.

Via Jason Kottke, Senses special: The art of seeing without sight

An artist who can draw complicated scenes upon request, despite the rather small handicap of being blind—a very interesting article indeed.

Monday, February 07, 2005

Kludge works

The server that this site was being hosted on. The one that went down last month? Well, last week it was retrieved and left behind my cubicle with that neat Zen-like emptiness to it. I trotted it down to the data center at The Company, powered it up, and set it to constantly read from the harddrives as I suspected those were the failure point.

Today I checked in on the server and found spewed all over the console window:

eth0: command 0x5800 did not complete! Status=0xffff
eth0: Resetting the Tx ring pointer.
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, tx_status ff status ffff.
  diagnostics: net ffff media ffff dma ffffffff.
eth0: Transmitter encountered 16 collisions -- network cable problem?
eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
  Flags; bus-master 1, dirty 47985(1) current 48001(1)
  Transmit list ffffffff vs. f7cea240.
eth0: command 0x3002 did not complete! Status=0xffff
  0: @f7cea200  length 8000002a status 8000002a
  1: @f7cea240  length 8000002a status 0000002a
  2: @f7cea280  length 8000002a status 0000002a
  3: @f7cea2c0  length 8000002a status 0000002a
  4: @f7cea300  length 8000002a status 0000002a
  5: @f7cea340  length 8000002a status 0000002a
  6: @f7cea380  length 8000002a status 0000002a
  7: @f7cea3c0  length 8000002a status 0000002a
  8: @f7cea400  length 8000002a status 0000002a
  9: @f7cea440  length 8000002a status 0000002a
  10: @f7cea480  length 8000002a status 0000002a
  11: @f7cea4c0  length 8000002a status 0000002a
  12: @f7cea500  length 8000002a status 0000002a
  13: @f7cea540  length 8000002a status 0000002a
  14: @f7cea580  length 8000002a status 0000002a
  15: @f7cea5c0  length 8000002a status 8000002a

wait_on_irq, CPU 0:
irq:  0 [ 0 0 ]
bh:   1 [ 0 1 ]
Stack dumps:
CPU 1:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
       00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
       00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
Call Trace:   

CPU 0:c1f31f2c 00000000 00000000 ffffffff 00000000 c0109a5d c029d094 00000000 
       f6a2c000 c0108d22 00000000 c02c5ce4 c02001a4 ecf7a000 c1f31f98 c0115621 
       ecf7a000 f6a2c368 c02c5ce4 c1f31f8c c1f30664 c1f30000 c011c5cf f6a2c000 
Call Trace:    [<C0109A5D>] [<C0108D22>] [<C02001A4>] [<C0115621>] [<C011C5CF>]
  [<C0125234>] [<C0125070>] [<C0105000>] [<C010588B>] [<C0125070>]

eth0, by the way, is the network interface.

The harddrives were still running the test I left them to, and no errors whatsoever. Dan, the network engineer, did admit to borrowing the network cable that was plugged into that server earlier this morning, and that was enough to trigger the slew of errors I saw (and I did thank him for doing that—otherwise I don't think I would have ever found what the problem might have been).

Well (and it's here I wished I remembered to take pictures).

The rack mounted case the system is in is not very tall, and certainly not tall enough to house a PCI card. So in one of the PCI slots was special card with PCI slots on it, such that you could now mount cards parallel to the motherboard (instead of perpendicular). Only you couldn't use the existing mounting bracket on the PCI card in question. So the mounting bracket on the network card had been removed, and only held in place by the friction between the card and the slot itself.

Not a stable connection.

Problems with this server only really started when some equipment was removed from the cabinet it was in, and I'm guessing the network cable was bumped just enough to make life interesting.

On the plus side, that means the server doesn't need to be replaced or even rebuilt (thankfully!).

Tuesday, February 08, 2005

My life in a bad Star Trek episode

Ah, “Project White Elephant.” Haven't talked about that in a while, but then, I haven't had much involvement with it for a while.

Until today.

The current sub-project is pretty straight forward. We have two machines, let's call them chip and dale (again, the names have been changed to protect the guilty me, but thematically, the pseudonyms are close enough). chip is the primary machine, which handles email, the websites, DNS, what have you, for “Project White Elephant.” dale is there solely to pick up if (or when) chip dies.

Now, chip has an IP address of C, and dale has an IP address of D. The services, DNS, SMTP, POP, IMAP and HTTP (among others), are not bound to address C or D, but to V. chip's network card is programmed to listen to V, but in the event that chip goes down, dale will then configure its card to listen on V and take over DNS, SMTP, POP, IMAP and HTTP (among others).

Not trivial, but doable and the details can be a bit tedious. Simplifying things a bit, you need to make sure that the configuration of all the services on chip are copied over to dale and that you can start the services on dale without error. Oh, you also need to replicate any datafiles (websites, email, etc) from chip to dale.

But …

Sadly, we're using Blech, a … <shudder> … control panel (yes, yes, I know … I said we weren't going to use a control panel for “Project White Elephant”—that order has since been rescinded—sigh).

Sure, a control panel makes simple yet tedious operations, such as configuring a new site on the system, easy and relatively painless. But attempt to do anything out of a proscribed set of procedures and basically, it ends up either being too difficult or outright impossible, that otherwise would be possible without the contraints of a control panel.

Today's particular problem had to do with site replication from chip to dale. We could configure the site on chip, and it even got pushed out to dale but the configuration of the webserver (Apache) wasn't replicated properly and sites pushed out to dale would end up with an IP address of D and not V.

I was on the phone with one of our contacts in “Project White Elephant” and I swear, the phone conversation was straight out of a bad Star Trek episode:

“Okay, we can set up the routers to preferentially route V to chip and then if it goes down, switch over to dale.”

“Wouldn't that require the configuation of RIP on the servers to initiate the router switch from chip to dale?”

“Yes, you're right. We can't do that. How about creating a special instance of DNS on dale such that if chip goes down, dale picks up, and—”

“Terrible idea. Each DNS change on chip requires tracking that and updating the private copy on dale

“Sure, but it can be scripted.”

“But Doctor, you miss the point. Zone A has a serial number of N. chip goes down. dale takes over, making sure to update the serial number of A to N plus 1. chip then comes back up and starts serving out zone A with a serial number of N.”

“And of course, other DNS servers would ignore that since it's an older serial number, meaning—”

“We'd have to update the zones back into chip such that Blech will accept it, and remember, Blech stores everything in a database and overwrites the DNS configuration files—”

“Meaning we'd have to script the changes back into the database or manually update the information through Blech.


“Okay, what about not running Blech on dale? Then just copy the sites, email and zones over?”

“Then you would have to either translate the configuration from chip to the non-Blech configuration we set up on dale, which means that K [being the admin who is responsible for running these boxes and can't use the command line—don't ask] won't be able to handle that box. Or we set it up just like Blech.”

“Dash it all! Okay, what about reversing the polarity of the flux capacitor and letting the backwash flow into the Jeffries Tubes?”

“Nice in theory, but you know what they say about theory and practice, right?”

“ ‘In theory, there is no difference between theory and practice, but in practice, there is.’ ”

“Exactly. Do that, and you run a risk of the back pressure rupturing the Jeffries Tubes, and let's not even get into the problem of stuck bits on the condensor plate if you reverse the polarity of the flux capacitor.”

“You're right! I forgot about that!”

Only the conversation was much longer. And not as interesting.

In the end, the only real sticking point was the websites. DNS isn't a problem if we can assign the services to address V. SMTP isn't a problem since you can set the MX records for incoming email to do the right thing. And since we did find a way to replicate the existing mailboxes between the two machines (which doesn't impinge on any configurations) and assuming we can get the IP address switch over working, then POP and IMAP aren't real issues (and in that reguard, Blech does seem replicate most of the site data between chip and dale, stuff like users and what not). That leaves HTTP. And a quick test of simplying copying the web server configuration and the ability to start and stop the webserver via the command line (which amazingly enough is a standard command!) I think we can pull this off.

Now only if we could do something about those stuck bits on the condensor plate …

Wednesday, February 09, 2005


Captain Napalm was only mentioned twice in the entire 10-year run of Calvin and Hobbes.

Cause confusion in the marketplace indeed … (link sent to me from my friend craniac)

Thursday, February 10, 2005

There actually is a control panel I like

I know I've mentioned plenty of times how I hate control panels, but driving to work today I realized that there was one control panel I actually liked and would love to use again. As I thought of this control panel, I had to think why I liked it so much, besides the obvious fact that it made such odious tasks like partitioning drives dead simple, and I figured out why I liked this particular control panel.

Unlike Insipid, Blech, Badminton or Torture Rack which tend to operate in a “black box” mode, this control panel gives you the option to actually view the commands it is about to run before you run them. A wonderful option so that if you need to know how it does something, you can see how it does something.

While there are other features I would love to see with Insipid, Blech, Badminton or Torture Rack (more on this below), this one feature would more than make up for all the missing features.

And the control panel?


Written by IBM for AIX, it is perhaps the best interface I've seen to system administration and I love the ability to see what commands are being run. Sad that no other control panel has this feature.

So yes, I don't hate all control panels, just anything that isn't SMIT.

Friday, February 11, 2005

Now what?

Ah, “Project White Elephant.” Just when we thought we were safe …

K (the administrator) calls, informing us that he is currently talking with someone else logged in as root on the system.


We found out how the person got in—8,500 login attempts and they got lucky (hey, I didn't pick the password; nor did Smirk, my boss). The person breaking in also didn't bother to wipe out the root shell history or even mask that they had logged in (heck, they initiated the conversation asking if we would allow them to run an IRC bot); fortunately, this was all the person did.

Still, quite annoying.

Saturday, February 12, 2005

Various types of bugs

For the past week or so, we've been fighting a loosing battle with a flea invasion fleet—given the three cats we have, it's no wonder. So today was the day we dropped “The Bomb.”

Or rather, two large bug bombs, Fat Man and Little Boy (one upstairs, one downstairs), guarenteed to remove our flat six legged blood suckers.

In order to pass the time while Fat Man and Little Boy did their work, we went to the Spy Café (which happens to be a McDonalds and a spy museum). Amazingly enough they have an actual Enigma Machine on display, along with plenty of movie posters and in each booth, a small TV screen showing spy related movies.

[A clandestine rendevous] [The Soviets installed this in the US embassy … guess what was inside?] [If produced so secretly, then how are we seeing it?] [An Office of Strategic Services film] [An Enigma] [A Cold War “Spy Radio”—picture taken on the run] [Parts diagram of an Enigma]

It just seems so strange that a museum would be in a fast food restaurant.

Upon returning home, Fat Man and Little Boy did their number on the flea population as well as the Palmetto Bug population—clustered around the door we found a number of former Palmetto Bug Gang members upsidedown, legs spastically twitching. Now all that remains is a mop-up operation on any fleas and Palmetto bugs that may have survived.

Sunday, February 13, 2005

It's Neal Stephenson, people! Neal Stephenson!

We are in a position akin to that of early physicians who could see that people were getting sick but couldnt do anything about it, because they didnt understand the underlying causes. They knew of a few tricks that seemed to work. For example, nailing up plague houses tended to limit the spread of plague. But even the smart doctors tended to fall under the sway of pet theories that were wrong, such as the idea that diseases were caused by imbalanced humors or bad air. Once that happened, they ignored evidence that contradicted their theory. They became so invested in that theory that they treated any new ideas as threats. But from time to time youd see someone like John Snow, who would point out, Look, everyone who draws water from Well X is getting cholera. Then he went and removed the pump handle from Well X and people stopped getting cholera. They still didnt understand germ theory, but they were getting closer.

We can make a loose analogy to the way that people have addressed the problem of power disorders. We dont really understand them. We know that there are a couple of tricks that seem to help, such as the rule of law and separation of powers. Beyond that, people tend to fall under the sway of this or that pet theory. And so youll get perfectly intelligent people saying, All of our problems would be solved if only the workers controlled the means of production, or what have you. Once theyve settled on a totalizing political theory, they see everything through that lens and are hostile to other notions.

Via InstaPundit, Neal Stephenson's Past, Present, and Future

It's an interview with Neal Stephenson.

Need I say more?

An insane number of bricks

As a kid, I had little say in the attendance of church—I had to go. I never did like attending it—it was too long, and the sermons I found boring (or scary if the Baptist minister did a sermon from the Revelation of St. John the Divine); the only things I enjoyed about church was the architecture and the music (I love church music—but it has to be sans vocals, or the vocals in a language other than English).

Overall, I would have rather stayed home and played with my Lego bricks.

But this Lego-built church (link from Spring) is just … just … words aren't enough to describe it. A 7′ by 5½′ by 30″ church, minifig scale, is incredible.

Architecturally, the design is wonderful and I would love to see a church in real life based on this design, although it would be a bitch to heat and cool, given the volume of the main room and the large amount of glass used.

And the acoustics, and the organ that takes up the entire back wall …



Monday, February 14, 2005

One of these days, I'll get a new graphic

Happy Valentine's Day … Straight from the Heart!

Tuesday, February 15, 2005

We have moveage!

Took a call from our realtor—the previous owners will be out of the house by midnight, and after that, we can commence moving into Casa New Jersey.


One of the first things we'll be doing tomorrow is taking extensive pictures of the house while empty, and I'm sure I'll be posting a few here later on tomorrow.

Wednesday, February 16, 2005

Casa New Jersey

Before going to work, we stopped by Casa New Jersey so I could take pictures of the “empty” house (it wasn't completely empty—the previous owners left a few “things” behind, where “things” can be read as “stuff we now classify as garbage”).

[Casa New Jersey] [Casa New Jersey from behind] [The Jersey Landscape] [The Jersey Landscape II] [Look closely—WASPS!]

Most of the junk left behind was upstairs in the Kids' Room, although The Kids were more than happy to keep it.

Too bad. It's junk. And what wasn't junk (like the large pieces of plywood used to cover the windows during a hurricane) is too useful to let them have at it.

[The Living Room] [The Dining Room] [The Kitchen] [The Bedroom] [The Master Bedroom] [The Kids' Room—pre-junked]

One of the more dangerous items found was a rusty machete in a stand of bamboo at the far corner of the lot, which I jokingly called our own little slice of Southeast Asia.

[The Hallway] [Our own little slice of Southeast Asia] [The Backdoor]

And in the Master Bedroom, the previous owners were kind enough to leave a painting for us.

How nice.

[A Lovely Parting Gift—I personally would have preferred a gift certificate]

The next few days will be spent cleaning up the remaining “stuff” and the actual move will happen next week.

Thursday, February 17, 2005

Uh oh …

My other boss, R, wanted a new site added to the server down in Miami. No problem, it's not something I haven't done before. So I go through the steps needed to add the site, and in this case, the site requires its own IP address (because of the group its in). Not a problem—just pick one of the currently unused addresses, add it to the network interface and there we go. Done, I log out to do other things (like post pictures of Casa New Jersey).

Well, there's a slight problem. The Miami server is also the one that my sites are stored on, and when I went to log back in when trying to post the previous entry, I got an error I've never seen before:

ssh_exchange_identification: Connection closed by remote host

Uh oh.

I can pull up websites, so that's fine. But ssh? FTP?

Nope. Can't log in.

I make multiple attempts, from several different locations across the Internet, trying to log in but the server is not letting me log in.

I do a Google search on the error, and it's heartening to see that this isn't a rare problem at all. But further reading doesn't reveal a solution to my particular problem. No, I didn't change /etc/hosts.allow or /etc/hosts.deny and it was working earlier when I added the site and IP address—

IP address. I added an IP address to the network interface.

And I'm guessing that was enough to throw sshd into suspicious mode and refuse logins.

Well, fine. I knew the solution—restart sshd (and the FTP server—apparently that was having fits too). But how? I can't log in.

Ah, but there is the power pole. Log in to the power pole (through a <cough> <cough>control panel<cough> <cough>) and power cycle the outlet the server is on. Not a great solution, but hey, it'll save me a trip down to Miami.

So I call C, who is responsible for the power pole setup. But well … there's a snag. Since the last debacle the IP address of the power pole was supposed to be updated, but he wasn't sure if it was.


But C needs to get with our network engineer to actually determine that, so until tomorrow (well, later today) no one will be able to log in to the server.


So that didn't work

Yes, the powerbar was recofigured with a new IP address.

No, we're not sure which outlet the server is plugged into.

Well, not 100% sure.

The first time I used the power pole to remotely power cycle a server I brought down the entire cabinet down in Miami. The power pole <cough> <cough>control panel<cough> <cough> gives you several options, immediately shut off an outlet, immediately turn on an outlet, immediately reboot an outlet. I was told the server in question was in outlet 1, so I immediately shut off that outet.

And turned off the network switch.

The network switch that the power pole was plugged into.

No way to turn on outlet 1.

Well …

Live and learn (always use the “reboot” option).

C was “pretty sure” that the server was in either outlets 2 or 3, but not 1. Nor 4. Half an hour of going round and round, my final instructions were to “reboot” outlet 2, and if that didn't reboot the server, then try outlet 3. If that didn't work, then I was facing a long drive to Miami.

So I started pinging the server.

64 bytes from XXX.XXX.XXX.XXX: icmp_seq=1 ttl=51 time=36.0 ms
64 bytes from XXX.XXX.XXX.XXX: icmp_seq=2 ttl=51 time=36.0 ms
64 bytes from XXX.XXX.XXX.XXX: icmp_seq=3 ttl=51 time=36.0 ms
64 bytes from XXX.XXX.XXX.XXX: icmp_seq=4 ttl=51 time=36.0 ms

And rebooted outlet 2. The <cough> <cough>control panel<cough> <cough> showed the outlet as “Off” and about ten seconds later, the outlet was back on. But during the “reboot” I kept getting pings from the server.

64 bytes from XXX.XXX.XXX.XXX: icmp_seq=15 ttl=51 time=36.0 ms
64 bytes from XXX.XXX.XXX.XXX: icmp_seq=16 ttl=51 time=36.0 ms
64 bytes from XXX.XXX.XXX.XXX: icmp_seq=17 ttl=51 time=36.0 ms
64 bytes from XXX.XXX.XXX.XXX: icmp_seq=18 ttl=51 time=36.0 ms

Okay, that wasn't it. Try outlet 3.

64 bytes from XXX.XXX.XXX.XXX: icmp_seq=22 ttl=51 time=36.0 ms
64 bytes from XXX.XXX.XXX.XXX: icmp_seq=23 ttl=51 time=36.0 ms

Okay, that seems to have been the right outlet. Okay, power restored to the outlet. Wait about a minute for the server to come back up.

Okay, I don't recall it taking this long …

Three minutes?

64 bytes from XXX.XXX.XXX.XXX: icmp_seq=22 ttl=51 time=36.0 ms
64 bytes from XXX.XXX.XXX.XXX: icmp_seq=23 ttl=51 time=36.0 ms

Not good.

Look at the time.

4:52 pm.


I get to drive to Miami, during rush hour traffic.

Drive. Punch. Drive.

What's there to say about the drive to Miami? An hour and a half in heavy traffic to the NAP of the Americas, getting there just as the sun was setting (in an “economically challenged neighborhood” as the politically correct would say), ten minutes to get to the cabinet, press the power switch. Ten minutes to get back to the car, and an hour in (still) heavy traffic to get home.

Friday, February 18, 2005

Free lunch

There's an interesting phenomenon thats known as “Andy giveth, and Bill taketh away.” No matter how fast processors get, software consistently finds new ways to eat up the extra speed. Make a CPU ten times as fast, and software will usually find ten times as much to do (or, in some cases, will feel at liberty to do it ten times less efficiently). Most classes of applications have enjoyed free and regular performance gains for several decades, even without releasing new versions or doing anything special, because the CPU manufacturers (primarily) and memory and disk manufacturers (secondarily) have reliably enabled ever- newer and ever-faster mainstream systems …

CPU performance growth as we have known it hit a wall two years ago. Most people have only recently started to notice …

Quick: Whats the clock speed on the CPU(s) in your current workstation? Are you running at 10GHz? On Intel chips, we reached 2GHz a long time ago (August 2001), and according to CPU trends before 2003, now in early 2005 we should have the first 10GHz Pentium-family chips. A quick look around shows that, well, actually, we dont. Whats more, such chips are not even on the horizonwe have no good idea at all about when we might see them appear.

The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software

Moore's Law never stated that CPU speed would double every year—no, it in fact stated that transistor densities would double every 18 months. It was a side effect that processors doubled in speed each time (and in recent times, about every 12 months or so). But this article stipulates that raw CPU speed has pretty much capped out so traditional software methodologies are ill- suited to the new reality of stagnating CPU speeds (Hah! looks like Microsoft is in trouble now) and that programmers now need to learn concurrent programming if they're going to take advantage of multiprocessor systems (which are becoming more prevelent; if CPUs won't get much faster, put in more CPUs).

Concurrent programming isn't easy. It's hard. Harder than you think.

And I expect because of that, just as most languages adapted some form of object-oriented programming over the past fifteen years, that programming languages will adapt some form of functional programming over the coming years.

Obligatory Picture

[The future's so bright, I gotta wear shades]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site:, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.