HN user
I am a dynamic figure, often seen scaling walls and crushing ice.
My email address is my HN username at north dash eastham dot org.
I just wound up using translucent ones which came with them, with the LEDs set to solid colors to group functionality together, and a legend on the display. Zoom keys blue, lights yellow, etc.
I had an XKeys strip for a previous iteration, which included similar keycaps. My hand-written labels were ugly, so I skipped them this time around.
I've done something pretty similar with an Adafruit Macropad, Karabiner Elements (and Zoom's global hotkey support), hass-cli, and a few esphome-loaded ESP32 devices. Physical audio/video mute, raise hand, lights, speaker/headphone switch, and screen lock buttons are wonderful.
Muscle memory.
Because the content is of high quality.
After the EMV liability shift date (October 2015), the fraud liability for a card-present, non-EMV transaction falls on the party which was noncompliant, the issuer or the merchant. Hopefully this will be a significant driver of EMV adoption by both issuers and merchants.
No, you are not.
Comcast simultaneously claims that some of their own VoD services -- services delivered via your cable modem, through your router and home wifi network -- don't count, because they're part of your cable service, not the internet, so they're allowed to treat them differently.
http://corporate.comcast.com/comcast-voices/the-facts-about-...
The alternative is for Comcast to buy enough transit to receive those bits from Netflix. I'm sure Netflix would be happy enough to deliver those bits to Comcast via transit, if enough capacity was available.
Shouldn't Comcast be required to purchase enough capacity to provide high-quality service to their residential customers? SFI between a content provider and an eyeball network should be a mutually beneficial cost reduction, but Comcast has enough market power (captive broadband subs) that they can get away with intentionally not buying enough capacity to serve their customers.
So, uh, does this mean that NSA has an internal LiveJournal instance?
Very, very well said.
Let's do some simple math to prove your point.
Assume Comcast has about 10 Tbps of traffic at peak, single-counting all traffic that transits AS 7922 (Comcast's national backbone network). [1] Now assume that a full 50% of that traffic is originated by Netflix, and the market price for transit is $2/mbps. The percentage is likely quite lower than that, and given 5 Tbps of traffic volume and coordination between the two networks to reduce the number of miles the bits need to be hauled by both networks, the per-megabit price is almost certainly quite a bit less.
But even with these obviously flawed guesses, we're only talking about $120mm/year in costs. Netflix's worldwide revenue in 2013 was $4.3b [2]; Comcast's 2013 revenue from their US HSI business alone was $10.3b. [3] If 50% of Comcast's $10.3b business was in jeopardy, don't you think they'd find a way to absorb that $120mm?
[1] http://as7922.peeringdb.com/
[2] Netflix Q4 2013 earnings release, http://ir.netflix.com/results.cfm
[3] Comcast 10-K filed 2/12/2014
(edited: formatting)
I don't think so. It's multiple direct 10GE ports. Given the traffic volume the two networks exchange, there's no way it would be economical to move these bits over a public peering exchange (which Comcast doesn't participate in in the first place).
Even so, if it were in fact going via the IX, you'd see Netflix's IP from the exchange (206.223.116.133) as hop 8 in the traceroute.
There are only a handful of buildings where you need to be in order to just be a cross-connect or switch fabric away from nearly every network in the world.
You're seeing this because that's where Comcast primarily buys transit and peers with other networks; those edges are where the congested ports are. They generally have plenty of capacity between SV1 and their CMTSes (even if they have to take you from Oakland to Sac-town to get from SF to San Jose).
Wonder if an electric pole counts as a "facility."
This is a route leak, plain and simple. Don't forget to apply Occam's Razor. All of those sites which are "coincidentally" misbehaving are located in the same /24.
This is what is actually happening. Virgin Media peers with Cogent. Virgin prefers routes from peers over transit. Cogent is turrible at provisioning and filtering, and is a large international transit provider.
Let's look at the route from Cogent's perspective:
BGP routing table entry for 199.58.210.0/24, version 2031309347
Paths: (1 available, best #1, table Default-IP-Routing-Table)
54098 11557 4436 40015 54876
38.122.66.186 (metric 10105011) from 154.54.66.76 (154.54.66.76)
Origin incomplete, metric 0, localpref 130, valid, internal, best
Community: 174:3092 174:10031 174:20999 174:21001 174:22013
Also, traffic passing through Switzerland is a red herring -- the poster is using a geoip database to look up where a Cogent router is. GeoIP databases are typically populated by user activity, e.g., mobile devices phoning home to get wifi-based location, credit card txns, etc. None of this traffic comes from a ptp interface address on a core router. GeoIP databases tend to have a resolution of about a /24, whereas infrastructure netblocks tend to be chopped up into /30s or /31s for ptp links and /32s for loopbacks, so two adjacent /32s could physically be located in wildly different parts of the world. More than likely, that IP address was previously assigned to a customer. The more accurate source of information would be the router's hostname, which clearly indicates that it is in London. The handoff between Virgin and Cogent almost certainly happens at Telehouse in the Docklands.
If someone were, in fact, trying to intercept your traffic, they could almost certainly do so without you noticing (at least at layer 3.)
Openness won in the early iterations of online services in part because there was a neutral medium over which you were able to connect to your choice of service: the PSTN.
The entire premise of that paper is misguided. It's fairly common for large providers[1], e.g., BT, Sprint, T-Mobile, to use several of the non-Internet-connected DOD /8s for management addresses, once they've exhausted RFC1918.
If they're not using SNI, this is reasonable. Hopefully they're not using SNI.
Actually, you'd be surprised -- Comcast is leading the charge on the residential IPv6 front in the US, and Time Warner Cable isn't too far behind. Verizon, the largest carrier in the US not owned by a content company (by my back-of-napkin math), has been slower in deployment of IPv6, by contrast. (OTOH, since IPv6 is critical to LTE deployment, VZW et al have been much quicker on the uptake.)
I actually think that the content hosting folks are behind the curve here. Amazon is one of the biggest hold-outs; their IPv6 rollout has thus far been a total joke. No IPv6 for Cloudfront? No IPv6 glue for Route53 authoritative nameservers? No IPv6 on VPC, barely on EC2 at all, etc., etc. From what I've heard, the management at Amazon doesn't really care about the network behind their infrastructure; instead of investing in building a backbone that could do a better job supporting this kind of stuff -- and all kinds of inter-region applications which would be useful -- they want pretend the network doesn't exist and that nothing needs to change. It's too bad. I think we'd see more IPv6 usage if Amazon would get their act together.
Taibbi's pieces always make me feel so powerless.
I've been using NewsBlur for a few weeks now (I met Sam a couple weekends ago) and I think it's fantastic. Highly recommended.
It'll certainly be interesting to see if scalability of the IPv6 DFZ routing table is actually better or worse than that of v4 (adjusted for growth in number of multihomed organizations, of course.) One could make an argument that the bloat in the v4 table today is largely due to disaggregated allocations from the RIRs due to exhaustion-avoidance address space allocation policy.
It is entirely possible that large organizations will be able to advertise fewer prefixes, as they have large, contiguous allocations, and thus can more efficiently aggregate at the border.
(Sorry, this is a bit late, but your comment got me to thinking...)
We do basically the same thing at our office, though with IOS Event Manager foo sprinkled in. It works great.
Forward your email to an Apps account, then set up your @gmail.com address as an alias. Works great and you get support. Gmail is smart enough to set the outbound email address properly for any replies.
On your last point, we'll have to agree to disagree. Good night! Thanks for the spirited discussion.
Most of your cable service's video is actually delivered over IP, but it is on dedicated RF spectrum, even though it's on the same physical wire. If Comcast wants to deliver video to my STB over separate channels, I don't care what protocol they decide to use.
However, if they're delivering video to a generalized computing device in my home, over my home Ethernet network, over the same downstream channels as Internet traffic, and further, they're prioritizing that traffic, that's different. If there was congestion in the last mile that wasn't just me hitting my rate limit with synthetic traffic, Comcast's traffic would be prioritized, and that's not right. It would be affecting your internet bandwidth. If Comcast had provisioned dedicated RF channels for handling this traffic, just as they do for your STB, then I could at least see your point, but that's just not the case.
[edit: typo]
If you read the decree:
If Comcast offers consumers Internet Access Service under a
package that includes caps, tiers, metering, or other
usage-based pricing, it shall not measure, count, or
otherwise treat Defendants’ affiliated network traffic
differently from unaffiliated network traffic. Comcast
shall not prioritize Defendants’ Video Programming or
other content over other Persons’ Video Programming or
other content.
[edit: formatting]
Fixed. Sorry!
You need to be a Comcast subscriber to use their iPad app, but they don't have to prioritize traffic or exempt it from bandwidth limits for it to work.