The sad thing is it shouldn't be better than HE-AAC. Being low latency does tend to mean one is better at the kind of time-domain issues many find so objectionable, but outside that OPUS is really packing a MUCH smaller toolkit than HE-AAC.

This is really egg on AAC's face, IMHO, and quite the upset. OPUS is so immature the bitstream isn't even stable yet.

HE-AAC uses SBR to reduce its data footprint. This results in worse reproduction of the source audio than LE-AAC at same bitrate (and often even lower bitrate). The whole deal with HE is that it can maintain good quality at very low bitrate, by giving up accuracy. So far, Apple's LE-AAC encoder in their Core Audio framework is the best choice for digitally non-lossless compression.

While your rant appears informative if not insightful on its face, it is completely missing the point.

This is a test of audio codecs at low bitrates.

I don't know what this "LE-AAC" is you speak of (and rather suspect you don't either) but AAC-LC was actually in this test, as the low anchor.

At these bitrates (~64kbps) HE-AAC (despite its "low-accuracy" as you put it) is perceptually better sounding than AAC-LC. Lossy audio codecs (even the LE-AAC [sic] encoder in Apple's Core Audio framework you love) can only be judged by how they sound, not how they look. "Accuracy" is not a metric very worthy of discussion.

Is this your entry in "how many incorrect statements can be made in one post"?

From TFA,

The adjustable beam is typically one degree wide

So for this to be effective, you have to aim fairly precisely at someone's eyeball. Presuming they aren't cooperating by standing stock-still with their eyes open and looking at you, the chances of managing a "hit" before they do whatever it is you would prefer they didn't must be quite small.

The angular diameter of the full moon (or the sun) is just about half that, and I think you'll find that is plenty large to paint a face quickly and easily.

Unless you make your attached cargo hold neutrally buoyant the change in your boat's ride height would be very obvious and attract attention.

Forget the 1000-core cluster. I want to know where I can get 1,000,000 images of people with all the (major) body parts zoned and referenced.

That's an impressive test corpus.

At least it'll kill USB drive viruses and the even worse autolaunching U3 crapware on some USB drives lol.

Nope. U3 "crapware" works because a U3 flash drive mounts with two USB endpoints, one of them identifying itself as a CD drive. All the autorun "magic" of U3 happens from the CD-ROM endpoint.

Or...you know....they just didn't find the problem. Considering that it only happened to be about 4 times within a 3 year time span, a few months of testing won't necessarily reproduce the problem.

A few months times dozens of drivers and hundreds of vehicles, including every single one with a unexplained reported sudden acceleration problem they were able to get their hands on.

If you had reported your sudden acceleration issue to your dealer the NHTSA would have contacted you.

Since you didn't mention the fact of their contact, much less the method which all of us in the loop should know, I call BOGUS.

I don't understand what the incentive is to stop using IRC for command and control.

From you post, it sounds like cracking a 9-digit password via rainbow tables is pretty trivial, yeah? As computers get faster and storage gets cheaper, the value of "trivial" gets correspondingly larger, but humans aren't getting any better at remembering passwords.

Humans don't need to get any better. Increasing the salt size in proportion to the increases in attacker resources works perfectly fine, and is resource asymmetric in favor of the defender.

You stop brute force through limitations on attempts, and you stop hash reversal through salts. All the problems are failures to implement one of these two simple steps.

You're comparing a local privilege escalation exploit (*unix) to a remote one (Win) as if they are even the same ballgame?

L O fucking L.

But, even if that were true, there are still very good reasons to recycle paper such as saving trees

Saving them from what? A life of indentured servitude? Seriously, the use of old-growth timber in paper making is a whole other topic, one which need not be used to muddy the merits of using paper products as a carbon sequestration vector.

I wonder if "THEY" already have one of these quantum computers and are keeping a lid on it so they can snoop on the PGP of our enemies. Would it be possible to develop one of these in secrecy?

Simplistically:
If THEY bought out 50% of the researchers in the field, without arousing suspicion amongst those who turned down the offer, THEY would only have a 50% chance of having one first.

More realistically,
If THEY bought out a significant percentage of the researchers in the field, without arousing suspicion amongst those who turned down the offer, THEY would likely only be a few months / years (at best) ahead.
And since the outlook on the QC front is rather bleak (in terms of a functional QC with any real power) the odds are strongly in favor of THEY not having squat.

Especially in today's world it isn't like top researchers are fragmented and isolated. In the past it was possible for a governmental organization to use its greater vision to collect isolated researchers and be the first to introduce them to each other, magnifying their individual efforts. Today everybody who is anybody in these fields is at least aware of the others, if not following closely.

The fact that amp-hour ratings are only valid for the specific amperage specified is true - but be careful extrapolating your experience with lead-acid deep-cycle batteries to LiPoly ones.

There is a (relatively) huge difference in amp-hour capacity of a lead-acid battery at 1/2 amp and the same battery at 4 amps of draw. This is due to the internal resistance of the battery, though, and as such affects the much lower internal resistance lithium chemistry batteries less than lead-acid ones.

What does this tell us? It tells us you need to compare apples to oranges.
Compare a ARM SoC to a x86 processor and all its support chips.