We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

   Technology StocksThe *NEW* Frank Coluccio Technology Forum

Previous 10 Next 10 
From: Frank A. Coluccio7/1/2009 8:55:07 PM
   of 46820
The Statistician Who Ate Humble Pie

Nassim Nicholas Taleb | s+b | June 30, 2009

Why are business and economic forecasts so often wrong, and why can’t they be improved? In a new feature from s+b -- Author's Choice -- leading writers select and introduce passages from notable books. In this piece, Nassim Nicholas Taleb, author of The Black Swan: The Impact of the Highly Improbable, introduces an engaging lesson in business forecasting from Dance with Chance: Making Luck Work for You, by Spyros Makridakis, Robin Hogarth, and Anil Gaba.

To read the full analysis:


Share RecommendKeepReplyMark as Last Read

To: Frank A. Coluccio who wrote (30433)7/1/2009 9:00:28 PM
From: Jorj X Mckie
   of 46820
Hey Frank,
It's pretty simple, it is all 802.11 based.

The backhaul is based on a two radio 5.8Ghz/802.11a architecture that allows us to support many hops without significant signal degradation and nominal delay characteristics. I think I have gone over the specs before, but we are averaging about 20 milliseconds of delay to the working face. This works out to about .8 millisectonds per hop.

We are shooting 5.8Ghz down two entries per section and for each backhaul we are shooting 2.4Ghz down two adjacent entries. In other words, we are providing signal in 4 entries in each section (primary escape (fresh air), travel, belt and belt adjacent).

They are using polycom/spectralink voip handsets that again have the option to operate in a push to talk mode, ext to ext and ext to PSTN.

Tracking is based on the node association coupled with the RSSI values from the VoIP handset.

It isn't a wrinkle free network yet, but it's pretty darn close.

I know it is kinda boring that it is all 802.11 based, but the two radio backhaul is the key to the high performance multi-hop networks.

Share RecommendKeepReplyMark as Last ReadRead Replies (1)

To: ftth who wrote (30429)7/1/2009 9:01:04 PM
From: Frank A. Coluccio
   of 46820
Broadband Stimulus: You so 2000 and late

Susan Estrada | | July 1, 2009

