Is that a relative of T'Pol? I guess funding the Vulcan economy is only logical.

Apple now has 20% of the market and 90% of the profits. Measuring units is a bit like counting songs published on Spotify while ignoring the number of plays. For both those numbers to be true Apple must be making about 40 times more profit per sale than Android.

Company convinced of their own success, at least in their own marketing materials. News at 11.

I see you're a bit late to the party but I can inform you that here on /. it's been the year of Linux for some time already.

I use chip-and-pin today, do I really care if the "chip" ends up being a smart watch or cell phone? Not really. I just wouldn't allow it to pay without confirmation. On my own device I wouldn't mind using a fingerprint scanner instead of PIN either, just swipe my watch and push the "pay" button/scanner and I'm done. I have two debit cards today, I'm honestly not sure what the code on the second one is because I never use it.

Newton looked at the spectrum and saw that it contained six distinct colours to the human eye: red, orange, yellow, green, blue, purple. But his alchemist beliefs considered 7 to be a magic number and so wanted the spectrum to have seven colours. He decided that purple should be split into indigo and violet to reflect this, but didn't split any of the others (even where the difference is at least as pronounced) because it contradicted his mystical thinking.

If even Newton 'One of the smartest men to ever live' couldn't manage to keep his science separate from his mysticism, what hope do you think other religious people have?

No, sorry. A compiler is, in theoretical terms, a partial application of an interpreter to a program. In practical terms, a compiler transforms the input into some other form, which is then executed, whereas an interpreter executes the input directly. JIT compilation is still compilation. A just-in-time compiler is the term given to compilers that produce their output just before it is executed, as opposed to ahead-of-time (AoT) compilers, which produce it all up front, even if some paths are never executed.

There's some complication, because most environments that do JIT compilation also include interpreters that gather profiling information to incorporate into the JIT compiled code and to improve startup times. JavaScript implementations, in particular, often spend a reasonable amount of time in the interpreter because most web pages contain a load of JavaScript that's only run one or two times and the time taken to compile it is more than the time saved to execute it. Some have multiple compilers - JavaScriptCore from the WebKit project has an interpreter and three different JIT compilers that have different points in the space between compilation time and execution time - they'll recompile hot paths multiple times as they're executed more, with more optimisation each time. The key difference between the interpreter and compilers here is that the compilers are each invoked once on a segment of code and it's then executed without involving the compiler. The interpreter is involved every time the bytecode is run. It reads a bytecode and then jumps to the segment of interpreter code that executes it and then returns. The compiler takes a sequence of bytecodes, generates a fragment of native code to execute them, and then this fragment is combined with other fragments to produce a running program.

The shader compilers in drivers, however, are not JIT compilers. They are AoT compilers that are invoked at load time - often at install time. They don't compile the code just before it's run, they typically compile it once and cache the result for multiple invocations of the program. Some drivers (Windows and Android come to mind) have a mechanism that allows you to do the compilation at install time. Unlike most JIT environments, graphics drivers don't tend to use run-time profiling for optimisation, the bytecode exists solely for the purpose of providing an ISA-neutral distribution format.

Ugh, trust MS to fuck up a reasonable UI choice. On OS X, by default, it only happens for programs and requires you to close the dialog and then bring up the context menu for the program while holding a modifier key. You don't know how to do it unless you've actually read all of the way to the end of the dialog, so it generally protects people.

There are some interesting corner cases though, such as shell scripts. The file manager doesn't know if the thing that you tell it to open a shell script with is a text editor or a script interpreter, so may warn spuriously.

Sorry, but it has absolutely nothing to do with the real world. They're giving twenty people - ten in experiment group and ten in the control group 30 minutes to do a bit of analysis. And they measure minutes to apply a few changes, without any qualitative measure on how the code is growing. There's very little proof that the refactoring they did made any sense, the sample size is so low you'd never get reliable results and pretty much what you can conclude is that refactoring doesn't make hackjobs easier. Never thought so, that just involves finding the place something's happening and hack it. If it's a good idea, well... it works there and then.

Well somebody has to be the first at discovering something before somebody else can confirm it. And yes, in human years it might take a while to build another billion dollar project to do that. Science works on incomplete information, otherwise there wouldn't be anything to do science on. Has anybody independently verified the Higgs boson yet? All the exoplanets discovered recently? Probably not. That's always how it will be at the leading edge of science.

Somehow I find that implausible, I expect China to take the whole country or not at all. South Korea would be to worried about a conventional or nuclear counter-attack on Seoul to do much of anything while China could probably swoop in and install a new authoritarian regime that by NK standards would seem like heaven, all they need to do is bring them into the 21th century. After that I'll think it'll be a bit like Life of Brian:

Not if you're talking game performance rather than compiler performance I think. From what I understand games generally compile their shaders to native instructions long before they're used, it's not just-in-time compilation like when you download javascript on a page and do it on the fly as you execute, more like delayed traditional compilation until you can optimize for this particular hardware like Gentoo ebuilds.

However, the IR instructions is probably much simpler than the source language, for example Java has tons of classes but only ~200 opcodes. It would make graphics drivers not quite, but a lot more like CPUs running "assembler-ish" code instead of being huge graphics libraries. Basically you're moving most of what's OpenGL/DirectX today over into the application. Stallman might not approve but it might mean more AAA games being able to run on a thin OpenGL Vulkan shim than Mesa.

They've come full circle:
1. AMD announces Mantle, a low level graphics API which may give consoles an edge over the PC.
2. Microsoft panics and announces DirectX 12, aiming for pretty much the same thing.
3. Khronos Group panics and announces OpenGL Vulcan, aiming for pretty much the same thing.
4. AMD announces there'll be no public SDK of Mantle, use OpenGL/DirectX.

So in the end we'll probably have feature parity again. How important it is remains to be seen, outside of drawcall benchmarks it's unclear how much real world difference it makes, what is certain is that it exposes a lot more of the complexity to the developer. That of course gives you more room to optimize, but it remains to be seen how many will be able to take advantage of it.

On the bright side, it might actually mean there's less code that needs to be written and that open source might catch up a bit, it says it'll run on top of all platforms that support OpenGL ES 3.1 which might become a much bigger goal than OpenGL 4.x.