Author said almost always. Nothing is absolute in cases like this. I agree with the article. We enable swap on our production servers precisely because the engineers don't rectify their memory leaks or whatever problems are internal to their software. Some of those engineers are our own and we can't convince them to fix their software. Others are for things we have no control over, such as Kafka, for example. When Kafka starts going out of control and you've got no swap, oom killer will kill it and you'll end up with corrupted index files, which is a bigger problem than the performance problem you'll see if it has to swap for a while until it gets itself sorted out.
6.6 years ago, here on HN at https://news.ycombinator.com/item?id=177865 , was a link to "Scientists Create First Memristor: Missing Fourth Electronic Circuit Element" at Wired. User rms said: "I don't think we'll have any keeping up with Moore's Law. In 5 years memristor storage will be everywhere. IBM will develop memristor processors for the Blue Brain project." User TrevorJ said: "I fear that the huge inertia that is the software and hardware industry ... will keep this out of mainstream for 5-8 years."
In 2010 Engadget (at http://www.engadget.com/2010/08/31/hp-labs-teams-up-with-hyn... ) described a collaboration between HP Labs and Hynix. "Williams hopes to see the [memristor] transistors in consumer products by this time 2013, for approximately the price of what flash memory will be selling for at the time but with "at least twice the bit capacity.""
If anything, the optimism has become more pessimistic, as the future horizon lengthened from 5 years to 10. :)
In case you hadn't noticed, the authenticity model of SSL was an afterthought and is completely broken. I recommend listening to Moxie's talk about this:
I don't think that's very relevant for this use case, though - JMAP is clearly intended for use by custom clients, not browsers, and those can use SSL with a completely different model from the CA scheme, including bundling certs for the most popular providers (similar to HSTS preload lists).
You don't need to trust the keyservers since you verify the fingerprints of downloaded keys against the fingerprints given to you in person.
The keyserver protocol includes commands to include keys in the keyserver network. How you send keys depends on the UI of the tool you use, geeks will do this:
You should definitely commit the output of yacc to git. This way not only you don't require your users to have yacc, but you make sure they are using the correct yacc version; you know, the one you tested against. And when you change the yacc version, you'll know because it's in your history; otherwise it's hard to remember at which particular time you decided to upgrade the yacc version used by the project.
Committing cpp output makes no sense because cpp output is specific to the machine which ran cpp.
I'm still working on it, but Perl::Critic is good (I've been using it in vim for a while, which checks every time you save), strict and warnings is good (which would be enabled on any new Perl program, but I'm working with a 15 year old codebase, so enabling these automatically creates a bunch of new failing "tests" that need fixing). There's a few different ways to use Perl::Critic in tests, the most promising seems to be Test::Perl::Critic::Progressive, which allows gradual introduction of Critic-friendly code without turning your whole smoker page red. (Which for me, is a problem...we'd have hundreds of failing tests, which would be overwhelming and make it hard to spot tests that will affect users.)
Devel::NYTProf is great for spotting performance regressions.
And, since we're pushing out HTML as the result of our application scripts running, I've been working on integrating HTML::Lint (I had to patch it to allow HTML::Pluggable::HTML5 to work, but I've sent a pull request to Andy, so the next version will likely support HTML5) into our test suite. This will tell us if any script breaks in such a way that it produces invalid HTML.
For JavaScript, jslint and jshint exist. I haven't started integrating or experimenting with either, yet. Our JavaScript is pretty minimal at the moment (a few thousand lines vs 500k+ lines of Perl), so it's not a priority compared to the Perl, and the Perl stuff is still in progress. JavaScript also has strict, which can catch some common problems, like the global scope "this".
ShellCheck already checks for bashism if the script is declared with #!/bin/sh, and finds most of the ones that checkbashisms does along with a few others. It's geared towards POSIX compliance though, and doesn't know which non-POSIX feature are available in e.g. busybox sh.
There is also some limited support for warning about features not available between non-POSIX shells, such as trying to use zsh =(temp files) in bash or bash ;;& case continuations in zsh, but this isn't as much of a focus as POSIX checks since it's not a common source of issues.
The Wooledge pitfall list was the original implementation checklist. About 38 out of the 46 are already covered in one form or another.
I haven't heard of Firehose before, but if you want to use it right now you can run shellcheck with -f gcc, to get gcc style error messages that Firehose can already parse.
But is there any way to use those to inspect traffic originating from outside of Firefox? With mitmproxy (or other tools, such as Charles/Fiddler/etc) you can run pretty much anything through them.
