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.
I've actually found that a lot of devices just ignore an invalid (ie not from a trusted CA) certificate for this. Android in particular will happily continue with no prompt to the user that the cert is not trusted. I even had it somehow forget the CA that I specified with the network credentials. I'm not 100% certain on this, but I vaguely remember having an issue with Network Manager also not validating the server certificate with TTLS.
It's just too risky where a device could decide either for "convenience" or incompetence not to notify about an invalid server certificate and go on to divulge that device's login credentials to the MITM. Or a user not configuring a device properly. I don't have to worry about that with regular TLS, it's enforced on the server and if it's invalid it won't connect, period.
Many devices don't support VPNs (Chromecast for example), and the ones that do don't usually have openvpn as a built in option. Not to mention the increase in battery usage on mobile devices due to keepalives. This mostly restricts your wireless devices to laptops and select tablets or smartphones. If you really don't trust WPA then just make some LAN resources accessible by VPN only (over WPA), but allow internet access without it. Any sites with sensitive data should be using TLS anyway.
Also, WPA2-Enterprise is pretty secure if you only use TLS auth, not TTLS where you use a username/password combo (too easy for a MITM), but regular TLS auth that uses client certificates. It's less effort to setup than a VPN, and you get VPN level authentication, plus support on a much wider range of devices out of the box. This is what I use, and I have a second SSID that uses WPA2-PSK for the few devices that don't support WPA2-Enterprise.