debian

Empaquetando software para Debian: Herramientas y procesos básicos

Submitted by gwolf on Tue, 09/11/2012 - 18:39
Written in...: 
2012

While it is true that there are many non-technical areas where you can contribute to help Debian grow, fact is how to create a Debian package is a recurring question among people interested in getting into Debian. In this talk/tutorial we will see the basic points of packaging, understanding how to build a simple package.

Points to cover:

  • What is a package?
  • What is apt's role? And dpkg's?
  • What do I need in order to create a simple package?
  • Dependencies, recommendations, and everything that surrounds it

If we have enough time, I'd like to touch some points on team maintainership (keeping packages in version control systems, schemes and tools for group coordination and communication, etc.)

Resumen: 

Si bien hay muchas áreas no técnicas con las que puedes contribuir con el desarrollo de Debian, la duda recurrente entre los interesados en acercarse a formar parte de Debian es cómo se hace un paquete. En esta charla-tutorial veremos los puntos básicos del empaquetamiento, comprendiendo cómo esta compuesto un paquete sencillo.

Puntos a cubrir:

  • ¿Qué es un paquete?
  • ¿Cuál es el rol de apt? ¿Y de dpkg?
  • ¿Qué necesito para crear un paquete sencillo?
  • Dependencias, recomendaciones, y todo lo que lo rodea

Si nos da tiempo, me gustaría tocar puntos de mantenimiento en equipos (mantener paquetes en sistemas de control de versiones, esquemas y herramientas de comunicación y coordinación en equipo, etc.)

Arquitecturas de paquetes al rescate

Submitted by gwolf on Fri, 06/18/2010 - 07:35
Wolf G.  2010.  Arquitecturas de paquetes al rescate. Software Gurú.

Modularización: Arquitecturas de paquetes al rescate

Convirtiendo a la hidra en nuestra aliada

En el número 27 de Software Gurú, Agustín Ramos presentó un artículo acerca de estrategias para lograr una modularización efectiva en Java. Varios de los puntos de su artículo me llevaron a dedicar la presente columna a explicar a qué llamamos una distribución de Linux, y cuál es su relación –y la solución que ofrece– a los problemas derivados de la complejidad derivada de la modularización, que bien describió Agustín.

Como deben ya saberlo, a diferencia de otros sistemas operativos, el entorno operativo completo al que normalmente nos referimos como Linux no es desarrollado por un sólo grupo, ni sigue un roadmap, criterios o visión en común. Mucho se ha argumentado acerca de las características que diferencían a los proyectos desarrollados desde planteamientos libres de aquellos desarrollados siguiendo metodologías tradicionales — No abordaré dicha discusión en este momento. Sin embargo, no quiero dejar de aprovechar la oportunidad de tener un artículo escrito por un colega en esta revista para ilustrar cómo abordamos la relación entre proyectos independientes –que logran una complejidad de miras mucho mayor que cualquier instancia de conjuntos de módulos desarrollados en casa– en el Software Libre, por qué enfatizamos tanto en lo prevalente que resulta dicha modularización, y cómo nos enfrentamos a su inherente complejidad.

Los sistemas basados en Linux son estructurados, pues, en distribuciones. Una distribución es un conjunto de programas –típicamente del órden de miles– que, entre todos, presentan la funcionalidad que un usuario espera ya no sólo de un sistema operativo sino que de todo un entorno operativo integrado. Además, se encargan de gestionar las relaciones de dependencia entre dichos programas, y resolver dichas dependencias, para facilitar al usuario la instalación, remoción y actualización de software.

