Retrospectiva

Breve comentario sobre lo que vivimos en Rosario

Primero que nada quiero destacar la buena onda y hospitalidad de toda la gente que nos encontramos, no sólo de los organizadores.

En cuanto a las conferencias, es de destacar (¡sinónimo por favor!) que había para todos. Hubiese sido copado que los conferenciantes hubiesen comunicado al LUGRo el nivel (principiante, medio, avanzado o lo que fuera, pero algo indicativo) de las conferencias al darles el contenido que se publicó en la web.

También hubiese sido interesante conocer algo más sobre los conferenciantes de antemano, por ejemplo, junto a los datos de la conferencia se podría haber agregado un dossier de quién daba la charla. Yo soy un lammer que vive en una tapita de seven-up, y en mi caso particular me enteré por suerte allá de quien era Juan José Ciarlante. Fue entonces que decidí asistir a su charla, y debo decir que hoy estaría arrepentido si no la hubiese visto, ya que fue muy buena y motivante. Por otra parte, no asistí a la de Perl porque la juzgué por los contenidos y luego me enteré que estuvo muy buena y que quien la dio es uno de esos super-profesores que por ahí se encuentran, una lástima no haber ido.

Por otra parte, no puedo dejar de contar esto: hubieron muchos problemas tanto con la instalación del primer Linux el primer día (Corel, no sé del segundo día, no asistí), como con los cañones proyectores.

La parte de instalación fue lisa y llanamente patética, y lo fue por lo siguiente: esa era una charla a la que asistiría mucha gente que recién se está acercando a Linux. Yo por mi parte, con casi dos años como usuario y algunos pre-acercamientos anteriores, estoy convencido de lo bueno de Linux y sé donde puede estar fallando un poquito para mí, pero no lo cambiaría por otros sistemas operativos, al menos no por ahora.

En cambio quien fue a ver esa charla para tomar conocimiento del asunto, salió con una idea bastante errónea de lo que es Linux. En particular quiero hacer notar que se produjeron todos los errores que se les suele achacar en tono jocoso a otros sistemas operativos que no mencionaré aquí, siguiendo la filosofía de Juanjo Ciarlante.

Por último, y esto lo sabe cualquier usuario Linux, no cuesta nada ponerse dos horas antes a hacer la instalación para asegurarse de que todo ande sobre ruedas.

Sobre los problemas con los cañones proyectores no me quedó claro por qué las fallas persistieron en ciertas charlas cuando ya se habían solucionado en charlas anteriores. Eso opacó bastante la exposición. ¿Costaba mucho preguntarle a otro cómo hizo?

Valga todo esto como recordatorio y esperemos no cometer los mismos errores en congresos venideros, sea quien sea que lo organice de la comunidad GNU/Linux.

No he hablado de Richard Stallman, ni lo haré aquí porque considero que el viejo merece un capítulo aparte. Una vez que lo ves te das cuenta por qué.

Las conferencias

Instalación de GNU/Linux en pantalla gigante (por Harpo Maxx)

Las jornadas se iniciaron a las 10:00, con una instalación de GNU/Linux en pantalla gigante. Muchos de los que viajamos -de hecho creo que todos- habíamos instalado Linux una cuantas veces, pero aún así decidimos ir a ver esa instalación.

Para nuestra desgracia vimos que la instalación era de una distro Corel 1.0, distribución por demás comercial y para el gusto de muchos bastante mala. Si bien esta distro esta basada en Debian, su orientación gráfica le ha quitado todo su poder.

Y esto creo que quedó demostrado cuando la gente de Corel NO PUDO realizar una instalación con éxito. Esto debido a que se colgaba ala Windows, tal vez por incompatibilidades de una placa de video o vaya uno a saber por qué; la cosa es que Corel GNU/Linux no se pudo instalar.

