(no commit message)
authortuxillo <tuxillo@web>
Thu, 17 Jan 2019 18:32:06 +0000 (18:32 +0000)
committerIkiWiki <ikiwiki.info>
Thu, 17 Jan 2019 18:32:06 +0000 (18:32 +0000)
history/index.mdwn

index e936b55..73fd4f9 100644 (file)
@@ -2,7 +2,7 @@ A technical introduction: The ultimate goal of the DragonFly project at its ince
 
 DragonFly BSD was forked from FreeBSD 4.8 in June of 2003, by Matthew Dillon. The project was originally billed as "the logical continuation of the FreeBSD 4.x series", as quoted in [the announcement](http://lists.freebsd.org/pipermail/freebsd-current/2003-July/006889.html), but this description has long since become obsolete.  From a performance perspective DragonFly's only real competitor these days is Linux.
 
-DragonFly BSD has been going through rapid and ever increasing development since the fork. One of the important works 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.
+DragonFly BSD has been going through rapid and ever increasing development since the fork. One of the important works 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. 
 
 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 to 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 regard to the third party applications and base system utilities needed to make any system usable in production. This resulted in the adoption of the [pkgsrc](http://www.pkgsrc.org/) framework for management of all non-base-system third-party applications in order to pool our resources with other BSD projects using this framework.