Una instalación mínima de cualquier distribución de Linux no tiene menos de un par de centenares de paquetes individuales. El núcleo Linux, por sí mismo, no representa más que la interfaz más básica para presentar una abstracción del hardware ante los programas que corren sobre él. Formalmente, al mencionar Linux ni siquiera nos referimos a la interfaz de línea de comandos (misma que generalmente es provista por los paquetes bash, dash o sash, dependiendo de las necesidades del administrador). Son en realidad contados los paquetes que no dependen más que de paquetes esenciales. Toda distribución define un pequeño conjunto (decenas) de programas que es fundamental tener instalados como base para cualquier otro, conjunto mínimo que asumimos que siempre estará ahí para asegurarnos la funcionalidad mínima.

Si bien las primeras distribuciones tuvieron por objetivo facilitar la instalación de un sistema basado en Linux a usuarios con menor involucramiento técnico, y fueron instrumentales en la primer ola expansiva de usuarios que fuimos adoptando Linux hacia mediados de los 1990, han trascendido ya a éste rol para dar respuesta al infierno de dependencias al que se refiere en su texto Agustín Ramos: Hacia fines de los 1990, aproximadamente cuando todas las distribuciones comenzaban a contar en miles los paquetes independientes que ofrecían, comenzó a hacerse obvio que no bastaba con que cada paquete indicara de qué otros paquetes dependía (incluyendo, claro está, la información de versiones pertinente), sino que era necesario contar con una arquitectura de paquetes: Un esquema orientado a depósitos y no a paquetes individuales, que se encargara de resolver las dependencias cada que el administrador instalara o eliminara un paquete. La primera arquitectura fue introducida por la distribución Debian, bajo el nombre de apt: A Package Tool. Es definitivamente gracias a apt que, al día de hoy, la versión de desarrollo de Debian cuenta con 15640 paquetes fuente independientes, que resultan en 27886 paquetes binarios, cubriendo prácticamente todas las áreas de necesidad en cómputo, tanto a nivel de aplicaciones como de bibliotecas.

A diferencia de otras arquitecturas previas, como los ports de los Unixes BSD, Apt está además construido basado en el manejo de depósitos múltiples. Esto significa que, además de servirme para instalar los paquetes oficiales de la distribución, nos permite definir depósitos adicionales con el software que desarrollemos localmente, así como de paquetes adicionales que preparemos localmente para uso en nuestra organización.

Con esto como introducción, veamos cómo ésto se aplica al texto de Agustín. Por razones de espacio, me enfoco a cómo éste esquema reduce fuertemente los efectos negativos de la modularización, permitiendo a los desarrolladores crear software más robusto y temer menos a esta tan dificil de conciliar fuente de dolores de cabeza.

Demasiadas dependencias
El argumento principal mencionado en el texto al que hago referencia en contra de tener demasiadas dependencias es la posterior dificultad de instalación de nuestros sistemas. Sin embargo, al crear paquetes con la información de las dependencias, convertimos el fastidioso proceso de instalación (y todo el tiempo que requiere documentarlo) en una sóla instrucción al sistema.
Dependencias cíclicas
Coordinar el trabajo de cientos de voluntarios en todo el mundo, sin más factores de cohesión que su voluntad por crear un sistema de calidad trae como resultado natural el que parte importante de sus esfuerzos estén encaminados a la creación de documentos de políticas comprehensivos — y a que su comunidad de desarrolladores comprenda la importancia de dichos documentos.
Claro está, si la unidad atómica de trabajo en una distribución es el paquete, problemas tan claros como las dependencias cíclicas fueron de los primeros puntos en ser prohibidos por política. Sin embargo, conforme la complejidad de cada uno de los paquetes aumenta, se vuelve posible que aparezcan dependencias cíclicas de indirectas. Para evitar problemas como este, y otros destinados del control de calidad en sistemas complejos, se hacen revisiones periódicas de todos los procesos imaginables.
En este aspecto, si bien no hay balas de plata para evitar las dependencias cíclicas, contamos con una comunidad de desarrolladores verificando que estos problemas se mantengan al mínimo. No estamos sólos en el manejo de nuestros proyectos.

