 contando patatas. Consideramos también interesante estudiar cómo ha evolucionado de bien, claro. Y cómo entender cómo está debían enfrentando la creciente complejidad debido al gran tamaño y a la cantidad de voluntarios que tiene. Por supuesto, más información acerca de nuestro equipo de investigación está en la página web. Bien, para hacer un resumen bastante pequeño y quizá un poco preciso en función de puntos sobre debían, soporta 12 arquitecturas, I386, AME64, etcétera, etcétera. No depende de ninguna empresa, es totalmente voluntaria, es totalmente el querer y el deseo de mucha gente. Cuenta con aproximadamente 1,500 dedicadísimos desarrolladores. Este es un punto importante en el que Anibal y yo estuvimos conversando un rato, es 1,500 desarrolladores, de los cuales aproximadamente 1,400, dependiendo del punto, hasta que lo veamos, son debían developers y el resto son debían maintainers, que vienen siendo unos 120, un poquito más de 100. Esto, lamentablemente, no está creciendo como debería. Y ese es otro de los puntos importantes a estudiar. Nos llama la atención muchísimo de debían por esto del contrato social y la guía de desarrollo de software. Por supuesto, el debían policy. Además de eso, la comunidad y sobre todo los desarrolladores hacen hincapié en incluir solamente software estable, cosa que, dependiendo del punto, vista que lo veamos, puede ser un inconveniente, puede que no, soporta varios kernels. Y el objetivo, por supuesto, del proyecto es construir un sistema operativo basado en software libre, según los estatutos de la debian free software guidelines. Bueno, estas son las releases que hay de debian, todos la mayoría las conocerán. Nosotros, lo que presento ahorita es sobre Lenny, por supuesto, la última. Un resumen de Lenny es que fue publicada en febrero de 2009, el 14, cuenta con más de 12,000 paquetes fuentes y más de 23,000 paquetes binarios. Ya veremos un poco cómo es eso. Fue publicada luego de 22 meses de desarrollo constante. Incluye OpenJDK, entre otras cosas, ofrece imágenes Blu-ray. Y, por supuesto, incluye la mayor compilación de, recopilación de paquetes de software libre en el mundo. Soporta FHS 2.3 y soporta software para lcb. En cuanto a los objetivos específicos del estudio, queremos estimar el tamaño de debian en función de las líneas de código. Usando una herramienta que se llama slow count, más adelante veremos un poquito más en detalle que hace. Una de las cosas interesantes es que es una línea de código. Podemos decir que una línea de código es simplemente algo que contiene espacio en blanco, una palabra reservada, por ejemplo, y una asignación que termina en un punto y coma, por ejemplo. Pero ¿qué pasa si en una línea hay dos puntos y coma? El compilador de cella entendería como dos líneas lógicas, más es una sola línea física. Nosotros tomamos una línea física, como lo entiende, slow count. El estudio lo hicimos en función del tamaño de cada paquete, en función de sus líneas de código. Identificamos los paquetes más grandes, identificamos los lenguajes más usados en la distribución y en cada paquete. Estudiamos el tamaño del paquete fuente, luego la modificación del desarrollador, y luego ese resultado sin el directorio de Avian. Más adelante también lo veremos. Hacemos una pequeña comparación con versiones previas, sobre todo en función de los lenguajes y de lo que ellos representan dentro de la distribución o dentro de la versión, mejor dicho. Y el estudio de esfuerzo y costo, lo hicimos utilizando un modelo que se llama COCOMO. Es un modelo realmente que se aplica al software privativo, pero lo usamos para tener una idea de el esfuerzo y el costo que implicaría el día de hoy, que una empresa diga, quiero hacer una relí de DEVIA, por ejemplo. Como les comenté anteriormente, enfrentamos varias situaciones para estudiar, para hacer el estudio. Una de ellas es el código duplicado, bien sea entre paquetes, bien sea por diferentes versiones de esos paquetes, o bien sea por versiones derivadas, como es el caso de GSC. Otra cosa que enfrentamos fueron los parches. GENAT es una serie de parches que se le aplican a GSC, pero termina siendo un código totalmente distinto. Eso se tomó en cuenta y consideramos GENAT como un paquete distinto a GSC. Debido a eso, para hacer el estudio, creamos una lista manual de estos de paquetes que tienen estas características para sacarlos del estudio, debido a que crearían imprecisiones. Así como lo que les comenté de las líneas de código, dependiendo de cómo queramos hacer el estudio, tenemos más o menos fuentes de imprecisiones. Esta lista se hace manualmente comparando versiones y estudiando el reuso de código o código similar. Bien, en cuanto a la metodología, en resumen, descargamos el paquete, lo desempaquetamos, hacemos el conteo con slow count y luego hacemos la suma y obtenemos los resultados de estadística. Entre los resultados tenemos las líneas física que ya veremos más adelante en tablas. La metodología en detalle sería la siguiente. Descargamos el sources.gc, que tiene la lista de paquetes con su descripción y versiones y tal. Seleccionamos los paquetes que serán estudiados. De ahí viene lo de la lista de paquetes purgados, por llamarlo de alguna manera, que son los que no tomamos en cuenta para el estudio. Entonces, para cada paquete lo descargamos, lo descomprimimos, ejecutamos el slow count, que ya más adelante, conversaré un poquito más en detalle de eso, esto nos da unas estadísticas de lo que es el paquete como tal, el fuente como tal, luego aplicamos los parches que vienen siendo las modificaciones de los desarrolladores, ejecutamos el slow count de nuevo, borramos el directorio de Evian y al final, ejecutamos el slow count de nuevo para tener tres medidas. Esto nos permite ver cómo se modifique el paquete para el estudio de Evian. Luego, esta información se va almacenando en directorios temporales que luego procesamos para extraer las estadísticas y tal. Al final, recopilamos los datos y hacemos las estadísticas. Bien. Ya hablando de la parte un poco más interesante, en cuando los resultados tenemos, en paquetes upstream, tenemos un total de 280 millones de líneas de código, bastante considerable, la verdad. Luego, ya cuando aplicamos los parches, tenemos 323 millones de líneas de código, que sería lo que es un paquete de Evian. Y los paquetes fuentes de Evian, sin el directorio de Evian, son 300 millones de líneas de código. Yo considero que el aporte de los desarrolladores es bastante apreciable, sin duda. Si comparamos actualmente las 323 millones de líneas de código, que es lo que totalmente tiene la versión 5 de Evian, comparándola con Ham, que tiene 25 millones de líneas de código, o sea, tenemos 12,78 veces más de código. Y esta es una relíquia que fue hace 12 años, ¿sí? 12 años, 13 años. Ham, aproximadamente. Luego, Sling, que son 8,70 veces. Y, por ejemplo, si vemos Edge, es 1.14 veces Edge, que fue lanzada apenas hace dos años. Esta es la distribución de los lenguajes más usados dentro de la distribución. Vemos que, bueno, perdón por el azul y el negro, este que no se ve. Anzise es el lenguaje más usado. De hecho, veremos en detalle luego tablas comparativas de los lenguajes. Veremos que Cese mantiene desde Ham como lenguaje más usado. Luego le sigue C++, que va creciendo. Luego Shell. Y, sorprendentemente, Java, que considero que es uno de los puntos un poco más interesante, veremos cómo va subiendo de posición, pero sorprendentemente. Que, de hecho, al final, de alguna manera, por decirlo así, le gana a Python y a Per en el ranking de lenguajes más usados. Al final, bueno, vemos otros lenguajes como PHP. Lisp, que en su momento fue, si mal lo recuerdo, el tercero o cuarto lenguaje más usado. Ahora, prácticamente, fíjense que el 2,5% que equivale a 7,972,000 líneas de código comparadas con las 323 millones de líneas de código es casi nada. Y aquí vemos el top 7 de los lenguajes más usados por versión. El primer número indica el ranking. El segundo número, las líneas de código que están dentro de la distribución que están en ese lenguaje, que están escritas en ese lenguaje. Y el porcentaje que representa dentro de la distribución. Entonces, si se fijan, C en ham está en el primero, con 19 millones de líneas de código, y equivale a 77% de la distribución o de la versión, mejor dicho. En sling, baja a 74, luego un potato a 69, y sigue bajando en woody, con 63,50, luego en search, luego en edge, en 51, y finalmente termina el lenguaje con 48,50. Pero veremos que, a pesar de que está disminuyendo el uso, por supuesto, también incrementa la cantidad de líneas de código por release de Debian. Pero en función de eso, el lenguaje sigue bajando, a pesar de que la distribución crece. El uso del lenguaje sigue bajando. Sin embargo, se mantiene en la primera posición. Luego en ham tenemos que C++ está en la segunda posición, con 1.5 millones de líneas de código, que es el 6,3%. Fija en la diferencia entre C en ham y en C++, la diferencia son como 17 millones de líneas, 18 millones de líneas de código, aproximadamente. Luego sube, va subiendo poco a poco. Ya veremos, por ejemplo, en edge, con 52 millones de líneas de código, que equivale al 18,72% de la distribución. Y ya luego en leni, ocupa el 20%. Podría una de las cosas interesantes sería ver si las aplicaciones que fueron escritas en C en su momento han migrado a C++ como, por ejemplo, es el caso de Vince, que es un caso interesante de estudiar y que en el grupo se hizo alguna vez una presentación. Y la línea de la manera como se distribuye la gráfica del estudio del repositorio de código de Vince es interesante, porque la vas viendo así en C, luego de repente hay un bajón y luego empieza otra vez arriba. Y eso fue un cambio de lenguaje que hicieron de C hace++. Es bastante interesante. Luego, fíjense el caso de Java. Java empieza en ham en el lugar número 13. Luego sube al 7. Luego se está en el 4, perdón, en Woody empieza en el 13. En ham en el 15. Y fíjense que es 0,89% de la distribución. Prácticamente no se usaba. Luego vemos que Nech está en la posición número 4, incluso por delante de Python, de Per y de Lisp, que inicialmente eran usados con respecto a Java, por ejemplo, Python con respecto a Per y con respecto a Lisp, que empieza en la posición número 3. Me imagino que será por el código de Max. Bueno, de aquí se puede sacar también bastante información interesante con respecto a cómo han cambiado la tendencia de los usos de lenguaje, bien sea por tecnologías, bien sea porque los lenguajes que han disminuido en ranking, bien sea porque a los desarrolladores, la cantidad de desarrolladores que escriben aplicaciones en esos lenguajes ya no son la misma cantidad, o el lenguaje ha perdido éxito, bien sea. Desde mi punto de vista, se espera que Python y Per sigan creciendo. La cantidad de gente que usa ahora Python y Per es bastante. Aunque C y C++ siguen siendo los lenguajes de primer aprendizaje normalmente en las universidades, aunque Java también. Bien, bueno, esta es otra gráfica donde se puede ver, por ejemplo, el uso de C, C++, Lisp y Shell. Bueno, vemos como las 25 millones de líneas de código de ham comparadas con las 323 de D. Si se fija el uso de C, incrementa, pero a su vez C++ también va ganando terreno con respecto al total. Algunos comentarios, bueno, básicamente, todos los he dicho, el uso de C y de Lisp está decreciendo. Java, Python y Per siguen incrementando. Java está por encima de Per y de Python en el ranking. Hay casi 6 millones de líneas de código escritas en Python y 5 millones de líneas de código escritas en Per. Con respecto a los paquetes, es interesante una de las cosas que se saca es que si comparamos con H hasta H, OpenOffice tenía 3 o 4 millones de líneas de código más que el kernel de Linux, pero ya que era la versión 2.6.18. Ahora en la versión 2.6.26 que tiene Lenny, se incluyeron 10 millones de líneas de código más. O sea, en la página web de la, ya la veremos más adelante, la página web del estudio, se ve como en H el kernel tenía aproximadamente 49 millones de líneas de código y OpenOffice tenía 52. Y ahora en Lenny, OpenOffice tiene 50 o algo así y el kernel de Linux tiene 59 millones de líneas de código. Me parece bastante interesante. Otra cosa es el crecimiento de OpenJDK, que me comentaron por ahí que uno de los movimientos de ZUN o de San Antesto fue librar Java. Por otro lado, vemos el CAFRI-BSD. Si vemos en los ranking anteriores, vemos que el CAFRI-BSD estaba en la posición 11 y antes tenía, pero ahora está, fíjense, en la posición 7. Dos, otros, seis, ocho, nueve, perdón, en la posición 9. Va creciendo, se nota que es una comunidad superactiva. Y si vemos la diferencia en las líneas de código entre release y release, es superbuena. Por otro lado, también, si observamos, las aplicaciones de usuario final como OpenOffice o LiveSafe y las de desarrollo están en el top 10 de lo que tiene más actividad dentro de la release. Sí. Eso a mí me resulta bastante interesante. Este es más o menos la distribución de los paquetes. En el eje de las X tenemos los paquetes ordenados por tamaño y, por supuesto, aquí por tamaño exacto, desde el que tiene más al que tiene menos y, por supuesto, aquí en las X. Eso es una distribución algorímica, logarímica, perdón, ya se ve más o menos. La de las releases anteriores es muy parecida, solamente que con menor cantidad de paquetes. La diferencia de cantidad de paquetes entre Edge y, por ejemplo, hablo de Edge por ser la anterior, más que todo, es de 2,000 paquetes o algo más. Antes tenía 10,000 paquetes y ahora tiene 12,000 casi. Otro comentario sobre los paquetes, bueno, como les comenté, cada frío se está creciendo rápido, tal como se esperaba y lo que se prevé es que siga creciendo súper rápido. La cantidad de líneas de código por paquete se decrese con respecto a Edge, que tenía 28,000 líneas de código por paquete, ahora tiene 26,958. Eso es una de las razones que encuentro yo que puede explicar eso es, o mejor dicho, que encontramos, que puede explicar eso es el uso de otros lenguajes de programación que requieren menor cantidad de líneas de código para hacer una o dos cosas o varias funcionalidades. Pienso yo. Como les comenté, las aplicaciones de usuario final y de desarrollo están en el top 10. Y otra cosa que encontramos que era bastante interesante era que los 100 paquetes más usados en leni corresponden al 32,53% de la distribución. Su contribución es esa, con respecto a ham, que era el 64%. Eso quiere decir que el resto de paquetes está tomando importancia, de alguna manera, la distribución es distinta. Se podría así que todos van tomando como una cierta importancia dentro de la distribución. Con respecto al desarrollo, estamos hablando de líneas de código de trabajo sobre el paquete. Antes el top 100 era el 64% de la actividad, por decirlo de alguna manera. En cuanto a la estimación de costos y esfuerzos, que es otro de los puntos más interesantes del estudio, puedo decir que se utilizó un modelo, como expliqué en su momento, que se utiliza para la estimación de costos y esfuerzos en desarrollo, en ingeniería del software, pero para el desarrollo de software privativo. Por eso le llamamos un modelo clásico. Y los resultados que arrojan este estudio en leni es que el esfuerzo de desarrollo requerido, si hoy una empresa dice, quiero desarrollar una Reli 5 de leni, viene siendo 183,000 personas por año. Se aplica un sueldo en teoría, se le está pagando para el estudio en teoría, se le está pagando un sueldo de 2,000 euros mensuales a cada desarrollador. Les tomaría 9,31 años hacerlo, que es casi, casi lo que tiene leni, 10 años. O mejor dicho, debía el preto, debía el no leni. Y tendría un costo de 6,006 millones de euros hacer esa distribución, hacer esa release. Comparándola con otros sistemas operativos en función de las líneas de código, si vemos aquí a esta release tiene 323 millones de líneas de código con respecto a la demás, prácticamente, demuestra que es la mayor recopilación de aplicaciones libres que existe, sin duda. Bueno, aquí podemos también observar cómo ha crecido con respecto a las otras, en función de la línea de código, con respecto a las otras releases. Duplicó ya hace rato la de 23, por ejemplo. Como conclusiones, básicamente, esto es un resumen de casi lo más importante que he dicho, que debía el leni publicado en febrero 2009, cuenta con 323 millones de líneas de código, tiene un costo estimado de 6,006 millones de euros y necesita un tiempo estimado de trabajo de 9.3 años. ANSI-C, C++, Shell, Java, Python, y Python son los lenguajes más usados. Debian, sin duda, hasta el momento es la copilación de paquetes más grandes de software libre que existe. Y como trabajo futuro, queremos hacer estudios de licencias y autorías, que es otra de las cosas más interesantes. Análisis detallar y profundo de las versiones y su comparación, entender de mejor manera esa evolución y ese crecimiento, y si eso podría significar realmente una mejora o se podría convertir en un problema. Una de las cosas que pensamos que nos llama mala atención es el hecho de esperar tanto tiempo entre releases. Analizar la actividad de los voluntarios, otro de los estudios que queremos hacer es estudiar los repositorios de código, pero quisiéramos no hacerlo paquete por paquete, porque eso se puede, sino como tal, la contribución de los desarrolladores a la distribución como tal. Estudiar las listas de código, las listas de correo electrónico y los sistemas de seguimiento de errores. Y entender mejor cómo está funcionando, cómo ha evolucionado o cómo se comporta esto de incluir, de los mantenedores y los desarrolladores de Deviant. Esa es la página del estudio. Ahí encontrarán información muchísimo más detallada, incluso por paquete. Se le hizo también el estudio de costo y esfuerzo a cada paquete y su representación. Cada paquete tiene el estudio de cuáles son las líneas de código, perdón, en qué lenguaje están escritas el paquete. En cuanto a las herramientas, la información la recopilamos con 3, 2 scripts, 3 scripts en Python. El primero se encarga de bajarla el source.gz, crear la anatomía de la distribución, todo esto, el pull, main, todo esto, aplicar o ejecutar el logcount sobre cada directorio y recopilar la información, toda la parte de hacer las estadísticas desde los archivos temporales que contienen la información que arroja el logcount. El análisis de las licencias o del copyright será hecho con Pyternity, es otra de las herramientas que se están desarrollando ahorita. Y tenemos otras herramientas que son los analizadores de repositorios de código, analizadores de listas de correo y analizadores del sistema seguimiento de errores o Backtracker System. Son herramientas bastante interesantes de usar porque puedes entender, por ejemplo, cómo es el crecimiento de la distribución y cómo es la actividad de cada paquete, porque ves quién es el comítter más activo, cuántos commits se hacen por México. En cuanto al analizador de listas de código es interesante también porque puedes entender cuán activa es desde el punto de vista de comunicación entre desarrolladores con usuarios y todo esto. Y sin duda, otra fuente riquísima de información son los Backtracker System porque entendemos cómo es la dinámica de resolución de errores y esa atención al usuario. Podemos ver por ejemplo quién es el que, si es un desarrollador o es un usuario el que reporta la mayor cantidad de bugs, por ejemplo. Este es parte del equipo de investigación de LibreSoft. Y, bueno, pues nada. Preguntas, sugerencias y gracias por haberme escuchado. Sí. Sí, sí. Por decirlo de alguna manera salvando muchas distancias en nuestra competencia. De hecho, estamos trabajando también en una forja. Elínas de código, para ver si sigue cumpliendo una exponencial. No, no la tengo. No tienes, vaya. Sí. Perdón. Esa. Ajá. Ya, ya. Si se evaluan los diferentes forks, o sea la diversificación de las aplicaciones, si se evaluan de alguna manera. Lo que comenté de las cosas que nos tocó enfrentar cuando hicimos el estudio de por qué hay forks, hay parches y hay reúso de código. Ese tipo de cosas, hay que estar con mucho detalle y es una de las cosas en las que queremos mejorar. Porque la lista que tenemos la hacemos a mano. Entonces, sí vemos ese tipo de cosas y lo que hacemos es coger el mejor representante de la lista. O sea, si por ejemplo, como comenté en el caso de GENAT y de GCC, decidimos que eran dos paquetes distintos, a pesar de que GENAT está basado muchísimo en GCC. Pero ahora aplican tantos parches que al final dijimos nada. Son dos códigos distintos. Ese tipo de cosas, con eso hay que ser muy minucioso, porque es una fuente de impresición supergrande. Pero verlo, imagínate, con 23,000 paquetes o con 12,000 fuentes. Estoy seguro de que debe existir una manera de hacerlo automáticamente, pero tenemos que desarrollarla. Pero sí, sí vemos esos casos, sin duda. Gracias. ¿Alguna pregunta más? Duda, recomendaciones, sugerencias. Nada más era comentar una cosa en las diapositivas. Tenías puesto, pero como si fuera un acrónimo. Y no lo es. La capitalización correcta sería P mayúscula y el resto minúsculas. Porque estamos hablando del lenguaje, no de la implementación. Cierto. Gracias. Sí, igual que el caso de contando, igual que el caso de tenía dudas con la traducción de how large is Lenny. Ya había puesto cuán grandes Lenny, y Ana me dijo que era mejor poner cuál es el tamaño de Lenny. Gracias.