Forgot your password?
typodupeerror

Comment: If you don't like your own food... (Score 3, Insightful) 304

by 1984 (#34136238) Attached to: Apple To Discontinue Xserve

Well I guess that answers the question about what *didn't* go in that big new data center.

In a previous life several years ago we looked at buying 300 of them to run Yellow Dog (yes, several years). They were nicely engineered units, but Apple clearly wasn't series about enterprise sales. They offered a kit of spare parts for field replacements, but not much beyond that.

Comment: This is a good idea. (Score 1) 266

by 1984 (#33425814) Attached to: Flight Data Recorders, Decades Out of Date

If you stoop to RTFA you'll see there's a lot of sensible stuff in it, with the two main points being: flight data recorders record a limited (25h) sliding window of data, and that you have to go and fine them and sometimes this isn't possible. Both those make crash investigations harder than they might be, and delay the results. If you could get results more quickly and reliably, that'd obviously be a good thing.

The author doesn't suggest a sudden wholesale replacement of black boxes, but a supplementary mechanism for also transmitting data in real time. That data could be aggregated and mined without waiting for a crash to occur, potentially providing a much richer source of information about aircraft behaviors in both normal and abnormal operation.

He confuses the point a bit in some of his summary sentences by implying that he *is* talking about a prompt wholesale replacement of black boxes.

Comment: Re:Know your colo contracts (Score 2, Informative) 305

by 1984 (#33258804) Attached to: Stupid Data Center Tricks

That's what I was getting at -- it's not as if it's a simple case of blowing on the end to clear out some fluff. Detailed procedures, including not least unplugging the other end of said cable to make sure it's unlit, which would include finding said other end. And likely go and get various the items required for the cleaning procedure. Which would add up at least to a conversation or two, and perhaps one with us the customer discussing the topic. I'm not disagreeing with cleaning of fiber cables sometimes being necessary, but I didn't for a moment believe all that had actually gone on.

Comment: Know your colo contracts (Score 2, Interesting) 305

by 1984 (#33257604) Attached to: Stupid Data Center Tricks

I had one a few years back which highlighted issues with both our attention to the network behavior, and the ISP's procedures. One day the network engineer came over and asked if I knew why all the traffic on our upstream seemed to be going over the 'B' link, where it would typically head over the 'A' link to the same provider. The equipment was symmetrical and there was no performance impact, it was just odd because A was the preferred link. We looked back over the throughput graphs and saw that the change had occurred abruptly several days ago. We then inspected the A link and found it down. Our equipment seemed fine, though, so we got in touch with the outfit that was both colo provider and ISP.

After the usual confusion it was finally determined that one of the ISP's staff had "noticed a cable not quite seated" while working on the data center floor. He had apparently followed a "standard procedure" to remove and clean the cable before plugging it back in. It was a fiber cable and he managed to plug it back in wrong (transposed connectors on a fiber cable). Not only was the notion of cleaning the cable end bizarre -- what, wipe it on his t-shirt? -- and never fully explained, but there was no followup check to find out what that cable was for and whether it still worked. It didn't, for nearly a week. That highlighted that we were missing checks on the individual links to the ISP and needed those in addition to checks for upstream connectivity. We fixed those promptly.

Best part was that our CTO had, in a former misguided life, been a lawyer and had been largely responsible for drafting the hosting contract. As such, the sliding scale of penalties for outages went up to one-month free for multi-day incidents. The special kicker was that the credit applied to "the facility in which the outage occurred", rather than just to the directly effected items. Less power (not included in the penalty) the ISP ended up crediting us over $70K for that mistake. I have no idea if they train their DC staff better these days about well-meaning interference with random bits of equipment.

Comment: Why the shock? (Score 1) 487

by 1984 (#32847458) Attached to: Open Source Music Fingerprinter Gets Patent Nastygram

I don't agree with software patents. I think it's a silly idea. Also, there are Shazam alternatives already available, ostensibly without infringing on the US patents now owned by Landmark LLC.

All that aside, though, this letter shouldn't come as a surprise. This guy didn't discuss alternatives, shortcomings, possibilities or even come up with something equivalent but independent. He called his post "Creating Shazam in Java", referenced someone else's detailed posting about how Shazam works, then went on to suggest sample code. Having some familiarity with the Shazam algorithm and having read the patents around it and the original white paper by Avery Wang, the linked article by Bryan Jacobs is very much a lightened up translation of the gory details of Shazam. The code is, it is stated, a rough guide for how to do that in Java (note he glosses over the FFT).

So it's not a surprise that Landmark is after him on patent grounds. The fact that such patents are allowed to exist is -- to me -- a problem. But the shock and whining about this particular case is naive. It's really, really obvious that this is something that would fall foul of that legal mechanism.

Comment: Seems like a non-issue, RTFA (Score 4, Insightful) 435

by 1984 (#32806300) Attached to: Ban On Photographing Near Gulf Oil Booms

I'm a hobbyist photographer and videographer, and I've been hassled for ID before when shooting in a public place. I read plenty of stories about photographers being harassed improperly, and reading the article I don't think this is one of them. They started at 300ft, which was silly, and scaled it back to 65ft when called on it. Leaving aside the who and why, 65 feet doesn't make this stuff hard to photograph. Even with a 200mm lens on a digital SLR (especially crop sensor) you can get very serviceable shots of "what's going on" at 65ft. Professional press photographers on assignment usually have a healthier complement of lenses than that, before considering telconverters, cropping in on the subject and so on.

If the story is something highly specific to do with equipment and handling of it then perhaps you need an even bigger lens or to be closer to the subject. But if you're taking shots of how they're laying out booms, who's involved and so on, 65ft isn't a big deal at all. Seems like a not unreasonable tradeoff to keep people from getting under the workers' feet. The subjective standard I'm applying here is does the restriction make it likely we'll not find out something that the public interest demands should be disclosed? No, it really doesn't.

Comment: VW's luxury brother already poked fun at this... (Score 5, Funny) 265

by 1984 (#32189400) Attached to: Stanford Robot Car Capable of Slide Parking

... before it even happened. A few Lexus introduced the automatic parallel parking feature, and Audi responded with this:

      http://video.google.com/videoplay?docid=3593724097279407250#

Amusing retort. Irrelevant for 99.9%+ of people, but sold right into the person you'd love to be.

Comment: So Google... (Score 4, Interesting) 187

by 1984 (#27021203) Attached to: Face Recognition — Clever Or Just Plain Creepy?

What exactly did everyone think "Don't be Evil" would mean once the company went public, grew up and grew larger?

Not that this is necessarily anything premeditated and sinister, but notice how thinking through whether something might seem weird or discomfiting isn't at the top of the list?

Polymer physicists are into chains.

Working...