DragonFly BSD , la enciclopedia libre

DragonFly BSD
Parte de BSD

Cargador de arranque de DragonFly BSD 6.2.1, UEFI
Información general
Tipo de programa BSD
Desarrollador Matthew Dillon & The DragonFly Team[1]
Modelo de desarrollo Software de código abierto
Lanzamiento inicial 12 de julio de 2004 (20 años, 5 meses y 18 días)
Licencia BSD
Estado actual Activo
Idiomas Inglés
Información técnica
Tipo de núcleo Híbrido
Plataformas admitidas x86-64
Interfaz gráfica predeterminada tcsh (root) / sh (users)
Sistema de gestión de paquetes pkgsrc de NetBSD; DPorts[3]
Versiones
Última versión estable 6.4.0 (info) ( 10 de mayo de 2021 (3 años, 7 meses y 20 días))
Enlaces

DragonFly BSD es un sistema operativo similar a Unix Software libre y de código abierto derivado de FreeBSD 4.8. Matthew Dillon, desarrollador de Amiga a finales de los 80 y principios de los 90 y desarrollador de FreeBSD entre 1994 y 2003, comenzó a trabajar en DragonFly BSD en junio de 2003 y lo anunció en las listas de correo de FreeBSD el 16 de julio de 2003.[4][5]

El objetivo inicial del proyecto fue reescribir toda la gestión de concurrencia, SMP y la mayoría de los subsistemas del núcleo.

Dillon inició DragonFly con la creencia de que las técnicas adoptadas para subprocesos y multiprocesamiento simétrico en FreeBSD 5[6]​ conducirían a un bajo rendimiento y problemas de mantenimiento. Trató de corregir estos problemas anticipados dentro del proyecto FreeBSD.[7]​ Debido a conflictos con otros desarrolladores de FreeBSD sobre la implementación de sus ideas,[8]​ su capacidad para cambiar directamente la base de código finalmente fue revocada. A pesar de esto, los proyectos DragonFly BSD y FreeBSD aún funcionan juntos, compartiendo correcciones de errores, actualizaciones de controladores y otras mejoras.

Diseñado como la continuación lógica de la serie FreeBSD 4.x, DragonFly se ha desviado significativamente de FreeBSD, implementando Subprocesos de núcleo ligeros, (en inglés) Light Weight Kernel Threads, LWKT, un sistema de paso de mensajes en el núcleo y el sistema de archivos HAMMER.[9]​ Muchos conceptos de diseño fueron influenciados por AmigaOS.[10]

Una de sus características es que posee un instalador propio, y adaptado por otras distribuciones BSD, llamado BSD Installer.

La mascota del proyecto es una libélula, Dragonfly, (en inglés).[11]

Diseño del sistema

[editar]

Núcleo

[editar]

El subsistema de mensajería del núcleo que se está desarrollando es similar a los que se encuentran en micronúcleos como Mach, aunque su diseño es menos complejo. El subsistema de mensajería de DragonFly tiene la capacidad de actuar de forma síncrona o asíncrona, e intenta utilizar esta capacidad para lograr el mejor rendimiento posible en cualquier situación dada.[12]

Según el desarrollador Matthew Dillon, se está avanzando para proporcionar capacidades de mensajería de entrada/salida (E/S) de dispositivo y sistema de archivos virtual (VFS) que permitirán cumplir el resto de los objetivos del proyecto. La nueva infraestructura permitirá migrar muchas partes del núcleo al espacio de usuario; aquí serán más fáciles de depurar, ya que serán programas más pequeños y aislados, en lugar de ser partes pequeñas entrelazadas en una porción más grande de código. Además, la migración del código del kernel seleccionado al espacio de usuario tiene la ventaja de hacer que el sistema sea más sólido; si un controlador de espacio de usuario falla, no bloqueará el núcleo.[13]

