Running the development branch of a *BSD daily might sound scary. Indeed, this is basically the experimentations’ land and this use case seems to apply only to BSD developers – the internal APIs might suddenly change because they need to, some bugs can be fixed, some new ones can be introduced without notice (although in general, the community is quite reactive and fixes them fairly quickly). I am going to talk about the BSDs I know and use the most and I’ll explain the reasons for using the -CURRENT branches.
One of the main reasons which I use -CURRENT branches is simply having the latest innovations. In the case of FreeBSD, I like having the very latest version possible of clang because I am following the coming of some expected features, like OpenMP support and sanitizers support, because of the compilation effectiveness improvements, and so on. As I often use virtualized environments, having the latest bhyve features is a very good point. From a developer point of view, having new syscalls like explicit_bzero (which can be preferred in place of memset for some use cases, avoiding the potential compiler optimization …), ppoll for the Linux emulation layer are beneficial. Casperd pro-vides some services not available in capsicum’s capabilities mode and can be seen as a proxy, for example, for DNS resolution.
For OpenBSD, having the latest relayd/httpd features interests me (i.e., I run a custom version of relayd which produces some additional custom HTTP headers). I appreciate their “backward compatibility breaking fearless for the better good” approach (the recent change in random C API, for example, could confirm it). Indeed since the 5.6, the static Position Independent Executable support for base system binaries was added, the legacy deterministic rand C API was strongly updated, and so on.
I recently retried NetBSD, with LLVM/clang in base following their willingness to move towards it. After some days of usage, I noticed a general small performance drop (one of my custom applications got something like 5/10 percent of difference) but it is a generally well known problem with clang; it is improving through the releases.
Lastly, DragonflyBSD recently brought GCC 5.0 in base (with a bunch of new sanitizations flags, in addition to the OpenMP 4.0 specifications support). Also more generally, a lot of effort is made in the graphic stack. Having the last fixes for Hammer1 filesystem is worthwhile (i.e Hammer2 is still not production ready).
One of the downsides of running current is if you’re using a desktop environment or more generally the ports system. In general, when a significant change in the base system occurs, it is recommended to rebuild all the ports afterwards. The time needed to do so could be potentially quite important, especially with software like KDE, Gnome 3, etc. It is a point to weigh well.
For FreeBSD -CURRENT, I very rarely run a desktop. I prefer to use the whole potential CPU/memory for compiling the system instead. Also, the fact that I enable a significant amount of debugging kernel options which slow down the general performance (like WITNESS (to detect potential deadlocks) / INVARIANTS (which add more kernel level’s assertion) flags) stops me from considering it. Those specific options are only useful for developers or beta testers though. It is advised to disable them otherwise.
In the case of OpenBSD -CURRENT, I run time in time the base cwn which is very light and xorg (called xenocara) is not in the ports but in the base system, that makes those updates easier. In addition, I enable MALLOC_STATS, hence allowing the D flag for MALLOC_OPTIONS for debugging purposes with the cost at a performance hit. Again, this last one is not recommended if you are not a developer.
From a company point of view, if a new feature is genuinely needed and if it is not possible to do it internally, sponsorship might be considered an option.
Bug acceptability level
Indeed, the -CURRENT branches introduce potentially some new bugs. In the case of FreeBSD, for example, recently the Random Number Generator framework change, which was made pluggable, was found to be broken. Instead of coming back to the previous version, which sounds less risky, the issue was fixed – I personally prefer this kind of approach. On my side, I run FreeBSD with some local fixes (for bsdgrep, for example), some were merged upstream, hopefully some others will be in the near future.
In the case of OpenBSD, the new XHCI driver (for USB 3.0) still does not work completely. For example, recently a memory leak was found in dhclient (but fixed). But nothing really major, OpenBSD -CURRENT is runnable daily as well.
DragonflyBSD had memory leaks in the kernel and in hammer filesystem. Once again, they were fixed promptly.
The bug “acceptability” level depends on whether you’re willing to patiently take the time to make explicit bug reports in case the bug in question is blocking, or fixing them internally and pushing those fixes upstream. But there is no support to expect – again a point to consider well.
Contribution
Most of the contributions are done in the -CURRENT branches. That makes perfect sense as the -CURRENT branches are the perfect areas for both fixes and innovative features, adding disruptive changes whereas the releases/stables welcome the fixes only. It also makes more sense for -CURRENT that recompiling the system is the natural usage.
If you are a quite advanced BSD user and you wish to contribute to make them better for the whole community then using the development branches can be considered. There are many areas, not only purely technical (like the documentation) which can be improved.
DragonflyBSD uses git internally and due to its branching model, it is pretty handy to create a proper diff to submit it for review.
Conclusion
Most companies stick to stable/release versions with only security fixes. If your applications rely on specific API/ABI versions, it is indeed better to keep on doing it. Somehow, few others run experimental branches. Indeed. For example, Yahoo uses FreeBSD -CURRENT internally for their servers. Given the short life release cycle chosen by OpenBSD with its fair amount of disruptive changes (ie., every 6 months), it is less surprising to find users using the development branch.
I recompile quite often FreeBSD / OpenBSD base systems but for those who have no interest at all in doing it, some snapshots builds are made fairly often. Saying that, it is advised to be registered in the relevant mailing lists: freebsd-current@freebsd.org, tech@openbsd.org, tech@netbsd.org, commits@dragonflybsd.org.
ABOUT THE AUTHOR
David Carlier has been working as a software developer since 2001. He used FreeBSD for more than 10 years and starting from this year, he became involved with the HardenedBSD project and performed serious developments on FreeBSD. He worked for a mobile product company that provides C++ APIs for two years in Ireland. From this, he became completely inspired to develop on FreeBSD.
