Blame for this issue lies soley at the feet of Verizon, At&T, Sprint, T-Mobile, etc.

In my case, the vendor is called Google -- I have a Galaxy Nexus. This phone is just two years old. No updates to 4.4, 4.3 is the last version supported.

Thus, I lay blame at the feet of the vendor -- Google.

PS: No need to tell me about CyanogenMod. I know about that. This is not about geeks being able to root their phone and replace the OS. This is about Google not doing proper support for a commercial product, a behavior that any other company in the IT business would be grilled about on virtual hot coals.

That's actually what it's like at "Mojave Spaceport". Hangers of small aviation practicioners and their junk. Gary Hudson, Burt Rutan, etc. Old aircraft and parts strewn about. Left-over facilities from Rotary Rocket used by flight schools. A medium-sized facility for Orbital. Some big facilities for BAE, etc. An aircraft graveyard next door.

SS2 has not completed testing and it is probable that there will be a need for redesign of one or more components. So, this is a really bad time to have the hand-off. Publicity isn't a good reason.

Right. It doesn't seem like a threat to say 'if you pass this then we'll have to actually do our jobs!' It just makes you wonder what they're doing now instead...

Actually, a lot of these games just use WINE's implementation of DirectX. This either translates the calls to OpenGL or implements a DirectX state tracker directly if you have Gallium drivers configured correctly. The same is true of a lot of Mac games. Good luck getting WINE to run on a console though...

Your typical GPU driver is about 10MB of object code. It contains a complex optimising compiler and controls a device that has complete DMA access to your computer. It is written with speed as the only significant goal. Making a GPU driver 1% faster contributes enough to sales to pay the salaries of several driver developers. Making the GPU driver more secure generates zero additional sales.

The shader code that's fed into this stack from WebGL is sanitised and is completely safe to run, assuming that your driver stack is 100% bug free. Still feel safe?

If you write a game that uses Direct3D, you can easily target Windows, XBox, and Windows Phone. If you write a game that uses OpenGL, then you can easily target all of the major desktop, mobile, and console platforms. If your game runs on a generation-old console, then it will run on current-generation mobiles as well. This gives you three markets: First release for high-end PCs, second for consoles, third for mobiles. You can get a solid revenue stream out of each one. You don't lose the Windows marked by choosing OpenGL, but you do lose every other market by using Direct3D.

That said, the APIs are so similar these days that you'll typically use some middleware to provide the abstraction. All of the important code is written in the shaders and these are much easier to port between GLSL and HLSL than they are to port between different GPUs and maintain performance.

Implementing this in the standard library means that the language needs to support pass-by-reference (which Pascal and C++ do, but C doesn't). This single feature does a lot to reduce readability. In C, I know that inc(x) is a function that does not modify the value of x, without reading any additional code[1]. In Pascal or C++, I need to look at the definition of inc() to know if x will be the same before and after the call.

An important idea at the core of readability for a language is the amount of code that I have to read to understand a single line. In any language that has pass-by-reference, this amount is larger than a language that doesn't. To achieve the same thing in C, I'd have to write inc(&x), and then everyone reading that code would know that x may be modified. (Note: the almost-equivalence of array and pointer types in C is a good counterexample where Pascal wins massively in readability).

[1] It could be a macro, but most coding conventions require macros that can't be used as if they were functions to be all-caps.

This would be true, except for two things:

• Lines with more than 66 non-whitespace characters decrease readability.
• Statements with more than 66 non-whitespace characters are common in most programming languages.

This means that you end up either with lots of continued statements or lots of overly-long lines in Python. If you have the former, then it's hard to see the indentation. If you have the latter, then you can see the indentation but the overall readability suffers. This can be fixed by using tabs for semantic indentation and spaces for alignment and an editor that supports highlighting tabs, but the Python style guides tell you not to do this.

There are some simple things where C is far more readable to a moderately experienced programmer. Consider the beginning and ending of blocks. In pascal, these are signified by begin and end. When you look at a chunk of Pascal code, they can be hard to pick out because they're just words in a sea of words. In C, you use the { and } symbols. These are symmetrical and the human brain has spent a lot of time evolving to be trivially able to spot symmetry because symmetry normally means 'predator about to try to eat me'. You can very quickly spot a column that has a { at the top and a } somewhere later (much more easily if they're aligned together and there's nothing else on the line). There were some studies done in the '80s that confirmed this, though sadly a lot of C coding conventions specify brace placement in a way that reduces readability.

The main strength of Pascal is that it forces you to think more than C. If you don't write what you mean in Pascal, it usually fails to compile. C will happily do... something. This level of redundant verbosity makes Pascal both quite a frustrating language for experienced developers and a great language for teaching. I find that people who learned Pascal tend to write better C code than those that didn't, but neither group has a strong desire to write Pascal.

There is no reason that we have to pick one and abandon work on the others. I don't see that the same resources go into solving more than one, except that the meteor and volcano problem have one solution in common - be on another planet when it happens.

The clathrate problem and nuclear war have the potential to end the human race while it is still on one planet, so we need to solve both of them ASAP.

'When I invented the term Object Oriented, C++ was not what I had in mind.' - Alan Kay.

Sure, there are going to be mediating forces in the environment. Melting is an obvious one. The positive feedbacks have been getting the most attention because they are really scary. It appears that there are gas clathrates in the ground and under water that can come out at a certain temperature. The worst case is that we get an event similar to Lake Nyos, but with a somewhat different mechanism and potentially many more dead. The best case is a significant atmospheric input of CO2 and methane that we can't control.

I don't think I have to discount Trenberth. He's trying to correct his model, he isn't saying there is no warming.

Thanks.

McKitrick is an economist out of his field. Trenberth and Fasullo cite many of their other papers and the publications to which they were submitted, but it seems mostly not accepted. But their conclusion seems to be that there were other times in recent years that the rate of warming decreased for a time only for it to return to its previous rate. I only see the abstract for Kosaka and Xie, but they state "the multi-decadal warming trend is very likely to continue with greenhouse gas increase."

I don't think you get to count a TARDIS twice just because it exists at multiple points along its history. If that were the case, then the universe contains millions of me!