Las llamadas al sistema se dividen en versiones de kernel y de usuario y se encapsulan en mensajes. Esto ayudará a reducir el tamaño y la complejidad del kernel al mover variantes de llamadas de sistema estándar a una capa de compatibilidad de usuario, y ayudará a mantener la compatibilidad hacia adelante y hacia atrás entre las versiones de DragonFly. El código de compatibilidad con Linux y otros sistemas operativos similares a Unix se está migrando de manera similar.[14]

Dado que la compatibilidad con varias arquitecturas de conjuntos de instrucciones complica la compatibilidad con el multiprocesamiento simétrico (SMP),[15]​ DragonFly BSD ahora limita su compatibilidad con la plataforma x86-64.[16]​ DragonFly se ejecutó originalmente en la arquitectura x86; sin embargo, a partir de la versión 4.0 ya no es compatible. Desde la versión 1.10, DragonFly admite subprocesos de área de usuario 1:1 (un subproceso de núcleo por subproceso de área de usuario),[17]​ que se considera una solución relativamente simple que también es fácil de mantener.[10]​ Heredado de FreeBSD, DragonFly también es compatible con subprocesos múltiples.[17]

En DragonFly, cada CPU tiene su propio planificador de subprocesos. Tras la creación, los subprocesos se asignan a los procesadores y nunca se cambian de manera preventiva de un procesador a otro; solo se migran mediante el paso de un mensaje de interrupción entre procesadores (IPI) entre las CPU involucradas. La programación de subprocesos entre procesadores también se logra mediante el envío de mensajes IPI asíncronos. Una ventaja de esta clara compartimentación del subsistema de roscado es que los cachés integrados de los procesadores en los sistemas multiprocesador simétricos no contienen datos duplicados, lo que permite un mayor rendimiento al dar a cada procesador en el sistema la capacidad de usar su propio caché para almacenar diferentes cosas en las que trabajar.[10]

El subsistema LWKT se emplea para dividir el trabajo entre varios subprocesos del kernel (por ejemplo, en el código de red hay un subproceso por protocolo por procesador), lo que reduce la competencia al eliminar la necesidad de compartir ciertos recursos entre varias tareas del kernel.[18]

Protección de recursos compartidos

[editar]

Para ejecutarse de manera segura en máquinas multiprocesador, el acceso a los recursos compartidos (como archivos, estructuras de datos) debe serializarse para que los subprocesos o procesos no intenten modificar el mismo recurso al mismo tiempo. Para evitar que múltiples subprocesos accedan o modifiquen un recurso compartido simultáneamente, DragonFly emplea secciones crítica y serializa tokens para evitar el acceso simultáneo. Mientras que tanto Linux como FreeBSD 5 emplean modelos mutex detallados para lograr un mayor rendimiento en sistemas multiprocesador, DragonFly no lo hace.[15]​ Hasta hace poco, DragonFly también empleaba spls, pero estos fueron reemplazados por secciones críticas.

Gran parte del núcleo del sistema, incluido el subsistema LWKT, el subsistema de mensajería IPI y el nuevo asignador de memoria del kernel, no tienen bloqueo, lo que significa que funcionan sin usar mutexes, con cada proceso operando en una sola CPU. Las secciones críticas se utilizan para proteger contra interrupciones locales, individualmente para cada CPU, lo que garantiza que un subproceso actualmente siendo ejecutado no será reemplazado.[17]

Los tokens de serialización se utilizan para evitar accesos simultáneos desde otras CPUs y pueden ser retenidos simultáneamente por varios subprocesos, lo que garantiza que solo uno de esos subprocesos se esté ejecutando en un momento dado. Por lo tanto, los subprocesos bloqueados o inactivos no impiden que otros subprocesos accedan al recurso compartido, a diferencia de un subproceso que tiene un mutex. Entre otras cosas, el uso de tokens de serialización evita muchas de las situaciones que podrían generar interbloqueos e inversiones de prioridad al usar mutexes, además de simplificar enormemente el diseño y la implementación de un procedimiento de muchos pasos que requeriría compartir un recurso entre múltiples hilos. El código del token de serialización está evolucionando hacia algo bastante similar a la función "Leer-copiar-actualizar" ahora disponible en Linux. A diferencia de la implementación RCU actual de Linux, DragonFly se está implementando de tal manera que solo los procesadores que compiten por el mismo token se ven afectados en lugar de todos los procesadores en el misma computadora.[19]