Largas cadenas de dependencias
Este fue precisamente el punto que motivó al desarrollo de las arquitecturas de paquetes. Podemos confiar en que la arquitectura que elijamos, empleando los depósitos del sistema y de nuestra organización, sepan resolver este punto sin que represente problemática alguna. Además, no tenemos por qué limitarnos al uso de este esquema para las dependencias de los componentes externos que empleemos. Si dentro de nuestra organización nos acostumbramos a empaquetar nuestro código en componentes, la reutilización de código que podamos hacer será muchísimo más simple y más natural.
Dependencias en conflicto
Nuevamente, aquí acudimos a la sabiduría de las masas, a la fuerza de la multitud. Una distribución basada en Linux no es sólo un conjunto de programas disponibles a través de un mismo depósito — La mayor parte del trabajo de sus creadores es asegurarse que todos los componentes sean mutuamente compatibles, y asegurar a los usuarios un producto de calidad, con todas las actualizaciones necesarias para asegurar su seguridad (cuidando no compormeter su estabilidad) durante su ciclo de vida.
Este puede ser un punto fundamental al elegir qué distribución vamos a usasr para determinado proyecto: Hay distribuciones principalmente orientadas al perfil de usuario de escritorio, para el cual es fundamental tener siempre soporte completo para el último hardware, aceleración gráfica compelta y demás bondades. Sin embargo, para basar nuestros desarrollos empresariales, típicamente preferiremos las distribuciones con ciclos de vida más largos, con un mayor soporte a largo plazo.

Como pueden ver, manejar una arquitectura de paquetes simplifica algunas de las tareas más complicadas (y más ingratas) del desarrollo de software, el manejo de toda la talacha creada por los componentes que, a fin de cuentas, incluimos para ahorrarnos trabajo.

Cuando veo los instaladores típicos, que crean enormes amasijos (típicamente en forma de enormes instaladores .msi o archivos .jar que incluyen copia de todas las dependencias para evitar estos problemas), no exagero: Me dan ganas de llorar. Porque además, al tener varias copias de una misma biblioteca en el sistema, tengo la certeza de que en caso de aparecer algún defecto en alguna de ellas, habrá componentes de mi sistema que reciban la corrección en cuestión — pero habrá otros que no. Acostumbrarse al manejo de dependencias externas nos reduce la tentación de acudir al tan temido ligado estático, reduce el peso de nuestras imágenes de instalación (y de nuestros sistemas ya instalados), y ayuda fuertemente a mantener un mayor control de calidad en nuestros procesos como un todo.

Mucha gente evita aprovechar la modularización como medida preventiva para no perder la razón resolviendo dependencias y bugs creados por compatibilidad incompleta entre versiones. Sin embargo, dejar de usar buen software, ya existente y probado por terceros, sólo por no contar con las herramientas de seguimiento correctas es un triste error en el que debemos evitar caer. La hidra de la modularización a la que se refiere Agustín puede ser un mounstro mortal, pero si aprendemos a hablar con ella puede ser nuestro mayor aliado. Porque si dos cabezas piensan mejor que una, ¿qué decir de decenas de cabezas?

( categories: )

Debian: Su ubicación en el universo de proyectos de Software Libre, y qué emerge de ella

Submitted by gwolf on Thu, 05/13/2010 - 13:04
Written in...: 
2010

What characterizes the Debian project? What differentiates it from other distributions? What characteristics emerge from these points? I cover:

  • What is Debian?
  • Relation between Debian and Free Software
  • Main motivators for its developers
  • Relation between this project and other developments
  • Release cycles and quality assurance

I prepared this talk for Quito, Ecuador, May 2010.

Resumen: 

¿Qué caracteriza a Debian como proyecto? ¿Qué lo diferencía de otras distribuciones? ¿Qué características emergen de estos puntos? Analizo:

  • ¿Qué es Debian?
  • Relación de Debian con el Software Libre
  • Motivación primaria de sus desarrolladores
  • Relación del proyecto respecto a otros desarrollos
  • Ciclos de liberación y control de calidad

