I do most of the time when standing or walking, mostly because it's uncomfortable in the front pocket and difficult to get out. I have a Nexus 6, so it's a bigger phone, and no I don't wear skinny jeans. That being said, I take my phone out whenever I sit down. It's second nature at this point, I don't have to even think about it. So no worries about sitting on it and bending it.
I think the south east is the only region that actually implements the cap. It's been "suspended" ever since they announced it, at least in California
Oh, I forgot to mention Netflix. Netflix streams would just drop, or would be slow, or say service was unavailable, particularly at night. Haven't had an issue since disabling IPv6.
Same with Comcast. I tried for a years actually, but some things were too slow. Ubuntu and Debian repos in particular were painfully slow, even on my VMs on linode, digital ocean, and prgmr. I ended up having the servers force IPv4 for them when their IPv6 servers went down for days. Speed and latency on IPv6 have gotten much worse over the last couple years in my experience.
Also, it appears Android doesn't play nice with IPv6. It basically silently drops the connection eventually (I'm guessing it stops listening for the RA broadcasts), and push notifications fail. Happens on Samsung devices and my Nexus 6. So it's reliable either push notifications and low latency site loading, or use IPv6. I finally bit the bullet and disabled IPv6 on the router and all my issues went away.
By default it will use a random privacy address (I believe RFC 4941). So the address will change daily, or every time the device reconnects to wifi, whichever happens first.
This should answer your question https://what-if.xkcd.com/58/
Basically, the energy intensive part of getting to orbit isn't getting high, it's going fast enough horizontally. You basically have to be going so fast that the ground falls out from under you (due to the curvature of the Earth) before you can hit it.
Apparently the new firmware now advertises that it supports queued TRIM, when in fact it doesn't https://bugs.launchpad.net/ubu...
The old firmware did not advertise queued TRIM support, so it wasn't an issue. The solution is a kernel patch to blacklist queued TRIM on all Samsung 8xx drives.
Thanks for the info. I was contemplating booting into Windows to run the fix, but it sounds like I might be better off using the live CD. I hadn't run the initial fix, so I'm debating if it's worth it to run it now and then run it again later when they release this fix, or just wait for the new fix.
Is the update that rewrites the data going to be a problem on a LUKS encrypted volume? From what I saw it looks like it only supports NTFS? I also have an NTFS partition on the drive though. I guess I'm just concerned about it borking the LUKS partition.
I hadn't heard about the original firmware update but was wondering why my read performance had gotten so much worse over time. Here I was blaming it on btrfs...
The Snapdragon 805 and newer has hardware accelerated VP9 decode.
Try Virtualmin. It has a web gui interface to configure things like vhosts, along with mod_fcgid, php, etc. It installs and sets up a bunch of extra crap as well that you probably won't need, but it's so quick that might be worth looking at anyway and just remove what you don't need.
The best explanation of asymmetric crypto (not taking authentication into account) that I've seen is mixing two colors of paint to create a third color. Each party can derive the other party's color by "subtracting" their color from the shared mixture. But an intermediary has no way of determining which two colors were mixed. This is an example that pretty much anyone can understand.
You might have better luck with the new Comedy Central android app and a Chromecast. I'm not sure if it's region restricted, but they're all up on there for streaming.
Hidden services actually use 7 hops. The hidden service picks several relays at random and makes them the "introduction points" and pushes this along with the hidden service descriptor. These introduction points are at the end of a normal Tor circuit (ie 3 hops). When a client wants to access the site, it connects to the introduction point also over a Tor circuit. The client and hidden service then randomly pick a relay as a rendezvous point, because you don't want the introduction points overloaded.
At that point, both client and server connect to the rendezvous point over regular Tor circuits, for 7 total hops. All further communication is done over this 7 hop circuit.