PUMASOL 2009, esta semana

Del día martes 21 al día viernes 24, se realizará el segundo coloquio universitario de software libre PUMASOL 2009, en el auditorio del edificio principal de la Facultad de Ingeniería de la UNAM en CU.

El calendario de ponencias lo pueden consultar en:

http://wiki.lidsol.org/index.php?title=PUMASOL_2009

Quedan todos invitados. La entrada es libre

Editores LaTeX para GNU/Linux

LaTeX según la definición de la wikipedia " ... es un lenguaje de marcado para documentos, y un sistema de preparación de documentos, formado por un gran conjunto de macros de TeX"[1]; que permite la edición de documentos con una gran calidad de presentación.

Como es un lenguaje de marcado, para generar el produncto final es necesario describir el contenido del documento a partir de etiquetas, que determinan el formato que se le ha de aplicar a cada elemento en el documento.

Describir el documento en LaTeX tiene un parecido a la manera en como se escribían las primeras páginas web, con la diferencia de que LaTeX es mucho más rico, y algo más complejo. Además, para poder ver el resultado final, es necesario compilar el archivo tex para obtener el documento final, que por defecto es en formato dvi. Es decir, el archivo descriptor, que es el fuente, tiene la extensión tex; se compila con el comando latex, y el resultado es el mismo archivo con extension dvi.

El documento se puede exportar a otros formatos, como postcrip o pdf.

Existe una herramienta visual que permite trabajar con LaTeX sin usar directamente el lenguaje, llamada LyX, que es un editor tipo YSIWIM (What You See Is What You Mean); además de ser multiplataforma.

A muchos no les gusta usar LyX porque al igual que cualquier herramienta "generadora de código", LyX agrega elementos innecesarios, que pueden incrementar considerablemente el tamaño del producto final, así que prefieren codificar el documento directamente.

En este sentido, existen varias herramientas que ayudan a la creación de archivos tex; emacs tiene auctex; pero para aquellos que prefieren las ventanas y no gustan de usar emac hay otras alternativas.

Para los que usan eclipse, existe un plugin para trabajar con LaTeX llamado texlipse; y para los que usan KDE pueden hacer uso de KDevelop, pero además existe una herramienta (un IDE) exclusiva para trabajar con archivos fuente de LaTeX llamada Kile. Personalmente, me gustó mucho ésta última.

Y para los que trabajan con GNOME, y no quieren usar herramientas de KDE, me enteré gracias al blog Linux Music 2.0 de la existencia de un plugin para gedit que permite trabajar con LaTeX que se encuentra en: http://sourceforge.net/projects/gedit-latex/

Por cierto, si te interesa aprender LaTeX, existe un libro que enseña el uso del lenguaje, que está en wikibooks, llamado LaTex que se puede descargar libremente y compartir.

[1] http://es.wikipedia.org/wiki/LaTeX

Minitip: Graficando el espacio usado de disco duro

Si en algún momento se está interesado en ver de manera gráfica en que se tiene gastado el disco duro, existen varias aplicaciones que permiten hacerlo.

Si se tiene instalado GNOME, viene con una aplicación que se llama baobab, que al ejectuarlo, se puede seleccionar algún directorio, y sobre éste hace el análisis, mostrando en una gráfica tipo pie, la proporción de uso que corresponde a cada subdirectorio.

En KDE se disponde de una herramienta parecida, llamada filelight, que también despliega en un gráfico tipo pie, como está ocupado el directorio.

Además existe una herramienta que solo necesita el servidor X para funcionar que se llama xdu. Se utiliza como:

>$ du | xdu.

Para saber más

>$ man baobab
>$ man filelight
>$ man xdu

Curiosidades en los compiladores de GNU

Haciendo unos programitas de ejemplos, escritos en lenguaje C++, como son muy pequeños y son compilados con el compilador de GNU, g++ en un sistema GNU/Linux, pensé que el binario iba a resultar tan pequeño, dado el tamaño del código fuente, que con respecto el mismo programa escrito en C, no iba a haber mucha diferencia en el tamaño.

Sin embargo la diferencia entre uno y otro si es notable, por ejemplo para el caso particular del siguiente código en C++:

using namespace std;
#include <iostream>

// Funcion que es llamada
int llamada(int x, int y){
 cout << "Estamos en la funcion!!" << endl;
 return(x+y);
}

int main(void){
 //Estos comentarios son propios de C++
 cout << "Vamos a llamar a la funcion..." << endl;

 // Llamamos a la funcion
 // y asignamos
 int z=llamada(5,7);
 cout << "Resultado: "<< z << endl;

 // Llamamos desde la salida estandar
 cout << "Resultado desde la llamada: " << llamada(6,7) << endl;
 cout << "Programa terminado\n" << endl;

 return 0;
}

Y el mismo programa en C:

#include <stdio.h>

// Funcion que es llamada
int llamada(int x, int y){
 printf("Estamos en la funcion!!i\n");
 return(x+y);
}