Preparé esta charla para presentarla en Quito, Ecuador, en mayo de 2010.

( categories: )

Bringing closer Debian and Rails: Bridging apparently incompatible cultures

Submitted by gwolf on Mon, 08/25/2008 - 13:32
Written in...: 
2008

Ruby on Rails has become a very popular framework for Web-based applications. And, even though Rails itself is neatly packaged and integrated in Debian, supporting Rails applications (specially in a large-scale provider) can prove rather difficult. Besides the core application, we face problems such as handling plugins, concurrent versions, and the like. In this BoF session we discussed the different problems we face, looking towards adequate solutions.
This talk was presented at DebConf 8, Mar del Plata, Argentina.

Resumen: 

Ruby on Rails se ha convertido en un framework muy popular para el desarrollo de aplicaciones Web. Si bien Rails mismo está empaquetado e integrado correctamente en Debian, el manejar aplicaciones Rails (especialmente si se trata de un proveedor de servicios a gran escala) puede ser más bien complicado. Además de la aplicación misma, nos encontramos con problemas como el manejo de plugins, tener disponibles versiones concurrentes de diferentes bibliotecas, y cosas por el estilo. En esta sesión discutimos acerca de los diferentes retos que esto nos trae, buscando llegar a soluciones adecuadas.
Esta ponencia fue presentada en DebConf 8, Mar del Plata, Argentina.

Integrating Perl in a wider distribution: The Debian pkg-perl group

Submitted by gwolf on Mon, 03/03/2008 - 17:32
Written in...: 
2007

Perl modules are very well organized in CPAN: They can usually be easily found and, thanks to tools such as the CPAN shell, they are easy to install and update even by novice users. However, when people start using Perl systems (as opposed to using Perl for writing such systems), asking them to take care of the dependencies or having them worry about different distribution architectures is a pain that should be spared from them.
In my talk, I will describe how Debian (and other Free Software distributions) addresses this problem by packaging a large subset of the CPAN archive, what is the task and scope of Debian pkg-perl team, some of the tools we use - and, most importantly, what is the best way for us to interact with you, the upstream authors' community - regarding our bug tracking systems, regarding module building and dependencies information, etc.
I presented this talk at YAPC::Europe 2007, Vienna, August 2007.

Resumen: 

Los módulos de Perl están muy bien organizados en el CPAN: Son fáciles de encontrar, y, gracias a herramientas como el shell de CPAN, son fáciles de instalar y actualizar hasta por usuarios novatos. Sin embargo, cuando la gente no involucrada comienza a utilizar sistemas basados en Perl (en contraposición con utilizar Perl para escribir dichos sistemas), pedirles que se preocupen de cubrir las dependencias o que tengan en mente diferentes arquitecturas de distribución de software es una molestia por la que debemos evitar que pasen.
En mi plática, describo cómo Debian (y otras distribuciones de Software Libre) lidian con este problema, empaquetando un amplio subconjunto del archivo CPAN, cuál es la tarea y misión del equipo pkg-perl de Debian, algunas de las herramientas que utilizamos - y más importante que todo lo demás, cuál es la mejor manera en que podemos interactuar con ustedes, la comunidad de autores - respecto a nuestros sistemas de seguimiento de fallos, construcción de módulos, información de dependencias, etc.
Presenté esta plática en el YAPC::Europe 2007, Viena, agosto de 2007.

Coordinación de esfuerzos en grupos de desarrollo e integración de Software Libre

Submitted by gwolf on Wed, 02/20/2008 - 16:28
Written in...: 
2008

I sent this short article for publication at the Software Gurú magazine. It describes the work we do at Debian's pkg-perl group. This is based on my slightly earlier talk Integrating Perl in a wider distribution: The Debian pkg-perl group, shortened and translated to Spanish.
It was published on the Software Gurú August-October 2008 magazine - You can get the printed version of this text as well.

