OT: my reading list …

So I am off on a vacation tomorrow. Normally for our summer forays, I grab Gardner Dozius compendium called The Years Best Science Fiction. I have from year 14 to the current (year 28). Its just not summer without it. Well, its not out yet. Will be out on 3-July. Oh well… Ok … I … Read moreOT: my reading list …

[updated] Lumps …

[Update] Not all of the issues were with the supplier. I started investigating and found out that we deserved some of the lumps. Me in particular for not paying more attention to the situation as it evolved. I made the assumption that someone else was covering it, and I didn’t need to. As I’ve discovered, this was a mistake on my part.
The story is more annoying than I allude to here. We have some things to fix in working with suppliers, and helping them to manage their processes shipping to our customers, as well as our own processes.
Yeah, its pretty humbling to discover that a core assumption you made was simply not the case.
As I note, the buck stops with me. And now I know the various trajectories, I can make changes to prevent a recurrence.

Read more[updated] Lumps …

Security and legal implications of the data bandwidth wall

Again, hat tip to Alastair who pointed me at this article. At the most basic level, there are real costs, and real consequences to not being able to act nimbly, and leverage the bandwidth you need to perform the operations you require to successfully perform your job functions. These consequences could have some significant implications for legal cases. Or for terror threats.
What if you have a trove of data, that you have to act quickly upon? What if you can’t move it? Or can’t process it? Or cannot store it?
This is not a hypothetical situation. The US government, among others, has been targeting the MegaUpload founder for prosecution. In order for them to provide support for their assertions, they need to comb through the data on his servers.
This founder isn’t dumb, and his business is not just storage, but bandwidth. He knows how to design systems and move data.
The question I have is, whether or not the US government side of the equation does. And this is where the anecdote comes in.
The money quotes are

The US government has been ordered by a New Zealand High Court judge to immediately prepare to copy the 150 terabytes worth of data held on Megaupload servers seized by the FBI in order to turn it over to indicted founder Kim Dotcom.

According to an affidavit by FBI agent Michael Postin, copying just 29 terabytes had taken the agency 10 days. Postin said that copying all the data could take two and a half months. Even then, some of the data could not be copied as it is encrypted, Postin stated.

So … several possibilities.

Read moreSecurity and legal implications of the data bandwidth wall

Is flash a flash in the pan?

This article makes a case that it is. As with many articles about X dying, its worth asking if their argument makes sense.
Basically the point they are making boils down to density, resiliency, and other aspects. Specifically they point out that the fundamental flash design is inherently flawed … it self destructs after a while … wears out. So their argument begins, the denser the bits per cell, the fewer write cycles before the cell is unusable. We can work around some of these issues using intelligent writing, signal processing, etc. But it doesn’t change the fundamental physics/mechanics/chemistry of the wear-out process.
The argument continues, pointing out the relationship between increased bit density and decreasing numbers of program-erase cycles. None of what they speak of is false, faulty in logic, etc. They are essentially correct. There are severe limits to bit density, and part of the constraint comes from the chemistry/physics of the cell, the hysteresis associated with the P-E cycle, and the accumulating structural damage to the cell.
Again this is correct.
So let me take a brief anecdotal side trip.
In 1991, we didn’t have blue LEDs. Couldn’t build them in a way that would be useful. They would tear themselves apart due to threading dislocations within a matter of minutes of lighting up. Basically, the chemistry of the LEDs was such that if you were using them as an LED, chances are you were dumping enough energy into the junction to dislocate atoms and start building these physically large defects.

Read moreIs flash a flash in the pan?