Oh, you thought any of that was going to stop? You're adorable.

No, the only things that are going to stop are the ones Republicans don't like.

This might as well be how Blackberry, Nokia, and Palm blew it. And I'm probably leaving off a few companies.

IMO it all comes down to arrogance about your own platform. In Nokia's case that was Symbian.

Go home. You're drunk.

GCC tends to overoptimize things to the point where the optimizations become self-defeating.

-Matt

They killed the goose that layed the golden eggs.

The uber-green and anti-nuke activists likely don't live there, and probably consider these folks collateral damage in their larger fight. Ideally, such activists would be up-front about the economic costs of some of their stands. Even beyond this now-impoverished small town, growing economies need affordable energy; that's just an economic fact. High energy costs reverberate through the entire supply chain, and raise the costs of virtually every good-and-service that normal people use.

Everybody wants clean air and water, but some green initiatives come with a serious price-tag.

No.

Not application backwards compatibility. Apple does not control that.

I'm talking about upgrading handsets to new OSes. Who does better than Apple?

"A lot of small publishing/design houses got burned in the transition from OS9 to OSX."

Kay. From my perspective as a user, it was pretty awesome.

Why is this so important to you? Seriously. Why do you care?

Good point. And, for my money, I prefer Apple's approach to Android's. We may get to the point where screens are high enough resolution I don't care about pixel accuracy, but we're not there quite yet.

Isn't it cool that there are several competing options in the market? I think that's a win, don't you?

Which is the phone manufacturer that has a better record of backwards OS compatibility than Apple?

I'm curious.

"it means China and other countries not covered improve their own standard of living (by emitting GHGs like there's no tomorrow) at our expense"

What do you propose to do about that?

I wouldn't call them desperate but I think they are seriously underestimated the intelligence level of their customers.

-Matt

I don't think the NSA has to break actual keys brute-force, but with information leakage it has been shown that data can be sussed-out of an encrypted stream (particularly an interactive one). Given sufficient leakage of known quantities, keys can be broken in much less time.

As we've seen just recently, even something as innocuous as HTTP compression over a SSL link can result in serious information leakage by anyone monitoring the size of the payloads.

Encryption streams, in general, require additional random data to be inserted into the stream and for the salt to be continuously modified (i.e. feedback) to remain strong. If one does neither of those things than the information leakage increases to the point where the keys can be broken without spending years of cpu cycles.

-Matt

I don't think you actually bothered to read and understand what I wrote. Try again. This time read my responses (or at least the first two) a bit more carefully.

I'm not in the least saying that transactional hardware support is bad. I am saying that programming to Intel's transactional interface FIRST, as your primary programming model, particularly for consumer applications, can lead to very undesirable results on hardware that doesn't support it.

Intel tends to implement first-run features with very weird restrictions and other goo that only leads to trouble down the line. Their HVM stuff being a really good case in point (AMD's is much, much cleaner, too bad AMD dropped off the performance curve a few years ago). There are plenty of other examples as well. There are very severe limitations to what Intel's (now TWO) transactional models can handle. Programming specifically to those interfaces is akin to the people who would hand-code assembly years ago for a 15% improvement over C and think it was good (hint: all that code was thrown out the window soon after).

Right now only very short locked code sections can operate reasonably under Intel's current transactional model. It just so happens that the most prevalent use of spin locks in modern architectures is with short locked code sections. Longer locked code sections do not typically use spin locks. So a reasonable first approximation of any implementation of Intel's model is going to be as a way to boost spin locks.

In a well written SMP application or kernel there are not actually very many places where conflicts create performance issues. In either Linux or DragonFly I can only think of two places: (1) Concurrent file descriptor access from a threaded program, and (2) Concurrent VM faults from a threaded program to the same memory location(s) (same underlying VM objects and same underlying page table page). And that's pretty much it. For applications it will depend on the application of course, I'm not completely dismissing it. I LIKE the concept. I DON'T LIKE the severe limitations imposed by Intel's model. It's that simple.

-Matt

Not to put too fine a point on it, but I've written hundreds of thousands of lines of SMP code on modern systems (and, frankly, I was doing SMP code with paired 8-bit CPUs over 28 years ago), so if you think you are somehow stating something in regards to my knowledge base, I would humbly suggest that you take your opinions and shove them down a toilet somewhere because you clearly have no clue whatsoever as to what I've been doing the last 20 years.

-Matt