MichaelGagnon

Agreed.

Also, be aware that many non-expert attempts to develop compression algorithms turn out to be flawed. However, it sounds like you've developed a compression pre-processor specifically targeting JSON-like structures, which seems like a much more plausible accomplishment than a non-expert developing a brand new general-purpose compression algorithm that can beat LZW.

All that said, if I were considering hiring you I would be much more interested in your ability to rigorously analyze the strengths and limitations of your algorithm (rather than the algorithm itself). Plus, without that rigorous analysis it makes it much more difficult for me to judge the quality of your algorithm.

As far as pop-culture goes, I think Clarissa still holds the cake for female programmer characters. Acid burn (from Hackers) is a close second...

Thanks; upon re-reading the comment I see it now

I disagree.

Node.js and client-side JavaScript should treat security issues differently because they face different risks. E.g. A DoS against client-side Javascript is not a big deal (because it might slow down a single browser, or even just a single tab within a browser). However, on the server side, a DoS could take down an entire service which is much more significant.

Thus you could say that V8 is "secure" on the client side but "insecure" on the server side because of the different risk assessments. It is poor security practice to take software designed for one security environment and assume it will be secure in other environments. If Node.js wants to have a secure system they will need to take these security issues into consideration and harden their system appropriately.

Augmented reality for the web

Bit Torrent. It's how Blizzard distributes their games. Although your game needs to be sufficiently popular for that to work...

Add together these three statements the author made:

(1) The vulnerability report exists in the "shadowy ground between the reports that are clearly crackpot and the reports which are clear enough that you can evaluate them with confidence" (from the blog)

(2) "Oh, we recognized it immediately. But it was so obviously wrong that we began to fear that we were missing something." (from the comments)

(3) "this entire investigation took five days to complete, plus another day or two to complete the necessary paperwork." (from the blog)

This blog post paints a picture that Raymond's organization does a bad job triaging reports and prioritizing investigations. It's a waste of five days to analyze an "obviously wrong" vuln report, just on the off chance that there is something deeper. How about spending five minutes emailing the author of the vuln report, explaining why it doesn't appear to be a vulnerability, then asking if there is anything deeper?

It's also crazy to spend a day or two filling out TPS reports on a crank vulnerability alert.

If an organization takes security seriously then it should spend increasing amounts of time on increasingly plausible vulnerability reports.

If you really wanted to attack their vuln-investigation processes, you would simply let them conduct business as usual since it seems they don't know how to triage potential vulnerabilities. If you force the issue by conducting a DDoS, they will respond by developing a better triage system that de-prioritizes crank vuln reports more quickly. Not only will this defeat your DDoS attempt, but it will make them more effective at handling vuln reports going forward.

And from the HN article "intellectual honesty requires bending-over-backwards to provide any evidence that you might be wrong."

The article is so close to a direct Feynman quote that it makes me wonder if the author was subconsciously plagiarizing Feynman. Normally, I wouldn't mind (subconscious plagiarism is everywhere). But in an article about intellectual honesty I would expect the author to "bend over backwards" to identify and declare potential sources of plagiarism. ;-)