Resumen: 

Envié el siguiente artículo corto para su publicación en la revista Software Gurú. Describe el trabajo que hacemos en el grupo pkg-perl de Debian. Esto está basado fuertemente en mi plática Integrating Perl in a wider distribution: The Debian pkg-perl group, reducido y traducido al español.

El artículo apareció en la edición agosto-octubre de 2008 de Software Gurú - Puedes ver también la versión que fue impresa.

Coordinación de esfuerzos en grupos de desarrollo e integración de Software Libre

Gunnar Eyal Wolf Iszaevich

Instituto de Investigaciones Económicas - UNAM

Acercarse a comprender el funcionamiento y la organización de las tareas dentro de las comunidades de desarrollo de software libre es una tarea harto complicada ante quien se acerca con curiosidad, proveniente del mundo del software propietario, desarrollado e integrado centralmente y dentro de compañías que operan como "cajas negras" - Sin exponer sus procesos, sin ofrecer a los clientes una ventana a cada uno de los momentos de su proceso de desarrollo. Comprender cómo funcionan las comunidades de Software Libre es una gran oportunidad para comprender distintas metodologías de ingeniería de procesos, en entornos donde todas las metodologías formales simplemente no tienen cómo ser aplicadas.

El ejemplo que presento se centra en el trabajo que realizo en el grupo de empaquetamiento de módulos de Perl (pkg-perl) para la distribución Debian GNU/Linux - Perl es un lenguaje de programación muy popular, especialmente para las tareas de administración de sistemas y de desarrollo de sitios Web, y uno de sus más importantes recursos es el CPAN (Comprehensive Perl Archive Network), una enorme biblioteca de módulos nacida en octubre de 1996, y que a febrero del 2008 cuenta con más de 13,000 módulos independientes.

CPAN ofrece a sus usuarios, además, herramientas para el desarrollo y seguimiento colaborativo, como un sistema de seguimiento de fallos y un sistema de organización, búsqueda y consulta de la documentación de dichos módulos.

El proyecto Debian, por su parte, es la distribución de software libre, hoy por hoy, más grande del mundo, con más de 15,000 paquetes fuente independientes. Su propósito es presentar una colección coherente, consistente y con un elevado nivel control de calidad.

El reto del grupo pkg-perl es empaquetar (de una manera consistente con las políticas de Debian) y dar seguimiento a los fallos que vayan apareciendo en dichos paquetes. Debian ofrece a sus usuarios un sistema de seguimiento de fallos centralizado a través del cual pueden comunicarse directamente con los "mantenedores" de cada uno de los programas. Son ellos los responsables de determinar, para cada fallo, si cae en el ámbito de la consistencia del sistema Debian (y por tanto debe ser corregido directamente por ellos) o si es relativo a la lógica de uno de los paquetes (en cuyo caso debe ser corregido en coordinación con el autor de dicho programa, para que la corrección "fluya" hacia las otras distribuciones que lo integran y, en general, hacia todos sus usuarios).

Hasta hace unos cuatro años, la norma en Debian era que cada mantenedor fuera responsable exclusivo de los paquetes que le interesaran; en 2003 nació el sistema Alioth, basado en GForge, y ofreciendo de una manera centralizada las herramientas necesarias para un verdadero desarrollo colaborativo, se comenzaron a configurar grupos amplios de mantenimiento de infraestructura - Uno de los primeros en aparecer, ante la iniciativa de Joachim Breitner, fue pkg-perl. El eje fundamental en torno al cual gira el trabajo del grupo es el depósito Subversion, donde mantenemos sobre un esquema de manejo de versiones todos nuestros paquetes, programas y documentos, así como los cambios independientes que vamos realizando sobre de ellos.

