Wish I had mod points to toss at you for this. Too many here - perhaps understandably - have no idea of the steps necessary to imagine, design, test, troubleshoot/re-engineer, certify, build, and ship a Real Working Product. If they knew even a fraction of what has to happen before something shows up at Newegg, they might have more understanding of why what you're trying to accomplish is so cool and potentially game-changing.

.
Kudos to you and your crew for getting even this far on a shoestring.

1.6 MPa = 232 psi (pounds/sq in). High, sure, but within the level you can contain in a soda pop bottle.

Would mod you up if I had points. And add:

Harlan Ellison: ""Gene Wolfe is engaged in the holy chore of writing every other author under the table. He is no less than one of the finest, most original writers in the world today. His work is singular, hypnotizing, startlingly above comparison."

In the very limited (3) cases that I've had to try and revive a client's dead desktop drive, replacing the PCB board from an identical model - usually purchased cheaply, used or new, online - has always worked.

The other advantage of this approach is that if the first drive becomes revivable, even a time, you now have a second same-capacity drive to transfer the data to (using intermediate storage media if in fact it was the PCB that was the problem and you can only get one drive working at a time).

If it doesn't work, you're no worse off and still have a replacement drive to load data from your (hopefully recent) backups.

And if anyone knows how to take what should be a simple, straightforward, technical discussion and turn it into a MS vs Google flame war, it will be Slashdot commenters.

I live in Seattle, you insensitive clod!

(where many residents were still using their furnaces as of last week, and today's the first sunny and warmish-day in what seems like a month)

(Gee, thanks for the civil reply. You gain a lot of karma points that way, I'm sure.)

In any case, the contention was not (if you read a bit more carefully) that a single-user metric should count the same user twice. Obviously. Rather, the argument is that at a single-user metric is not really a good one to measure 'market browser share' at all, because it overstates the usage by low-use, occasional users, and understates usage by high-use, constant users. As a website developer, sure, I'm interested in both per-visitor and per-page metrics - but the latter is much more important to me because it more accurately tallies who's using my site the most.

But since your position in Microsoft management is pretty secure, that distinction's probably not important to you.

lol; "better" not "netter". Though that's that's probably true, too. :)

Even if you think of this (as another commenter has it) as a "unique workflow", I think it misses an even greater source of error in NetApplication's approach. Consider:

- My grandma uses IE as preloaded on her Windows PC and goes to, say, Gmail (yes, at least I got her off Hotmail :) once a day to get her cat pictures. She's counted as a single unique visitor by NetApp.
- I go to Gmail with Chrome in the morning and live on it all day, loading hundreds if not thousands of pages during that time. Despite that, I'm _still_ counted as a single unique visitor by NetApp. Even though the "eyeball time" (the real "browser usage") between me and grandma is vastly different.

I think the "single user" metric has an inherent biased towards low-usage, unsophisticated users - the ones most likely not to have replaced IE as loaded on their systems. So it makes sense (not even counting the geo-weighting issues) that they'd have IE's share much higher than anyone else's. Though no single approach is perfect, that's why I think of the two StatCounter's is netter. (And frankly it's always been more in line with other metrics - like the Wikimedia stats - that seem unbiased and cut a wide swath of the Net. NetApplications has always been the outlier.)

Original "has": http://icanhascheezburger.com/2007/01/11/i-can-has-cheezburger-3/

"Haz" would have been way funnier here, though.

"I CAN BE HAZ MAT?!"

I can has worldwide pandemic?

That $70 is for "Basic Phones" and so doesn't apply to anything Verizon deems a "smartphone". Which is pretty much everything that can deal with mobile data in a non-trivial way. Not a valid comparison unless you're my grandma.

It's pretty obvious the new pricing is a "screw the single user who wasn't using a bazillion bytes of data or talk time" plan. Maybe it's Verizon's way of saying I should get hitched? My mom would like that, for sure.

Or maybe they're abandoning the singles market in dense urban centers to Sprint (about the only place Sprint works well, so it plays to their strengths).

Honestly, I was thinking about switching to Verizon when my AT&T contract ended later this month or when the next iPhone came out. It would have only been about $5 more. Now it will be $25 or more greater. Non-starter for me, and I suspect many others.

For certain definitions of the the term, sure, it's both; for others, not.

"Mistake" was put in quotes in what I wrote because of the original poster's implication was that all bugs were things completely avoidable, serious failures that were something the programmer should rectify for free and that not doing for a customer so was immoral/improper - like mis-assembled car that should have its manufacturing defect(s) covered under warranty. Custom-written software isn't in the same category, IMHO. If you want perfection, you have to pay for testing to perfection - not something most clients are willing (understandably) to do.

I sure would not want to program for you. In 25 years of independent development, I only saw the bizarre belief you express from a single one client. I gave them two alternatives:

(a) "After the initial acceptance period, we'll fix all bugs for free...but of course you need to pay my team for 5-man-weeks of testing and QA time so that we can both be assured it's perfect first", OR
(b) "You'll pay us time and materials to fix any significant bugs you find, but we'll only charge you for 5-man-days of testing and QA time beforehand and you'll work with us to discover any others we missed as you use the software."

Needless to say, not being stupid, they took option (b) and we probably only ended up charging them for a few minor fixes.

A software bug is not "a mistake". It's an inevitable part of the process, one that can be mitigated by good design, good coding, good management, and good testing. But all of those things take time and money. There's no magic zero-cost shortcut to perfection in any non-trivial project.