As you probably know, the Notice of Funds Availability came out today for the BTOP and BIP (sounds like a kid's cartoon show...) billions. It was an interesting first read, mostly to figure out how they defined the key criteria.

Broadband is defined as 768 Kbps down and 200 Kbps up. The good news is that, with limited funds, this really keeps the focus on areas that really have crappy service, if any. The bad news is that providers can bid this unbelievably lousy service level and "comply" with criteria. The only hope we have is that there will be enough folks that bid higher speed levels than those who want to bid the slower ones and the slow ones won't get funded. Keep your fingers crossed.



Share RecommendKeepReplyMark as Last Read

From: pltodms7/1/2009 9:16:03 PM
   of 46820
Western Union, A piece of nostalgia, if you have time to relax and go through.

Main site:
western union alumni

(view an actual telegram from 1857 submitted by Ed Brown of Richmond, VA.)

(view an actual telegram from 1962 with description of the contents and handling.)

(The function of the RN office was basically ship-watching: to generate information regarding merchant vessel movements in New York Harbor to various clients: harbor pilots, towing companies, ship agents, government agencies, and so on. It was at the time the only privately-operated signal tower in the United States, perhaps even the world.)
--- ---
(Here is the index of all volumes.)

Western Union Technical Review was published from 1947 through 1969. .
Western Union Museum - an item which appeared in Vol. 19 No. 4 Technical Review, October 1965.

A stroll down memory lane - in photos!

Share RecommendKeepReplyMark as Last ReadRead Replies (2)

To: pltodms who wrote (30442)7/1/2009 10:58:30 PM
From: Frank A. Coluccio
   of 46820
You guys are killin' me, what... with Jim's reintroducing Albert LaFrance's archives, and now pltodms's bringing WU to the table, I'm never going to get over my reading backlog. Not to mention what all of this is doing to my ability to prioritize my time. Incidentally, I've not had contact with from Albert LaFrance now for about four, maybe five, years. We once chatted regularly both online and offline on the Compuserve Telecommunications Forum during the mid-Nineties. I've wondered from time to time how he is doing. I'll try contacting him and ask him to make a cameo appearance here if he's up to it.


Share RecommendKeepReplyMark as Last Read

To: pltodms who wrote (30442)7/1/2009 11:20:24 PM
From: Frank A. Coluccio
   of 46820
As with algorithmic trading, also known as program trading, today, here's an earlier example of the need to remain geographically close to the center of stock trading activity going back to the earliest days of the telegraph, albeit in order to satisfy a slightly different, yet analogous, set of transaction-affecting parameters:


"When the New York and Mississippi Valley Printing Telegraph Company (NYMVPTC) was organized in April 1851 in an office in the Reynolds Arcade building in Rochester, it was a small company with a big name. But it grew rapidly, and in 1856, Ezra Cornell, its largest stockholder, insisted that the name be changed to The Western Union Telegraph Company to indicate the unification of western lines with those in the east.

"As the renamed company continued to grow, it developed a major business opportunity in the provision of stock quotation services emanating from the securities markets in New York City. To exploit this opportunity, the company moved in 1866 to a shared, five-story building at 145 Broadway in downtown Manhattan, which it soon outgrew."

In contrast, today brokerage houses from around the nation and every corner of the globe are moving their 21st Century equivalents of the telegraph feeds to "shared, five- and fifty- story buildings" in and around downtown Manhattan to remain close to, sometimes on top of and in time within the same clouds as, ticker plants, only now those buildings are called variously collocation centers, Internet Data Centers and carrier hotels.


Share RecommendKeepReplyMark as Last ReadRead Replies (1)

To: axial who wrote (30437)7/1/2009 11:56:36 PM
From: Frank A. Coluccio
   of 46820

My last message to you indicated I didn't recall our earlier discussing the materials issues. My fault. I was suffering a moment of chronological dyslexia, focused on the earlier 2007 threads, not the new blogs you alluded to concerning the recent disaster at sea. For that one I had to select another set of filters, so you can disregard my request for additional pointers. Thanks.



Share RecommendKeepReplyMark as Last ReadRead Replies (1)

To: Frank A. Coluccio who wrote (30445)7/2/2009 12:43:31 AM
From: axial
   of 46820
My fault, Frank. Miscellany was the right word... I was including many of the issues you've brought up here, in one post: man-machine interfaces (aircraft control in unforeseen circumstances, programming issues), the use of advanced design processes (ie., CAD in design as with the Airbus 380), production delays because you're "pushing the envelope" in new designs (Airbus and Boeing), susceptibility of new materials (delamination of composites, Airbus and Boeing), suitability of composites in airframes that experience lightning strikes (no "Faraday cage"), susceptibility of fly-by-wire systems to lightning strikes, use of RF reporting as an adjunct to/replacement of black boxes (with possible implications for cloud storage), and finally, possible unforeseen RF interference issues near low-frequency naval communication sites.

Almost all of these issues were covered in the "Comments" section of the NYT blog about the mid-Atlantic Airbus crash. It's worth reading.

Others have arisen separately, as we follow the info streams associated with Airbus' and Boeing's troubles in getting their latest-gen aircraft to customers. They're both late, and the evidence is that they're both having problems because they're pushing the limits of current design, manufacture and (perhaps) safety.

On reflection, I don't see how you could possibly have understood all that. Mea culpa.


Share RecommendKeepReplyMark as Last ReadRead Replies (1)

To: Jorj X Mckie who wrote (30440)7/2/2009 12:43:59 AM
From: Peter Ecclesine
   of 46820
>>It's pretty simple, it is all 802.11 based.<<

>>the two radio backhaul is the key to the high performance multi-hop networks.<<

Tomorrow (PDT) the Aironet 1524SB should be visible, a mesh radio with two backhaul radios ;-)

Share RecommendKeepReplyMark as Last ReadRead Replies (2)

From: LindyBill7/2/2009 1:13:06 AM
   of 46820
When I'm dead, how will my loved ones break my password?

Tales from the encrypt: If you care about the integrity of your data, it's time to investigate solutions for accessing and securing it – and not just for the here and now

Fatherhood changed me – for the better. It made me start to think on longer timescales, to ponder contingencies and contingencies for contingencies. My wife, too. Now that our daughter, Poesy, is 16 months old, we're settled in enough to begin pondering the imponderable.

We're ready to draw up our wills.

It was all pretty simple at first: it was easy to say what we'd do if one of us died without the other (pass assets on to the survivor), or if we both went together (it all goes in trust for the kid); even all three of us (a charity gets the money). I thought about a literary executor (don't want to risk my literary estate being inherited by a child who may grow up to be as weird about her father's creations as some of the notable litigious cranks who have inherited other literary estates), and found a writer I like and trust who agreed to take things on should I snuff it before the kid's gotten old enough for me to know I can trust her not to be a nut job about it all. We found a lawyer through a referral from another lawyer who'd already done great work for me – I checked him out and he seemed fine.

Then we hit a wall.

What about our data?

