1. 32
  1.  

  2. 13

    This happens a lot in OpenBSD (and frequently related to ancient VM bugs as well), but the first step is always to back out. Regardless of cause, it’s important to have a working system. Then it can be investigated and fixed.

    “My code is correct, it merely triggers and existing bug” is small consolation. (Not saying that’s the FreeBSD attitude, but I’ve certainly seen it in other communities. People refuse to fix regressions on the grounds that it’s not their regression.)

    1. 4

      “My code is correct, it merely triggers and existing bug” is small consolation. (Not saying that’s the FreeBSD attitude, but I’ve certainly seen it in other communities. People refuse to fix regressions on the grounds that it’s not their regression.)

      To be fair, it is awfully dispiriting to do something that is correct, and be bitten by a pre-exisiting bug.

    2. 4

      Thinking is slow, while modern tools are very fast. You should only try thinking after you’ve done everything you can with tools/automation.

      1. 4

        What do you mean by this? For example, I think automation is the result of thinking in order to enforce invariants. But once those invariants are broken, one has to think. In what way did the author of this post not use automation in the way you are describing?

        1. 2

          You should only try thinking after you’ve done everything you can with tools/automation.

          And how do you know what to do with these tools and automation? You likely know because some thought has been put into what to do. Such “fast” things only become fast because of planning and forethought. (Note that “thought” in this case does not have to be done by the user of the “fast” things.)

          If what you mean is to have a plan to deal with getting things up and running again right away, then that’s fine. In this case, you should have a plan to revert the system to its previous state and assume/hope that it still works. (And I agree with @tedu here: that should have been the first step.) Perhaps such things can be automated. If so, great.

          If what you mean is that they are wrong to think about the problem and instead it is wiser to just start using tools, then I’m completely mystified as to how that would even work.

          I think you have things inverted here: you should be thinking well before you start doing much with tools.

        2. 3

          We had one of those today in the FreeBSD.org cluster. Every month we rebuild everything to make sure that we still can, and to make sure we find problems before you do.

          I really hope they build world more frequently than just every month.

          1. 7

            I believe this is specific to the production freebsd.org cluster running snapshots of HEAD, getting rebuilt every month and then actively used in a production setting. This is, from what I understand, completely separate from jenkins/CI doing frequent builds of HEAD and running various tests.

            1. 1

              They build continuously[1] but the official cluster servers are only updated to the latest revision once a month.

              [1] https://jenkins.freebsd.org