Neither device has a CPU that supports the x64 instruction set. These both have arm chips, though they are both capable of 64 bit operation.

It's not quite what you're asking for (and I'm asking for it too) but I have an Asus RT-AC56U running dd-wrt. It is an arm box with a decent amount of RAM, all gig ports and supports 802.11ac. It doesn't quite run Debian, but I have the next best thing: an SSD attached via USB3 with a Debian install that I run services out of via chroot from a boot script - I essentially turned off all of dd-wrt's services other than the wireless access point and then use the dd-wrt's kernel with a Debian userland for everything else. It took some messing around to get it all working, but it just works now and allowed me to shut off a much bigger device.

It's in fact very common for dynamic content.

Cannot be in the header, since the headers are not compressed in HTTP.

That's certainly possible, just like it's possible he tolerates 700 kilobits/second on what he thinks is 21 megabits per second and hasn't pursued it as some acute problem with his service, or just gone elsewhere.

TFA says they are able to come close for a random sampling of users, for what they claim to be a maximum speed for some class of connection. When I see someone post about "21 meg or some shit" and claim to be tolerating 700 kilobits/second in the early evening, I assume they're mistaken or haven't behaved rationally in resolving it.

Sounds pretty likely by the ambiguous units in your post that your expectations are inflated by a factor of 8 because you're misunderstand the units of what's advertised vs. the units in what you're observing.

Do you really think there's some abundance of extraordinary programmers that are incapable of thought, communication, and working in an office because they didn't spend 36 hours "studying" Philosophy in college? Can your barber or cleaning lady think, communicate, or "handle" living in society? Is this argument the result of some superior general education curriculum during your BS?

Everything in the story makes sense as describing an architectural style and some architectures that follow the principles of that style. Seems like the gotcha in the grandparent post is some mis-used can criticism of "is it written in REST?!". Extra lame points for trying to leave "architectural style" out to play up the difference.

"There's no financial incentive for ISPs or any companies to invest in IPv6"

Hogwash.

Carriers are running out of public IPv4 addresses. When they do, they'll have to deploy multi-layer NATs (so called Carrier-Grade NAT (CGN) or Large-Scale NAT (LSN)). This presents a problems for the ISP: Cost. Right now, the ISP don't pay for NAT. Their customers do. With CGN/LSN, the ISP now has to run NAT. That's a financial incentive to deploy IPv6 (with IPv6, there is no need for the ISP to run NAT).

*Sigh* Shouldn't you be embarrassed to be so willfully ignorant of reality?

The whole "no, we're not really running out of IPv4" argument has been thoroughly debunked. The IANA free pool is down to 28 /8s. The IANA allocates, on average, 10 /8s per year. So in roughly three years, the IANA free pool will be depleted. The RIR pools will be depleted roughly 12-18 months after that.

The RIRs do replenish their pool by voluntarily returns of unused address blocks and by revoking address space (usually for failure of payment of membership fees by the address holder). According the ARIN, they have 1.08 /8s of voluntarily returned space, and 85 /16s of revoked space. See this presentation - https://www.arin.net/participate/meetings/reports/ARIN_XXIII/pdf/wednesday/rsd.pdf for more details.

In short, addresses are going out faster than they're coming back.

Maybe you're on an OS with a dataready or HTTP accept filter. Timeout applies to reading the entire first line of the request.

They will possibly use DHCPv6 Prefix Delegation to configure your home router's DHCPv6 server. DHCPv6-PD is one of the more useful aspects of DHCPv6.

Also, Comcast will deploy IPv6 alongside IPv4, so your IPv4-only devices will continue to work just fine.

Could we please stop it with the baseless assertions that the extra 20 bytes in an IPv6 header will cause so many problems? There is no evidence at all to support this claim. The best example of now IPv6 header size is a non-issue is a paper about adding IPv6 support to OpenMPI. The developers investigated potential performance impacts of running MPI over IPv6 in a cluster. They found a whopping 1.4% drop in throughput and no increase in latency (section 4.1). If IPv6 shows such little hit in a such a sensitive environment, I'm very confident that it will work fine in broadband and cellular access networks.

Further, if you were really so concerned with bandwidth, you'd stop using HTML, since it's a remarkably inefficient encoding system.

IP addresses don't identify people. They tell routers where to forward packets.

Can we please move beyond this 1980s idea that IP addresses identify people?