Readit NewsHmm I'm pretty sure practically every programming languages have it. It usually looks like "!=" or "<>".
The even more obscure logical XNOR is usually denoted "==" or "="
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.
grep = my_file
env1=foo env2=bar env3= my_program
I still think that self-driving stuff should be more enhanced cruise control and less "there is no steering wheel or controls".
Google has been making arguments along these lines -- for instance: http://gizmodo.com/why-self-driving-cars-really-shouldnt-eve...
dd if=/dev/zero of=/dev/sdXXX bs=1048576
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.
I believe there is a long standing bounty for anyone who can retrieve useful data from a drive that had been zero'd once. No one has been able to thus far.
A lot of the disk wiping "culture" stems from a much earlier time when disk technology was less reliable, especially in regards to writes. Dan Gutmann himself says that the Gutmann method is long antiquated and only worked with MFM/RLL encoded disks from the 80s and early 90s.
Perhaps instead of humoring these people, we should be educating them. A zero'd out disk is a wiped disk until someone proves otherwise.
Yes, the hosts could wildcard. Yes, there are other solutions out there. But for the average Joe who is blogging about his vacations and family? They're going to be completely lost.
Why don't shared hosts just wildcard? Shared certificate? Well, let's think about it... Charging ~$5/month/dedicated IP is a nice upsell, and getting $70 for an installed SSL cert that costs them $10 from their SSL cert reseller, that takes them 2 minutes to configure... That's a nice slice of pie. I'd take that bet any day.
If it's self signed, and going to throw massive warnings with a direct connection, shouldn't you use anything other than 443?
Any subtleties I should be aware of?
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.
> Testing your irrigation water won't keep the feedlot next door from blowing dried-up cow shit dust all over your lettuce. (Or, you know, into your irrigation water on a day when you're not testing). [1]
> It won't keep harvest crew co's from putting so much time pressure on crews that they can't clean their harvest rigs properly between shifts. [2]
> And it sure won't solve our traceability problem. There's no way in hell we're having this much trouble tracing the lettuce to its source, unless there's massive supply chain fraud going on. We should be worried about THAT. [3]
This one reminds me of a situation I ran into once:
> (You also have to ask, WHY would a farm or any other business target their testing towards when they're likely to get red flags? They don't want that. Any time you do testing, there are lots of ways to game it to lean towards clean results. Which is what farms & companies want.) [4]
We were installing a drinking water monitoring system at a rural retirement home (on well water), probably a couple hundred residents.
Up to that point, one of the tests they did was a manual daily chlorine level check. Essentially you need to have a certain amount of residual chlorine in the water at the point of use, which lets you know you you are putting enough in (if you put too little in, it gets used up as it's breaking down organics in the water, and you end up with a zero). If the level is too low, you have to report it and explain what happened and how you fixed it, and if it happens too much, inspectors will start looking closely at your practices and forcing fixes and basically nobody likes that.
The new system had continuous monitoring of several parameters, one of them being chlorine, and would record everything as well as send alerts to people if anything dangerous happened. The chlorine monitor was installed at the opposite end of the building from the water supply, trying be representative of the worst case 'point of use' level.
As soon as it was online, it started sending alerts every night in the middle of the night. The free chlorine level would drop starting late in the evening (as the usage dropped), and then somewhere between 2 and 5 am would drop below the alarm threshold, and around 6-7 am jump back to normal. The owner was pissed that we had screwed the system up, because they didn't have this problem before the monitoring system was in.
Of course what was happening was not new, it was just that as usage dropped off as the residents went to bed, the water in the pipes just sat stagnant, and residual chlorine was slowly used up to the point there was none left. The daily checks were usually done mid-morning, after there was a lot of use as everyone woke up, and so all the water in the lines was freshly chlorinated when the check was done.
For years, anyone getting water in the middle of the night was drinking technically unsafe water (it still had been treated and likely posed no real health risk, so long as there was no contamination in any of the pipes or fixtures), and all that happened was the situation was exposed.
We eventually added a solenoid to the end of the line, and programmed it so it would open and dump water when the chlorine level got low but before the alarm threshold, at least getting fresh water into the main distribution lines of the building and avoiding the alarm condition.
It always stuck with me that the owners reaction was not "Oh, thank you for finding and fixing a problem I didn't even know about before it got someone really sick" but more like "your stupid system made things WORSE, we should rip it out and go back to how it was before."
[1] https://mobile.twitter.com/SarahTaber_bww/status/10670961003...
[2] https://mobile.twitter.com/SarahTaber_bww/status/10670961010...
[3] https://mobile.twitter.com/SarahTaber_bww/status/10670961017...
[4] https://mobile.twitter.com/SarahTaber_bww/status/10670961060...
* 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.