That's simply not true, I'm sorry that you seem to have had really shitty experiences but _good_ experienced programmers aren't really good candidates for outsourcing.

I am, and have been, in management (Product Owner, CTO, etc) for nearly 20 years and I can't hire enough good developers because they simply aren't looking to move. Good organizations hold on them and treasure them.

That's inaccurate, at least in the larger scale of things. While it's true that there is no federal law compelling them to log and so they can't be forced to hand over what they don't have. A CALEA (and several other types) of warrant will compel them to start logging and hand off a copy of all traffic (in unencrypted form) to and from a specific IP or set of IP addresses.

The problem for service providers is that increasing capacity costs money and their business models didn't catch up with the reality of increasing average usage. I agree that monthly data caps are a very poor method of controlling usage, but the problem is that the "better" methods cost more and are more complex both to implement and explain to consumers.

It's relatively easy to explain to customers that they have a limited amount of total transfer per month or billing cycle. Trying to explain to customers that they have the right X amount of high priority transfer or Y amount of peak usage transfer (peak usage varying either by time of day or actual measure usage) is much more difficult. One of the "best" methods for actually controlling peak traffic is based on actual measurements of usage for the service group (DOCSIS) or OLT or splitter (PON) and giving everyone in the group equal priority for that bandwidth. The problem is that these physically based objects aren't split evenly inside of an ISP's customer base nor is it practical to expose the total port/service group/AP/splitter capacity to all the customers being served by that element. While the average /. reader could probably understand a usage meter that displayed that that same level of understanding is impossible for the vast majority of customers.

Of course not, the problem is that capacity is consumed while the packets are in transit. Transfers are not (and cannot be) instantaneous. That transit times are short, to human perceptions, doesn't change the fact that it's limited and while you're downloading a file no one else can use capacity that you're consuming. If transfers we're (could be) instantaneous then you'd be correct, but they're not and will never be. In fact, as we increase the number of devices in the home network the problems get to be more severe since in addition to the bit rate limits there are also various physical limitations, like time slots in DOCSIS, that also limit the capacity in the network.

Now, that doesn't mean that Mediacom is correct, they're using a very poor analogy IMO, but again the argument that nothing is consumed in transit is also fallacious, just because the capacity is restored once a transfer is complete.

The cookie analogy fails, on several levels, but so do the criticisms.
".. since transmitting data over a network doesn't actually consume anything," This is fallacious, as capacity is consumed and is a limited capacity. Take every criticism the article levels and apply it to seats on an airplane, which is a far better proxy for explaining the limits of network capacity, and you can see they're just as flawed as the original argument.

That's completely wrong on LTE-U. Part of the problem with the standard is that while the data channel is over the unlicensed bands the control channel is over licensed spectrum. Only companies who have licensed spectrum could have ever used LTE-U. I'm still looking at how LAA works, but LTE-U is a technology that only cell phone companies could use. Perhaps you are thinking about one of the other potential standards like MuLTEfire.

"Wrong. The "TFA" is wrong. That's why that article is doing such a disservice to its readers. The CSAT algorithm in LTE-U small cells first begins by listening for other Wi-Fi access points transmitting in its vicinity. It is in fact able to listen not just to "energy" being transmitted on a given frequency - it is in fact able to receive and decode Wi-Fi beacons. If it find a channel with no existing occupants, it'll just use it. But if it has to share, it listens to determine the number of existing occupants. Then it transmits for only its portions of the time. And during its "off" cycle, it listens again to determine if there are new Wi-Fi access points that came online, and automatically reduces its share of the air time the next time around. So not only does it check initially, it checks continually for other occupants, to keep things fair."

This was not the case the CableLabs study which did indeed use a commercial implementation. Further, listen before talk in LTE-U is only now being a proposed as part of the standard. There are vendor specific implementations that already have this, but the standard does not and did not when the tests were done.

http://www.lteuforum.org/uploa...

LTE-U does NOT use listen before talk unless there's been a recent change in the protocol. It, just like normal LTE, is centrally scheduled. There are some vendor specific and non-standardized version of LTE that can do listen before talk, but that's not the standard.

No, you cannot. Part 15 has some very specific language about intentional interference. You might want to read the regulations before pointing a dish at someone else's tower without having another dish to receive it on the other side. I'd further say that using a dish is about the worst way to do this, since the signal would be highly concentrated at the ranges you can legally push 2.4 GHz (~60 dBm) it will be very obvious that you're intentionally interfering with someone else's signal.

The central problem is that WiFi is a "listen first" protocol while LTE is centrally scheduled. That means at full duty cycles, this was the worst case assumption the CableLabs study worked off of, that LTE-U absolutely degrades WiFi performance substantially. The counter claims were that LTE is seldom at full duty cycles is true, but only on towers that are lightly loaded. A busy tower will have a full or nearly full duty cycle in its licensed bands and there's no reason to imagine that the same won't be true for the unlicensed bands.

That's false, I've seen the tests, ie I've been there in person and while there are some worst case assumptions the testing that CableLabs did is completely valid and accurate. The notion that LTE isn't commonly running at full duty cycles is simply false for many/most urban and suburban towers.

You need to remember that the power from your AP is irrelevant since your mobile devices will out put a max of about 250 mW and the average laptop and gaming console registers less than 1 watt.

That's only true of the over the air rate, which matters a lot when you're talking about one hop, but isn't worth anything when you have to repeat the signal. The kind of network proposed would be several orders of magnitude worse than what we have at present because each radio repeater would increase latency more than the total injected in the much longer fiber runs.

Sysadmins know almost nothing about MSO operations, unless you've worked for an operator. Just because you've worked on a low end Cisco router and a few nix boxes doesn't give you any insight into how DOCSIS cable systems works. I know, I had to go through that learning curve myself when DOCSIS 1.0 came out and I looked at the modem and thought, "It's just a bridge, how complicated can it be..."

Then you're a fucking moron.