Esto seguramente no hubiera pasado si hubiera existido la posibilidad de realizar una instalación en modo texto. Pero claro, la gente de Corel no consideró necesario colocar esa funcionalidad. Algo que tiene que servir a otras distros como RedHat para darse cuenta de que lo gráfico si bien es lindo, muchas veces trae más dolores de cabeza de los que supuestamente soluciona.

Lo feo de esto es que dejó un amargo sabor de boca a la gente, por que definitivamente es mala publicidad para GNU/Linux.

 

El proyecto GNU/Debian (por Harpo Maxx)

Esta charla fue totalmente informal y divertida. La dió uno de los mantenedores de paquetes de Debian. Como muchos saben, Debian es la única distro armada por gente de todo el mundo, básicamente al igual que el kernel Linux. Realmente la charla tenía el estilo informal que caracteriza a GNU. Nick no pretendía vendernos Debian, por que sencillamente él no gana dinero con ello, a diferencia de RedHat o Corel que definitivamente sí lo hacen. <P> Lo más interesante de esta charla fue el saber que la misma gente de Debian opina que sólo los tontos usan la versión estable de Debian. ¿Y esto a que viene? Como todos saben, la versión estable de Debian es muy vieja; es más aún tiene kernel 2.0.36. Cuando estamos en los albores de la versión 2.4.0 del kernel, tener una distro con un kernel tan viejo, es de por sí una mala publicidad para Debian. Pero la gente de Debian dice que la versión de desarrollo, cuyo nombre es Potato es totalmente usable y que sólo un tonto no la usaría.

De esta manera aprendimos que las versiones estables de Debian no son usadas por nadie. Un comentario que nos hizo pensar en instalar Debian es que según Nick, Debian es totalmente upgredable... no como otras, que se jactan de serlo y que la mayoría de las veces resultan un fracaso. En conclusión, ¡vale la pena probar Debian Potato!

 

Linux Kernel, Presente y Futuro (por Harpo Maxx)

Esta charla, que prometía por su nombre, no fue más que un fiasco, o al menos esa es mi opinión. El tema es que era demasiado introductoria y que solamente al final parece que se puso linda. Esto lo digo por que partí a los 15 min hacia la conferencia de Perl.

 

Perl (por Harpo Maxx)

A ésta llegué un poco tarde como es de suponer, pero debo decir que me fascinó: hace mucho que vengo escapándole a Perl, por que muchos dicen que es un tanto obscuro. Debo decir que quien diga eso está equivocado. Las posibilidades de Perl realmente me asombraron.

La charla estaba dada por el gurú del LugRo, del cual no recuerdo el nombre pero que tenía la apariencia típica de un gurú de UNIX... adivinen... ¡una larga y frondosa barba!

El tipo se veía que venía de la escuela de UNIX: archivo en PostScript a modo de presentación, empezó con un breve intro sobre Perl y ahí no más se metió con un par de ejemplos bastante interesantes.

Un par de aplicaciones cliente/servidor, en las cuales el cliente enviaba código en Perl al servidor y este a su vez lo ejecutaba. No tenía más de 20 líneas de código. Con esto yo me quedé impresionado. Claro que no soy un gurú ni mucho menos... pero me sorprendió lo sencillo del código.

Otro fue usando el módulo PERL/TK, el cual hacía muy sencilla la creación de ventanas en entornos gráficos. El ejemplo fue armar una ventana para navegar por los directorios del disco. Realmente se hizo rápido y no ofreció ninguna dificultad a la hora de leer el código.

Realmente el tipo supo vender a Perl, y creo que es un must see.

 

Cálculo Numérico con GNU/Linux (por Harpo Maxx)

Definitivamente esto estaba fuera de mi campo, ya que no soy un físico/matemático, pero quería ver como alguien que no era un computonto usaba GNU/Linux para algo real.

El tipo que dió la charla era el típico físico/matemático medio loco de la cabeza. Básicamente se necesitaba calcular los vórtices que se han producido en el universo desde su creación (esto no sé si era realmente así). Para esto obviamente se necesitaban realizar un montón de cálculos. El tipo comentó cómo fue pasando por lenguajes de programación diferentes. Fortran, C++, hasta finalmente llegar a C, esto debido a que según él, C era el más rápido ejecutando su código.

