opejn

Thank you for sharing your story. I hope you don't mind if I turn it into a thought experiment, because I find it a good example of how tricky finding and fixing a problem can be. I know nothing about water quality standards, so they might be naive, but the following questions stick out to me:

* Is there a reasonable contamination hazard from water sitting in pipes that are flushed daily with chlorinated water? In other words, is it vital that there always be residual chlorine 100% of the time, or were the standards designed to accomodate this sort of periodic lapse?

* If the dips were harmless, would the inspectors be willing to accept that?

* Was the dump solenoid effective at flushing the entire network of pipes, or just the branch containing the sensor?

Depending on the answers, the end result could range all the way from "the new system let us eliminate a serious hazard", through "we were probably fine before but now we can be sure at a little extra cost", down to "now we have to waste water to avoid tripping a sensor so we don't get fined, with no actual improvement to the water quality". It's a great example of how what we want, what we test, and what we enforce can get just a little out of alignment, and make a hinderance out of what ought to be a definite improvement. Thanks again for sharing.

Yes! In C its full spelling is "!a != !b".

Not to mention the fact that Homebrew itself uses the system git to install itself.

To me, this is the biggest problem, and it's not just Homebrew. Any source package manager that uses Git will potentially have this problem. With a vulnerable Git on your system, you have to second-guess every build script you ever run that might make use of Git, to make sure it obeys the path you set instead of choosing its own.

A breaking example might be trying to find lines containing an "=" in a file:

    grep = my_file

    env1=foo env2=bar env3= my_program

The problem with this is the limits of human attention. It's hard enough to maintain focus on long drives as it is; if the "enhanced cruise control" takes over the job entirely, the driver will have nothing to do and is likely to stop paying attention to the road at all. Then he'll either miss his chance to take manual control, or do so in a state of panic.

Google has been making arguments along these lines -- for instance: http://gizmodo.com/why-self-driving-cars-really-shouldnt-eve...

I think the question was whether we can easily mass-download the papers from Scihub.

is there a disadvantage to using a higher blocksize?

Maybe, depending on the details. Imagine reading 4 GB from one disk then writing it all to another, all at 1 MB/sec. If your block size is 4 GB, It'll take 4000 seconds to read, then another 4000 seconds to write... and will also use 4 GB of memory.

If your block size is 1 MB instead, then the system has the opportunity to run things in parallel, so it'll take 4001 seconds, because every read beyond the first happens at the same time as a write.

And if your block size is 1 byte, then in theory the transfer would take almost exactly 4000 seconds... except that now the system is running in circles ferrying a single byte at a time, so your throughput drops to something much less than 1 MB/sec.

In practice, a 1 MB block size works fine on modern systems, and there's not much to be gained by fine-tuning.

This reminds me of assertions we used to take for granted about DRAM. We used to assume that the contents are lost when you cut the power, but then someone turned a can of cold air on a DIMM. We usually assume that bits are completely independent of each other, but then someone discovered the row hammer. The latter is especially interesting because it only works on newer DIMM technology. Technology details change, and it's hard to predict what the ramifications will be. A little extra caution isn't necessarily a bad thing.

I think you're overstating how bad things are. Dreamhost, for example, no longer requires a dedicated IP for SSL, though they do still recommend it for e-commerce. They are charging $15/year for a CA-signed certificate. Granted, that's for a single-site cert and they don't support wildcards under this scenario, but the vacation blogger isn't likely to need that anyway.

The main reason I would think it's a good choice is because if you decide to get a CA certificate later, you just drop it in and you're done; no additional configuration required.

If you don't have a CA certificate, you're probably not advertising your https:// URLs anyway, so unless search engines are aggressively looking/prioritizing for https transport, it wouldn't seem to hurt anything to run a self-signed certificate there.

You can tunnel through HTTPS too, given a client/server pair that supports HTTP CONNECT. Conversely it's possible to disable the SSH port forwarding function. From the firewall's point of view, they ought to be equally risky.

Even if you did do this, any server implementing SYN cookies would ignore the payload and require you to retransmit anyway.

Yes, it makes the passphrases a lot more memorable. But when there's guaranteed to be at least one taboo word in a passphrase (and it looks like 2+ is likely even with only four words), I think it's reducing the search space too much.

I think Schneier was assuming here that the user chooses the words himself rather than using a random generator. It's a fair assumption, given that most people won't actively seek out tools to help them make up passwords.