Joe Maller.com

Third very hot day: Things start breaking

It’s New York City’s third day in a row where the temperatures haven’t gone below 95°F and we’re starting to see some trouble. Not a blackout, but evidence that the system is straining.

Con Ed has problems on the East Side

>Con Ed tells Eyewitness News that three feeders are out in both the Madison Square and Kips Bay networks. It believes at least one of the inoperable feeders in each network should be back around noon.

>Kips Bay has 12 feeders altogether. Madison Square has 24.

>There are no voltage reductions in place because of the problems, but Con Ed is asking for extra conservation between 5th Avenue and the East River from 14th Street to 40th Street on the East Side.

>Con Ed says it was manhole fires that damaged the feeders, and that the company is in constant communication with the New York City Office of Emergency Management.

Power problems in NYC

>Con Edison asked New York residents and businesses between 40th Street and 14th Street from Fifth Avenue to the East River to shut off any unused or unnecessary appliances. The area is largely residential.

That would be our neighborhood. The 14th St Y is dark and has signs in the doors reading “Closed to conserve power.” Stores on First Ave north of 14th St are running without AC and most have their lights off. Several traffic lights north of 16th St are on low-power mode (1st Ave flashing yellow, cross-streets flashing red).

I’ll post more if I find anything out.

**Update** I just walked from our apartment at 14th and First to the office on 20th just west of Fifth. Not much evidence of anything past Second Ave. All the stores on Fifth were open, Park Ave and even Irving Place seemed completely normal.

Share |

link: Aug 03, 2006 2:56 pm
posted in: misc.
Tags:

Mobile ESPN loses $135 million and counting

Ben notes:

>Merrill Lynch issued a note to investors calling for ESPN to “throw in the towel” on its branded mobile phone service. Analysts Jessica Reif Cohen … now estimate that ESPN Mobile will lure a mere 30,000 subscribers over the course of this financial year, well below their original estimate of 240,000. Along with the losses generated by a second Disney-branded phone service, ML expects that the Mouse will lose $135 million on its experiment in FY06

You know, I could have saved ESPN $130 million dollars if they just asked me first. For the small consulting fee of $5 million, I could have written at length about how branded single-channel digital devices were a stupid, archaic model that was doomed to fail. Anyone with a proper internet-enabled phone could have all of ESPN’s features and a thousand times more.

However I don’t think ESPN is completely at fault here. They were likely sold a bill of goods by whichever wireless companies they partnered with. American wireless carriers have no idea what they’re doing. The phones and services are often crippled or charged per use, data access is difficult and expensive. Charging to get photos out of a phone is madness. In Japan you can use your phone like a credit card, here people think I’m some kind of tech-god for getting a weather report via SMS.

$5 million, negotiable. Call anytime.

Share |

link: Jul 20, 2006 9:24 am
posted in: misc.

Imagining the Tenth Dimension

Halfway through the discussion of dimension 5 I got that wonderful brain-ache where the mind’s expansion seems to have a physical corollary. Click auto-play and enjoy: Imagining the Tenth Dimension.


I didn’t think the Del.icio.us link pulling script was even still working… Guess it is.

Share |

link: Jul 19, 2006 9:31 pm
posted in: misc.

Unix’s Find, double-slashed paths, symbolic links and RTFM

So I was having this weird problem where the results of Find command were coming back with a double slash in the file path.

After thinking I’d solved it and starting to write out the solution, I realized the issue was because my search target was a symbolic link. I then found Find’s switch for dealing with this problem. Doubtlessly someone else is or will come across this same issue, so I’ll explain what was happening anyway.

This all came up because I needed to grab a set of files that resided in my /tmp directory. On Mac OS X, tmp is actually a symbolic link (a unixy kind of alias) which points to /private/tmp.

Here are a few iterations of this command and a description of their results:

find /tmp -name 'Web*' -print

Returns nothing because find is searching /tmp as a file instead of following the link to the target directory.

find /tmp/ -name 'Web*' -print