Esto último originó una discusión entre algunos fanáticos de C++, que decían que el C++ era más o igual de rápido que C, lo que pasaba es que mucha gente se viciaba con C++ usando cosas como tempates, etc. debido a su vagancia. Ahora... yo digo: si vamos a usar C++ sin ninguna de su ventajas, ¿por qué mejor no usar C?

En fin. La cosa es que el tipo lo hizo en C, pero tenía un problema: para obtener la solución se necesitaban ni más ni menos que 100 días de procesamiento. Y para esto se necesitaba una plataforma lo suficientemente robusta como para que no se colgase durante esos 100 días. Como bien dijo el tipo, esa plataforma no es DOS/Windows, esa plataforma es GNU/Linux.

De esta manera el tipo comentaba que en su casa con un PII/350MHz podía obtener soluciones que antes hubieran requerido de máquinas muchos mas grandes y costosas corriendo UNIX comerciales.

 

Cálculo Numérico en Cluster Beowulf (por Harpo Maxx)

Esta conferencia era muy similar a la anterior, por lo menos en relación a sus fines, ya que en este caso el físico/matemático que la dió también pretendía usar la potencia de Linux para resolver una gran cantidad de pequeños cálculos. Sin embargo la diferencia esta vez estaba en que sería hecho por un cluster de 6 máquinas.

Básicamente el cluster estaba formado por 5 PIII/350MHz y un 1 PII/250MHz con placas Ethernet 100Mbps y todas excepto una eran diskless.

Una de las ventajas obvias de un cluster es su economía, y acá en Argentina eso es una ventaja fundamental. He allí la razón de que las máquinas sean diskless.

El tema de usar un cluster para cálculo es más que interesante. Sin embargo, a veces no da los resultados esperados debido a que existe un overhead muy grande a medida que más y más máquinas se comunican entre sí. Y a veces ocurre que no se obtiene una gran ventaja con este tipo de procesamiento.

Ahora bien, para poder ejecutar estos programas se necesita que los programas vengan ya preparados para hacer uso del cluster, por ello deben estar compilados contra alguna de las librerías públicas para procesamiento en cluster como ser MPI o PVM.

El tema de cluster resulta muy amplio y si bien la conferencia estuvo muy interesante a mí me quedó con gusto a poco. Sin embargo era una buena intro a clusters Beowulf, por alguien que lo está usando con un fin muy práctico y real.

A los interesados visitar:

• http://www.beowulf.org
• http://www.netlib.org

 

KDE 2 (por C0r0nel)

KDE 2 ofrece grandes mejoras visaules y de funcionamiento. De lo que primero se habló fue de Konqueror. Esta aplición reemplazará al viejo KFM. Las principales ventajas son:

 

• Es un browser de web muy completo: soporta HTML 4.0, Java Script, plug-ins de Netscape e importa automáticamente sus bookmarks.
• Como adminstrador de archivos incorpora soporte para la mayoría de los protocolos, entre ellos SMB. (poniendo un URL smb:// podremos entrar al Entorno de Red de Windows.
• También es capaz de acceder a mailboxes POP3 poniendo pop3://maquina.

En fin... Konkeror promete mucho.

En cuanto a los más core, se puede decir que está basado en la nueva versión de Qt que incorpora soporte para texturas y transparencias (muy cool).

Se ha implementado un protocolo de comunicación entre aplicaciones que reemplaza completamente al que se había empezado a desarrollar (CORBA). Este protocolo se llama DCOP: está pensado para agilizar el intercambio de información entre todas las aplicaciones que lo usen, entre ellos el mismo KDE.

Una de las cosas en las que se hizo incapié fue en la velocidad. KDE2 es mucho más rápido que su antesesor 1.x.

Antes las configuraciones eran almacenadas en archivos de texto que luego las aplicaciones iban y leían. Eso es lento. Ahora las configuraiones que leen las aplicacioness son archivos binarios (una suerte de registro, pero que anda bien ;-)). Ojo: los archivos de texto viejos siguen existiendo para que el usuario pueda ir y tocar a gusto.