More specifically, what about the secrets that protect our data? Like an increasing number of people who care about the security and integrity of their data, I have encrypted all my hard-drives – the ones in my laptops and the backup drives, using 128-bit AES – the Advanced Encryption Standard. Without the passphrase that unlocks my key, the data on those drives is unrecoverable, barring major, seismic advances in quantum computing, or a fundamental revolution in computing. Once your data is cryptographically secured, all the computers on earth, working in unison, could not recover it on anything less than a geological timescale.

This is great news, of course. It means that I don't have to worry about being mugged for my laptop, or having my office burgled (even the critical-files backup I keep on Amazon S3's remote storage facility is guarded by industrial-strength crypto, so I'm immune from someone raiding Amazon's servers). The passphrase itself, a very long, complicated string, is only in my head, and I've never written it down.

This is fantastically liberating. I'm able to lock it all up: my private journals, my financial details, 15 years' worth of personal and professional correspondence, every word I've written since the early 1980s, every secret thought, unfinished idea and work in progress. In theory, I could limit this cryptographic protection to a few key files, but that's vastly more complex than just locking up the whole shebang, and I don't have to worry that I've forgotten to lock up something that turns out to matter to me in 10 or 20 years.

I can even lock up all my passwords for everything else: email, banking, government services, social networking services and so on, keeping them in a master file that is itself guarded by crypto on my drive.

So far, so good.

But what if I were killed or incapacitated before I managed to hand the passphrase over to an executor or solicitor who could use them to unlock all this stuff that will be critical to winding down my affairs – or keeping them going, in the event that I'm incapacitated? I don't want to simply hand the passphrase over to my wife, or my lawyer. Partly that's because the secrecy of a passphrase known only to one person and never written down is vastly superior to the secrecy of a passphrase that has been written down and stored in more than one place. Further, many countries's laws make it difficult or impossible for a court to order you to turn over your keys; once the passphrase is known by a third party, its security from legal attack is greatly undermined, as the law generally protects your knowledge of someone else's keys to a lesser extent than it protects your own.

I discarded any solution based on putting my keys in trust with a service that sends out an email unless you tell it not to every week – these "dead man's switch" services are far less deserving of my trust than, say, my wife or my solicitor.

I rejected a safe-deposit box because of all the horror stories I've heard of banks that refuse to allow access to boxes until the will is probated, and the data necessary to probate the will is in the box.

I pondered using something called Shamir's Secret Sharing Scheme (SSSS), a fiendishly clever crypto scheme that allows you to split a key into several pieces, in such a way that only a few of those pieces are needed to unlock the data. For example, you might split the key into 10 pieces and give them to 10 people such that any five of them can pool their pieces and gain access to your crypto-protected data. But I rejected this, too – too complicated to explain to civilians, and what's more, if the key could be recovered by five people getting together, I now had to trust that no five out of 10 people would act in concert against me. And I'd have to keep track of those 10 people for the rest of my life, ensuring that the key is always in a position to be recovered. Too many moving parts – literally.

Finally, I hit on a simple solution: I'd split the passphrase in two, and give half of it to my wife, and the other half to my parents' lawyer in Toronto. The lawyer is out of reach of a British court order, and my wife's half of the passphrase is useless without the lawyer's half (and she's out of reach of a Canadian court order). If a situation arises that demands that my lawyer get his half to my wife, he can dictate it over the phone, or encrypt it with her public key and email it to her, or just fly to London and give it to her.

As simple as this solution is, it leaves a few loose ends: first, what does my wife do to safeguard her half of the key should she perish with me? The answer is to entrust it to a second attorney in the UK (I can return the favour by sending her key to my lawyer in Toronto). Next, how do I transmit the key to the lawyer? I've opted for a written sheet of instructions, including the key, that I will print on my next visit to Canada and physically deliver to the lawyer.

What I found surprising all through this process was the lack of any kind of standard process for managing key escrow as part of estate planning. Military-grade crypto has been in civilian hands for decades now, and yet every lawyer I spoke to about this was baffled (and the cypherpunks I spoke to were baffling – given to insanely complex schemes that suggested to me that their executors were going to be spending months unwinding their keys before they could get on with the business of their estates, and woe betide their survivors, who'd be left in the cold while all this was taking place).

Meanwhile, I'm left with this conclusion: if you're not encrypting your data, you should be. And if you are encrypting your data, you need to figure this stuff out, before you get hit by a bus and doom your digital life to crypto oblivion.
Tales from the encrypt: the secrets of data protection | Technology | (1 July 2009)

Share RecommendKeepReplyMark as Last ReadRead Replies (1)
Previous 10 Next 10