Question

what is the operation for DragonFly BSD

DragonFly BSD os structure

Answer 1

DragonFly BSD: The DragonFlyBSD operating system is a fork of the highly successful FreeBSD operating system. Its goals are to maintain the high quality and performance of the FreeBSD 4 branch, while exploiting new concepts to further improve performance and stability. In this paper, we discuss the motivation for a new BSD operating system, new concepts being explored in the BSD context, the software infrastructure put in place to explore these concepts, and their application to the network subsystem in particular.

DragonFly BSD is a free and open-source Unix-like operating system forked from FreeBSD 4.8. Matthew Dillon, an Amiga developer in the late 1980s and early 1990s and FreeBSD developer between 1994 and 2003, began working on DragonFly BSD in June 2003 and announced it on the FreeBSD mailing lists on 16 July 2003.

Dillon started DragonFly in the belief that the techniques adopted for threading and symmetric multiprocessing in FreeBSD. would lead to poor performance and maintenance problems. He sought to correct these anticipated problems within the FreeBSD project. Due to conflicts with other FreeBSD developers over the implementation of his ideas,his ability to directly change the codebase was eventually revoked. Despite this, the DragonFly BSD and FreeBSD projects still work together, sharing bug fixes, driver updates, and other improvements.

Intended as the logical continuation of the FreeBSD 4.x series, DragonFly has diverged significantly from FreeBSD, implementing lightweight kernel threads (LWKT), an in-kernel message passing system, and the HAMMER file system. Many design concepts were influenced by AmigaOS.

DragonFly 5.8.3 released

DragonFly version 5.8.3 has been released. DragonFly version 5.8 brings a new dsynth utility for building your own binary dports packages, plus significant support work to speed up that build - up to and including the entire collection. Additional progress has been made on GPU and signal support. 5.8 1 brings a number of bug-level updates, including a HAMMER2 deduplication fix. 5.8.2 includes a large number of bugfixes and updates, and 5.8.3 contains two CVE fixes missing in 5.8.2.

System design

Kernel: The kernel messaging subsystem being developed is similar to those found in microkernels such as Mach, though it is less complex by design. However, DragonFly uses a monolithic kernel system. DragonFly's messaging subsystem has the ability to act in either a synchronous or asynchronous fashion, and attempts to use this capability to achieve the best performance possible in any given situation.

According to developer Matthew Dillon, progress is being made to provide both device input/output (I/O) and virtual file system (VFS) messaging capabilities that will enable the remainder of the project goals to be met. The new infrastructure will allow many parts of the kernel to be migrated out into userspace; here they will be more easily debugged as they will be smaller, isolated programs, instead of being small parts entwined in a larger chunk of code. Additionally, the migration of select kernel code into userspace has the benefit of making the system more robust; if a userspace driver crashes, it will not crash the kernel.

DragonFly BSD
Developer	Matthew Dillon
OS family	Unix-like
Source model	Open source
Latest release	5.8.3 / 24 September 2020
Available in	English
Package Manager	pkg
License	BSD

Package management

Third-party software is available on DragonFly as binary packages via pkgng or from a native ports collection – DPorts.

DragonFly originally used the FreeBSD Ports collection as its official package management system, but starting with the 1.4 release switched to NetBSD's pkgsrc system, which was perceived as a way of lessening the amount of work needed for third-party software availability.Eventually, maintaining compatibility with pkgsrc proved to require more effort than was initially anticipated, so the project created DPorts, an overlay on top of the FreeBSD Ports collection.

CARP support

The initial implementation of Common Address Redundancy Protocol (commonly referred to as CARP) was finished in March 2007.As of 2011, CARP support is integrated into DragonFly BSD.

HAMMER file systems

Alongside the Unix File System, which is typically the default file system on BSDs, DragonFly BSD supports the HAMMER and HAMMER2 file systems. HAMMER2 is the default file system as of version 5.2.0.

HAMMER was developed specifically for DragonFly BSD to provide a feature-rich yet better designed analogue of the increasingly popular ZFS. HAMMER supports configurable file system history, snapshots, checksumming, data deduplication and other features typical for file systems of its kind.

HAMMER2, the successor of the HAMMER file system, is now considered stable, used by default, and the focus of further development. Plans for its development were initially shared in 2012. In 2017, Dillon announced that the next DragonFly BSD version (5.0.0) would include a usable, though still experimental, version of HAMMER2, and described features of the design.[30] With the release after 5.0.0, version 5.2.0, HAMMER2 became the new default file system.

Application snapshots

DragonFly BSD supports Amiga-style resident applications feature: it takes a snapshot of a large, dynamically linked program's virtual memory space after loading, allowing future instances of the program to start much more quickly than it otherwise would have. This replaces the prelinking capability that was being worked on earlier in the project's history, as the resident support is much more efficient. Large programs like those found in KDE Software Compilation with many shared libraries will benefit the most from this support.