Para poder refrescar las configuraciones que leen las aplicaciones se creo KSycoca. Esta aplicación es un daemon que está constantemente olfateando si cambió algún archivo de configuración (texto) y va y modifica el binario.

Koffice. Este paquete en sí es tan grande como el resto del KDE. Lleva casi dos años en desarrollo y ya está listo para salir a la calle. Esta suite contiene: KWord, KSpread, KPresenter, KChart, KIlustrator, KOSShell.

Themes. ¡Sí! Ahora tenemos themes copados, con botones texturados, ventanas semi-transparentes y soporte para temas de GTK. Muy bueno.

KMail. Bueno... que se puede decir... todo lo que le faltaba al viejo Kmail lo tiene. Por ej. búsquedas de mails, threading de mensajes, resaltado de colores, subfolders, etc. ¡Ah! y para el que todavía navegue por el lado oscuro, Kmail es capaz de importar mails y libreta de direcciones desde OutLook Expre$$. Muy bueno.

Sonido. Todo nuevo por aquí. Ahora el mixer se puede anclar como applet en la barra. Hay una nueva aplicación llamada ArTS que es un deamon que se encarga de administrar todos los eventos de sonido.

En cuanto al escritorio, además de lo ya existente, se puede por ejemplo poner una aplicación como papel tapiz. Sí: ¡dije papel tapiz! En la demo tenían corriendo el KWorld de tapiz, y mostraba la tierra girando y donde es de día o de noche.

Y como broche de oro, se va a incluir KDevelop que es un IDE impresionante, capaz de administrar proyectos para KDE, GTK, C estándar y un montón más.

En fin... Como conclusión, KDE2 debe estar en sus escritorios más o menos para principios de setiembre. Según el schedule oficial que puede restrasarse o no.

En el LUGMen lo estamos probando, así que para quien se quiera unir, tenemos los sources de la Beta 3 ya bajados.

Have fun!

 

Kernel Hacking (por Groucho Marx)

En nuestra visita a Rosario con motivo del Primer Encuentro Nacional de GNU/Linux (excelente excusa para no ir a trabajar el viernes y apreciar los notables frutos de la tierra litoraleña) concurrimos a la conferencia titulada "Desarrollo del Kernel: una experiencia personal" a cargo del cordobés/mendocino Juan José Ciarlante. ¿Lo ubican de los créditos del kernel?

En mi opinión, la más grosa de las conferencias que se dictaron. Más aplaudido que el propio Richard Stallman (plato fuerte del ciclo de conferencias), Juanjo (como gusta que lo llamen) ofreció un relato humilde y comprensible para incitarnos a contribuir código a Linux.

Uno pensaría que hay que ser un gurú para escribir un par de líneas de código de Linux, pero luego de escuchar la conferencia descubrí que lo único que hace falta es tener ganas de resolver un problema y algunos conocimientos de C. Me sorprendió escuchar que el mismo Juanjo no tiene idea de como funcionan partes importantes del kernel como el administrador de memoria, o el scheduler, y que tampoco hace falta para hacer algo útil (como demuestran las propias contribucines de Juanjo).

