Be careful - the europeans will mod you down for such heresies! Allah forbid that we have informed facts. I learned that while living in France while attending HEC and UParis...

Oops I did it again... darn.

Oy vey.. can't they just get it out? Europe GOOD, America BAD.

But I counter that lots of places in Europe have a very low percentage of renewable energy sources, there are many gaps in production. France and Germany still utilize quite a bit of nuclear energy, Italy is 90% non-renewable, and most of the biomass/biofuel systems still require a lot of non-renewable energy (even though they are counted as 100% renewable in such studies just like corn ethanol is promoted in the USA). They also ignore the enormous amount of energy and waste used to produce wind and solar generators.

Same is certainly true in the USA - being a far larger landmass it will take far longer to develop such programs.

So certainly it's a step in the right direction, but I wouldn't let such a study inform my decision-making process. The facts remain that the tech and investment necessary to keep moving us all forward to a renewable energy economy necessitates a market shift towards electric vehicles.

Oddly enough, the most likely reason they're putting in a plant in the USA is...... (wait for it).... to sell into DOD. You get an instant +5 karma by manufacturing in the USA for contract win purposes.

ffmpeg supports both Avid DNxHD and Apple ProRes codecs, REDCODE decode, EXR, DPX, and all the best unencumbered formats as well. This means that most pro video and film production can integrate into OSS with much more ease than ever before. It also means that proprietary data lock-in is on the way out.

Way to go ffmpeg!

Ah, that makes good sense! Thanks for the clarification.

Not surprising at all, as PA SEMI was founded by Daniel W. Dobberpuhl.

Daniel Dobberpuhl had his hand in StrongARM and DEC Alpha design - both hand-drawn cores which to this day command some respect in chip design circles I'm told.

Anyway,

Who knew Wichita was such a practical HOTBED of IEEE membership?

Moreover, a kgdb session could likely track this bug down. I'm going to guess that it's a simple locking bug, likely in the intel drivers. Compiz or whatever is performing some operation out of synch with what is "normal" activity and trying to perform a double-lock.

Since cursor operations are tied to a hardware interrupt they still continue to operate.

Another possibility is that the kernel is running at a higher interrupt level in the driver after wakeup, and not locking the iommu/register area away from userspace operations - thus the graphics chip state is getting corrupted and goes into a unknown hardware state. Switching video modes is causing an interrupt which awakens the chip again, and restarting X causes the graphics unit to reset properly.

Yes, I used to be a graphics driver developer for X long, long ago.

I can assure you that nearly every redneck out here has either iPhone or high-end Android.

USDOT supports your view as well... essentially drivers are going to drive at a their own speed and accidents stay essentially flat no matter what the speed limit is.

http://www.ibiblio.org/rdu/sl-irrel.html

No it's not. Sorry - but average speeds are 70 mph (limit is 60 mph) in Dallas and Houston. There are a few outliers shooting through town after dark, but it's not the norm.

You're correct on the rural highways however, as I routinely see people hitting 80. There are far fewer accidents, but the accidents are on average much more deadly. However I think that accident rates will go down as the difference in speeds between the slowest and fastest drivers will narrow.

Up until 1991 you could get on a plane in the USA without any id. I could pay for a flight in cash and get on it a few minutes later, without any inspections. Seriously - did it all the time. It wasn't until the first Iraq war that they started asking the security questions and performing metal detector tests for everyone.

Seriously... the ability to stitch together a thousand different versions of "the same" virus using pieces of code commonly available on every system would be overwhelming and devastating to a target.

No, you don't send the generator in the payload (unless you have it generate itself first), as it would be easily detected and reverse engineered. You send a thousand viruses at a set of targets and there will be no virus scanner able to handle 100% of them without dynamic analysis. With a zero day exploit and root kit implementation this is potentially devastating. With some careful engineering you could sometimes defeat dynamic analysis as well.

What makes current viruses largely ineffective is that you can only make a few effective ones in a limited time period. You need a large team of experienced developers to be able to build such a critter. Iterating new payloads takes lots of testing and QA. With this sort of tech you build one good virus blueprint and out comes thousands of different little beasties with a good probability of success. Each one is different!

This stuff is dangerous - atomic bomb dangerous if it gets a proper engineering.

I'm with you... basic office usability was getting pretty good in 2005 on Linux - and then they tore it all apart and it got much worse. The piecemeal approach of integrating compositing into X11 was a failure to me. They ended up rewriting lots of code, over and over again to support new X extensions and such. Every project needed a new backend every 3 years. IDE projects were continually started and abandoned. GUI projects threw away perfectly good, working debugged code over and over again. So much wasted effort. I quite.

I was an XFree86 member, worked on DEC Alpha drivers and did some gnome and glibc development also in 2000's. I watched XFree86 flounder and burn. I absolutely LOVE the Unix side of Linux - it works better than any Unix ever. But the GUI stability, driver stability and API stability has always sucked.

It would have been far better to just build a compositing OpenGL based window system on FBDev, with X11 as an add-on. We could have done it in a year, as the work was already done in OpenGL anyway - but our insistance on REBUILDING the same crap over and over until we arrive at the solution WE ALREADY KNEW was asinine.