Plus of course the fact that DKIM usually identifies the domain, rather than the user, so it would generally only be evidence that the email came from a specific ISP (or company), rather than a specific person, which is much less useful.

I think you meant "symmetric" :-)

It doesn't make it smaller - in fact, it will make the data larger. It gives improved performance because of the way TCP responds to dropped packets:

(1) Normally the receiver has to notice the dropped packet, notify the sender, and wait for the packet to be retransmitted - meaning that the data in question (and any data after it in the stream) is delayed by at least one round-trip. With this scheme, there is enough redundancy in the data that the receiver can reconstruct the missing data provided not too much is lost, improving the latency.

(2)TCP responds to packet loss by assuming that it is an indication of link congestion, and slowing down transmission. With wired links, this is a good assumption, and results in TCP using the full bandwidth of the link fairly smoothly. With wireless links, however, you can get loss due to random interference, and so TCP will often end up going slower than it needs to as a result. The error correction allows this to be avoided too.

Not a joke, but a badly-worded summary - the invention is called "coded TCP" (presumably because it's a version of TCP with error-correcting codes). I agree that the summary reads as if the protocol is called "TCP"...

You are correct... here's an easy way of figuring it out:
N+ ... +1 = (N+1)
(N-1)+...+2=(N+1)
(N-2)+...+3=(N+1)
Pairing up a term from the beginning of the expression with one from the end always makes (N-1), and there are N/2 such pairs. So the total is N(N-1)/2 (at least for even N - though it works for odd N too).

I think you're possibly underestimating the degree of variation in pronunciation of English... for example, where I come from, the vowel you mention is in fact identical between the two words - but the "-inge" ending is all they have in common (e.g. the first vowel differs noticeably, and the "r" in "door-hinge" is not pronounced). This may go some way to explain the amount of disagreement you're encountering with your assertion :)

She is exempt from some taxes, but not others. Of the ones from which she is exempt, she pays most of them on a voluntary basis.

Because most Slashdot readers already have all the software they need, but could do with some more clean clothes? ;-)

No - or at least, I've never heard anyone refer to them that way here.

No, I wouldn't say that's true. Certainly there exist publications with a whole range of different slants on the Palestinian question, but that's a very different thing from being anti-Semitic. And there's always over- and under-emphasis of topics—and plenty of inaccuracy in general—but I don't think a charge of anti-Semitism is justified.

Is that what's known as an ark-hive?

As Cardinal Richelieu said: "If you give me six lines written by the hand of the most honest man, I will find something in them to have him hanged."

There's certainly truth in that, but is the engineer who makes one sloppy mistake in step 10 really vastly better than his colleague who makes one sloppy mistake in step 1? The former will get 90%; the latter will get 0%...

That's true, but to do that it has to sacrifice a lot on compression ratio (and to guarantee the latency you have to give up losslessness). That's great for squeezing, say, a 1080p signal into a channel designed for 1080i, but when it comes to having multiple 1080p streams from the different cameras in a studio you'll likely need the higher bandwidth Ethernet can provide anyway. And of course the potential market for fast Ethernet hardware is much bigger than for a codec that is only used within a particular industry - so the economies of scale are potentially much better there.

The trouble is that the more effective codecs tend to require an entire frame before they can do any compression (so that they can compress more effectively by taking the whole frame into consideration). So if you have a series of pieces of equipment processing the video (camera, distribution, control desk(s), effects etc), then each one has to wait until it's received the last lines of a frame before it can even start sending out the first lines of that frame - so each element in the chain adds a whole frame's worth of latency. Whereas if you do it uncompressed, most equipment can start sending out the first line of a frame before it's even received the second line.

That's dependent on a lot of factors. 100Gbps Ethernet has the potential to reach much bigger economies of scale than broadcast-quality codec hardware (though it has a long way to go before reaching that far as yet).

The trouble with lossless codecs is that they can never guarantee to make a frame smaller - mathematically there must be some frames that are uncompressible. Over the course of a long video, the codec will win on average, but when working with live streams, if you get just one frame that doesn't compress nicely (or worse, a few in succession) then your network has to be able to handle that bandwidth - so you might as well not use the compression in the first place.

It's actually very close to 100 gigabits per second. (The encoding overhead is already accounted for in the 100Gb figure, and the protocol overhead is very low: if you're using jumbo packets - and you'd probably want to - then it's easily less than 1%).