DragonFly cambió a un asignador de bloques seguro multiprocesador, que no requiere mutex ni operaciones de bloqueo para las tareas de asignación de memoria.[20]​ Eventualmente fue portado a la biblioteca C estándar en la zona de usuarios, donde reemplazó la implementación malloc de FreeBSD.[21]

Núcleo virtual

[editar]

Desde la versión 1.8, DragonFly tiene un mecanismo de virtualización similar al Modo de Usuario Linux,[22]​ que permite a un usuario ejecutar otro kernel en el espacio del usuario. El núcleo virtual (vkernel) se ejecuta en un entorno completamente aislado con interfaces de red y almacenamiento emuladas, lo que simplifica las pruebas de los subsistemas del núcleo y las funciones de agrupación.[10][23]

El vkernel tiene dos diferencias importantes con el kernel real: carece de muchas rutinas para manejar la administración de hardware de bajo nivel y utiliza funciones de biblioteca estándar C (libc) en lugar de implementaciones en el kernel siempre que sea posible. Dado que tanto el kernel real como el virtual se compilan a partir de la misma base de código, esto significa que las rutinas dependientes de la plataforma y las reimplementaciones de las funciones libc están claramente separadas en un árbol de código fuente.[24]

El vkernel se ejecuta sobre una capa de abstracciones de hardware, proporcionadas por el kernel real. Estos incluyen el temporizador basado en kqueue, la consola (asignada a la virtual terminal donde se ejecuta vkernel), la imagen de disco y el dispositivo Ethernet de kernel virtual (VKE), canalizando todos los paquetes a la interfaz tap, a los dispositivos de red virtual del núcleo, del host.[25]

Gestión de paquetes

[editar]

El software de terceros está disponible en DragonFly como paquetes binarios a través de pkgng o de una colección de Ports nativos: DPorts.[26]

DragonFly usó originalmente la colección FreeBSD Ports como su sistema oficial de gestión de paquetes, pero a partir de la versión 1.4 cambió al sistema pkgsrc de NetBSD, que se percibió como una forma de disminuir la cantidad de trabajo necesario para la disponibilidad de software de terceros.[7][27]​ Eventualmente, mantener la compatibilidad con pkgsrc requería más esfuerzo del previsto inicialmente, por lo que el proyecto creó DPorts, una superposición sobre la colección FreeBSD Ports.[28][29]

Soporte CARP

[editar]