¿Entonces qué hay que saber para escribir un trozo de kernel? Primero hay que saber el contexto de ejecución, o en otras palabras quién y cuando nos va a invocar. ¿Nos van a invocar en forma reentrante, nos van a poder interrumpir? La respuesta a estas preguntas se entiende conociendo algo de la arquitectura interna del kernel. El kernel está bastante estratificado, con capas inferiores siendo invocadas por capas superiores, y encima de todo, las llamadas al sistema invocadas por los programas de espacio de usuario. Si vamos a escribir un driver que provea una funcion de red -por ejemplo- debemos saber que vamos a ser invocados desde abajo posiblemente por el servicio de interrupción de la placa de red, que nos proveerá de un paquete. Nuestra tarea es copiar ese buffer a una zona de memoria asignada por nosotros de manera de desacoplar nuestro funcionamiento (posiblemente lento) del funcionamiento del servicio de interrupción. Apenas copiamos el buffer, se reactivan las interrupciones y el servicio de interrupción puede ser invocado nuevamente. De esta forma, la ejecución de un servicio de interrupción se reparte en 2 trozos de código, de los cuales uno (el "bottom half") correrá con interrupciones desactivadas y el otro (el upper half) con las interrupciones activadas y pudiendo ser reinvocado mientras se ejecuta. Esta architectura es la causa del cortísimo tiempo de latencia que ofrece Linux (tiempo que transcurre desde una exitación de hardware hasta que el sistema reacciona).

En las versiones anteriores del kernel (versión 2.2) se garantizaba que desde arriba sólo se nos invocaría una vez. Para garantizar esto, en sistemas multiprocesador se establecían bloqueos globales al entrar una CPU a ejecutar código del kernel, de manera que todas las otras CPUs se quedaran congeladas esperando para acceder al kernel. Es una forma burda pero infalible de evitar problemas de sincronización. ¿Cómo se implementan los global locks? De la forma más gay y simple:

 

 

while(global_lock);

 

Mientras una condición sea cierta (la condición de que esté activado el global lock), la CPU da vueltas a lo tonto alrededor de un bucle vacío. Por este motivo, a esta forma de sincronización se la conoce como spin lock (bueno, A. Tannembaum lo llama "espera activa"). Una zona crítica de código (una zona en la que no se admita que otra CPU ejecute código simultáneamente) se protejerá de acceso simultáneo así:

 

 

while(global_lock); /Espero a que me dejen entrar/

global_lock=1; /Ahora que entré, no dejo entrar a nadie mas/

hacercosasgrosas(); /Esto es la zona crítica/

global_lock=0; /Ya está. Si otro quiere entrar, lo dejo/

 

En las versiones recientes del kernel (versión 2.4) el funcionamiento multiprocesador ha madurado lo suficiente como para permitir que un trozo de kernel pueda ser invocado desde arriba en forma reentrante.

¿Cuando habrá que usar spin locks? Siempre que se desee actualizar una estructura de datos que otras CPUs puedan leer mientras que la CPU que realiza la actualización esté haciendo cambios. Todos los ejemplos que se me ocurren de estos son demasiado largos de explicar, o demasiado inventados como para que me crean que en realidad pueden ocurrir. Pero ocurren.

Una forma simpática de empezar a hacer pruebas es usar la función printk() que es una versión de printf() que se puede invocar desde el kernel y que escribe texto en la consola del sistema.

 

El Proyecto GNU y la Free Software Fundation (por Harpo Maxx)

Esta fue la mejor conferencia de las 2 que dio Richard Stallman. La conferencia empezó a tiempo y fue dada totalmente en inglés, debido a que a RMS no le gusta ser interrumpido por un traductor. De alguna manera esto limitó la cantidad de gente que podía escucharlo. Sin embargo su inglés fue muy entendible.

Richard Stallman ,fundador del movimiento GNU de Software Libre, es otro típico gurú de Unix de la década del '70, de larga barba y extensa cabellera, con una expresión sonriente y una panza digna de Homero Simpson. ¡Al verlo uno se da cuenta por que se los compara con los gurúes orientales!

El relato de Stallman fue el clásico discurso GNU que uno puede observar el las paginas del movimiento en http://www.gnu.org.

Su historia se remonta a cuando él trabajaba en el prestigioso MIT como programador, donde existía una cierta camaradería entre todo el ambiente computonto de la época. Una época definitivamente ingenua donde todos compartían sus conocimientos y sus programas.

