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%).

Singular nouns that refer to groups of people often take plural verb agreement in English (admittedly this is more common in British than US English, but it does happen in both). Compare "My family is big" with "My family are big"...

Yep, exactly - the "they" clearly indicates the company is being thought of as a group in this example.

Of course, the whole thing just goes to show how poorly written the original title was in the first place :-)

Really? I'm not sure that's an improvement...

You are assuming that the medication under test actually works. If it doesn't (and we don't know whether it does or not, or else we wouldn't be testing it), then those taking the placebo are no worse off, and indeed may be better off if the medication has side-effects.

No - that was one of the points of the article.

Increasingly the source of phishing URLs is social media rather than email. In tweets (and to a lesser extent on other social media) it's common to send a shortened URL (tinyurl, bit.ly, goo.gl etc) that redirects to the actual URL, and consequently users won't be surprised to receive such a short URL, and will probably click on it - whereas if they received a massively long "data:" URL with lots of base64 data after it, their suspicions would be more likely to be raised...

What have eels got to do with it?

Of course you can—that's why you have to be careful sailing near Somalia, in case you get boarded and forced at gunpoint to hand over the source to the latest version of Emacs...

You're right, that would be stupid—and, despite what the summary tries to tell us, that's not actually what the article's suggesting.

The ampere is currently (no pun intended) defined as the amount of current that must flow in two parallel wires a specific distance apart, in order to get a certain amount of (magnetic) force between them. (The Coulomb is then defined as the amount of charge that flows past a point in one second when the current is one Ampere.) That definition is good enough for most purposes today, but there are limits to the precision that can be achieved in an experiment that measures current using mechanical forces. If it's now practical to create a stream of precisely counted electrons, then we can define the Coulomb and Ampere directly in terms of numbers of electrons, which then has the potential of being much more precise.

So the value of the Ampere and Coulomb won't change (or at least, not significantly), because any new definition will be chosen to be consistent with the old one—but the way we pin down their meaning may do.

Umm... are you sure about that?