How is that possible? Practical TV broadcasts didn't begin until years after the January 1, 1923, cutoff for the Copyright Term Extension Act. And U.S. copyright law allows state copyright in sound recordings to continue until 2067.

Nothing plays VP8 codec in MP4 container either.

A lot of geographic areas don't have a second provider other than satellite and cellular. In most cases,* switching from a provider with a 150 GB per month cap to a provider with a 10 GB per month cap (source: exede.com) isn't a good idea. Nor is moving to a different town.

* Watch someone come up with an edge case.

You mean:

Computer, sudo end program.

Privately recorded videos fall under the conditions of the ticket granting admission to said insignificant local games. If said conditions include an assignment of copyright in any privately recorded video to the league, it could produce the situation you describe. But such conditions would not apply to, say, recording your kids playing soccer at a public park because nobody owns the exclusive rights to the sport of soccer itself. A video game publisher's copyright is different because it affects your ability to broadcast game play even if you start your own league or even if the match is not associated with a league at all.

What high-level language does not depend on the C standard library and so would be suitable for implementing the C standard library?

It is possible, but for good performance it needs hardware support. We've implemented hardware-enforced bounds checking for C code using our processor. If you only care about accidental bugs and not about a malicious attacker, and don't use threads (or are happy to bound every pointer store with a transactional region), and don't mind that the semantics of C are subtly broken in the kinds of permitted pointer operations, then Intel's Memory Protection Extensions will do the same thing.

The OpenBSD philosophy says that the difference between a bug and a vulnerability is the intelligence of the attacker. There are lots of categories of bugs (null pointer dereferences, integer overflows) that were thought to be unexploitable, right up until someone exploited them. It's the same as with cryptosystems: the fact that you can't break your encryption algorithm doesn't mean that it's secure.

I remember when hard drives didn't fail. It was the time in between getting my first hard drive and it failing...

Actually, come to think of it, my first hard drive (40MB!) didn't fail, but my second one (60MB in a laptop) did.

Your laptop has to be on the same network as your backup machine, but even backing up my laptop over WiFi only takes a couple hours for an incremental backup. I don't have to leave it doing nothing, I just need to leave it on. If I haven't backed up for a while, I might leave it doing the backup overnight, but most of the time I run the backup while I'm working.

I bought 3 2TB disks just before the flood. About a month ago, they finally became cheaper than I paid. I'd been planning on swapping them out for 4TB disks after 2-3 years, but the 4TB ones are still 50% more than I paid for the 2TB disks. At this rate, 4TB flash will hit the £50 mark before 4TB hard disks...

The difference in cost between tapes and disks hasn't changed much, but the difference in cost of the tape drives to disk drives has changed hugely. You used to be able to get a tape and a drive for only a little bit more than the cost of the disk it would back up. It made sense to use tapes for backups then, because you could afford one tape for the same cost as a backup disk and add new tapes for very little money. Now, if you buy a disk at the sweet spot for price, the tape drive that can back it up to a single tape will cost you about an order of magnitude more than the disk drive. At that point, unless you want a lot more than 10 backups per disk, it isn't worth it.

That's not necessarily true. You can get the same amount of space in a smaller number of tracks around the edge of the disk, so the horizontal movement for the largest seek is going to be smaller. Seek times on mechanical disks are based on three factors. The first two are related: the time it takes to move the head between tracks (proportional to its distance) and the time it takes for the head to settle and be able to be lowered again (dependent on its speed). The third is the time it takes for the correct sector on the track to spin under the head. In the middle, you have fewer sectors per track, so you need to move the head more often (this is where the upper bound on seek times comes from).

It's probably the ultra-restricted version of Jazelle that is part of ARMv7 - it supports the branch to Jazelle mode instruction, but throws a trap when it is encountered so that it can be emulated by a JIT compiler.

I don't know about Canada, but here in the States they have the fruit of the poisonous tree doctrine that evidence from a constitutionally impermissible chain of investigation is inadmissible in court.