Submitted by DragonFlyBSD 1.12 has been released. “This release is primarily a maintainance update. A lot of work has been done all over the kernel and userland. There are no new big-ticket items though we have pushed the MP lock further into the kernel. The 2.0 release is scheduled for mid-year. Of the current big-ticket item work, the new HAMMER filesystem is almost to the alpha stage of development and is expected to be production ready by the mid-year 2.0 release.”
Keep an eye on this one. Kerneltrap has been following many of the HAMMER status updates for those who are interested. It’ll be exciting once Dillon gets it working properly.
Now I can use the DVD-ROM drive in my server (for the first time ever, in fact—this machine’s always run DFBSD).
here are the release notes, and links to ISOs.
http://www.dragonflybsd.org/community/release1_12.shtml
What’s the current relationship between FreeBSD and Dragonfly. I remember the split several years ago, with DF wanting to rearchitecture a few things to make the whole system cleaner. Did this split make code sharing between the two projects more difficult, or is there a significant amount of cross pollination? Anyone who knows?
Drivers and userland bugfixes are mostly what gets shared. Anything to do with their MP architectures, VFS systems, third party package management are now too different for any meaningful sharing of code to occur.
Except that said rearchitecturing is being left on the line because Dillon suddenly figured he needed to focus on his magic new filesystem.
“Except that said rearchitecturing is being left on the line because Dillon suddenly figured he needed to focus on his magic new filesystem.”
Not exactly true.
Most of the work that has been done in DragonFly since it was first introduced in 2003 has been code cleanup and implementing the new MP architecture (lockless replication of subsystems across available cores, message passing subsystem used for IPIs and communication between threads on different cores), as well as basically rewriting the VFS subsystem in order to make it ready for the Project’s clustering goals.
There are still some parts of the kernel that are not yet MP safe, such as the I/O subsystem which invariably gets called by everything in the kernel that is already MP safe. Its something that needs to be dealt with before DF will be winning any scalability benchmarks, but if you’ve been keeping an eye on the mailing lists and reading the notes for each release, you’d notice that the global kernel lock gets pushed farther out of the way as time goes on.
Unrelated to what you mentioned in your post, there are some nifty things that DragonFly can do that FreeBSD currently can’t, such as surviving something as simple as having a mounted USB thumbdrive being yanked out without panicing the system.
Also due to the fact that the process scheduler is implemented on top of the kernel threads scheduler, it is at least in theory trivial to for pluggable userland schedulers to be implemented. DragonFly jails can have unique IP addresses, something that is still a work in progress on FreeBSD.
It would also be a shame to forget about DragonFly’s virtual kernel architecture. FreeBSD has nothing like it (yeah, Linux has had the equivalent for years. Bastards ;-).
Yes, FreeBSD is finally able to show off the scalability they’ve put years of work into, but I wouldn’t discount the DragonFly folks just yet. There’s just more work to be done. Both systems have been heavily modified over the last several years, but of the two there have been far fewer growing pains in the DragonFly camp.
Edited 2008-02-28 14:56 UTC
Could you explain what you mean? I must be missing some subtle detail. FreeBSD jails require unique (from the host) IP addresses already.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-int…
————————————————————-
A jail is characterized by four elements:
…
* An IP address — this will be assigned to the jail and cannot be changed in any way during the jail’s life span. The IP address of a jail is usually an alias address for an existing network interface, but this is not strictly necessary.
————————————————————-
Common, DragonFlyBSD’s direction depends on Dillon’s mood. At first it started as gentle continuation of FreeBSD 4.x. Then later all of a sudden he said: “F**k gentle FreeBSD 4.x continuation! I’m gonna re-engineer it AmigaOS style!”
And even later: “I have an idea for a file system. It has nothing to do with my AmigaOS-inspired re-engineering, but whatever.”
I’m not bashing DragonFlyBSD. It’s a nice research OS.