I bought a cheap Brother laser printer 20 years ago, and it works great today. Just plug in the USB cable, and it works on a modern machine with no extra drivers or software. (It's old enough that it still also has a parallel port on it.)
I recently replaced the toner and drum with third-party ones, and they work fine - no vendor lock-in.
Starting the car takes a lot of power from the battery (the battery has to run the starter motor to crank the engine), so if you don't drive the car long enough to recharge the battery to at least where it was before the trip, you'll have less charge than you had before. If you repeat that cycle enough times, the battery will eventually die.
The guidelines also say: "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
In this case, assuming good faith would be assuming that @ordx is stating a fact that they're aware of, not trying to stir up controversy. If you were interested in finding out how they knew that, you could politely ask them what their source of information was, without implying that they have ulterior motives.
I'd say it's a bug, since the unsound statistical methods are incorporated into the three most common software packages that are specifically intended to be used for fMRI analysis. If these methods don't work well for fMRI data, fMRI software shouldn't be using them.
From the paper: "Using this null data with different experimental designs, we estimate the incidence of significant results. In theory, we should find 5% false positives (for a significance threshold of 5%), but instead we found that the most common software packages for fMRI analysis (SPM, FSL, AFNI) can result in false-positive rates of up to 70%." (http://www.pnas.org/content/early/2016/06/27/1602413113.full)
Choosing a bad algorithm for your software is as much of a bug as a null-pointer crash, and is something that needs to be tested for when building software.
This happened to me, and is one of the reasons I quit being a manager and went back to being a developer. The product didn't actually fail, but the daily stress of constant interruption and long hours of slogging through thankless shitty tasks eventually wore me down.
Also, I regret not having delegated some of those boring and shitty tasks, since they would have developed skills in my staff (like debugging under difficult environments) that would have made them stronger and more independent developers.
I think you're overestimating the impact of the Morris Worm - there weren't all that many servers to bring down.
The first commercial ISP in the U.S. was founded in 1989.[1] Until then, only a few people in universities and the tech and defense industries had access to the internet. According to this chart[2], the number of internet hosts in 1992 is barely distinguishable from zero on today's scale.
When the second edition was published in 1988, there were seasoned C programmers, but security wasn't nearly the issue it is today. Since there was no World Wide Web yet, most computer systems weren't exposed to a global network full of people who wanted to crack code for profit. There was no e-commerce, no on-line banking, etc.
In the U.S., if you're mailing a large number of items, you can get significant discounts for providing the mail to the post office pre-sorted by the 9-digit ZIP code. To take advantage of that, your address schema would at least need to be able to extract that information.
One compromise would be to impose an address schema by default, but allow users whose addresses are incompatible with it to opt out of it and enter a free-form address.
