Bitrig.org describes this new BSD operating system as "Bitrig is a free, fast, secure, and highly portable Unix-like Open Source operating system. It is available on current hardware platforms. The source code is freely available under a non-viral license." This doesn't say too much, aside from that they're only targeting current hardware platforms, unlike the many obscure architectures where OpenBSD is supported. The primary Bitrig architectures will be i386 and amd64 (x86_64).
The Bitrig Roadmap reflects some of the planned features compared to OpenBSD as providing KVM virtualization support, WAPBL as a journaling file-system, ARM support for the Beagle Board and Panda Board, fine-grained multi-processor support by eliminating the big-lock, FUSE/puffs support, support for the latest GNU binutils, and porting libc++ to Bitrig.
Not all of the planned work for Bitrig is surprising. Bitrig has already migrated from using the GNU Compiler Collection to using LLVM/Clang as its default build compiler. FreeBSD already moved to Clang in an effort to deprecate GCC from the other popular BSD distribution. The move to libc++ has also been sought after by other BSDs to get rid of the GPL-licensed libstdc++ library.
As far as why Bitrig was forked from OpenBSD, the project explains, "OpenBSD is an amazing project and has some of the best code around however some of us are of the opinion that it could use a bit of modernization. OpenBSD is a very security conscious project and inherently it has to be more conservative with features. We want to be a bit more loose when it comes to experimenting with features."
The Bitrig FAQ describes the project goals as being:
- Target actively developing hardware only. Legacy platforms are fun to hack on however we are trying to go along with new trends.As far as whether Bitrig will succeed as a viable BSD distribution remains to be seen. It was just yesterday that I brought up the Magenta Project operating system that pairs the Linux kernel with a Darwin/BSD user-land and iOS 5.0 binary compatibility.
- Make the base system as small as possible in order to be able to run on embedded systems.
- Use social networks to disseminate information and news.
- Try to become an incubator for students who wish to contribute via GSoC and internships.
- Be a very commercially friendly code base by using non-viral licenses where possible.
- We are aiming to have long lived releases and paid for maintenance (this process is still being defined).
- Do a major release every year with a quarterly RC (Release Candidate). Snapshots will be provided throughout the year as well.