I predate MIMO, so I had to take a brief refresher in what it is - and if I understand correctly what I read of MIMO (and what I read was correct - two important provisos!), MIMO seems to depend on using digital signal processing to be able to match the emit and receive channels, but it is using a physical separation (on the WiFi access-point side) of a few centimeters between antenna. I can see where you might find that kind of separation in laptops or even tablets, but not necessarily in a cell phone or an Internet-of-Things tiny appliance (like a light-bulb.) I couldn't tell how stateful the DSP part would have to be, or how long it would take to optimize for a particular set of signal paths. I also couldn't tell how well MIMO works out in a mix of MIMO clients and non-MIMO clients (like my IoT light-bulb). Can anyone offer any guidance?

QAM strikes me as (somewhat) incompatible with MIMO because using phase-shifted channels (QAM) (carrying different data) would be akin to space-shifted channels (MIMO) when the wavelengths and the distance between the antenna are similar - and the distance (and phase) between the MIMO antenna depend on the orientation between the sender and receiver of MIMO. But maybe that's just more DSPing?

Perhaps if you have real hardware for your data, and your data is static. But once you escape into the real world, you shouldn't be designing web applications that depend on L1 (or L2) cache.

800bps (call it 1600Ghz, using Shannon) is in the Far Infrared to (barely) mid infrared spectrum, and that's just base-band signaling (from a point-like source.) Doing any kind of modulation (to allow multiple channels for multiple simultaneous transmissions) is going to put that more firmly in the mid-infrared spectrum where things like the atmosphere appears to be opaque. I realize that this is a mass-media article, and depends on "... and then magic will happen" sort of science, but I don't see how this works (much less scales) without excessive speculation using ancient undergraduate digital communications classes too far.

But, to speculate WITH ancient undergraduate digital communications classes, I would think of things like this:

• Multi-point (physical separation) of channels, with individual channels at more "modest" speeds. Something like 1000 locations per. simultaneous customer being served 800Gbps.
• (As. per. above) very, very tiny cells, packed very, very, very, very closely together.
• Very, very tiny ceramic antennae.
• Extreme differences between upload and download speeds, like on the order of 10E6.
• A hot-spot would literally be that.

It makes sense when you understand the trust model, but that takes some explaining and isn't as simple to "civilians" as "check to make sure that the site begins with 'https://' or look for the 'key' icon provided by your browser." (Asking them to verify the host/site part of the URL is the advanced part of the explanation.)

It's rather like teaching people how to cook by telling them "be careful of hot burners, pots, and pans", but that is what we in IT have been doing to "civilians".

It's the organizations that put strong controls over their staff use of desktop computers that do this when they generate an image. Those organizations that value micromanaging what their staff can do more than getting work done used to (and may still) block much of the internet, etc. and in that context of tightening everything down so much that the threads get stripped, managing the CA root list makes sense.

There's already toddlers squeezing through the fence ... perhaps Rep. Gohmert's intent is "cull the herd" by having a moat.

