Out of the BSDs, I would say DragonFly is the most innovative. Its implementation of virtual kernels, HammerFS, thread scheduling via message passing and it has been rock solid as an NFS file server, serving all my local media to other *nix nodes on my LAN. Wikipedia gives a great rundown on the innovations and why Matt decided to fork.
I would almost term it as a permanent research platform for FreeBSD. Never would I recommend someone run it in production, but if I'm looking for cutting-edge parallel OS techniques, Dragonfly is definitely on the short list. Come to think of it, it might be the only one on my short list—OS innovations seems to be driven by virtualization, container, filesystem, and network concerns more than anything these days.
>I would almost term it as a permanent research platform for FreeBSD
DragonFly BSD was forked from FreeBSD because of fundamental design disagreements between Matthew Dillon and the rest of the FreeBSD developers. Thus I doubt that the characterization as "research platform for FreeBSD" fits. You might as well say OpenBSD is a research platform for NetBSD.
As far as I know, all of the BSDs have adopted code from each other over time. It might simply be a side of effect of the common heritage and license, but it seems to be one that none of the people involved have a problem with and often consider desirable.
But that does not make Dragonfly a "research platform" for FreeBSD. Both systems have different priorities and goals.
(Although I wonder if any of the things that Dragonfly set out to do differently has been adopted back into FreeBSD?)
Unfortunately, little if any of the development is ported in the direction Dragonfly -> FreeBSD.
The last time somebody tried porting HAMMERFS it was discovered that the systems are already divergent enough that it would be a huge job because to stay true to form, other Dragonfly's systems upon which HAMMERFS is built would also need to be ported, and as such systems include such basic stuff as the threading model, the effort was abandoned.
Just listened to this BSD Talk episode yesterday. Matt is doing some extremely interesting work, not only on the kernel and file system research side, but also in terms of their completely customised networking stack, which utilises multi-core non-blocking networking I/O to achieve really high speeds. I would like to see some of that incorporated back into the FreeBSD kernel (not sure if it has been done, but I doubt it).
"The drm/i915 driver is now mostly based on the Linux 3.8.13 implementation and is no longer similar to the FreeBSD driver. Many Linux APIs and data structures have been implemented in the DragonFly kernel in order to reuse as many parts as possible of the Linux drm/i915 code without modifications."
I was wondering how did they deal with licensing issue. I thought Linux drivers are all under GPL. And DragonFly is (obviously) under BSD. Then I've noticed gpu/drm/i915 has a permissive (MIT?) license. E.g.:
The DRM code itself as well as most of the drm drivers is under a MIT/X11 license.
It was only integrated in Linux in 2008 (not 100% sure of the date) and was maintained in a separate tree before that. It also had to be compatible with X11, hence the choice of license.
This is great news, the DragonFly project keeps doing really interesting things. The interview linked elsewhere in the thread give a good overview of how the project is doing. Matthew Dillon mentions in the interview that DragonFly will be able to be much more than an experimental operating system.
This project has intrigued me for a long time. I seriously believe it could eventually become the premiere BSD-flavor OS. Although given all the low-level changes they've made it may not be easy to "label" it BSD in the future.
FreeBSD itself has diverged significantly from its own 4.x release, which is where DFBSD forked. I would still call DragonFlyBSD a "BSD" now and in the future since it still leverages a lot of work from FreeBSD (and other BSDs) to this day. It would be stupid to not continue to leverage the upstream work.
Agreed. I think it's a fantastic ecosystem, and they should all continue to feed off one another. A great example was discussed in the interview. The decision to integrate FreeBSD ports will almost certainly make it easier for folks who are considering adopting / experimenting with it. (not a recent decision, but an important one)
I would say the primary identifier of BSD systems are their interface with the kernel, the userland, and the license. DragonflyBSD is a true BSD to the kernel; the implementation details may differ, but you can compile most freebsd code for dragonfly with no changes and have it run perfectly (or as well as dragonfly can swing it).
"While DragonFly was forked off FreeBSD and has generally quite a few similarities to other *BSD, you definitely cannot rely on understanding FreeBSD to understand what's going on here."
The first OS to drop 32 bit support, thus eg fixing the year 2038 problem the easy way. Not sure if any others will though, at least not until arm64 is more widespread.
I'm not sure PC-BSD qualifies as an OS unto itself.
Last time I checked, they were mostly a FreeBSD distribution with a bunch of user friendly sugar coating on top (an easier package manager, default installation includes a fully configured desktop environment, ...)
I don't mean that as a bad thing - I used PC-BSD for a while and it was great. Not everyone needs to reinvent the wheel and reimplement drivers etc. But I see it more as a distribution of an OS than an OS.
The graphics support sounds neat for (developer) workstation usage, hope it gets at least a basic suspend/hibernate support soon to complete the picture.
What single feature/change caused this to be a major release as opposed to a minor release?
In reading the OP link, nothing in particular stood out to me.
(Please don't take offense to my statement. The changes are all great. I'm just typically use to major releases to be when something foundational has changed and I'm just not seeing that here)
Version numbers are arbitrary. Sometimes an incriment denotes features, sometimes it is age. And sometimes version numbers get incremented just for publicity.
> Despite this, the DragonFly BSD and FreeBSD projects still work together contributing bug fixes, driver updates, and other system improvements to each other.
True, but there are many issues that might not seem obvious at first. For starters, XNU is _not_ a FreeBSD kernel. It’s a hybrid kernel, there is a Mach 3 based kernel at the very bottom with a FreeBSD kernel ontop. Mach takes care of providing, well, Mach IPC, but also virtual memory, threads, processes, scheduling and all that kind of stuff. The FreeBSD part is, in a lot of ways, only a shim down into Mach land, but also brings its own systems like the VFS and networkstack and most of the other userland facing things.
I feel like it would be very non-trivial to switch to DragonFly BSD, because then a lot of the shims have to be re-designed in order to still work, simply because of the highly different design of DragonFly BSD. Disclaimer: I haven’t studied the DragonFly BSD source code yet.
http://en.wikipedia.org/wiki/DragonFly_BSD