I wish I could determine pi
"Eureka!" cried the great inventor.
Christmas pudding, Christmas pie
To the problem's very center.

Twenty digits (omitting the 3, which everyone can remember anyway), and I find it very memorable.

Don't be foolish. Of course Steve Jobs didn't pick the wrong tablet size. If Jobs and reality are ever in conflict, reality is wrong.

In particular it isn't news to Linus. Which is how git got its name.

I can tell the difference between a constant and a variable, and I know whether to put an apostrophe in 'yours'. If your IQ really is slightly above average, then the average is pretty woeful these days, and I'm glad mine isn't down there.

Your 'easy peasy' solution isn't that easy peasy after all if you apply some thought to it, of course. Because you have to know what time period to calculate your k over, and as the overhead changes you're either going to end up with too long a period, in which case you'll still be calculating based on old data, or you're going to end up with too short a period in which case your progress bar will jerk around frantically as the load on the system varies.

The real answer is the one that you dismissed; it's impossible to create an accurate progress bar representing the time taken by an operation, because things that change that time can (and will) happen during the operation, which will leave you in an inaccurate state for some part of the operation, or lead to counter-intuitive behaviour of the progress bar. Given that, the goal of the developer shouldn't be to create an accurate progress bar; it should be to create one that gives the impression of being accurate enough or change the way progress is represented so that it doesn't give the misleading impression that it's about providing an accurate time to completion.

All these constants go out of the window if anything else starts accessing the drive as well, of course, and they're actually variable based on file system and a variety of other things.

The relevant questions were asked of the jury. Hogan gave misleading answers to those questions.

If the jury had found for Samsung on every point, despite Hogan's possible bias against Samsung and their position, of course there wouldn't be a basis to demand a new trial. A better question might be whether Apple would be demanding a new trial had an anti-Apple zealot made it onto the jury by concealing their past history with Apple and then browbeating the other jurors into ignoring and misinterpreting law in a way that favoured Samsung.

And I think we all know the answer to that one.

See, you're proving the point that being able to write more than 140 characters doesn't prevent you from being an irrational asshat with nothing useful to say. Everything you say in your first paragraph is inaccurate. Everything you say in your second paragraph is unsupported and subjective.

In what way does imposing a 140-character limit constitute 'dumbing down'? You haven't done anything to defend that view, which isn't supported by reality. Yes, some people write dumb things in 140 characters. But some people write dumb things in more than 140 characters. Limiting the space does at least force you to consider what you're saying, especially if your initial attempt runs to slightly more than 140 characters, as you have to decide what is redundant and what isn't.

The truth of it is as always that dumb people will say dumb things, and smart people will say smart things. The smart ones will use Twitter in ways where it's appropriate and other resources where Twitter isn't the right tool for the job. The dumb ones will make incoherent anonymous personal attacks on people on Slashdot, apparently.

It's easy to fall into the trap of thinking that Twitter is just for inanity, because unfortunately that's the majority content of the internet in general. But it can be useful, and the 140-character limit is not inherently dumbing down. And I suspect you know it, which is why you haven't defended that claim in the slightest and resorted to pitiful anonymous ad hominem.

The ability to get a coherent message into 140 characters isn't 'dumbing down' by any measure. Verbal diarrhea can be every bit as bad.

1. Good rebuttal. No, seriously, proof by dogmatic assertion is great.

Of course it causes all these things. If you're refusing to modify existing code, then you can't refactor it to handle extra cases, which is going to lead to unnecessary duplication (and probably hideous cut/paste code). It will expand the size of the codebase, because this is what happens when you add code, which will eventually cause problems on some platforms (trust me - I've been there).

2. Turn in your coding license. Now. Except for a very small subset of coders working on very specialised projects and using formal proofs of correctness, anyone who claims their code contains (or should contain) no bugs when first written is a fool, and a dangerous fool at that.

3. That may be your experience. Rolling back version control history to find out where defects were introduced can be very useful, and if the tools are good enough (which they are) it isn't exactly difficult either.

As for the idea that you can't track all dependencies from the deleted code to the whole system, if that's true to the extent that you claim then your design is screwed.

Unfortunately bitter experience prevents me from being too nasty on this one, because too many times I've been through the process of having good test policies in place, followed by senior management decreeing that in order to meet deadlines, testing and documentation will have to fall by the wayside 'just for a few weeks'. I know it would count as justifiable homicide, but I still can't afford the court time. ;)

1. Not always true by a long way, especially when you're coding for devices with limited space. It can also lead to unnecessary duplication, overly convoluted logic to avoid modifying existing code, unnecessary duplication, poor performance and unnecessary duplication.

2. Bug fixes are dangerous? Really? That could have saved me a lot of time at my job before last. :D

3. If you think deleting code causes information to be lost, you need to review your source code control policies. Now. Yes, it can be dangerous to remove crufty looking old code, because it frequently contains years worth of minor fixes to deal with bizarre edge cases, device oddities and the suchlike. But you know what? Those should all be well commented in the code, and covered by appropriate tests that will ensure your new version works too. If they're not, you might need to review some other policies as well.

That's what the tests are for, surely? :D

Except we know where Apple stands on competition. They'd rather do it in the courtroom than in the labs these days. Which is why they're rushing to sue people for using black rounded rectangles, and rushing equally quickly to copy the 7" tablet form factor that they swore nobody wanted.

You'd be better off waiting for selenorhodanemod, azidodithiocarbonatemod or dicobalt-octacarbonylmod, maybe.

Well, it sure beats raising cattle.