int main(void){
 //Estos comentarios son propios de C/C++
 printf("Vamos a llamar a la funcion...\n");

 // Llamamos a la funcion
 // y asignamos
 int z=llamada(5,7);
 printf("Resultado: %d\n", z);

 // Llamamos desde la salida estandar
 printf("Resultado desde la llamada: %d \n", llamada(6,7));
 printf("Programa terminado\n");

 return 0;
}

Que como se observa, no hay mayor diferencia en las declaraciones y en el propósito del programa, y sin embargo al compilarlo el primero genera un ejecutable de tamaño de 9372 bytes, mientras que el segundo su tamaño es de 6718 bytes, lo que me lleva a pensar que en una aplicación realmente grande, ese tamaño seguramente se ha de incrementar bastante.

La compilación fue el primero con g++ sin más argumentos, el segundo fue con gcc sin argumentos, el ejemplo es de un documento llamado: Tutorial de C++ (o el diario de Peter Class)

ACTUALIZACIÓN:

Después de leer el comentario, debo aclarar que solo es una suposición, y que en donde dice:"... lo que me lleva a pensar que en una aplicación realmente grande, ese tamaño seguramente se ha de incrementar bastante..."
Una mejor forma de explicar mi idea es:"... lo que me lleva a pensar que en una aplicación realmente grande, una proporción equivalente pudiera mantenerse, siendo el binario de la versión en c++, de mayor tamaño..."

Conferencia en la FI de la UNAM por Luciano Bello

"Explotando vulnerabilidades de seguridad en OpenSSL" por Luciano Bello

Resumen:

"Luciano Bello descubrió la gran vulnerabilidad del PRNG (Pseudo-Random Number Generator) de OpenSSL en la distribución de Debian. Es ingeniero en Computación y trabaja como investigador en el SI6 Laboratorio de Investigación y Desarrollo de Seguridad Informática del Instituto de Investigaciones Científicas y Técnicas para la Defensa (CITEFA) en Buenos Aires, Argentina.

En esta charla se hablará sobre el problema, su descubrimiento, publicación, consecuencias y explotación. Se mosotrarán herramientas para la explotación y demostraciones prácticas."

La cita es el día jueves 16 de octubre de 2008 de 16:00 a 18:00 hrs en el auditorio Sotero Prieto, del edificio Anexo de la Facultad de Ingenieria, en Ciudad Universitaria.

LIDSoL y la FI-UNAM invitan.

¿Crisis finaciera buen momento para el FOSS?

Es de todos conocido la gran crisis financiera por la que están pasando la economía mundial y que resulta en grandes pérdidas para muchos (quiebras, despidos, etc).

Y sin embargo, es un momento propicio para los que se saben mover en los mundos de las casas de bolsa. Quienes podrán hacer leña de tantos y tantos árboles caidos (metáfora, claro).

De igual forma, considero que es un momento propicio para quienes se dedican a proveer servicios basados en FOSS, porque muchas empresas se verán obligadas a hacer recortes en sus gastos, para poder paliar lo mejor posible la recesión, que para los que son conocedores, dicen que será larga.

Dado que es necesario gastar menos, ¿porqué no considerar entre esas reducciones el costo de licencias?; es decir, si una empresa tiene instalado una X cantidad de software por el cual paga licencias, anuales, o tal vez mensuales; podría omitir el gasto de ellas, reduciendolo o al sueldo de un especializta en software equivalente libre, o al contrato con quien puede ofrecer ese servicio.

De hecho, Google ha logrado algo parecido, al lograr que el gobierno regional de Washington DC, sustituya sus licencias de MS Office por su Google Apps, que le redundará en un ahorro considerable a dicho gobierno. Mejor sería, si una empresa FOSS fuera quien lo hubiese logrado.

Así que a río revuelto, ganancia de pescadores, que para aquellos que se dedican seriamente a servicios basados en FOSS, creo que hay un buen pretexto para avanzar.

minitip: Compilando con varias tareas

Si tienes a tu disposición uno de esos nuevos procesadores que tienen varios nucleos, y te gusta descargar codigo fuente para compilar aplicaciones en tu propia máquina, se puede realizar más rápido si al comando make (que es quien indica en que forma se ha de compilar), se le especifica cuantas tareas deseamos que se realicen al mismo tiempo.

Así, si por ejemplo se tienen dos núcleos, se puede especificar simplemente (después del respectivo ./configure):

>$ make -j 2

Si por ejemplo se cuenta con 3 núcleos, se especifican las tareas con un número igual al de nucleos que se dispone, es decir, para este caso:

>$ make -j 3

Es importante notar, que el número de tareas no necesariamente es igual al número de nucleos o procesadores con los que se cuenta. De hecho la opción existe desde hace tiempo, así que se pueden colocar más tareas que nucleos, solo hay que hacer notar, que esas tareas "sobrantes" se ejecutarán de manera concurrente.