In the UK definitely, and I believe in most of the rest of Europe.

There have been a few proposals recently to abolish SIMs. They were created back in the days of rented carphones so that people could move their phone number and contacts between phones easily. Now, they basically serve the same purpose as a WiFi password. It wouldn't be too difficult to provide the keying material in a QR code or similar so that when you get a new phone you just photograph it and have an app provide it to the baseband processor.

Carriers are very hostile to this, because if the SIM isn't a physical device there's no constraint on the number that can exist in one phone - you could easily have an app that would select the best rate from a dozen or so pre-pay virtual sims for whatever country you happened to be in.

Page 11 is talking about capital cost. The figure for nuclear is $7,591/kW, which is a lot more than some (although not the highest). But how does that work out over the lifetime of the plant? Assuming 100% uptime, that's 8,760kWh in the first year, so that's less than $0.90/kWh. If the plant is operating for 20 years, then that's around 4/kWh. Most nuclear plants are built with a 40-60 year expected lifespan, which makes the capital cost negligible over the lifetime of the plant.

The correct page to look at is Page 2, which gives the unsubsidised cost of electricity from all of the generating mechanisms. Nuclear is $124/MWh - that's lower than all of the other fuel sources in their 'conventional' bucket that have a little representative diamond listed (coal doesn't, and has a range that extends both above and below nuclear). Only Gas Combined Cycle is cheaper on average, and that's only when excluding most of the costs. Only utility-scale PV comes out cheaper overall, and you also need to add in storage costs if you want to use PV for a significant amount of grid supply.

That's fine too. The problem is building neither. The other problem is not fixing the design that was known to cause hydrogen build-up and explosions that breach containment in any problem scenario.

For every anecdote of a human taking over and saving the day, you can find a similar one of the human taking over and crashing. It mostly boils down to the amount of training that the pilot has had - and even the ones that end up crashing in situations where the automatic systems would probably have managed have had vastly more training than almost any driver on the road...

It's worth noting that there is one piece of automation in cars already that does give a different kind of driving license in a lot of places: automatic gear change. If you get a driving license in a car that has an automatic transmission then you can't drive manual cars with it, though the converse is allowed.

I've been playing a bit with GOGS. It has most of the things that I like about GitHub, but can be hosted locally.

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?

Code runs. It continues to run. And, over time, the requirements change. Maintenance is adapting the code to the new requirements. If you don't understand why this is important, then I can only assume that no one is using code that you've written.

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.

There are two problems. The first is that the OS allows you to run porn.jpg.exe having downloaded it from some random place on the 'net. I don't think that either OS X or Windows do: they'll both pop up a thing saying 'You are trying to run a program downloaded from the Internet, do you really want to?', which isn't normally something that happens when people try to open a file so ought to trigger them to avoid it (if it doesn't, then seeing the .exe extension probably won't either).

The second is that the OS allows programs and other file types to set icons at all before their first run. This also leads to confused deputy-like attacks where you think you're opening a file with one program but are actually opening it with something that will interpret it as code. The solution to this is probably to have programs keep their generic program icon until after their first run. If you double click on something that has a generic program icon, then you probably intend to run it...

This post needs a '-1 not even wrong' moderation. I started to write a reply to your points, but I honestly can't tell if you're trolling or completely fail to understand any of the parts of the hardware and software stacks involved.

Not really. Self has multiple prototype chains, Smalltalk and Java have only single inheritance. Both JavaScript and Smalltalk lack any declarative mechanism for defining classes in the language and do so by manipulating objects.

This removes the need for a shader language parser in the graphics driver. It still needs a compiler, unless you think the GPU is going to natively execute the bytecode. If you remove the compiler from a modern GPU driver, then there's very little left...