Phasor Burn

I saw this in my referrer logs today :

http://search.msn.com/results.aspx?srch=105&FORM=AS5&q=gigantic+balls

I’m not quite sure what to make if it. First there’s the FORM parameter. Did they really mean AS5 or perhaps it was a bizarre typo of ASS? Then there’s the puzzling idea that this blog would even match a query like that. Maybe it does.

Certainly will match this posting at least.

I’m afraid to look into this further

Physicist to Present New Exact Solution of Einstein’s Gravitational Field Equation from PhysOrg.com
New antigravity solution will enable space travel near speed of light by the end of this century, he predicts.

On Tuesday, Feb. 14, noted physicist Dr. Franklin Felber will present his new exact solution of Einstein’s 90-year-old gravitational field equation to the Space Technology and Applications International Forum (STAIF) in Albuquerque. The solution is the first that accounts for masses moving near the speed of light.
[…]

By the end of this century? Yeah… sure… Let’s get that permanent L5 colony going first, eh?

Wow, that’s a first for me . . .

Well isn’t this special. I’ve been battling a sporadic error with jumpstarting some brand spanking new Sun equipment. You see, every other jump or so, one to three systems would get to the point where they loaded the Solaris kernel ok but then halted with a “ERROR: No disks found”.

Poking these systems and telling them to jump “boot net - install” a second time almost always resulted in a successful jump. This is with about 14 v210’s and 7 v440’s in an environment were they will need to be jumped on a regular basis; perhaps 2-3 times a week.

Getting reliable jumps was critical and maddenly just out of my grasp.

No amount of disk reseating, swapping disks around, trying Solaris 9 for the network boot kernel instead of Solaris 10 (actual jump data was Solaris 10 FLAR’s) seemed to work. I eventually had to break out the Expect book and code up a babysitter script.

The babysitter gets kicked off every time a series of jumps starts and essentially connects to all of the ALOMs in sequence and checks the console history, then sleeps for a minute and checks them all again. It looks for several different strings and acts accordingly. I even managed to discover a few cases where a kernel panic could occur during jump.

A day or two after getting this script functional and watching it perform well enough for a short-term hack… (still wanted to find the root cause but no time to pursue it further) I found out from the onsite Sun engineer that there’s a run of bad disks from Hitachi. Including approximately 54 disks in the batch of servers that I had been fighting with.

Doh!

For systems that are covered under a maintenance contract (and perhaps warranty, but I don’t care about details like that.. just get this fixed damnit!) Sun is doing a proactive replacement of Fujitsu disks of type MAT3073N with a serial number range of 0450Bxxxxx through 0532Bxxxxx. It’s not like the disks are outright failing, but rather there are indications of a problem with that production run where early failure or similar could happen. Hence the term ‘proactive replacement’.

I hope this helps someone avoid spinning their wheels needlessly, if they should stumble upon this article via google whilst looking for a way to make their new servers jumpstart reliably.

I saw this in the parking lot when I was leaving work. Had to stop to take a snap with my cell phone (hey, those 0.3 megapixel cameras do have a few uses…)

Upon closer inspection, it appears that this was a custom paint job and not some weird vandalism (I’ve NEVER seen a car painted up like this before by vandals). The rear quarter panel said it was a custom job by blah blah blah.

Yeah. Pimp my ride, baby….

Yeesh, that’s somewhat worse than all those cars driving around in various states of kitting out, where they obviously have dozens of pounds of useless added plastic that has yet to be painted to match the rest of the car.