Los módulos del CPAN ofrecen varias ventajas para su mantenimiento masivo colaborativo - A diferencia de lo que ocurre en muchos lenguajes, casi la totalidad los módulos están basados en una estructura de compilación ampliamente conocida (ExtUtils::MakeMaker o Module::Build). En primer término, esto permitió la creación de dh-make-perl, un script bastante genérico cuyo objetivo original era simplificar la creación de paquetes Debian directamente a partir del CPAN para ser instalados localmente por los administradores, pero que fue extendido por el grupo pkg-perl para automatizar la creación de paquetes.

Si bien formalmente el grupo pkg-perl cuenta con 70 miembros, en todo momento hay aproximadamente 15 miembros activos. Actualmente, el grupo es responsable por 660 paquetes - Responsable de dar seguimiento a los fallos reportados, de mantenerlos al día (tanto respecto a nuevas versiones producidas por sus autores como respecto a las políticas en Debian, que van cambiando poco a poco reflejando la evolución del proyecto), de realizar operaciones transversales de control de calidad a través de todos los paquetes, y demás.

Para simplificar la coordinación de todas estas tareas, los integrantes del grupo (especialmente Martín Ferrari, de Argentina, Gregor Herrmann, de Austria, y Damyan Ivanov, de Bulgaria) hemos creado un script que compara el estado de los módulos en CPAN, los paquetes en el depósito Subversion, los reportes en el sistema de seguimiento de Debian, y los paquetes publicados en la distribución misma de Debian. Hoy en día, este script es nuestra principal herramienta, brindándonos un reporte de estado condensado y adecuado específicamente a nuestro flujo de trabajo - Y tan útil resulta este resumen que actualmente estamos adecuando este script para que lo utilicen también otros grupos con un enfoque similar; probablemente para cuando este artículo esté impreso, lo estén utilizando ya los grupos de empaquetamiento de Python y Java - habiendo varios más en el horizonte.

En resumen, el ejemplo que aquí presento es sólo uno de tantos - Pero es ilustrativo. Bajo el modelo del software libre, las barreras entre desarrollo e integración se desvanecen, y el contacto directo entre usuario final y los desarrolladores deja de ser una rara ocurrencia, y se vuelve la norma - algo que damos por supuesto en todo momento de nuestros desarrollos.

Aprovechando a Debian para la administración de sistemas

Submitted by gwolf on Mon, 02/04/2008 - 00:09
Written in...: 
2006

Beyond what the Debian policy gives us, a highly coherent system in which everything is in its place and works as it should (for what we the system administrators are really thankful for), we can find a great amount of tools for easing the homogeneity in the administration both in the planning of its package management system as in many packages we have at our disposition. We will go through this, as well as the process of creating .deb packages, beyond the basic instructions. This talk was originally prepared for CICOL, June 2006

Resumen: 

Más allá de lo que ya nos dan las políticas de Debian, un sistema altamente coherente en el cual todo está en su sitio (lo cual bendecimos los administradores de sistemas), tanto en la planeación de su sistema de paquetes como en varios paquetes que tenemos a nuestra disposición encontraremos una gran cantidad de herramientas para facilitar la homogeneidad en la administración de sistemas. Revisamos algunas de ellas, así como el proceso de creación de paquetes .deb, más allá de las instrucciones básicas. Preparado originalmente para el CICOL, junio 2006

Software Libre: Un modelo alternativo para la producción de conocimiento

Submitted by gwolf on Sun, 02/03/2008 - 23:58
Written in...: 
2005

This talk is basically the result of mixing What is Free Software and Quality Assurance in Free Software projects, emphazising in the knowledge production aspects related to Free Software. This talk was first given at the UNAM Economical Research Institute, April 12, 2005.

Resumen: 

Esta plática es básicamente la mezcla de ¿Qué es el software libre? y Control de calidad en proyectos de Software Libre, enfatizando en los aspectos relativos a la producción del conocimiento que propone el Software Libre. La plática fue impartida por primera vez en el Instituto de Investigaciones Económicas el 12 de abril del 2005.

Participación en proyectos de Software Libre: Aspectos técnicos y sociales

