El inicio del estudio se remonta a 1993 reuniendo estadísticas compiladas en cada versión estable, teniendo en cuenta el número de paquetes en cada versión y comparando con la versión anterior. Esto les permitió rastrear la historia de vida de los paquetes, viendo como los nuevos se han introducido y los más viejos caen en desuso. Además de recopilar las estadísticas, el equipo también recogió la versión x86 del sistema operativo e instalo paquetes al azar, que les dio una medida estadística de la frecuencia de las dependencias e incompatibilidades.
Varias tendencias eran evidentes en los datos. Por ejemplo, la modularidad del sistema fue creciendo exponencialmente hasta la versión 3.0, después de lo cual hubo una fuerte caída. A partir de ahí, la modularidad se mantuvo estable, con las sucesivas versiones. Esto tuvo un efecto importante en la funcionalidad, que se define como la velocidad a la que los paquetes elegidos al azar con éxito se instalan en un sistema Debian, valor que empezó a subir de forma significativa con la versión 3.1 una vez publicada. Los autores atribuyen esto a la gran diferencia de tiempo entre los lanzamientos que tuvieron lugar en este momento.
Con el tiempo, los módulos de software (clusters de paquetes con alta interdependencia) también aumentaron en tamaño y número. A medida que estas tendencias se mantuvieron, el número de conflictos entre los módulos de software se redujeron, sin embargo, en un modulo aumento el número de conflictos. "Por lo tanto, existe un trade-off -una situación en la cual por ganar una cualidad se pierde otra- entre la reutilización de muchas piezas de código existente y la aparición de incompatibilidades entre paquetes de software", concluyen los autores.
También demostraron que es posible el modelo de este trade-off con las herramientas estándar ecológico: la dependencias entre los paquetes parecen las interacciones predador-presa, mientras que los conflictos se parecen a las especies que tienen una relación de exclusión competitiva.
En general, la características clave de la modularidad del equipo identificado parece ser que la disminución del número de conflictos a través de módulos significa que más de los programas disponibles para el sistema operativo se puedan instalar, ya que es raro que un conflicto bloquee completamente un módulo completo de la instalación y en funcionamiento. Los autores sugieren que se puede aprender algo acerca de la biología mediante el estudio de software, pero en realidad no se proporcionan ejemplos de cómo esto podría funcionar, en esta etapa, entonces, no es un argumento especialmente convincente.
Referencia:
- John Timmer,"Over time, Linux package dependencies show predator/prey relationship", Ars Technica.
0 Comments
Publicar un comentario