1. 6
  1. 5

    Wifi support (or lack thereof) is arguably the major weakness of FreeBSD when it comes to desktop. Glad to read that there are plans to improve things on that front.

    Server-side, I have adopted FreeBSD a few years ago, and I am very happy with it. Solid, coherent, understandable, well-documented. Keep it up and it simple!

    1. 1

      What’s the init system story like? I heard the BSDs use a shellscript-primary model; this surprised me, considering how well-integrated and non-kludgy pretty much everything else about BSD is, at least compared to Linux. As someone running BSD server-side, do you feel there are any downsides that would make InitWare or systemd a better-streamlined fit for server maintenance? Or not much difference either way?

      1. 2

        Not the starter of that thread, but as someone who has used FreeBSD in production for week over a decade now I want to point out that I think it’s common to imagine rc.d to be like the previously common init.d on Linux when it really is not.

        rc.d is a lot closer to what for example OpenRC has been offering on Linux. It’s by no means the same, but it’s certainly more streamlined to use the term you used. rc d feels almost like writing a config file, but gives you more flexibility when needed. It also has some nice benefits like being extendible and in rc.conf not only enable or disable services but being able to create custom options to for example make a slur of arguments to append to a command into a nice option for example to set a listen address using daemonnamw_address=localhost. Then there’s also a nice command line utility called daemon that can help with doing typical tasks like telling where logs go, how the restart behavior is, which i user to run a service as and so on.

        All of that makes a new init system way less of a priority, than it might have been on Linux distributions using init.d shell scripts. I really don’t think they have too much on common other than being init and written in shell. What you get when rc.d is way more structured, especially if you take a closer look like one would have to do when starting with systemd or any other as well

        1. 2

          Yes, FreeBSD’s configuration is based on text files and scripts. AFAIK, there has been some proposal for a more unified approach (more à la launchd rather than systemd): for example, read “The Init System Debate Relaunched” article in Jul/Aug 2016’s issue of the FreeBSD Journal.

          I haven’t mentioned that my experience with FreeBSD is not at a professional level—just for home servers. I like the feeling of being able to know exactly what the system is doing. With systemd, I feel like there is always something that I don’t understand. But that’s obviously just a consequence of my biased experience.

          1. 2

            It’s perhaps more accurate to say that the FreeBSD service management system is mostly implemented in shell scripts. For a long time, shell was the only memory-safe programming language that shipped in the base system (now Lua does as well), which meant that it was a good choice for anything that’s security-critical. rc.subr contains a lot of generic infrastructure for service management, including passing options to services, defining dependencies, and so on. Most RC scripts are almost entirely declarative, but because they’re also shell scripts the ones that need to do something custom are able to fall back to a more flexible programming language.