Not quite true, the ISM bands are Unlicensed bands, not unregulated. In order to sell equipment used to transmit on these bands, the systems must be type approved. Part of this type approval process includes ensuring that the equipment in question will not cause undue interference to other users on the band. To me, sending rogue de-auth packets constitutes interference.

In Meraki's Air Marshal Whitepaper, they explicitly state on page 8 that Unauthorized containment is prosecutable by law (subject to the FCC’s Communications Act of 1934, Section 333, ‘Willful or Malicious Interference’)..

I actually had this particular issue affect me. As a volunteer, I operate a community-wide network, including a widespread wifi network, at a retreat centre high in the mountains of WA. At this time, there is a significant mine remediation project going on in our valley, so we have leased out several buildings to the construction companies, who setup their own Meraki system. Unfortunately, they enabled Air Marshal, which then went on to attack our wireless network. Despite running WPA-Enterprise on our network, it was still successful in attacking our networks, and rendering them nearly useless. In the end, we had to flex our muscles as the landlord to get the feature disabled.

In my mind, the ability to attack adjacent networks should be illegal, and Cisco and the others should not be permitted to sell this technology to the general public. Rather the systems should simply alert on the presence of other wifi networks, and assist in locating them. Also, the wifi standards should really be updated to fix this type of vulnerability... in a WPA-Enterprise environment, clients should only respond to a de-auth packet encrypted/signed with the session key between the client and the AP its connected to.

Huh? How would accessing the programming tell when you were on vacation? The program/configuration that controls your stuff is stored on the device itself, not stored/run in the cloud. The only information stored in the cloud is how your remote/system is configured, not its state. Once you configure the device, if you're exceedingly paranoid, you can always firewall it off from the outside world, and it will continue to work.

The programming of the system is cloud based. The communications between the remote, the base, and your device occurs locally. The only ongoing cloud stuff comes in if you want to be able to use the app on your smartphone to control certain devices while you're away. If you don't want this functionality, nothing stopping you from firewalling off the base so that it can't communicate with the outside word.

Eh, not everyone does. I quite enjoy driving, I don't even mind being stuck in traffic, as long as I've got the CBC or NPR on the dial...

That said, I keep (handsfree) call short and sweet, and the only time I would ever check/send a text is stopped at a red light (which is still a ticketable offence here).

Did they find that? I'm sure we all want to meet the doctor... ;)

Vancouver, BC has a very extensive trolleybus network, with 265 active trolley busses. The system works quite well, and the busses do have battery backup, so they can go off the wires for short periods of time (to go around road construction, accident, pass a parked bus, etc...). As for the wires being ugly? I dunno, they're just part of the fabric of the city. There are some intersections though with rather impressive spider webs hanging over them. :)

Correct. We basically buy 1.6MHz on the satellite, and have our own private connection. Because it's SCPC (Single Carrier Per Channel) latency is typically 550ms, and the high priority QoS queue has very little jitter (on the order of 5 to 10ms). This makes the voice quality near toll quality, and very reliable.

For reference, over the past 24 hours, the folks on site downloaded 6GB and uploaded 2GB (including all the voice traffic), and this was a light day. I've had days when it's closer to 10GB downloaded (See patch tuesday). Anyhow the goal is to make it reliable, albeit slow, and in that we mostly succeed. I also deploy some measures to combat things like bittorrent and other P2P applications, just out of necessity to protect the network.

The site in question is actually in the US, north-central Washington State. The surrounding terrain is extremely rugged and federal wilderness. We've looked at fixed microwave, but that would require two self-powered mountain-top repeater sites (never mind the fact that one of them would actually have to be built in the Wilderness area, which would require an act of congress to approve). Also, conservative estimates put the price tag on the system at about $250k, and ongoing maintenance wouldn't be cheap either.

Heh, I operate one site that has ~60 people connected to 1.2Mbps/300kbps satellite, which also carries up to a dozen phone calls in the evening. Would we like more? sure, but the current system already costs $5000 a month (which is a pretty good deal for raw satellite capacity). Does it suck to use? sure, but once you give up on things like Youtube and put some strong QoS in place, it's remarkably useable assuming a little patience.

The biggest killer? sites like Facebook going https by default. Facebook used to cache really well. As soon as they went https by default, my cache hit rate dropped 50% or more. (It's also a BYOD environment, so I'm not doing SSL MITM etc...)

This is why man invented search domains. Yeah, they don't support multiple levels of DNS, but if you're running something that does that, you're doing it wrong(tm)

I still don't understand why people use their own strange TLDs internally. I always just use split horizon DNS, and put everything under the corporate domain name, thus eliminating the problem.

I've actually sat around and gotten drunk with a couple of astronauts, both of whom have spacewalked. Apparently you don't get vertigo looking down towards the earth, it's when you look into the void. (Note that the helmets are designed so that as long as you're looking ahead, it's not within your field of view.

Sure, but the free options generally don't come in something the size of a shoe-box, with nearly silent fans, and 8 hot-swappable drive bays. Besides, as others have said, I've got better thigns to do with my time than futz around with mass storage.

Because it's not for programmers. Contrary to popular belief, computer science is not about programming. It's about software architecture, design, etc...

The tiles on the shuttle's belly were the complete opposite. The main tiles on the belly of the shuttle were roughly 10% silica fibers, 90% air. Think very low density styrofoam, except that it can be heated to glowing temperatures without losing its properties. This was actually the really cool demo that I saw. The person giving the demo heated it with a torch until it was glowing yellow/white, then picked it up with his bare finger tips. Because the thermal conductivity of it was so low, it could be handled (with care) with bare hands.

For the OP, the point of the thermal protection system was precisely the opposite of being a heat sink. It's entire purpose was to insulate the shuttle against the heat that the belly was exposed to during re-entry. Contrary to popular belief, the majority of heating during re-entry was due to compressive heat (think diesel engines, boyles law and all that), Not friction. Basically the shuttle would compress the air in front of it, causing it to heat up to plasma type temperatures, which was then transferred to the body of the shuttle through convective heating. As such, the best way to deal with it was just to insulate yourself, and wait for the high temperatures to pass.