61–70 of 70 posts
Earlier quoted context omitted.
Solaris, the system were ease of use is an enemy.
Unlike other Unixen...
Tiny example, GNU ls:
ls -lh bla : ok
ls bla -lh : ok
Most non-GNU lses, second form : oh-oh! :)
I was expecting an error considerably larger than a fuel calculation which ended up giving a better race strategy in terms of surviving the first corner, and netted the same position overall as predicted! I used to prepare my own rally car (up to WRC level), and made many mistakes much bigger than that, but I guess that explains why he works for an F1 team and I'm currently looking for job!
I think you might have missed the point of the article. Excellence is not in avoiding mistakes, Excellence is learning from mistakes so you can do better next time.
Can someone explain this to me? I'm only familiar with the current regulations and so the logic of this paragraph doesn't make sense to me: > Back in 2006, the regulations required teams to qualify their cars with race fuel-loads. The trade-offs were obvious – load the car up with fuel and you’d end up further down the grid, but with the benefit and flexibility of adjusting your strategy in the race. By contrast, qua…
However, previously, there was refueling possible during the race, which allowed for some strategy variation:
- either you start with small amount of fuel, gain advantage due to lighter car (~1s faster per lap), and refuel early in the race (probably 2 refueling stops needed in such case)
- or start with bigger amount of fuel and stay longer on the track, but only do 1 stop for refueling
Also, since you needed to start the race and qualifications with same amount of fuel, going with less-fuel-and-double-refuel strategy meant you were more likely to win a pole position due to lighter car during qualifications.
Earlier quoted context omitted.
Particularities elided, I was working on a POC of pretty critical (possible damage) closed loop (tightly controlled by operator at the time) system - basically read inputs, react according to algorithm, rinse and repeat. Inputs, however, came from multiple unsynchronised sources and we could arrive at situations where output depended on multiple inputs. I guess we took pretty natural decision to use latest available…
So basically treat even invariants as possibly varying.
I guess rather well-known real world example is systems starting to show weird behaviour when database resultset ordering changes (e.g. changes in indexing) and someone relies on correct entry being first/last.
Assumed invariant here is resultset ordering and code is written with this particular invariant in mind. If not enough ordering clauses are used, resultset ordering is not invariant, even though it worked for years already :)
Earlier quoted context omitted.
We occasionally ship a build with the equivalent of 'DEBUG=true' to (parts of) production. Deliberately. For an extremely short time period. What that gains us is a run with real data and a build that's instrumented with assertions - which flushes out a lot of previously unknown issues. So yes, you learn useful things. If you ever did it accidentally, the useful thing you learn is that shipping ideally is not an on/o…
That's fascinating. Is there any reason to do this in production vs. a staging environment (assuming you've got one prod-like enough with replayed traffic)? It seems a little risky to me!
I'm working on desktop software, and this happens to builds that are full production builds, but that don't go to stable. So a very small subset of our users - who has agreed to being guinea pigs - occasionally gets these.
It also helps that we have a clear policy that assertions can only fire in cases that truly would be a bug in the wild - you can't assert and handle the issue. Either you think it might happen, then you handle it - or you state an invariant, in which case there's no reason to handle it being false. In other words, the only price you pay is that your build is slower - any assertion that fires would've been a silent bug before anyways. And, to be as close to non-debug as possible, any assertion firing merely creates a crash dump, it doesn't actually crash the executable.
And finally, we simply need to do it in the wild because many of our bugs are simply due to the staggering number of environments desktop software encounters.
Now I want to see an Honda F1 engineer followup