Submitted by gwolf on Sun, 02/03/2008 - 23:18
Written in...: 
2007

This talk is heavily based on QA in Free Software projects; it has basically been reformatted, rearranged and updated. So yes, if it sounds familiar... it is because it is so.

Resumen: 

Esta plática está basada fuertemente en Control de calidad en proyectos de Software Libre; básicamente, fue reformateada, reacomodada y actualizada. Así que, si el contenido te parece similar, es porque lo es.

Control de calidad en proyectos de Software Libre

Submitted by gwolf on Sun, 02/03/2008 - 23:06
Written in...: 
2004

How is Quality Assurance handled in Free Software projects? Even more, what does Quality Assurance mean in the Free Software world? The Debian project is analyzed as an example. This talk was prepared to be presented in CLEI2004, Arequipa, PerúForman parte los siguientes archivos:

Resumen: 

¿Cómo se maneja el control de calidad en los proyectos de Software Libre? Más aún, ¿qué significa el control de calidad en el mundo del software libre? Analizamos como ejemplo al proyecto Debian. Plática preparada para presentarla en el CLEI2004, Arequipa, Perú.
Forman parte los siguientes archivos:

Puede serte también de interés la plática Participación en proyectos de Software Libre: Aspectos técnicos y sociales, fuertemente basada en esta, reformateada y actualizada.

Aspectos sociales del Software Libre

Submitted by gwolf on Sun, 02/03/2008 - 16:40
Written in...: 
2003

What social characteristics can define the Free Software developers? Are we really a homogeneous group? Which problems can appear when facing a global project? How can we avoid them? I analize mainly the Debian project, comparing a bit with the OpenBSD and Ximian/Gnome projects.
This talk was prepared for the 2003 GULEV conference.
It is available as:

Resumen: 

¿Qué características sociales definen a los desarrolladores de Software Libre? ¿Somos realmente un grupo homogéneo? ¿Qué problemas principales pueden darse al enfrentarnos con un proyecto mundial? ¿Cómo los evitamos? Analizo principalmente al proyecto Debian, comparando un poco con los proyectos OpenBSD y Ximian/Gnome.
Esta plática fue presentada en la edición 2003 del Congreso GULEV.
Está disponible como:

Introducción a Debian GNU/Linux

Submitted by gwolf on Sun, 02/03/2008 - 12:14
Written in...: 
2002

In this presentation, I explain what is Debian GNU/Linux, and what makes it be what it is. I presented it for Departamento de Seguridad en Cómputo's GASU seminar, May 2002.

The following files are very old, dating from the 2002 seminar I gave this talk at. Anyway, in case you are interested:

Resumen: 

En esta presentación muestro qué es Debian GNU/Linux y por qué es lo que es. La presenté para el Seminario GASU del Departamento de Seguridad en Cómputo, mayo del 2002.

Los siguientes archivos son ya muy viejos, de la primera vez que presenté esta plática, en el seminario GASU, julio del 2002. Como sea, por si te interesan:

Breve introducción a los sistemas de manejo de paquetes / Brief introduction to package management systems

Submitted by gwolf on Sun, 02/03/2008 - 11:15
Written in...: 
2002

A presentation prepared for Días de Software Libre, confernce organized by Melix at CUCEI (Guadalajara, May 2002). Here I talk about what are package management systems, why are they needed in modern operating systems, the main characteristics
for the main package management systems, and briefly explain how to create .deb (Debian) packages.
This talk is available as:

Resumen: 

Plática que preparé para los Días de Software Libre, organizado por Melix en el CUCEI (Guadalajara, mayo 2002). Hablo primero acerca de qué son y por qué son necesarios los sistemas de manejo de paquetes en los sistemas operativos modernos, menciono las principales características de los principales sistemas de paquetes, y explico brevemente cómo crear paquetes en formato .deb (para Debian).
Esta plática está disponible en dos formatos:

Syndicate content