The tweet has been removed?
Never trust a system that seems to be working
311–320 of 376 posts
Re: Never trust a system that seems to be working
#312[flagged]
Re: Never trust a system that seems to be working
#313In the self-driving context, this reminds me strongly of Tesla Autopilot. Good enough to work most of the time, but likely would end up in greater overall injuries/accidents per mile if actually enabled at scale. Waymo, Cruise, Aurora, and others are doing it the right way.
Well, I was driving home yesterday, and the integrated navigation map of my car was randomly rotating 180 degrees every few moments, just long enough to be noticeable on-screen, but then flipped back. I have no idea why (something in the compass integrated in the car? was GPS being hacked?). But the thought I kept having was "If I had a self-driving car, what would be the impact of this?". All I could think of was ho…
A proper self driving car will have more signals for orientation than just the compass.
Re: Never trust a system that seems to be working
#314Earlier quoted context omitted.
Similarly, the joke that the engineer’s second worst nightmare is, “it doesn’t work but it should”, while their worst nightmare is, “it works but it shouldn’t”.
That’s the surest way to nerd snipe some people. This code doesn’t work, and yet it does. After reading the commit history, it in fact never worked, and yet it has been up until yesterday. What in the actual fuck.
My favorite was C code that was roughly (all functions and variables h:
int bar;
...
foo()
{
if(bar) {
doX();
else
doY();
}
}
doY() had been broken for years but nobody ever set bar to be true; doX() was nevertheless being called. Setting bar to zero caused the buggy doY() to happen. Setting bar to one seemed to work, but would occasionally segfault.
Then someone explicitly initialized bar and got a linker error. Turns out in ye olden days of C, before "extern" was a thing there was a feature where variables that were initialized in no more than one compilation unit would be all coalesced by the linker. Before doY was broken, someone defined a function named bar, which then caused bar to have a non-zero (i.e. true) value. Someone later added some broken feature to "doY" and it passed all the tests because changing doY() didn't have any effect.
Re: Never trust a system that seems to be working
#315Earlier quoted context omitted.
Sure, except in this case foone has explained exactly why they dislike their stuff showing up on HN.
They also seem to hate Factorio itself, which is the reason that while they play it and tweet about it so much, they mangle its name. I don't understand it, but everyone is free to remove what they want from their own Twitter I guess.
FWIW re the mangling: According to foone, the reason they blank out the name is to avoid it showing up on searches for the game (automated or otherwise), which they say has led to a subset of fans of the game sending them transphobic comments because of the past drama and the presence of a trans flag on their twitter page.
But as you say, people can do what they like.
Re: Never trust a system that seems to be working
#316This is why 4-20 mA is a common signaling standard in industrial automation. 4 mA means zero and 20 mA means one. 0 mA means broken transmitter !
Another example is how garage door opener trip-beams work (the sensors that detect if something is in the way before lowering the door). The transmitter and receiver are wired in parallel and connected to a power supply through a series resistor. When the receiver receives the signal from the transmitter, it pulls the supply voltage down, which then causes the transmitter to stop transmitting, which then causes the r…
That sounds very complicated. What advantage does it have over wiring the two in series and having an open circuit indicate an obstruction?
edit: it gets you protection against one of the two failing closed, duh
Re: Never trust a system that seems to be working
#317This tweet has been deleted... I should have checked sooner, had too much trust that it'd still be working... I feel like there is a joke in there somewhere
Re: Never trust a system that seems to be working
#318Earlier quoted context omitted.
That’s the surest way to nerd snipe some people. This code doesn’t work, and yet it does. After reading the commit history, it in fact never worked, and yet it has been up until yesterday. What in the actual fuck.
My favorite was C code that was roughly (all functions and variables h: int bar; ... foo() { if(bar) { doX(); else doY(); } } Note that uninitialized globals in C are implicitly zero-initialized. doY() had been broken for years but nobody ever set bar to be true; doX() was nevertheless being called. Setting bar to zero caused the buggy doY() to happen. Setting bar to one seemed to work, but would occasionally segfaul…
You're missing the } and { around your else, btw. I'm only mentioning that because I immediately saw it and got ready to read a horrifying story involving the text "#define else".
Re: Never trust a system that seems to be working
#319Tweet was deleted?
Re: Never trust a system that seems to be working
#320the tweet was deleted :/