I'm sure people said the same about fly by wire when it was first suggested.

Yes it will likely take many years of experimentation, risk calculation, arguments with regulators and so-on to turn this from a concept into an actual product but I don't see any reason why it couldn't be delivered at an acceptable risk level.

Yes there is some risk of a total hydraulic or electrical failure but nevertheless the benefits from having larger planes than are practical with manual flight controls were deemed to outweigh those risks. Similarly the benefits from having a stronger more aerodynamic airframe and better visibility under normal conditions may be deemed to outweigh the risks of total camera system failure combined with a situation that prevents landing on instruments or a hazard that can only be spotted visually.

You will never reduce the risk of flying to zero, there always has to be some balance.

The documentation for using the module on your own board is available from the B2B section of their site. The connectors are off the shelf parts from hirose.

However while desinging and making a carrier for this will be much easier than designing with the imx6 directly it's going to be beyond most hobbyists. The connectors have a pin spacing of 0.4mm and massive numbers of pins.

At least here in the UK there is a lot of protection for consumers but far less protection for people buying stuff for buisness reasons. The tricky bit of course is distinguishing real consumers from failed scalpers fraudulantly claiming to be consumers.

no idea if the same applies in other countries.

If the markup per item is high enough then it may be worth paying people to buy them for you even for a single item.

Or depending on how exactly they are enforcing the one per customer limit just creating fake identities for yourself.

Not likely to happen any time soon, these arm SoCs simply don't have the memory busses to drive the number of ram chips you need to get that much ram. Heck even the mainstream desktop platforms from intel/AMD pratically max out at 32GB.

It's difficult to tell for sure without benchmarking individual applications. Having said that some general points

The odriod line like the Pi have USB based ethernet (though some odriod models have multiple USB busses from the SoC unlike the Pi) and no SATA ports, I'd avoid them for anything storage/network heavy. IIRC they are also lagging behind in terms of getting kernel support upstream. On the other hand when it comes to CPU power they are at the uppper end of what affordable arm boards offer.

The IMX6 based stuff (wandboard, cubox etc) seems like a pretty good all round choice, make sure you get a model with SATA if storage is important to you.

Most of the boards have some sort of GPIO but sometimes it's on awkward connectors or the software is immature. For some applications a board with a dedicated IO processor like the UDOO (or the arduino Tre when it's released) may be worth considering.

There is no such thing as a "generic arm board", there are a load of SoCs out there which while they share the CPU core design they are very different in pretty much every other way. The differences don't end at SoC level, there are many differences at the board level too. Most pins on a modern SoC are programable to multiple functions and if you want things to work then the important ones need to be programmed to match the hardware you have on the board. Enumeratable "plug and play" busses are they exception not the rule.

If you have documentation than porting the bootloader and kernel is likely to be hard work but doable, without documentation it is going to be extremely difficult. In my experiance kernels intended for andriod often have problems running regular linux userlands and vendor kernels are often way out of date. Also a serial console is needed to debug/troubleshoot this stuff and most phones/tablets don't have an easilly accessible serial console.

Once you have a usable bootloader and kernel then getting a generic linux system up and running is fairly easy. Of course if you want to use specific features of the chip (e.g. acceslerated graphics) then you will have more work to do.

Sometimes they do, sometimes they happen because a series of inputs while valid individually nevertheless result when combined in a value too big for an internal buffer.

So you have three options
1: write a validator and assume the validator produces "safe" output
2: don't validate the data and treat it as potentially hostile whereever it passes in your system
3: write a validator but neverthless treat the data as potentially hostile even after passing through the validator. That way you have to screw TWO things up to get a serious exploit.

So you have three options
1: try to work out what the maximum size is and use a fixed buffer of that size with no bounds checking
2: do the above but put in checking so that if you screw things up you get an error instead of memory corruption.
3: use a buffer allocated on demand of the size that is actually needed.

I presume by "lethal doses" they mean "doses that would have been lethal to mice not injected with the enzyme".

Sometimes what they do is set up in the US but in a different part of the US. This allows them to sidestep protectionist import restrictions while also drawing from a different labour pool and avoiding existing unions.

Toyota has a number of factories in the US but none in detroit or even in mitchagan.

Sure using a local design would be the ideal but that would require having a usable local design.

However local production has distinct advantages even if the design is imported. Firstly it makes it harder for other countries to cut off supply. Secondly it means that if a backdoor is to be slipped in it must be slipped in at a much earlier stage of the process making it harder to keep secret. Thirdly it means you are sending less money abroad.

On at least some boards the management port can also act as a regular network port.

So unless you take special steps to isolate the management interfaces from each other this sort of bug could easilly turn a single machine compromise into a much larger compromise.

Most public wifi services do not have useful encryption whether they have a password or not. Lets look at the wifi encryption/authentication options as they relate to public wifi.

open wifi: no encryption
open wifi with a web based login required to unloc internet access: no encryption
wep: encyrpted but everyone with the network password has the key and trivial to crack even if you don't have the network password
wpa/wpa2 in PSK mode: encrypted but everyone with the network password has the key, with public deployments the network password is likely easilly available to an attacker and also likely short/simple enough to easilly bruteforce.
wpa/wpa2 in enterprise mode: AIUI these theoretically give inter-user protection but I wouldn't like to place bets on how secure it is in practical deployments. Also has practical difficulties that make it tricky to use for public wifi.

The bottom line is that if you want security on public wifi you should route all your traffic over a VPN with strong authentication and encryption.

3: people working on client sites where the client is too paranoid to let outsiders on their network.
4: people staying in places which either don't bother to provide wifi, provide a terrible wifi service or charge through the nose for wifi.
5: people trying to find their way arround on foot in a new city (google maps is pretty good for this, there are probablly offline alternatives but they are nowhere near as ubiquitous)