Can I get some food that gives me lots of energy and no calories? perhaps you could sell it using your not-ad promotions?

The point is, getting around encryption is too costly to do it on a mass scale, so they can only really do it for the small portion of targets judged worth it.

It's like with door locks. Your door lock is good at stopping casual probing, but pretty much useless against a determined attacker. If a government agency (any government) decides that they really need to enter your home then they will enter. It may be with a warrant, with an armoured bulldozer or with a covert penetration team. But it's much too costly and much too risky to do so unless you have really good reason. They can't do it for every house in the city, on the off chance somebody might have something interesting stashed away somewhere.

Same thing with crypto: it may not stop them if they decide you are a high-value target. But it stops mass surveillance dragnets in their tracks.

One limitation of "the cloud" (also called "other peoples' servers") for many HPC applications is the data transfer costs. Transfering data in is cheap or free, but getting your data out again is anything but. Even if the cpu-hours would be cheap enough, it's usually cost-prohibitive to transfer a few tens of gigabytes of results out of the server and back home for each job.

It specifically says SatNav is allowed. But just like speed limits you still have a responsibility of your own. You can drive the speed limit and still be prosecuted if your speed is excessive for the current conditions. And if you use the navigation in a way or at a time when it is dangerous you're still responsible for that.

"hands-free holder or connected by Bluetooth"

Either or, not both. And headphones aren't mentioned at all.

But is that due to a greater risk of accident, or due to more people walking when the area becomes pedestrian-friendly?

So, we should see advertising billboards along roads removed because they are specifically designed to grab peoples attention.

I don't know about where you live, but here there are rules for how big and close they can be to a road, where they can and can't be placed, design limitations (no flashing lights, etc) and so on precisely for that reason.

Places I've interviewed with always pay the travel costs for the interview. At my current employer we regularly interview people from around the world and paying the costs is a given. If the NZ tech companies have not been paying it so far then no wonder they can't attract people from abroad.

With that said, NZ is fairly high on my list of places I could accept living in. Not exciting, but comfortable and pleasant.

Those rules sound pretty reasonable. If you use it in a way that takes your attention away from the road, it's forbidden. If it doesn't, it's OK.

It (or the Quadro version) will find itself in high-end workstations, and the card is probably also very reasonable as a lower-cost GPGPU accelerator.

If VR takes off you'll have plenty of other uses besides gaming. Scientific visualizations, vertical applications and whatnot. You'll want to support Linux as an OS just like NVIDIA supports it for GPGPU, workstations and embedded applications. That it gives Linux desktops 3D gaming ability is just a small bonus.

Fortran is still very much in use for mathematical programming.

Any language that could replace C and assembler would need to be statically compiled. So for Java, C#, Python and so on you'd have to define a subset that does not require a runtime parser or standard library. And you'd need extensions (or a static module system) that allows you to add assembler for direct hardware access. And a new compiler that can generate static code instead of the intermediate VM they target now. Not impossible by any means and probably a fairly interesting exercise too, but the languages would end up rather different and more restricted than the full versions people are used to.

Rather, I expect and hope that something like Rust will eventually supplant these languages in this space. Rust gives you the best of both worlds, with a statically compiled binaries and good memory safety at compile time, rather than runtime. You pay for it by having to be much more explicit about ownership than in these languages though. I've followed that project for a good while and it's clear that targeting small embedded systems is a struggle even for such a language; Java and friends would be much more difficult still.

FORTH is the rare language that tends to be even more memory efficient than C. The runtime interpreter is truly minimal (really just following a bunch of jump tables); you can have a small environment and application code in less than 8K.

On the other hand - and I say this as someone who likes FORTH a lot - you'd be hard pressed to find people claiming that FORTH is any higher-level (or easier to develop in) than C or assembler.

On the third hand - and off-topic here - it's quite a fun little language to use. Just like you can say that Scheme is programming directly in an AST, using FORTH is writing code directly for a stack machine. It's probably good for you to have a bit of experience even if you never do anything "real" with it.

The high-level VMs and the drivers to drive the specific hardware isn't developed by magical Low-Level Elves in Happy Rainbow Fairly Land. Every IoT device is going to have their oen special hardware stuff, and somebody needs to write the low-level code to interface with it. That is done in a combination of C and assembler.

Also, at volume the price difference between a MCU that can run a VM and one that can not will be on the order of tens of cents (either currency). If you plan to make on the order of a million devices, then 20 cents per unit will more than pay for a programmer that knows to use the small MCU over a Java hack that does not.