1. 18
  1.  

  2. 5

    The video of this talk is here.

    1. 4

      I have/had been a FreeBSD user since 2.2.5 (which according to their release page was Oct 1997), and I really wish they’d find a way to figure out stability when transitioning from current -> stable. Maybe the releases are too ambitious? Maybe most of the developers jump on the more exciting -current and consider -release dull? I have no idea. The final straw for me (worse than the 4.x to 6.x transition) was that both 9.0 and 10.0 were unusable for one reason or another, and I hate having to say/support “wait until the x.1 release for stability” to use something.

      In contrast, every OpenBSD release is RELEASE+0.1, and every release is reliable, stable software. On a personal level, I also like that they fix larger design issues without renaming/requiring relearning everything: the package tools are still pkg_*, power management is still apm (even if it’s leveraging more ACPI than old-school APM), etc.

      1. 1

        OpenBSD still has the problem of -stable being left out in the cold to be picked up by third parties, which you may not trust

        1. 1

          That’s not been my experience in the past 5 years. MTier’s stable packages are nice for convenience, but far from required.

          1. 1

            I do use their packages, but I’m aware of users who want it to be from the trusted first party and expect it from other OSes.

            And you do need -stable, unless you don’t want patches.

      2. 4

        Slide 33 kind of throws out the recommendations of another story: http://blog.lusis.org/blog/2014/11/20/systemd-redux/

        All the people here and on HN saying they’re moving to FreeBSD to get away from things like systemd are going to be in for a surprise.

        1. 4

          The systemd issue isn’t with the launchd style init, it’s how systemd is changing the Linux ecosystem. See my comment here. Building on that, a launchd / systemd like system wouldn’t be a big stretch for BSD init, which is already a declarative system thanks to run_rc_command style scripts. See this example from the rc(8) page:

          #!/bin/sh
          #
          
          # PROVIDE: foo
          # REQUIRE: bar_service_required_to_precede_foo
          
          . /etc/rc.subr
          
          name="foo"
          rcvar=foo_enable
          command="/usr/local/bin/foo"
          
          load_rc_config $name
          run_rc_command "$1"
          

          So really, this wouldn’t be THAT big of a change for FreeBSD. Especially compared to what is happening with systemd and Linux, a situation with many other latent problems that go far beyond one boot strategy over another.

          1. 3

            I don’t think Jordan is really driving FreeBSD development. He can say it would be nice, but that won’t make it happen. (There are others, however, who could probably push such a change through.)