The 2.8.2 release of DragonFly BSD is now available, featuring significant advances in multi-processor performance based on DragonFly’s signature soft token locks. It also includes many feature advancements including: pf from OpenBSD 4.2, the Wifi stack from FreeBSD and DataMapper from NetBSD (with significant enhancements). This release also marks the return of the GUI image. See the release notes for full details.
At reading the teaser in Opera’s feeds reader, I thought “how many BSD variants are there?”. Why? Because of this:
The landscape seems crowded to me and since as I’m not into BSD systems, I thought I’d better ask the question here.
FreeBSD, NetBSD, OpenBSD, and DragonflyBSD are the most popular “flavors.” There are other flavors, but you’ll find that these four make up the bulk of *BSD systems.
These flavors are commonly confused with Linux distributions. Unlike Linux distributions, which all use the same kernel and really only differ in the userland tools they provide, each “flavor” of *BSD has its own kernel, own base system, own userland tools, and own package management system. Each *BSD flavor its its own full-featured OS.
All of the current *BSD’s are based on the original 4.4-BSD operating system. FreeBSD and NetBSD are direct ports, while OpenBSD and DragonflyBSD are forks of NetBSD and FreeBSD respectively. Since they share the same heritage, they also share a lot of code which makes porting tools easy. This is why you see DragonflyBSD using tools from other flavors and visa versa.
It is far less crowded than the linux variants (and better segmented), and there is far more code reuse.
There are 4 major BSD OSes (listed alphabetically):
* DragonflyBSD
* FreeBSD
* NetBSD
* OpenBSD
There are various permutations to each of these OSes (pfSense, FreeNAS, EchoBSD, PC-BSD, etc). However, these tend to build upon one of the 4 BSDs, with specific things added or removed to make it work in particular niche.
The BSDs tend to co-operate a lot and share code around (PF, wifi, and NIC drivers are great examples).
There are also commercial forks of BSD systems. For example, JunOS, used in Juniper routers, is a fork of FreeBSD.
And MacOS X uses a lot of FreeBSD and NetBSD code.
There’s also the original commercial BSD/OS, which is no longer available.
So, while there’s more than one BSD OS out there, the environment is nowhere near as crowded as the Linux distro environment.
Thanks to all for the information. The “crowded” qualification was due to ignorance on my end and hasty judgment I must confess. In fact, in the light of foldingstock’s comment, the differences are more fundamental compared to Linux distributions yet there are less “variants”/”flavors”…
Is there binary compatibility? Between DragonflyBSD and FreeBSD for instance? Or some sort of “acceptance” in the sense of one system accepting packages built for an ancestor?
I guess these four flavors are desktop OSes? Is the user base significant? At what level should BSD as a whole be placed? The same as Linux? or somewhere between Linux and the likes of AROS, MorphOS, Haiku, etc.?
DragonFly and FreeBSD do not have binary compatibility with one another. That said, DragonFly has preserved ABI compatibility since it forked from FreeBSD, so in theory FreeBSD 4.x binaries should run on DragonFly. To my knowledge nobody has tested this in recent history (years). I cannot speak with authority on the compatibility of NetBSD and OpenBSD, but I would guess that binary compatibility does not exist. Different threading implementations makes this problematic.
What all of the BSD’s do have, however, is a Linux binary compatibility layer. This isn’t an emulation layer, per-se, it is a separate system call vector. Basically this means that the BSD kernels support multiple “sets” of system calls, one set supports native programs, another supports Linux programs. There is/has been some support for other systems too, such as SVR4. This binary compatibility is complete enough to run Linux versions of Flash, Java and OpenOffice to name a few.
While there isn’t cross-BSD binary compatibility, generally software ports quite easily between the different BSD’s, because of their common ancestry. DragonFly, for example, uses NetBSD’s pkgsrc system and a large proportion of the software within that system compiled from the outset, without any additional patches.
No, there’s no binary compat between the BSDs. They are all separate OSes, with separate ABIs/APIs/etc. Just like you can’t (normally) run a RHEL 4.x binary on a Debian 5.x system, you can’t run an OpenBSD binary on FreeBSD.
You guess wrong. While they can be used as desktop OSes, and run the same GUI stack as Linux (Xorg, GNOME/KDE, XFce, etc), they are developed primarily as server OSes.
Considering all but DragonflyBSD are older than most (if not all) Linux distributions, I’d place them on the same level. lol However, if you just go by market share and mind share, they’re one rung lower than Linux, but way ahead of all the rest of the alternative OSes.
I think it makes sense to add that all four are used for professional, productive and commercial applications. At least NetBSD and OpenBSD also by governments. There are computers on the international space station running NetBSD and also the CERN is/has been using it for high performance networking.
I don’t know any other alternative operating system besides GNU/Linux achieving things like that. FreeBSD is used by every bigger computer/internet “related” company.
I wish PureDarwin had taken off. It could be a very good member of the team.
Just a quick note. These ones are sometimes called distributions, because they are BSDs with different software and settings.
While DragonFly, FreeBSD, NetBSD and OpenBSD are usually called derivatives, because they are forks of each other but in reality different operating systems. I’d consider MacOSX a of that family.
Very impressive given how little press they get
http://www.dragonflybsd.org/team/
— initrd (initial ramdisk/malloc disk) support.
— mkinitrd – A tool to generate an initrd image to be able to boot from crypto, lvm and other devices.
— libdevattr – A library giving access to additional information about kernel device nodes with an API that is mostly compatible with Linux’ libudev.
— udevd – A support daemon for libdevattr.
— kern_udev – A framework to associate optional information with device nodes.
— Imported lvm (Logical Volume Manager).
— Device Mapper imported from NetBSD.