A running description of activity related to DragonFly BSD.
Another piece of work by one of the fine students participating in Google Code-In is a new 2.8 installation screencast/video. Check it out at the following link:
DragonFly BSD 2.8 Installation Screencast on YouTube
If you have been following along but have not yet tried DragonFly, this should evidence how easy it is — wait not a second longer!
See the announcement and the release notes.
The index page of the DragonFly site has been updated by Matt Dillon with some notes regarding the status of the 2.8 release. Among these, it is mentioned that the GUI image will be making a return for 2.8! There will be no DVD image this time, only an image suitable for writing to a disk, such as a usb stick.
Matt Dillon and Venkatesh Srinivas conspired to fix another nmalloc issue, which should resolve any remaining problems people were having with Firefox, and possibly other applications as well. Due to an oversight of sorts, all locking operations on nmalloc’s depot were ineffective, as if there were no locking at all. Curiously, it worked remarkably well considering such a large race condition was present.
Matthew Dillon sent an email to the kernel list detailing the performance improvements that he and Alex Hornung have recently made to dm_crypt and opencrypto. The disk encryption work does still come with a warning, however.
Matthew Dillon reports that DragonFly now has a catastrophic recovery tool for HAMMER filesystems, with pertinent details.
Matthew Dillon has provided some details about recent kernel work, along with a release forecast.
You have probably seen reports declaring the demise of OpenSolaris by now, many taking a less than conservative approach in reporting the news one way or the other. So what do you make of the news? By all accounts, the source code (including future changes) for things such as ZFS will continue to be published under the CDDL. Will Oracle closing up development make it impossible for operating systems like FreeBSD to maintain ZFS without forking it? What do you think the ramifications will be for DragonFly’s HAMMER and DragonFly in general?
DSCHED_FQ was added to GENERIC, making it the default disk scheduling policy for master. You might want to refresh your memory of dsched and the fairq policy with some prior details and benchmarks.
Update: As Venkatesh Srinivas pointed out in the comments, adding DSCHED_FQ to GENERIC does not make it the default, but you no longer have to load the fairq module. Which raises the question, should fairq be the default?
The libevent library has been removed from the repository to ease the maintenance burden. There is some additional rationale in this tracker issue.