- Security
- Whats New in 3.9?
- Money and a Free OS
- Why Should I Care?
- The Future of OpenBSD
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Future of OpenBSD
The OpenBSD project is continuing to move forward, in its traditional incremental fashion. The OpenBSD release schedule calls for a release every six months and so there are usually few user-visible changes between releases.
One area that has undergone a lot of work recently is ACPI support. Producing a complete and correct ACPI implementation is a significant amount of work, and unfortunately isn’t all that is required. A great many ACPI "compliant" BIOSes have significant bugs that need to be worked around. Future releases are expected to contain gradual improvements to this, making OpenBSD an even better choice for laptop deployment.
In 2004, the first OpenBSD release to support SMP was created. The original BSD kernel was designed to run on PDP-11s, and later VAXen, both of which were single-processor designs. As such, the kernel is not designed for concurrency. The simplest way of supporting multiprocessing systems is to put a Big Giant Lock around the entire kernel, ensuring that only one userspace program is allowed to be executing a system call at a time. This was the strategy adopted by older FreeBSD releases, and was the initial step for OpenBSD.
The Big Giant Lock strategy is guaranteed to be correct, because the kernel is still effectively behaving as a single process, and it allows multiple userspace programs to be run concurrently. Unfortunately, it does not scale well. Most programs spend around 10 percent of their time executing system calls. This means that with 11 concurrent processes, you are guaranteed to have at least one waiting for another to complete a system call. Owing to the birthday paradox, this probability doesn’t drop to 50 percent until you have a much smaller number of tasks, meaning that you need significantly more active tasks than processors for this scheme to provide much performance benefit.
The next step, therefore, is to gradually move subsystems out from this lock into a finer-grained system. The correct strategy for doing this is the matter for some debate. In the FreeBSD world, a disagreement over the best strategy led to the forming of DragonFly BSD, which is adopting a microkernel-esque approach with concurrent components communicating over a simple message-passing interface, while the main FreeBSD branch continues to use more traditional threads and locks method. Whatever approach is used, it is very easy to introduce potentially exploitable bugs caused by unforeseen interactions between concurrent components. For this reason, the OpenBSD team is being very careful and methodical about the addition of greater degrees of parallelism into its kernel.
OpenBSD, while perfectly usable on desktop and laptop systems, is traditionally seen as a server operating system, and a lot of development is focused on supporting this use. As such, one significant focus for both current and future development work is better support for RAID hardware. OpenBSD already boasts the only fully open implementations of drivers for a range of RAID hardware, as well as a uniform RAID management interface, and this support is growing.
While the exact future course of OpenBSD depends on the whims of the developers, it is certain that it will continue to provide good clean code with a simple and well documented user interface.
OpenBSD is not the flashiest of operating systems, and not one that gets a lot of attention. My impression of OpenBSD is that it does for the command line what Apple does for the GUI—things Just Work, and work as you would expect them to. Most of the great features of OpenBSD are only apparent when using a system which lacks them.