Su primer encuentro con el software cerrado fue cuando EPSON gentilmente otorgó al MIT una impresora láser. El problema que se les presentó es que la impresora estaba a unos cuantos pisos del lugar en donde RMS y mucha otra gente estaba programando y el driver no proporcionaba la información necesaria para saber cuándo la impresora se quedaba sin papel. Esto traía aparejado una gran pérdida de tiempo, ya que muchas veces uno se quedaba esperando un tiempo prudencial y cuando iba a recoger el trabajo de la impresora, se daba cuenta que no tenía papel.

En uno de sus viajes a "vaya uno a saber dónde" se enteró de alguien que tenía el código fuente del driver y se hizo un tiempo para ir a visitarlo para pedírselo a fin de poder arreglar sus problemas en el MIT. Para su sorpresa la persona que tenía el código fuente se negó a dárselo aludiendo que había firmado un convenio para no divulgar esa información. Para aquella época, eso era impensable.

Por desgracia eso se fue propagando y RMS vió con horror como su amada comunidad en donde todo se compartía se volvía cada vez mas egoísta.

Esto fue lo que le hizo pensar en alguna manera de salvar esa situación y fue cuando decidió trabajar paralamente a su trabajo en un proyecto que hoy tiene mucho de locura, pero que para aquella época era muy factible llevar a cabo. Un proyecto que involucraría la creación de todas las herramientas que un programmer necesitase pero que sean FREE. Entendiéndose por FREE como LIBRE y no como gratuito.

Cuando su jefe le solicitó que firmara un convenio para no divulgar información, RMS no tuvo mas opción que renunciar, y allí su jefe le dijo: Ok. ¿Quieres una máquina para trabajar en tu proyecto?

Y así fue como RMS siguió en el MIT, sin trabajar oficialmente, pero usando sus máquinas para su proyecto, proyecto que ahora conocemos como GNU, (GNU is Not Unix). La idea de este proyecto pasó de ser simplemente el "copiar" las herramientas necesarias para un programador, a tratar de implementar todo un SO similar a Unix.

Definitivamente la idea era buenísima, al principio se realizaron las herramientas básicas, Emacs (un editor poderoso según dicen), gcc (un compilador multiplataforma), libc (un conjunto de funciones de la librería standard), make, bash, etc.

Llegó un momento en que casi todas las piezas estaban listas salvo una pequeña parte: el kernel (cuando RMS dijo esto en la conferencia, todos se rieron pensando que era un ironía; después nos dimos cuenta que lo dijo en serio).

Ahí fue cuando Linus Torvalds, en Finlandia liberó el kernel Linux bajo la misma licencia con la que estaban trabajando la gente del proyecto GNU: la licencia GPL. Pero Linus nunca les comentó nada a la gente del proyecto. Por que según Stallman y también el propio Linus el no lo había hecho teniendo en cuenta toda la filosofía política que llevaba tras de si el proyecto GNU, en palabras de Linus, lo hizo to have fun.

Ahí fue cuando la gente se dió cuenta de que existía una gran cantidad de software libre a la que le faltaba una parte, y esa pequeña parte (según RMS) que era el kernel de Linux, combinándose así en lo que RMS quiere se que llame GNU/Linux o GNU+Linux.

Ahora bien, RMS está enojado, muy enojado por que la gente lo llama vulgarmente Linux, sin hacer referencia a todo el trabajo y la filosofía que hay detrás de GNU.

No sabemos si tiene razón en estar enojado o no, ya que por una parte Linux le permitió al proyecto GNU volverse masivo. Ahora según RMS el miedo que ellos tienen es que la gente se olvide de la razón por la que nació Linux y olviden las bases filosóficas que tiene detrás. ¡Eso el tiempo lo dirá!

 

Conclusiones

Quiero dedicar mi más caluroso aplauso al LUGRo, porque más allá de las pequeñas fallas, el esfuerzo vale un montón. Y ojalá el año que viene podamos viajar de nuevo a conocernos más.