This returns the files I was looking for, but their paths contained double slashes (ie. /tmp//Webkit...). The double-slashes were strange, and I suspected (wrongly, keep reading) that they might be causing problems with later commands.

find /tmp/* -name 'Web*' -print

This works, and returned correct file paths, but it probably uses shell expansion which seems silly on top of Find’s own abilities.

Reading the man page again, after the symbolic link realization, I finally saw the -H flag:

The -H option causes the file information and file type (see stat(2)) returned for each symbolic link specified on the command line to be those of the file referenced by the link, not the link itself. If the referenced file does not exist, the file information and type will be for the link itself. File information of all symbolic links not on the command line is that of the link itself.

Well that took a stupid amount of time to discover. Using -H, the command works perfectly with the simple /tmp target:

find -H /tmp -name 'Web*' -print

Same results as the /tmp/* line, but a much cleaner command.

A funny, or sad, footnote of this story is that my original problem had nothing to do with the double-slashed paths. I didn’t realize the files were owned by root and that was causing my command to fail.

Share |

link: Jul 14, 2006 7:52 pm
posted in: misc.
Tags:

Smart vs. Hip

Bruce IM’d with a quote I hadn’t seen in years:

>”Hip is transitory. Smart endures. Hip is defined by others. Smart is defined by intelligence. Hip is only for the moment. Smart is timeless. Hip is driven by trends. Smart is driven by performance. Hip is perpetually looking over your shoulder. Smart is making your own decisions. Hip is mango-chestnut gelati. Smart is chocolate ice cream. Hip is often difficult to define. Smart is always logically defensible. Hip is flash. Smart is substance. Hip is something that looks cool. Smart is something that works. Hip talks the talk. Smart walks the walk. Hip gets you a $300 a week cocaine habit. Smart gets you a big raise and the corner office.” 

He remembers it from a xeroxed handout in one of Brad Durham’s classes we both had at Art Center sometime in the very early 90s.

Amazingly, that only appears to be in Google once, on a seemingly abandoned Tripod page. Nothing in the Usenet archives and most non-Google search engines couldn’t even find the one tripod page.

Anyone remember where this is from or who wrote it?

*update:* also posted to Google Answers

Share |

link: Jul 12, 2006 3:44 pm
posted in: misc.

EXIF and the Unix Strings command

I got an email over the weekend pointing out a bug in my iPhoto Date Reset if an original image contained a single-quote in its name. Most all of my iPhoto images were imported from the camera, so I hadn’t seen this before, but I’m pretty sure I’ve already gotten it fixed.

While fixing that, I did a little revising of the EXIF sniffing script. I was using a one-line Perl snippet to scrape the date out of the first kilobyte of the file. Here’s the command broken across several lines

 perl -e 'open(IMG, q:[ABSOLUTE PATH}:);
 read(IMG, $exif, 1024); 
 $exif =~ s/\n/ /g; 
 $exif =~ s/.*([0-9]{4}(?::[0-9]{2}){2} [0-9]{2}(?::[0-9]{2}){2}).*$/$1/g;
 print STDOUT $exif;'

That worked, but perl one-liners usually need to be enclosed in single-quotes, since AppleScript was filling in the path, single-quotes in the name broke the script. I’m not that fluent in Perl, so there’re probably better ways of doing that.

But then I stumbled across the Unix Strings command. This basically does most of what I was doing. It scrapes a binary file (meaning non-text) and extracts anything that seems to be a string. The output from JPEGs often contains a bunch of gibberish, but right above the gibberish is every unencoded string from the EXIF header.

Using strings, sed for the pattern and head to trim, that somewhat convoluted perl script became this trim little shell script:

 strings [ABSOLUTE PATH] | sed -E -n '/([0-9]{4}(:[0-9]{2}){2} [0-9]{2}(:[0-9]{2}){2})/p' | head -n1

They’re both essentially instant on my computer so I’m not going to bother building a test to figure out which is actually faster.



« Previous PageNext Page »