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:
- First: Sean
- Middle: Patrick
- Last: Conner
- Email: email@example.com
- URL: http://www.conman.org/people/spc/
- Public Key: 0123456789ABCDEF…
- Street: 123 Main St. #9
- City: Boca Raton
- State: Florida
- ZIP: 33431
- Country: US
- Street: 123 Main St. #9
- City: Coral Springs
- State: Florida
- ZIP: 33065
- Country: US
- Shipping: (same as billing)
- Home: 555-555-1212
- Cell: 555-555-1213
- Work: 555-555-2121
- Credit Card:
- Type: ACME
- Number: 1234567890
- Expiration: 12/09
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
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.
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).
Finally, curiousity got the better of me, and I decided to track down the source of the whirring.
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.
Back to work.
At least it has a beat you can dance to.
Oh, it stopped.
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:
To: Johannes Ernst < XXXXXXXXXXXXXXXXX>
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:
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:
(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
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
POST methods to see what information is
passed through Apache to the simple script I was referencing. The results
|Method||Script URL||Paramters obtained from URL||Paramters obtained from
|Method||Script URL||Paramters obtained from URL||Paramters obtained from
||script.cgi;n1=v2;n2=v2||Requested URL script.cgi;n1=v1;n2=v2 was not found on this server|
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.
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?
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.
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.
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).
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.
I'm beginning to think that the Miami International Map Fair may be in order next year.
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 else but asphalt and grass remains.
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.
An artist who can draw complicated scenes upon request, despite the rather small handicap of being blind—a very interesting article indeed.
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!).
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.
The current sub-project is pretty straight forward. We have two
machines, let's call them
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
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,
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
and that you can start the services on
dale without error. Oh,
you also need to replicate any datafiles (websites, email, etc) from
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
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
“Wouldn't that require the configuation of RIP on the servers to initiate
the router switch from
“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
chip requires tracking that and updating the private
“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
Blech will accept it, and remember,
stores everything in a database and overwrites the DNS configuration
“Meaning we'd have to script the changes back into the database
or manually update the information through
“Okay, what about not running
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
“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
Blech does seem replicate most of the site
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 …
Captain Napalm was only mentioned twice in the entire 10-year run of Calvin and Hobbes.
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.
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
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.
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.
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.
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.
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.
It's an interview with Neal Stephenson.
Need I say more?
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.
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 …
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.
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”).
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.
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.
And in the Master Bedroom, the previous owners were kind enough to leave a painting for us.
The next few days will be spent cleaning up the remaining “stuff” and the actual move will happen next week.
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
I can pull up websites, so that's fine. But
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.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
suspicious mode and refuse logins.
Well, fine. I knew the solution—restart
sshd (and the
server—apparently that was having fits too). But how? I can't log
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.
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.
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 …
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
Look at the time.
I get to drive to Miami, during rush hour traffic.
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.
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.
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.