Adding the tax after helps keep it down. Compare the sales tax rate in the US where its added in clear view of the consumer vs in Europe where it isn't? In the US it ranges from about 0% to 13% with most in the 4 to 8% range. VAT in the EU is 15 to 27% When its hidden, its much easier to hide increases and it tends to be done in greater steps as well.

The keys for an Aussie Police system have been out for at least 2 years according to people who were at Ruxcon this year talking about this very topic.

The radios sent lots of known plain text at the end of every call and its trivial to get the encrypted data. The rest is lucking into a key for newer systems or trying them all for some of the older systems.

I have no idea what they are doing but I would like to know. I do know that the single fiber GPON that is being deployed here is just as future proof as the stuff I was putting the in ground in the mid 80s and splicing with xacto knives in the early 90s... as in its going to be ignored.

I can't imagine that Google would try anything other that dual fibers to a switch and then run it from there. There are gigabit switches you can get that can hang from a cable.

I want to put part of a RAID array on the other side of town.

"Once you have fiber to the house, you can offer what ever speed you decided to offer."
Why do people keep repeating this lie? PON has been in use for about 2 decades and in that time has speed up 40x from the first production stuff to the fastest in a lab. Point to point fiber has increased 20,000x times in 4 decades based on the fastest gear I can buy over the counter in town today.

Most FTTH is some sort of passive optical which is shared with somewhere up to 4096 other customers and one strand. This is not the yellow multi-mode fiber pairs that you can slap a 40 gigabit transceivers on and make it go faster.

Since its a single fiber, when the ONT (i.e. fiber modem) turns on its laser to talk to the head end far away, it blinds its own receiver. It also blinds the receivers for most of the other nearby ONT as well and there is a delay before they can start seeing packets again. Some companies have tried to get the transmit on one color and receiver on another but that makes things very expensive. Some places have tried optical filters with other problems but most just use the cheapest lasers they can get and live with the self-blinding problem because they are building cable TV networks.

There is also the packet coordinating problem. An ethernet packet on the 25 Gbit types PON systems is about an inch long and travels a bit faster than half the speed of light. To get 100% utilization out of your upload bandwidth, you have to coordinate the low cost optical modems to about a tenth of a nano second. The optical length of 10 km of fiber hung from poles changes by tends of meters as the wind blows it around.

PON and its derivatives are broadcast networks that started out life as a way to reduce the cost of large cable TV networks. Its not a peering network and I'm not sure it will ever be.

The network of the future will mirror the current telco networks with a pair of fibers to a central switching fabric.

Most major fiber runs tend to follow highway, railroad or pipeline right-of-ways. KC is in the middle of all 3. As you mentioned, its along the Texas-Chicago route but also a cross roads for the east-west as well as links to the North West. St Louis is about as well connected but since it has fewer oil pipelines and less fiber along the rail lines and a mess of governments, I could see why it KC would be a much better choice for a pilot project.

1950's computer science used a model of "input/output/processing/storage" and it worked well for most projects but it also kept programmers minds on data flow. Find out how that data flow can be abused and prevent it. The simpler a system is, the few bugs it will tend to have.

Also don't use systems that want to load up hundreds of packages to do something simple. Software complexity is the root of all security issues.

Most programmers use the C { as just part of the loop. The first C compilers treated the { as a "create a stack frame" and } to close the frame.

Bit reduction in hashes is vital for many of their uses and that will result in collisions.

There are lots of silly assumptions about crypto that just aren't true. For example thinking that there is a 1:1 mapping of keys. As far as I know, all public / private key crypto not 1:1 but is 1:N with where one private key can have more than one public key and it may be N:M. Since someone is going to argue the point... here is some RSA code

I know of a charity that was used to test lots of card numbers and the bank happily took the money back and issued a charge back which was a real pain for the charity since they had already spent the money so now they can't help as many people.