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)

All governments control what people do through their ability to hand out punishments.

It's not unheard of for a country to enforce punishments on personell or assets located outside their borders (see the guy who leaked israelli nuclear program) but it's pretty rare because it is diplomatically expensive and in extreme cases could be considered an act of war.

What they can more easilly do though is impose punishments for activities outside their border on personnel and assets that are within their borders. For example they can impose a fine on google, if google refuses to pay they can confiscate googles canadian assets.

Though the biggest problem on modern wireless networks is not "noise" in the traditional sense but interference between cells. The combination of such interference (which looks and acts similar to noise given modern modulation techniques) with the fading inherent in mobile microwave devices makes it very hard to achive more than a few bits/sec/hz on average across the celll.

Conventional MIMO helps a little but the close spacing of the antennas means the channels have low independence limiting the gains.

So that gives a couple of options. One is to move to higher frequencies where there is more bandwidth available and where signal strength tends to fall off quicker. Downsides are the cost of the hardware and if the signal falls off too quickly that limits the environments in which it can be delployed to very high density ones. The other one would be to implement cross-cell MIMO but that would require a heck of a lot of backhaul work.

Right, then you change ISP or your ISP decides to change your prefix, all your machines lose their v6 internet IPs and get a new set.

In an ideal world all your internal communications would be based on something else (names, link local or unique local IPs etc) and would keep working. In the real world what are the chances of internal services using internet IPs to talk to each other and breaking when those IPs change.

To move manufacturing requires you to either build a factory or find one with spare capacity, then you have to fit out that factory to do what you need to do, train the staff to make it with suffuicant reliability and so-on. For any non-trivial product this takes time, especially if lots of people are doing it at once and in the event of a country dropping off the supply map you would have to think about not only your factories but those of your suppliers and your suppliers' suppliers and so-on.

For beter or worse the world has become very interconnected. Taking out peices of that interconnectected puzzle would cause large shocks to the system not just "slight increases in price".

The "class E" space is marked as pasture on that XKCD map. It's unallocated in the sense that the powers that be haven't decided what if anything to do with it but it can't easilly be used because existing systems treat it as invalid. there have been proposals that it should be assigned to "large private intranets" (think: comcast's management network) but they never got approved (and given the need for upgrades to nearly all operating systems that work with the network it's questionable whether it would be better to just move to v6 for such networks).

The map also marks 10.0.0.0/8 (the largest block of private space) in green for some reason.

There also seems to have at least one error. The iana lists 7.0.0.0/8 as being administered by arin since 1995, yet the xkcd map marks it as pasture

In any case all the /8 unicast blocks are now allocated to either a RIR, a corporation or a special use.

Whats different is that in the v4 world NAT is the norm, in the v6 world NAT is strongly discouraged.

Nat has several impacts, one of them is obviously to conserve addresses but another is to make it so that the internal machines don't know or care what the outside IP is unless they go out of their way to look for it so they can do some tricks to make P2P work.

Whereas with v6 you are expected to assign public IPs to end machines (most likely via stateless autoconfiguration) In principle you can assign machines multiple IPs so that you can keep your local stuff in the same place when your ISP changes your global addresses. How well this works in practice I don't know, it's certainly something that would make me wary when deploying v6 on a small buisness network.

Windows 7 uses 6to4 and teredo by default under certain network conditions. I don't know if anythig has changed in newer versions.

For 6to4 iirc windows will enable it if it finds the machine has a public IPv4 address and no public ipv6 address, I don't think there are any other checks beyond that but few windows machines have public IPv4 addresses.

For teredo windows by default looks for a domain controller, if it doesn't find one it assumes it's on an "unamanged network" and enables teredo client behviour . If it finds one* it assumes it's on a "managed network" and disables teredo client (yes this behaviour can be overrideen but we are talking about default here). IIRC teredo client is only enabled if no other public v6 address (including 6to4) is available.

IIRC windows will also act as a teredo "host specific relay" by default if it has a non-teredo ipv6 address.

* Or something it thinks is one, i've had samba trigger it even though I wasn't using samba as a domain controller.

Afaict the result of trying to apply that policy to IPv6 was that people said "fuck you i'll stay with IPv4". The RIRs realised that the only way to get any chance of widespread IPv6 adoption was to make it at least as easy to get v6 PI space as it previously was to get v4 PI space.