That seems like an oversimplification since the DEFLATE algorithm includes a huffman encoding step, and it is within the specs for the compressor to simply never emit back-references. It would be a horrible bug in the implementation of zlib to have worse compression performance than a basic huffman encoding.

Although it has not been fully disclosed yet, it's my understanding that the attack is only practical because of a sort of implicit "trust chain" in the implementation of TLS 1.0 where knowledge of one block gives you all the information you need to decode the next block... but also that proper decryption of one block means that you know that you decrypted the previous block successfully. That's the kicker - if you are just making guesses at one block but know the contents of the next block, the encrypted results of the second block are a kind of oracle to see if you got the first block right or not.

Now, if you use javascript to prime the channel with a (block size minus one) byte message, you're going to be able to guess the first byte of the next message and then check to see if you were right using the oracle trick. Once you know that, use a (block size minus two) prefix and guess the second byte. Rinse, repeat until you've grabbed it all, one byte at a time, thanks to the ability to check your guess using the next packet as an oracle.

My layman's understanding of the fix is that it neutralizes the oracle by adding additional variation. This means that you'd have to guess the random variation in order to craft an "oracle" packet that tells you that you guessed the previous packet correctly. Multiply the guessing search space (2^8 possibilities) by the variation and you're up in "computationally infeasible" territory. The attack is thus neutralized.

The point isn't to provide critical or useful feedback. The point is to provide positive reinforcement and emotion. Most human beings, believe it or not, enjoy feelings of acceptance and appreciation and despise criticism. You're welcome to tell them to go home until they grow a thicker skin, but then all you've got left is a bunch of nerds and engineers trying to maintain articles about 15th century art.

"Lost at a bar" probably means that someone left it on the bathroom counter, and another patron came in and swiped it as soon as he saw it, then realized it wasn't a normal phone and tried to sell it to tech sites for cash. Or maybe the bartender decided not to wait for the owner to claim it.

Not everyone is morally responsible. If the choices are 1) pre-planned conspiracy, or 2) average people behaving badly, it's always the latter.

As far as I can tell, the author of this paper just figured out a way to offload a bunch of memory management tasks to an idle CPU core, and then counted it as a performance gain. OK?

So, monolithic single-threaded applications can be made faster on multi-core systems, at the cost of bulk-allocating more memory than is actually required, and only if there is enough idle CPU to run your memory-management thread in realtime on another core. I am not exactly blown away.

The press release tries to trump it up as some kind of major advancement in performance, but it's not a performance gain at all. If you ran four copies of these single-threaded benchmarks simultaneously, you'd probably see a net performance decrease.

Open source bugs get fixed because people notice and are bothered by the bugs. This is the biggest motivator of open source contributions - everybody has an itch to scratch. The bugs that get fixed fastest are the bugs that are encountered the most. And this is why the Microsoft guy is absolutely correct in his analysis.

Bad security is not a user-facing bug. Unlike functionality bugs, there is little incentive for community members to identify and fix security bugs. Sure, the Linux kernel and other key packages will attract expert eyes, but the average random piece of open-source software will not.

Security analysis is both complicated and un-glamorous. There are not a lot of people attracted to that kind of work. There are even fewer people who would do it for free. The position of the linked article is that it's better to pay people to think about security than it is to rely on the principles of OSS. I agree 100%.

You would be amazed what firmware can do. Sony recently announced a revision to the physical disc format that places the pits closer together to increase storage by a significant percentage... and all existing Blu-Ray drives will be made compatible via firmware.

There is a reason that these drives cost so much to manufacture. The physical hardware is incredibly generic, and nobody really knows the limits of its capabilities.

There's a pretty big difference between "one second" and "50ms". And your assumptions about what is noticeable and playable are pretty much wrong when it comes to console controllers.

http://www.eventhubs.com/news/2009/sep/07/measuring-input-latency-games/

LAME MP3s are still compatible with the original reference spec. Sure, VBR sounds even better, but even 128kbps CBR has jumped light-years ahead in quality past the original generation of MP3 encoders.

In theory, the BBC's new encoders could be making better use of error analysis, redistributing the bitrate to avoid highly-noticeable errors (such as macroblock artifacts) in exchange for increased error in less important/perceptible regions of the picture.

There is no theoretical reason that a perfectly encoded 9.6mbps stream has to look worse than today's average 16mbps stream.

In reality though, from the complaints it sounds like the BBC's new encoders are kind of shitty.

But those things require format changes. My point is that you can improve the decision making in the encoder without changing the output format at all.

If you play an 128kbps CBR MP3 authored with the latest LAME using an MP3 player from 1992, it will sound light-years better than the same MP3 from a 1992-era encoder. This is not because of new features; there is no new coding, no varible block sizes, just a better understanding of which frequencies are important for human hearing.

Lossy compression formats depend on an understanding of human perception. Nobody has a perfect model of the human brain, and nobody has a perfect algorithm for deciding what data to keep and what data to throw away.

If you have a better model of human perception than your competitors, then your encoder will yield higher quality output. If you spend 50% of your bits on things that nobody will notice, and I spend 25% of my bits on things that nobody will notice, then my 650kbps stream is going to look better than your 900kbps stream.

LAME did not win out as the MP3 encoder of choice just because it is free. It won out because its psychoacoustic model yields better-sounding MP3s at 128kbps than its competitors managed at 160kbps or even 192kbps.

I'll bet that you are actually being bothered by something else - perhaps near-inaudible high frequency buzzing from some electronic component - and have mentally associated it with Wifi. But because of the mental association, you will feel discomfort whenever you expect to, which is whenever you are near an active Wifi device.

Diagnosing the actual cause of the discomfort could be useful because if you can demonstrated to yourself that it is not Wifi, you might convince your brain to stop feeling uncomfortable :)

A competitor to OpenDNS that doesn't hijack the google.com domain results and redirect users to a private server, for one.

Also they get plenty of high-level aggregate data on website popularity from bookmarks and so forth, which they can't capture from search data alone.

Ignore the trolls who will spin conspiracy theories about logging individual behavior and tying it to accounts, they expressly deny it in the FAQ and it would open them to so many international lawsuits that they'd have to fire all their engineers and replace them with lawyers.

They state very bluntly that IP addresses are expunged from the logs after 48 hours, and that no data is shared with Google Accounts or other Google services. They still get to play with a lot of aggregated data, but this seems like a fairly non-evil way to do it. Good for them. http://code.google.com/speed/public-dns/faq.html#privacy

Excel and Word are practically their own operating systems. You can't blame their problems on anything other than the insane legacy of backwards compatibility with a sprawling 20-year codebase.