Well, actually it's the Supreme Judicial Court, or SJC.

Check your hardware, including your pfsense and cablemodem.

I'm on Comcast, and I run three VPNs over my residential connection -- SSL outbound from an internal NAT client to my work network for about 8 hours a day, plus a nailed-up outbound IPSEC tunnel to my personal server in Chicago, and I also have a listener for inbound OpenVPN sessions. All this and I've been doing about 100GB/month in torrents, yet my connection is rock solid.

I think that ship sailed when Microsoft started contributing code to the Linux kernel, although they had released lots of code under OSI-approved licenses way before that.

I once checked out the TV section of a Yodobashi Camera (and if you're ever in Japan, you really must visit a Yodobashi Camera, it's like every store of the floor is the size one or two BestBuy stores, except there's half a dozen floors or more). The brands of TVs on offer was very different from what you'd see outside of Japan. In most of the world, Korean brands like Samsung and LG are quite popular, but in that TV section (of what are probably the largest electronics stores in Japan), there was not a single non-Japanese television brand to be seen. Not a single Samsung or LG television was available.

Via DSLreports:

I reached out to Comcast and was told by spokesman Charlie Douglas that the report is "wildly inaccurate."

"The anecdotal chat room evidence provided is not consistent with our agents’ messages and is not accurate," said Douglas. "Per our own internal review, we have found no evidence that these conversations took place, nor do we employ a Security Assurance team member named Kelly.

Douglas proceeded to state that "Comcast doesn’t monitor users’ browser software or web surfing and has no program addressing the Tor browser. Customers are free to use their Xfinity Internet service to visit any website or use it however they wish otherwise

Crazy, isn't it?

Evidently, there is some unwritten law that states that Geolocation by IP address shall override any and all set preferences by the user on their device, and ignore any possibility that barring or redirecting the user makes no sense.

I get a version of this periodically on Spotify, where I'm informed that the particular album or single I'm looking at can't be played because it isn't licensed to my region. And of course there's the small matter of my being IP-blocked from Pandora Radio for the same reason.

I ran into a particularly nasty geolocation issue back in late 2012, when I was informed that I couldn't access my National Lottery account because they no longer believed that I was accessing it from the UK. Went back and forth between them and my ISP (VirginMedia), with each blaming the other for the problem.

I've also heard of situations where people have found the books on their Kindles vanishing because they're holidaying in an area where said books aren't licensed.

Have you ever ridden in a cab? I'm guessing you haven't.

- The difference is irrelevant, the apps are stored as platform-independent bytecode that (as of the next Android release) is then converted to machine code by ART or done on-the-fly by Dalvik itself. As a result, so long as Dalvik or ART supports the processor architecture, the application doesn't need to.

- As long as the ARM app doesn't use NEON (which I believe Intel's Houdini emulator doesn't support), it shouldn't have any problems running the ARM code on the x86 devices. In fact, you're likely to have better compatibility running emulated on x86 than you are natively on some older ARM devices.

You're accounting only for full-drive failures. IIRC BackBlaze indicates failure rates are higher than 5% per year, but that's not really relevant. The bigger problem is a read error during a resilver. That's something that the drive specs indicate should be expected at least once during any resilver, although in practice I find it less likely than that.

If you're using mirrored pairs, any resilver is (by spec) highly likely to result in corruption due to unrecoverable read errors due to lack of redundancy. Resilvering a single drive in a raidz2 array, however, still provides you with redundancy to recover from any read errors.

One could argue that he and his State are competing in a free market against other states. There are obviously benefits to having these business operate in your state. If the people of his State didn't support these deals they would almost certainly discontinue electing assembly people and governors who support it.

Yes, but write throughput is still increased, and not everybody needs more write IOPS. Furthermore, even with 8 disks you can build two raidz2 arrays and put them in a pool, at which point you've got the IOPS of two disks. And on top of that, you can use fast SSDs as ZIL cache devices.

Some points here:

- Most Android apps are Java bytecode, not native code, so the underlying processor architecture is irrelevant (for those apps)
- x86 is a supported Android platform, so many apps that do require native code have x86 binaries available
- Intel provides an ARM emulator for the x86 version of Android so that x86 Android devices can run ARM binaries
- Some ChromeOS devices use ARM processors to begin with.

Only if ZFS is communicating with that higher level. A simpler solution is to just use ZFS's native RAID instead of treating a RAID array as a block device. I can't think of a single benefit to doing that, but I can think of lots of reasons why it's a bad idea.

Sorry, brain fart. I meant "DEDUPE consumes insane amounts of RAM", not "BSD".

You shouldn't have to reinstall ZFS after any updates (apart from maybe a distro release upgrade, which on a file server running Ubuntu are probably being done every two years, or six months if you live on the edge), as it uses DKMS and will recompile the modules when you update the kernel or zfs.