1. 34
  1.  

  2. 13

    Tangental: Please please do not name things this! It is effectively useless at his point. Alternative titles:

    • Long term support keeps bad code around longer
    • Linux fragmentation is inherently insecure
    • Long term support is at conflict with security
    1. 3

      Thank you for at least complaining about the title and not the post. :) I think many of the people citing Meyer’s article haven’t actually read it, because he’s clearly talking about the contents and tone and not just the title. That said, I believe in truth in advertising. If you don’t like considered harmful articles, you can save some time by not reading them. Sadly, that never seems to work as intended. The more clearly one marks an article as “not for you”, the more complaints it attracts. Sorry, a little tangent there.

      1. 5

        On the contrary, I liked the article a lot. But the title didn’t actually represent the article in any useful way.

        1. 3

          Future posts will be titled “short term support considered good” :)

    2. 5

      If that’s your viewpoint then why have a release at all? Just tell everyone to always use HEAD.

      (not entirely a strawman - I’m a happy Gentoo user)

      The advantages of doing releases - full scale integration testing of a particular set of versions over a weeks- or months-long “freeze” that you simply couldn’t do more frequently, providing consistent snapshots for application vendors to test against, and reducing the amount of admin time your users have to devote - all argue for making releases less frequent. There’s a balance to be struck to be sure, but the maturity of *nix (how many new features in OpenBSD 5.2 did you really need? If you were still running 3.8, would you notice anything missing?) seems to argue for less, not more frequent ones.

      1. 6

        OpenBSD does advocate that users run snapshots, so we’ve already gone to that logical extreme. And yes, we make releases for many reasons other than support. The integration and cooling down period ensures that future development will have a stable base to work from. Can’t let things get too hairy.

        Also, snapshots aren’t a good way of delivering targeted fixes. Sometimes you really need some patch, but if it lands in the tree at the same time as an untested feature, I certainly agree you don’t want both. So releases do have their place.

        You may think you’re happy running 3.8, but there have been many security fixes since then that weren’t issued errata, much like ghost. That’s my entire point. For two examples:

        OpenBSD used to use RC4 to generate random numbers before the switch to chacha20. It contains some mitigations against the more popular attacks, and the way it’s used means it’s going to be difficult to exploit. But that doesn’t rule out some dedicated individual figuring out exactly how to exploit the biases and predict TCP ISNs, for instance, and then you’re going to have bad day.

        More recently, several leaks in Open(now Libre)SSL were fixed. They appeared to be in functions that weren’t normally used. Turns out, due to the wonders of OpenSSL, they were network exposed in all servers. 5.5 needed a patch, 5.6 didn’t. If you upgraded to 5.6 at a convenient time, you didn’t need to do a forced patch of 5.5.

        1. 2

          If that’s your viewpoint then why have a release at all? Just tell everyone to always use HEAD.

          I think that is certainly fine for developers and people working on the OS itself, but end users generally want to spend as little time as possible managing updates. I think OpenBSD’s release cycle strikes a very nice balance. End users aren’t constantly updating, but the current release/support lifetimes do not appear (from the outside) to be holding back development of the OS much either.

          In contrast, as a FreeBSD user, I think FreeBSD’s long support lifetimes are too long. I imagine people managing large corporate networks would disagree with me though.

        2. 2

          Generally agree, but

          No one upgrade is likely to end in disaster because there simply isn’t enough change for that to happen.

          The recent ABI change did create a major headache with my colo server. It’s in a different state and I don’t have remote management on it. I think that may have been the most painful upgrade since I was a full-time sysadmin (a number of years ago). I ended up having to fly out to fix it, but the system was unusable for a few weeks until I was able to arrange that. I’ve now virtualised it, so it won’t be a problem in the future.

          Fortunately, the software in the OpenBSD packages has an excellent track record of working stably and the custom software I deploy is statically built. Upgrades are almost never something I think about; I run openup regularly, and schedule an upgrade every six months.

          1. 3

            I think the question is, if upgrading from 5.4 to 5.5 was painful, do you think upgrading from 4.5 to 5.5 is somehow going to be less painful?

            1. 2

              Less painful? No. Less than 10x as painful? Maybe, and that’s the real question.

              1. 1

                Wasn’t a question I had. Jumping forward 5 years is probably going to be painful even without an ABI change.