La implementación inicial del Protocolo de Redundancia de Dirección común (comúnmente conocido como CARP, Common Address Redundancy Protocol (en inglés), finalizó en marzo de 2007.[30]​ A partir de 2011, la compatibilidad con CARP está integrada en DragonFly BSD.[31]

Sistema de archivos HAMMER

[editar]

Junto con el sistema de archivos Unix, que suele ser el sistema de archivos predeterminado en BSD, DragonFlyBSD es compatible con los sistemas de archivos HAMMER y HAMMER2. HAMMER2 es el sistema de archivos predeterminado a partir de la versión 5.2.0.

HAMMER fue desarrollado específicamente para DragonFly BSD para proporcionar un sistema de archivos análogo, rico en características, pero mejor diseñado que el cada vez más popular ZFS.[10][32][33]​ HAMMER admite el historial del sistema de archivos configurable, instantáneas (snapshots), suma de verificación, duplicación de datos y otras características típicas de los sistemas de archivos de este tipo.[22][34]

HAMMER2, el sucesor del sistema de archivos HAMMER, ahora se considera estable, se usa de forma predeterminada y es el foco de un mayor desarrollo. Los planes para su desarrollo se compartieron inicialmente en 2012.[35]​ En 2017, Dillon anunció que la próxima versión de DragonFly BSD (5.0.0) incluiría una versión utilizable, aunque todavía experimental, de HAMMER2, y describió las características del diseño.[36]​ Con el lanzamiento de la versión 5.2.0, HAMMER2 se convirtió en el nuevo sistema de archivos predeterminado.

devfs

[editar]

En 2007, DragonFly BSD recibió un nuevo sistema de archivos de dispositivos (devfs), que agrega y elimina dinámicamente nodos de dispositivos, permite acceder a dispositivos por rutas de conexión, reconoce unidades por números de serie y elimina la necesidad de una jerarquía de sistema de archivos /dev rellenada previamente. Se implementó como un proyecto Google Summer of Code 2009.[37]

Instantáneas de la aplicación

[editar]

DragonFly BSD es compatible con la función de aplicaciones residentes estilo Amiga: toma una instantánea del espacio de memoria virtual de un programa vinculado dinámicamente después de la carga, lo que permite que futuras instancias del programa se inicien mucho más rápido de lo que lo habría hecho de otra manera. Esto reemplaza la capacidad de vinculación previa en la que se estaba trabajando anteriormente en la historia del proyecto, ya que el soporte residente es mucho más eficiente. Los programas grandes como los que se encuentran en KDE con muchas librerías compartidas se beneficiarán más de este soporte.[38]

Desarrollo y distribución

[editar]
DragonFly BSD 6.2.1,entorno de escritorio Lumina.

Al igual que con FreeBSD y OpenBSD, los desarrolladores de DragonFly BSD están reemplazando lentamente el código C estilo prototipo previo a la función con equivalentes ANSI más modernos. Similar a otros sistemas operativos, la versión de DragonFly de GNU Compiler Collection tiene una llamada realzada el Stack-Smashing Protector (ProPolice) habilitada de forma predeterminada, que brinda protección adicional contra ataques basados en desbordamiento de búfer. A partir del 23 de julio de 2005, el núcleo ya no se compila con esta protección de forma predeterminada.[38]

Debido a que es un derivado de FreeBSD, DragonFly ha heredado un sistema de compilación integrado fácil de usar que puede reconstruir todo el sistema base desde el origen con solo unos pocos comandos. Los desarrolladores de DragonFly utilizan el sistema de control de versiones Git para gestionar los cambios en el código fuente de DragonFly. A diferencia de FreeBSD, DragonFly tiene versiones estables e inestables en un solo árbol fuente, debido a una base de desarrolladores más pequeña.[8]

Tal como otros kernels BSD (y los de la mayoría de los sistemas operativos modernos), DragonFly emplea un depurador de kernel incorporado para ayudar a los desarrolladores a encontrar errores en el kernel. Además, a partir de octubre de 2004, se instala de forma predeterminada un kernel de depuración, que hace que los informes de errores sean más útiles para rastrear problemas relacionados con el kernel, a expensas de una cantidad relativamente pequeña de espacio en disco. Cuando se instala un nuevo kernel, la copia de seguridad del kernel anterior y sus módulos se eliminan de sus símbolos de depuración para minimizar aún más el uso del espacio en disco.

Medios de distribución

[editar]

El sistema operativo se distribuye como Live CD y Live USB que arranca en un sistema DragonFly completo.[22][39]​ Incluye el sistema base y un conjunto completo de páginas de manual, y puede incluir código fuente y paquetes útiles en futuras versiones. La ventaja de esto es que con un solo CD los usuarios pueden instalar el software en una computadora, usar un conjunto completo de herramientas para reparar una instalación dañada o demostrar las capacidades del sistema sin instalarlo. Las instantáneas diarias están disponibles en el sitio maestro para aquellos que desean instalar las versiones más recientes de DragonFly sin compilar desde el origen.

Al igual que los otros BSD libres y de código abierto, DragonFly se distribuye bajo los términos de la versión moderna de la Licencia BSD.

Historial de Versiones

[editar]
Versión Fecha[40] Cambios significativos
6.4[41] 02022-12-30 30 de diciembre de 2022
6.2.1[42] 02022-01-09 09 de enero de 2022
  • NVMM portado a DragonFly.
  • Se agregó soporte para growfs para cambiar el tamaño de un volumen HAMMER2 existente.
  • xdisk agregado. Se pueden montar discos HAMMER2 remotos (característica experimental).
  • Controlador amdgpu importado, compatible con Linux 4.19.
  • DRM actualizado.
6.0[43] 02021-05-10 10 de mayo de 2021
  • Trabajo mejorado de 'dsynth' - herramienta que permite mantener el repositorio DPorts local
  • Se eliminó el soporte de MAP_VPAGETABLE mmap (), como resultado, ningún 'vkernel' en esta versión puede funcionar
5.8[44] 02020-03-03 03 de marzo de 2020
  • dsynth(1) escrito y agregado a la base. dsynth se usa para construir parte o la totalidad de la colección DPorts.
  • El soporte de DRM (GPU) continúa mejorando lenta pero constantemente.
  • Los algoritmos de paginación mejorados reducen o eliminan las fallas de la interfaz de usuario/navegador en situaciones de poca memoria.
5.6[45] 02019-06-17 17 de junio de 2019
  • Sistema de memoria virtual mejorado
  • Actualizaciones a radeon y ttm
  • Mejoras de rendimiento para HAMMER2
5.4[46] 02018-12-03 03 de diciembre de 2018
  • Controladores actualizados para red, máquinas virtuales y pantalla
  • GCC 8.0 con las versiones anteriores de GCC
  • HAMMERo con más correcciones de problemas
5.2[47] 02018-04-10 10 de abril de 2018
  • El sistema de archivos HAMMER2 ahora se considera estable
  • Soporte de mitigación de Meltdown y Spectre
  • Actualizaciones de ipfw
  • Soporte gráfico mejorado
5.0[48] 02017-10-16 16 de octubre de 2017
  • Nuevo sistema de archivos HAMMER2
  • Ahora puede admitir más de 900000 procesos en una sola máquina
  • Compatibilidad mejorada con i915
  • IPFW mejor rendimiento
4.8[49] 02017-03-27 27 de marzo de 2017
  • Soporte inicial de AMD Ryzen
  • Compatibilidad mejorada con i915
  • Rendimiento del núcleo mejorado
  • Soporte de arranque eMMC
  • LibreSSL reemplazó a OpenSSL en la base
  • GCC 5.4.1
  • Soporte para LTO
  • Marco de Clang inicial
  • Soporte de instalación de UEFI
4.6[50] 02016-08-02 02 de agosto de 2016
  • Compatibilidad mejorada con i915 y Radeon
  • Soporte para NVM Express
  • Rendimiento SMP mejorado
  • Rendimiento de red mejorado
  • Soporte preliminar para arranque UEFI
  • autofs importados desde FreeBSD; amd eliminado
4.4[51] 02015-12-07 07 de diciembre de 2015
  • GCC 5.2
  • gold es ahora el enlazador predeterminado
  • Compatibilidad mejorada con i915 y Radeon
  • Revisión completa del sistema local
  • Soporte de intercalación para locales con nombre
  • Biblioteca Regex reemplazada por TRE
  • Soporte de versiones de símbolos en libc
  • Numerosas limpiezas y correcciones de HAMMER
4.2[52] 02015-06-29 29 de junio de 2015
  • GCC 5.1.1
  • Compatibilidad mejorada con i915 y Radeon
  • Soporte de sonido mejorado
  • Soporte mejorado para controlador de memoria y sensores de temperatura
  • Path MTU Discovery habilitado de forma predeterminada
  • Se eliminó la compatibilidad con SCTP
  • Sendmail reemplazado por DMA
  • Páginas GNU Info eliminadas
4.0[53] 02014-11-25 25 de noviembre de 2014
  • PF multihilo sin bloqueo
  • Redes relacionadas mejor enhebradas para mejorar el rendimiento
  • Característica de seguridad de Procctl en el kernel
  • Compatibilidad con hasta 256 CPU
  • Compatibilidad mejorada con redes inalámbricas
  • Rust y Free Pascal ahora son compatibles
  • Soporte i915 mejorado en gran medida
  • GCC 4.7.4
3.8[54] 02014-06-04 04 de junio de 2014
  • Soporte dinámico de raíz y PAM
  • USB4BSD ahora por defecto
  • Soporte nativo C-State para CPU Intel
  • Token de puerto TCP dividido para un mejor rendimiento de TCP connect(2)
  • GCC 4.7.3
  • HAMMER2 en el sistema (no está listo para su uso en producción)
  • Lanzamiento final de 32 bits
3.6[55] 02013-11-25 25 de noviembre de 2013
  • Reducción de contención SMP
  • Configuración del modo kernel para GPUs Intel y AMD
  • Aceleración de hardware para GPU Intel hasta Ivy Bridge[56]
3.4[57] 02013-04-29 29 de abril de 2013
  • Nuevo administrador de paquetes, DPorts, introducido
  • GCC 4.7
  • Uso mejorado de la CPU y rendimiento de tmpfs bajo carga extrema
3.2[58] 02012-11-02 2 de noviembre de 2012
  • El kernel con capacidad multiprocesador se volvió obligatorio.
  • Mejoras de rendimiento en el programador.
  • USB4BSD importado de FreeBSD.
  • PUFFS importados de NetBSD.
3.0[59] 02012-02-22 22 de febrero de 2012
  • El kernel con capacidad multiprocesador se convirtió en el predeterminado
  • Mejoras en el rendimiento de HAMMER
  • Soporte de encriptación compatible con TrueCrypt
  • dm-crypt reemplazado con una biblioteca con Licencia BSD compatible
  • Compatibilidad mejorada con POSIX
  • Controlador de dispositivo para memoria ECC
  • Principales mejoras en la pila de protocolos de red y SMP
  • Mejoras relacionadas con ACPI
2.10[60] 02011-04-26 26 de abril de 2011
2.8[61] 02010-10-30 30 de octubre de 2010
2.6[62] 00006-04-2010 2010 de abril de 6
  • Intercambio de caché
  • tmpfs importado de NetBSD
  • HAMMER y mejoras generales de E/S
2.4[63] 02009-09-16 16 de septiembre de 2009
  • devfs
  • Nuevo controlador AHCI, que incluye compatibilidad total con NCQ[64]
  • Mejoras en NFS
  • Compatibilidad completa con x86-64
2.2[65] 02009-02-17 17 de febrero de 2009
  • HAMMER oficialmente listo para producción[22]
  • Importantes mejoras de estabilidad
  • Nuevos medios de lanzamiento: LiveCD y LiveUSB
2.0[66] 02008-07-20 20 de julio de 2008
1.12[67] 02008-02-26 26 de febrero de 2008
1.10[68] 02007-08-06 6 de agosto de 2007
1.8[69] 02007-01-30 30 de enero de 2007
1.6[70] 02006-07-24 24 de julio de 2006
1.4[72] 02006-01-07 07 de enero de 2006
1.2[74] 02005-04-08 8 de abril de 2005
1.0[75] 02004-07-12 12 de julio de 2004

Véase también

[editar]

Referencias

[editar]
  1. The DragonFly Team - dragonflybsd.org (en inglés).
  2. wiki.dragonflybsd.org FAQ Spanish Sección:¿Qué arquitecturas soporta DragonFly?.
  3. [url=https://www.dragonflybsd.org/docs/howtos/HowToDPorts/ HowToDPorts]
  4. Dillon, Matthew (16 de julio de 2003), «Announcing DragonFly BSD!», freebsd-current mailing list, consultado el 26 de julio de 2007 .
  5. The History of DragonFly - dragonflybsd.org(en inglés).
  6. Lehey, Greg (2001), Improving the FreeBSD SMP implementation, USENIX, consultado el 22 de febrero de 2012 .
  7. a b Kerner, Sean Michael (10 de enero de 2006), «New DragonFly Released For BSD Users», InternetNews, archivado desde el original el 28 de junio de 2011, consultado el 20 de noviembre de 2011 .
  8. a b c Biancuzzi, Federico (8 de julio de 2004), «Behind DragonFly BSD», O'Reilly Media, archivado desde el original el 9 de abril de 2014, consultado el 20 de noviembre de 2011 .
  9. Loli-Queru, Eugenia (13 de marzo de 2004), «Interview with Matthew Dillon of DragonFly BSD», OSNews, consultado el 22 de febrero de 2012 .
  10. a b c d e Chisnall, David (15 de junio de 2007), «DragonFly BSD: UNIX for Clusters?», InformIT, consultado el 22 de noviembre de 2011 .
  11. DragonFly - Our Mascot - dragonflybsd.org
  12. Hsu, Jeffery M. (13 de marzo de 2004). The DragonFly BSD Operating System. AsiaBSDCon 2004. Taipei, Taiwan. Consultado el 20 de noviembre de 2011. 
  13. Andrews, Jeremy (6 de agosto de 2007), «Interview: Matthew Dillon», KernelTrap, archivado desde el original el 15 de mayo de 2011 .
  14. Chisnall, David (15 de junio de 2007), «DragonFly BSD: UNIX for Clusters?», InformIT, consultado el 22 de noviembre de 2011 .
  15. a b Biancuzzi, Federico (8 de julio de 2004), «Behind DragonFly BSD», O'Reilly Media, archivado desde el original el 9 de abril de 2014, consultado el 20 de noviembre de 2011 .
  16. «DragonFly BSD MP Performance Significantly Improved», OSNews, 16 de noviembre de 2011, consultado el 19 de noviembre de 2011 .
  17. a b c Luciani, Robert (24 de mayo de 2009), M:N threading in DragonflyBSD, BSDCon, archivado desde el original el 23 de diciembre de 2010 .
  18. Sherrill, Justin (11 de enero de 2004), Paying off already, archivado desde el original el 30 de abril de 2014, consultado el 20 de noviembre de 2011 .
  19. Pistritto, Joe; Dillon, Matthew; Sherrill, Justin C. et al. (24 de abril de 2004), «Serializing token», kernel mailing list, archivado desde el original el 15 de abril de 2013, consultado el 20 de marzo de 2012 .
  20. Bonwick, Jeff; Adams, Jonathan (3 de enero de 2002), Magazines and Vmem: Extending the Slab Allocator to Many CPUs and Arbitrary Resources, USENIX, consultado el 20 de noviembre de 2011 .
  21. Dillon, Matthew (23 de abril de 2009), «New libc malloc committed», kernel mailing list, consultado el 8 de agosto de 2011 .
  22. a b c d Vervloesem, Koen (21 de abril de 2010), «DragonFly BSD 2.6: towards a free clustering operating system», LWN.net, consultado el 19 de noviembre de 2011 .
  23. Andrews, Jeremy (6 de agosto de 2007), «Interview: Matthew Dillon», KernelTrap, archivado desde el original el 15 de mayo de 2011 .
  24. Economopoulos, Aggelos (16 de abril de 2007), «A peek at the DragonFly Virtual Kernel», LWN.net (part 1), consultado el 8 de diciembre de 2011 .
  25. Economopoulos, Aggelos (16 de abril de 2007), «A peek at the DragonFly Virtual Kernel», LWN.net (part 2), consultado el 8 de diciembre de 2011 .
  26. «HowTo DPorts», DragonFly BSD, consultado el 2 de diciembre de 2013 .
  27. Weinem, Mark (2007). «10 years of pkgsrc». NetBSD. Joerg Sonnenberger about pkgsrc on DragonFly BSD and his pkgsrc development projects. Consultado el 22 de noviembre de 2011. 
  28. Sherrill, Justin (30 de septiembre de 2013), «Why dports?», DragonFly BSD Digest, archivado desde el original el 30 de abril de 2014, consultado el 2 de diciembre de 2011 .
  29. Sherrill, Justin (29 de septiembre de 2013), «Any new packages?», users mailing list, consultado el 2 de diciembre de 2013 .
  30. Buschmann, Jonathan (14 de marzo de 2007), «First Patch to get CARP on Dfly», kernel mailing list, consultado el 20 de noviembre de 2011 .
  31. «CARP(4) manual page», DragonFly On-Line Manual Pages, consultado el 20 de noviembre de 2011 .
  32. Andrews, Jeremy (6 de agosto de 2007), «Interview: Matthew Dillon», KernelTrap, archivado desde el original el 15 de mayo de 2011 .
  33. Dillon, Matthew (10 de octubre de 2007), «Re: HAMMER filesystem update - design document», kernel mailing list, consultado el 20 de noviembre de 2011 .
  34. Larabel, Michael (7 de enero de 2011), «Can DragonFlyBSD's HAMMER Compete With Btrfs, ZFS?», Phoronix, consultado el 20 de noviembre de 2011, «HAMMER parece ser un sistema de archivos BSD muy interesante. Aunque no es tan rápido como el sistema de archivos ZFS en BSD, también es un sistema de archivos original para el proyecto DragonFlyBSD en lugar de ser un port de OpenSolaris. HAMMER no solo es generalmente más rápido que el sistema de archivos UFS común, sino que también tiene un conjunto de funciones mucho mayor.» .
  35. Dillon, Matthew (8 de febrero de 2012), «DESIGN document for HAMMER2 (08-Feb-2012 update)», users, consultado el 22 de febrero de 2012 .
  36. Dillon, Matthew (18 de agosto de 2017), «Next DFly release will have an initial HAMMER2 implementation», users, consultado el 3 de julio de 2018 .
  37. Mr (7 de enero de 2010), «DragonFlyBSD with Matthew Dillon» (ogg), bsdtalk, archivado desde el original el 25 de abril de 2012, consultado el 20 de noviembre de 2011 .
  38. a b «DragonFly BSD diary», DragonFly BSD, 7 de enero de 2006, consultado el 19 de noviembre de 2011 .
  39. Mr (7 de enero de 2010), «DragonFlyBSD with Matthew Dillon» (ogg), bsdtalk, archivado desde el original el 25 de abril de 2012, consultado el 20 de noviembre de 2011 .
  40. DragonFly: Releases
  41. DragonFly BSD 6.4
  42. DragonFly BSD 6.2
  43. DragonFly BSD 6.0
  44. DragonFly BSD 5.8
  45. DragonFly BSD 5.6
  46. DragonFly BSD 5.4
  47. DragonFly BSD 5.2
  48. DragonFly BSD 5.0
  49. DragonFly BSD 4.8
  50. DragonFly BSD 4.6
  51. DragonFly BSD 4.4
  52. DragonFly BSD 4.2
  53. DragonFly BSD 4.0
  54. DragonFly BSD 3.8
  55. DragonFly BSD 3.6
  56. Tigeot, Francois (31 de julio de 2007), «KMS + i915 support now in -master», users mailing list, consultado el 2 de diciembre de 2013 .
  57. DragonFly BSD 3.4
  58. DragonFly BSD 3.2
  59. DragonFly BSD 3.0
  60. DragonFly BSD 2.10
  61. DragonFly BSD 2.8
  62. DragonFly BSD 2.6
  63. DragonFly BSD 2.4
  64. Matthew Dillon (4 de junio de 2009). «"Re: DragonFly-2.3.1.165.g25822 master sys/dev/disk/ahci Makefile TODO ahci.c ahci.h ahci_attach.c ahci_cam.c ahci_dragonfly.c ahci_dragonfly.h atascsi.h"». 
  65. DragonFly BSD 2.2
  66. DragonFly BSD 2.0
  67. DragonFly BSD 1.12
  68. DragonFly BSD 1.10
  69. DragonFly BSD 1.8
  70. DragonFly BSD 1.6
  71. a b Kerner, Sean Michael (25 de julio de 2006), «DragonFly BSD 1.6 Cuts the Cord», InternetNews, consultado el 20 de noviembre de 2011 .
  72. DragonFly BSD 1.4
  73. Townsend, Trent (18 de enero de 2006), «A Quick Review of DragonFly BSD 1.4», OSNews, consultado el 16 de noviembre de 2011 .
  74. DragonFly BSD 1.2
  75. DragonFly BSD 1.0

Enlaces externos

[editar]