• (A) Nearly worthless because a lot of the advice given out to "civilians" is that "https" can be trusted, "look for the lock", etc. More subtle advice (like check the URL, don't mistake "1" for "l" or "0" for "O", etc) are advanced techniques (at least for too many civilians.) Charging for SSL certificates - and the turnaround time it takes to issue them, install them, etc. meant that a certain class of quick-and-fast scams weren't practical. Cheap, fast, easy to install SSL certificates make this easier, thereby making the "https" indicator less valuable. (In short, use of "https" to "trust" a site is a gross mistake - but a mistake IT people have been advising civilians to do.)
• (C) I'm not a security researcher, I know a little about running a CA. A faked up CA isn't going to help someone trying to figure out what an App is trying to send over a SSL session, unless they're somehow able to replace the certificate and key in the App. Of course, a web app isn't going to have a certificate and key - but a smartphone/tablet app might.
• (i) On this, I think you're arguing that the CA system is even more broken than I am. I won't protest that.
• (ii) I'm not going to cry - but if there's enough money involved, Congress will do something stupid.
• (iii) I'm talking about "Extended Validation" certificates - which were an enhancement (via. another X.509 attribute) that suggested that the issuing CA did some due diligence (other than verifying that a credit card accepted a charge.) Whether the CA actually followed the guidelines is another matter. Is there a way for an outsider to audit this 'Extended Validation' for a particular Certificate? Without that, "Extended Validation" is just a way for CAs to charge more money.

Apps

Why do this?
So that:

• (1) App developers get used to designing and testing with https/SSL instead of gluing it in at the last minute AND GETTING IT WRONG
• (2) to encourage encryption and privacy, and to make the use of https/SSL less likely to distinguish between valuable communication and noise

Why not do this?
Because it:

• (A) makes the value of the https signifier on a URL / browser bar nearly worthless
• (B) will encourage App developers to send even more information to poorly secured servers
• (C) prevent researchers from determining what privacy-violating information an App is sending

What might happen because of this?
It will:

• (i) break the already weak link between certificates and the organizations they represent.
• (ii) kill the business model of the certificate authorities
• (iii) result in another somewhat meaningless revision of the "verified" certificate

Overall, it might work out well - but I doubt that App developers are going to bother so the major good reason will be ignored. App developers will STILL get it wrong, and even if they do set up https, that'll just encourage them to pass even more sensitive information to poorly secured APIs.

Web Browsers DID used to accept self-signed certificates (and certificates signed without a known CA - or cert-chain.) People just clicked through and accepted them willy-nilly. That was a poor security model. Although the existing security model of having a swamp of independent Root Certificate Authorities (per browser) is not too great either, but at some point you have to establish whom to trust - and for most of us, it's the browser vendor. (Some of us prune the Certificate Authority list and distribute the new list with software imaging technologies....)

So, a coffee maker is a robot? A rice cooker is a robot? Your definition would make "robot" synonymous with any kind of automation - or even a non-automated tool like a wheel barrow.

I've yet to see the usefulness of LinkedIn and I've maintained a profile since 2008. It seems to be a place where people set up a profile when they're looking for a job, but I've yet to notice anyone actually find a job through it. It seems to survive only because it has (somehow) tagged itself as the "business" or "professional" networking site, something that it fails to deliver.

What it does deliver - with some regularity - is compromised services. LinkedIn is the poster-child for why you should NEVER reuse passwords.

This was a hard question because I had to think about just what a robot was. I thought to work out by definition by example - for instance, a dish washer (or clothes washer or dryer) wasn't a robot. An elevator wasn't a robot. I'm really not sure if a self-driving car is going to qualify as a robot.

Google didn't help. Most of the robot definitions I could find there were either anthropomorphic (requiring a human-like body shape), or were nebulously described in terms of being "programmable for complex tasks". "complex" seems like a moving target to me.

For now, the idea that a robot is something that can carry out actions in a place unreachable, unsuitable, or unsafe for people seems like my best definition, That covers space probes, sewer & pipe crawlers, and even fighting robots (after all, what human would want to be in the mechanical death-pit with those rolling buzz-saws.) It even covers various industrial robots.

But that still didn't really help me pick an answer, so I decided to choose from the alternatives the one that would be most appealing as click-bait.

AT&T's competition is Comcast/TWC - which are distracted by a touchy-feelie orgy of merging. The Comcast/TWC merger involves the combined entity throwing off certain customers (like the entire state of Michigan), either to a minor competitor or to a made up placeholder company (Greatland Communications) which will outsource all of it's operations. Comcast/TWC isn't going to be competing with anyone while it's either planning for the orgy, or deeply engrossed in it. It'll probably be two years (or more) before AT&T needs to compete again.

This is just an excuse to lay back and collect rent on grossly substandard service. The ISP equivalent of an absentee landlord for properties in a poverty stricken slum.

There's also differences in administrative properties - such as access rights, how different users & schemas might interact, how database backups, replication, fail-over, mirroring, etc. all work. There's also subtle differences in some data types - such as what kind of date or time types are available, whether geographical information system (GIS) data types are available - and how much they might cost, etc. With older versions of MySql (5.1), you can have trouble joining the same table multiple times - unless you create a view on the multiple tables. I'm not sure if that's been fixed in the modern variations of MySql.

Like other's have remarked, if your database needs are modest then you can likely use most any database. It's when you have high reliability, high volume needs that you start designing things that tie you to a particular database system.

SQL is a "standard" much like "romance languages" is a standard...

Aren't most (if not all) "active shooter" type incidents of the sort that end long before the police have a time to show up?
Even if there are police officers on site, are there going to be enough officers to go after a shooter?