X-Git-Url: https://gitweb.dragonflybsd.org/ikiwiki.git/blobdiff_plain/ab1715732b80974b774d1677a79e080a2b46334a..aeec5c3ced6d3278aaebab4450718d91d035ae5a:/history/index.mdwn

diff --git a/history/index.mdwn b/history/index.mdwn
index c8a812da..2443087d 100644
--- a/history/index.mdwn
+++ b/history/index.mdwn
@@ -1,24 +1,15 @@
-DragonFly BSD was forked from FreeBSD 4.8 in June of 2003, by Matthew Dillon. The project is "the logical continuation of the FreeBSD 4.x series", as quoted in [Matthew Dillon's announcement](http://lists.freebsd.org/pipermail/freebsd-current/2003-July/006889.html).
+A technical introduction: The ultimate goal of the DragonFly project at its inception was to provide native clustering support in the kernel. This type of functionality requires a sophisticated cache management framework for filesystem namespaces, file spaces and VM spaces. These and other features eventually culminate in the ability to allow heavily interactive programs to run across multiple machines with cache coherency fully guaranteed in all respects. This also requires being able to divide resources, including the cpu by way of a controlled VM context, for safe assignment to potentially unsecured third-party clusters over the internet. This original design direction, although no longer the primary goal of the DragonFly BSD project, has influenced many of the design decisions made in the intervening years. While full cache coherency is no longer a top level goal, filesystem coherency is, and that direction continues to guide the project in a number of ways.
 
-DragonFly has been going through rapid development ever since, working towards the goal of creating a single system image across multiple computers. In the process of moving towards this goal, improvements to the code have been made and changes from other BSDs have been brought in.
+DragonFly has been going through rapid and ever increasing development since the fork in 2003. This work has included the simplification and general cleanup of the majority of the kernel subsystems. This work was originally intended to support single system image clustering, but has had the effect of making the kernel much more reliable, understandable and easily maintainable. One of the fundamental synchronization concepts that DragonFly uses throughout the kernel, the token, lends itself directly to ease of maintenance and understandability of the kernel.
 
-From 2003 (when DragonFly first forked from FreeBSD), to early 2007,
-the DragonFly project focused on rewriting most of the major kernel
-subsystems to implement required abstractions and support mechanics
-for the second phase of the project.  This involved a great deal of work
-in nearly every subsystem, particularly the filesystem APIs and kernel core.
-During all of this we have managed to keep the system updated with regards
-to the third party applications and base system utilities needed to make
-any system usable in production.  We have also adopted the [pkgsrc](http://www.pkgsrc.org/) system for
-management of all non-base-system third-party applications in order to pool
-our resources with other BSD projects using the system.
+During the first major phase of the project, which lasted until early 2007, the DragonFly project focused on rewriting most of the major kernel subsystems to implement required abstractions and support mechanics for the second phase of the project, which at the time was intended to be single system image clustering. This involved a great deal of work in nearly every subsystem, particularly the filesystem APIs and kernel core. During this time a paramount goal was to keep the system updated with regards to the third party applications and base system utilities needed to make any system usable in production. This resulted in the adoption the [pkgsrc](http://www.pkgsrc.org/) system for management of all non-base-system third-party applications in order to pool our resources with other BSD projects using the system.
 
-In the 2007-2008 time-frame a new filesystem called [[HAMMER|hammer]] was developed
-for DragonFly.  HAMMER saw its first light of day in the July 2008
-2.0 release.  This filesystem has been designed to solve numerous issues
-and to add many new capabilities to DragonFly, such as fine-grained
-snapshots, instant crash recovery, and near real-time mirroring.
-The Hammer filesystem is also intended to serve as a basis for the clustering
-work that makes up the second phase of the project.
+In the 2007-2008 time-frame a new filesystem called [[HAMMER|hammer]] was developed for DragonFly. HAMMER saw its first light of day in the July 2008 2.0 release. This filesystem has been designed to solve numerous issues and to add many new capabilities to DragonFly, such as fine-grained history retention (snapshots), instant crash recovery, and near real-time mirroring. The Hammer filesystem is also intended to serve as a basis for the clustering and other work that makes up the second phase of the project.
 
-Further information on the project goals and status are available on this website, and discussion of the project is possible on a variety of newsgroups and mailing lists. 
+Recently, many developers have focused on SMP scalability while others have put an emphasis on new feature development and driver porting.  The VM system was finally fine-grain locked all the way down to the pmap in late 2011, resulting in huge performance gains on many-cores machines.  Further and more up to date information on the project goals and status are available on this website, and discussion of the project is possible on a variety of newsgroups, mailing lists and IRC.
+
+DragonFly BSD was originally forked from FreeBSD 4.8 in June of 2003, by Matthew Dillon. The project is "the logical continuation of the FreeBSD 4.x series", as quoted in [Matthew Dillon's announcement](http://lists.freebsd.org/pipermail/freebsd-current/2003-July/006889.html).
+
+The original photograph that inspired the name:
+
+[[!img /images/mascot.jpg alt="Fred"]]