jueves, octubre 20, 2011

Ciclo de charlas de Software Libre 2011

El Grupo de Usuarios de Software Libre de la Universidad Nacional de Luján (UNLUX) invita a toda la comunidad, profesionales e interesados en Tecnologías de la Información y la Computación al “Ciclo de charlas de Software Libre -- CDC SoL” edición 2011.

Este es un evento gratuito, abierto, de interés general, orientado a toda la comunidad y destinado a la difusión y capacitación en el cual expertos en diferentes áreas hablaran sobre temáticas del Software Libre. Habrá charlas técnicas e informativas, cuyos principios fundamentales son el fomento y la difusión del software libre tanto en el uso de herramientas cotidianas, como también para el desarrollo de modelos de negocio sustentables.

El CDC SoL 2011 se llevará a cabo el día 19 de noviembre de 2011 de 10 hs. a 18 hs. en la sede central de la Universidad Nacional de Luján.

Para obtener más información o registrarse como asistentes pueden dirigirse al sitio oficial cdcsol.unlux.com.ar o bien al correo organizacion@unlux.com.ar.

¡Esperamos contar con la participación de todos!

miércoles, octubre 12, 2011

Your browser matters nothing to me

"Your browser matters" dicen en Microsoft, porque en un montón de medios salieron a vitorear que publicaron con un sitio web que "analiza la seguridad que nos brinda nuestro navegador web".

Pfffff... Puro verso. Qué me dicen de esto?

Chromium 6.0 no está mal. Llega a puntuar 4/4 (el máximo) .

Prueben ejecutando:

$ chromium-browser --user-agent="Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" http://www.yourbrowsermatters.org/

o bien

$ chrome --user-agent="Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" http://www.yourbrowsermatters.org/

Your browser matters... Mentira, lo único que importa es el User-Agent.

miércoles, octubre 05, 2011

Bashismos

Esto surgió mientras un amigo depuraba un script de backup.
Supongamos que creamos un script denominado ./myscript con el contenido siguiente:

echo parametro1 es $1
echo parametro2 es $2

Y luego lo ejecutamos alternativamente con los intérpretes Dash y Bash:

mauro@yoda$ dash
$ . ./myscript
parametro1 es
parametro2 es
$ . ./myscript foo bar
parametro1 es
parametro2 es

mauro@yoda$ bash
$ . ./myscript
parametro1 es
parametro2 es
$ . ./myscript foo bar
parametro1 es foo
parametro2 es bar

¿Se nota la diferencia?

Efectivamente, al utilizar el comando "." (dot o source) Dash no pasa ningún argumento al script, mientras Bash sí lo hace. ¿Bug o Feature? Según parece, es una implementación estricta del estándar POSIX. En cualquier caso, hasta que nos dimos cuenta, fue un dolor de cabeza.

jueves, septiembre 01, 2011

Random wallpaper changer

La semana pasada dediqué unos minutos a buscar algún software sencillo para rotar el fondo de pantalla aleatoriamente en GNOME, porque los que tengo ya me aburren, y se me ocurrió que ir rotándolos al inicio o cada cierto tiempo estaría piola. Lamentablemente no pude encontrar nada en Gnome que me permita indicar un directorio con imágenes y vaya cambiándolas cada tanto. Curiosamente XFCE sí lo tiene y si no me equivoco KDE también lo permite desde hace bastante.

El repositorio de Debian posee aplicaciones para cambiar el fondo de pantalla, pero no encontré ninguno que me satisfaga, sea porque no realiza rotación automática, porque no está disponible en la release estable, porque el método de funcionamiento es un tanto complejo para lo que hace, o bien porque requiere un montón de dependencias para funcionar (mono, anyone?).

Lo que pido es muy sencillo, dar una carpeta con archivos de imágenes, un tiempo de duración de cada fondo y listo, no más que eso; ni siquiera hace falta un diálogo de configuración. Como sé que, afortunadamente, los entornos de escritorio en Linux se llevan bien con la línea de comandos, no tardé mucho en encontrar la forma de cambiar el fondo de Gnome desde consola. Y de allí a cambiarlo automáticamente es un paso, por lo que terminé con un pequeño script en bash que denominé, en un alarde de creatividad, wallchanger, que no es sino una versión floreada de algo extremadamente sencillo:

#!/bin/sh
while true; do
    CHOSEN=`find /usr/share/backgrounds -iname \*.jpg -print | shuf -n 1`
    gconftool-2 -s -t string /desktop/gnome/background/picture_filename $CHOSEN
    sleep 300   # 5 min
done

La versión completa soporta además algunos parámetros útiles tales como cambiar la carpeta de imágenes, el tiempo de presentación de cada una, o el entorno de escritorio sobre el cual realizar el cambio:

Usage: wallchanger [-g|-x] [-f FOLDER] [-o MODE] [-w NN]
  -g          set GNOME wallpaper
  -x          set XFCE wallpaper
  -f FOLDER   choose from wallpapers in FOLDER
  -o MODE     set wallpaper mode [scaled|zoom|centered|...]
  -w NN       change wallpaper every NN seconds

Como siempre, por si a alguno le es útil, dejo el enlace de
descarga: wallchanger

martes, agosto 30, 2011

Waiting for /dev to be fully populated...

Desde hace algunos meses me venía mordiendo un bug extraño en la máquina de trabajo donde a partir del kernel linux 2.6.39 e incluyendo la versión 3.0.0 el sistema se bloqueaba al inicio (el clásico freeze on boot) justo después del mensaje

Waiting for /dev to be fully populated

Y luego de eso, nada. Curioso, ya que con 2.6.38 el arranque iba de lo más normal, además que el equipo es un clon de los más comunes:

Procesador: Intel(R) Pentium(R) D CPU 2.80GHz
Motherboard: Intel Corp. D102GGC2
VGA: ATI Technologies Inc RC410 [Radeon Xpress 200]
Memoria: 1 GB

Obviamente a esa altura del arranque no hay muchos dispositivos disponibles, por lo que logs como para diagnóstico no tenía ninguno, así que por un tiempo desistí la investigación y me mantuve con el 2.6.38, ya que había que trabajar.

Pero recientemente, aprovechando un día que llegué demasiado temprano, le dediqué unos minutos a este inconveniente que ya me tenía incómodo.

El primer sospechoso fue naturalmente udev, al fin y al cabo era el emisor del último mensaje que veía en pantalla. Diagnosticar problemas con udev es, digamos, un poco tedioso. Si leen el manual de udev encontrarán que en /etc/udev/udev.conf puede establecerse la variable udev_log en err, info o debug para definir la prioridad de los mensajes que serán mostrados en pantalla. Una vez hecho el cambio basta con reiniciar el equipo para ver los mensajes de información o diagnóstico correspondientes.

Desde ya es todo un pergamino de eventos el que va sucediendo en el arranque. Tantos eventos (y sin logging ni forma de recuperar los que ya pasaron) que me resultó imposible encontrar un patrón extraño o una pista siquiera de qué es lo que estaba sucediendo. Opté entonces por el clásico diagnóstico del pobre: conociendo dónde almacena udev las reglas (/lib/udev/rules.d/), fui desactivando las reglas y reiniciando el sistema tras cada cambio. Si el sistema continuaba el arranque luego del mensaje "Waiting for /dev ..." entonces las reglas activadas eran inocentes; si no, alguna de las reglas activadas es la culpable. En algunos inicios no tenía gráfica, en otros no tenía disco, y en la mayoría ni siquiera teclado.

Una especie de búsqueda dicotómica me llevó, en pocos reinicios, a encontrar el archivo presuntamente culpable: 80-drivers.rules. Incluso llegué a determinar que la línea responsable era la séptima. Sin embargo el avance no fue mucho, ya que esta línea carga un montón de módulos en el kernel entre los cuales estan los de teclado y ratón: se ampliaba la lista de sospechosos.

Hasta acá, apenas si moví un paso, pero al menos llegaba a arrancar y controlar el sistema mediante SSH. Entonces un gran compañero de laburo (hat tip a Leandro), iluminado por el conocimiento (o quizá cansado de mis improperios) me recomendó: "¿y si probás cargando los módulos que faltan, uno a uno?".

Entonces iniciamos el diagnóstico del pobre parte II. Haciendo un diff casero entre el lsmod del equipo iniciando con kernel 2.6.38 y uno iniciando con kernel 2.6.39 (sin 80-drivers.rules) llegamos a una lista de unos doce o quince módulos faltantes. Allí, tan cerca, login ssh y a probar cada uno de los módulos... pcspkr, evdev, psmouse, snd_hda_intel, todos cargaban bien... parport, fuse, ok... processor... chan! ahí se tildó todo.

AHA! El módulo processor! Pero ¿qué función cumple ese módulo? O mejor, ¿por qué sigue andando el sistema sin él?. Bueno, resulta que es el ACPI Processor Driver, que no es realmente necesario pero maneja cuestiones útiles tales como los estados de energía del procesador. Si lo recuerdan ACPI ya nos viene dando dolores de cabeza desde hace bastante.

Ya con esos datos, una búsqueda en Google reveló un dato fundamental, aunque se ve que no es nuevo: en ciertos equipos el sistema se cuelga a menos que uno cargue el módulo processor con el parámetro nocst=1.

Así que, de momento, agregué la línea

processor.nocst=1

a los parámetros de inicio del sistema y con eso estoy andando actualmente. ¿A qué se debe el bug? Ni idea, habría que hacer un bisect entre las versiones de kernel 2.6.38 y 2.6.39 para determinar cual es el commit jodido. En cualquier caso, queda como tarea para vacaciones...

martes, agosto 16, 2011

Livepass es una mierda

Me lo venía aguantando... Conocen el sitio de venta de entradas Livepass? No? Qué suerte que tienen! Yo lamentablemente lo conocí cuando intenté comprar entradas para el show de Roger Waters. Como un gran número de gente (llegó a trending topic en Twitter) encontré que no sólo es prácticamente imposible adquirir entradas por Internet, sino que por vía telefónica es más probable hablar con el rey de Francia a que te atienda algún operador de la empresa.

El sitio web se les cae a pedazos... evidentemente no han previsto y/o no tienen la más remota idea de como manejar un pico de tráfico... por si fuera poco está hecho con ASP en IIS, no me extrañaría que el backend sea una base de datos Access 2003... No sólo da time-outs y fallos a mitad de las transacciones; falla hasta el procesador de pagos (NPS, otro responsable del quilombo) incluso luego de haber cargado la tarjeta. Por si fuera barato el “cargo por servicio”, de qué servicio me están hablando?

Y si las caídas frecuentes no son suficiente escarnio, como medida “paliativa” se les ocurrió agregar una demora al ingreso:

Welcome! Por favor aguarde unos instantes, Ud. a ingresado a una sala de espera y sera redireccionado en unos minutos para poder adquirir sus entradas.

Welcome! ... Ud (H)A ingresado ... (y la traducción?? y el corrector ortográfico??!!) Además de que la demora no es otra cosa que un meta refresh que actualiza la página cada 20 segundos, es decir, el equivalente a pasársela apretando F5 todo el día, nada de cola de espera por orden de llegada ni un control más efectivo, acá gana el que tiene la latencia más baja y los hue*os más grandes. Si llego a conseguir UNA entrada, obviamente voy al recital con una remera que diga en grande ME CAGO EN LIVEPASS, LA PRÓXIMA VENDAN ENTRADAS PARA CARAMELITO.

Para colmo de males, a la mediatarde surge en twitter un detalle de la página de la empresa. Un video con el título “NO ANDA NADA WANDA NARA” y un enlace al video de Anonymous. Inside joke? I hope so! Pero que oportuno, me deja mucho más tranquilo saber que es una empresa que protege los datos de sus clientes igual que protege a su (paupérrima) infraestructura...

Update: parece que algunos usuarios han encontrado una mejor forma de expresar su cariño. Tienen todo mi apoyo.

Contra esto hay que quejarse. Informen de esta falta de respeto a la gente del show (help@rogerwaters.com / tickets@rogerwaters.com) que responden personalmente y a Defensa del Consumidor. Update: también recomiendan publicar su experiencia en tema abierto en el foro del artista e informarse sobre como denunciar estos abusos en Protectora.org.ar. Otro más: los que quieran saber hasta donde llega la estafa, lean este excelente (e indignante a la vez) post en T!.

En resumen, si quieren aprender cómo se hace una venta por internet para el orto, aprendan de Livepass. En el remoto caso de que algún productor de espectáculos llegue a leer este post, por favor le pido encarecidamente que evite contratar a esta empresa de novatos.

PD: me hicieron calentar... y no es que los demás sean mejores eh. He tenido dolores de cabeza similares con TicketPortal, Ticketek, EntradaPlus, y demás... todos tienen sistemas de venta hechos por los amiguitos de mi sobrino de 6 años. Aprendan a laburar, inútiles!

lunes, agosto 15, 2011

Sobre el bloqueo a leakymails

Hace unos días, Fabio publicó en su blog una buena nota de opinión sobre el bloqueo en Argentina al sitio LeakyMails. Yo que ya venía medio indignado con este tema, aproveché la ocasión para descargarme con el comentario que transcribo, que va a colación de otros sumamente interesantes. Sepan disculpar el auto-bombo...

A ver si alguno me puede aclarar algo... desde mi ignorancia puedo pensar en algunas formas de bloquear un sitio web, Uds. me podrán iluminar con muchas más:

1) bloquear la resolución DNS del nombre de dominio, lo que requiere que todos los servidores DNS de ISP de la Argentina deniegen tal solicitud, por lo que bastaría con apuntar los resolvers a los de OpenDNS u Google (8.8.8.8) para zafar.

2) bloquear el acceso a la dirección IP que hostea el sitio, que fue el *moco* que se mandó Telecom, bloqueando a su vez el acceso a buena parte de blogspot.com y,peor aún, mail-attachment.googleusercontent.com (que es desde donde gmail descarga los adjuntos)... Sí, señora, por eso Ud. no pudo bajar las fotos de su nieta estos días.

3) bloquear el acceso según la URL que aparece en la cabecera HTTP de cada paquete dirigido al puerto 80. Lo que implica que todo ISP de la Argentina tendrá que analizar cada una de las cabeceras de capa de aplicación de cada uno de los paquetillos que pasen por su red, por si registrar los sitios que visitamos y "caparnos" la velocidad no fuera agravio suficiente.

Ahora, y es mi opinión.. hay que ser muy bol^Wignorante para "DECRETAR PREVENTIVAMENTE el bloqueo por parte de los proveedores locales de servicios de Internet en el acceso..." sin tener la menor idea de cómo funciona la red por debajo. Cualquiera de estos métodos es un engorro para todo ISP, además que pueden aparecer mirrors del sitio cada dos días y medio, y así van a seguir jugando al gato y al ratón.

Pero aún así, es mayor el abuso del que estamos siendo víctimas los usuarios finales con este tipo de decisiones chabacanas. Este fallo ya ha sentado precedencia, y de esto a bloquear cualquier otro sitio por el motivo que se le cante a alguno de los del tope de la pirámide hay, lamento decirlo, pocas teclas de distancia.

Fíjense que acá no hablo siquiera del contenido del sitio, que para el caso podría haber sido de correos verdaderos, apócrifos, o de recetas de cocina tailandesa.

martes, junio 07, 2011

Reiniciando [rebooting]

Matthew Garrett es un biólogo (ahá) y reconocido hacker de Linux que lidia normalmente con complejas cuestiones de bajo nivel, pegadas al hardware, tales como ACPI, EFI, power management, y otras, que normalmente publica sus desventuras en el campo digital en un blog en livejournal. Muchos de sus artículos me han resultado realmente sorprendentes en cuanto a los intrincados detalles que pueblan los componentes de hardware desarrollados por diversos fabricantes.

Esta última semana publicó un artículo sobre el sencillo problema de cómo reiniciar correctamente una computadora. Me he tomado la libertad de traducir mejor dicho, interpretar ilegalmente, el post en cuestión. Para aquellos que se sientan cómodos con el inglés, les recomiendo el artículo original.


Reiniciando

Se podría pensar que es fácil reiniciar una PC, ¿no? Pero también podría pensarse que es fácil convencer a la gente de que al menos hacer un esfuerzo para ser amable con los demás es una propuesta de beneficio mutuo, y miren lo bien que nos ha funcionado.

Linux tiene un montón de maneras diferentes de reiniciar un sistema x86. Algunas de ellas son exclusivas para 32 bits y por eso las voy a ignorar porque, honestamente, que estás haciendo de tu vida [si estás trabajando en 32 bits]. Además, son horribles. Entonces, esto nos deja con cinco de ellas:

  • kbd - reiniciar a través del controlador de teclado. La IBM PC original tenía la línea [el cable] de reinicio de la CPU asociada a la controladora del teclado. Escribiendo la apropiada cantidad mágica de pulsos en la línea y la máquina se reinicia. Todo esto es muy sencillo, salvo por el hecho de que las máquinas modernas no tienen controladores de teclado (en realidad son parte del controlador embebido) e incluso las máquinas más modernas ni siquiera pretenden tener un controlador de teclado. Ahora, los controladores embebidos ejecutan software. Y, como todos sabemos, el software es terrible. Pero, aún peor, el software del controlador embebido está escrito por autores de BIOS. Así que claramente cualquier pretensión de que esto funcione es una especie de ficción complicada. Algunas máquinas son muy exigentes con el hardware, exigiendo que esté en el estado exacto que Windows lo programaría. Algunas máquinas funcionan 9 de cada 10 veces y luego se bloquean debido a algún raro problema de temporización. Y otras simplemente no funcionan en absoluto. ¡Hurra!
  • triple - intentar generar una falla triple. Esto se realiza cargando una tabla vacía como vector de interrupciones, y luego llamando a int(3). Falla la interrupción (no hay IDT), falla el manejador de fallos (no hay IDT) y la CPU entra en un estado que debería, en teoría, desencadenar un reinicio. Salvo que no parece haber un requerimiento de que esto suceda, y esto simplemente no funciona en un montón de máquinas.
  • pci - en realidad no pci. Tradicionalmente, el acceso al espacio de configuración PCI se logra escribiendo un valor de 32 bits al puerto io 0xcf8 para identificar el bus, el dispositivo, la función y el registro de configuración. El puerto 0xcfc luego contiene el [valor del] registro en cuestión. Pero si se escribe el par apropiado de valores mágicos en 0xcf9, la máquina se reiniciará. Espectacular! Y no estandarizado de ninguna manera (ciertamente no es parte de la especificación PCI), por lo que chipsets diferentes pueden tener diferentes requisitos. Booo.
  • efi - Los servicios EFI en tiempo de ejecución proporcionan un punto de entrada para reiniciar la máquina. Incluso a veces funciona! Siempre y cuando los servicios de tiempo de ejecución EFI estén funcionando, lo que puede ser una exageración.
  • acpi - Las versiones recientes de la especificación ACPI permiten especificar una dirección (por lo general en espacio de memoria o E/S de sistema) y un valor a escribir ahí. La idea es que escribir el valor a la dirección reinicia el sistema. Resulta que eso, a menudo, falla. También es imposible representar el método de reinicio PCI a través de ACPI, porque el método de reinicio PCI requiere un par de valores y ACPI sólo da uno.

Ahora, debo admitir que esto suena bastante deprimente. Pero la gente claramente vende computadoras con la expectativa de que van a reiniciarse correctamente, entonces ¿qué es lo que pasa?

Hace un tiempo hice algunas pruebas con Windows corriendo sobre qemu. Esta es una buena manera de evaluar el comportamiento del sistema operativo, porque uno tiene el control completo de lo que se entrega al sistema operativo y lo que el sistema operativo trata de hacer con el hardware. Y lo que descubrí fue un poco sorprendente. En ausencia de un vector de reinicio ACPI, Windows utiliza el controlador del teclado, espera un momento, lo intenta de nuevo y luego abandona. Si existe un vector de reinicio ACPI, Windows lo utiliza, luego prueba con el controlador del teclado, luego vuelve a utilizar el vector ACPI y prueba el controlador del teclado una vez más.

Esto resulta ser importante. Lo primero que significa es que genera dos escrituras en el vector ACPI de reinicio el sistema. El segundo es que deja un espacio entre ellas mientras toquetea el controlador de teclado. Y, sorprendentemente, resulta que en la mayoría de los sistemas el vector de reinicio ACPI apunta a 0xcf9 en el espacio de E/S del sistema. Incluso cuando la mayoría de las implementaciones nominalmente requieren escribir dos valores distintos, parece que este no es un requisito estricto y el método ACPI funciona.

[La versión del kernel Linux] 3.0 incluirá este comportamiento por defecto. Hace que varias máquinas funcionen (algunas Apple, por ejemplo), mejora las cosas en otras (algunas Thinkpad parecen quedarse tiesas durante largos períodos de tiempo, de otra manera) y con un poco de suerte evitará la necesidad de añadir más peculiaridades específicos al código de reinicio. Todavía hay algunas divergencias entre nosotros y Windows (mayormente en cuán seguido escribimos en el controlador de teclado), que se puede limpiar si resulta que hace alguna diferencia en cualquier lugar.

Ahora. De vuelta a los bugs de EFI.

- mjg59

lunes, marzo 28, 2011

El negocio de la mentira

Desde hace un tiempo vengo siguiendo los problemas autoinfligidos en la economía norteamericana; aunque en realidad, si nos ponemos a indagar un poco, el trasfondo de esa obsesión más que acercarse a la economía se entorna sobre la naturaleza del ser humano, de cómo se puede mentir al prójimo descaradamente y de cómo sobre los pilares de la corrupción y la mentira se construye un modelo de negocios (y una sociedad entera!). Obviamente mi búsqueda no tiene nada de nuevo y como yo no soy un economista sino un ciudadano común, más de uno me apuntará con razón a los textos clásicos tales como De Officcis, El Príncipe y otros.

Lo que más me fascina del tema, sin embargo, es este fenómeno de “profesionalización de la corrupción”, donde no estamos hablando ya de un mero trato secreto sino de una asignatura que se estudia y se perfecciona en los niveles académicos (algo de esto verán más adelante).

Ya he tocado el tema del colapso financiero en post de años anteriores, incluso con algo de humor. Un documental relevante y muy iluminador, que lamentablemente olvidé de mencionar en este blog, es The Smartests Guys in the Room, sobre el ascenso y la estrepitosa caída de la empresa de energía Enron en 2001, que si bien no está relacionado directamente con la crisis de las subprime, presenta las bases del modo de actuar de estos “hábiles empresarios neoyorquinos”.

El último material que pasó por mis manos, gracias a este post en Kriptópolis, es el documental Inside Job de Charles H. Ferguson. En Inside Job se tocan temas tales como la desregulación de la pseudoindustria financiera, el fraude en los libros de las empresas y del gobierno, el auge y la crisis de los préstamos hipotecarios, las vista gorda y las lavadas de mano de las agencias calificadoras, el posterior rescate financiero, los grotescos montos de dinero repartidos por la pirámide financiera, la estúpida indulgencia para con los grandes bancos y sus directivos, la influencia de las empresas en la academia y en la investigación económica (si me permiten la expresión), y la obscena (y continua) manipulación de las instituciones públicas. Temas que, como habría de suponer, no se han resuelto y decididamente no se resolverán.

De todas formas asustarse de las tramoyas y de la desidia/inescrupulosidad extranjera es casi una anécdota cuando tenemos las locales que están a la vista de todos y sobre las cuales también se hace poco y nada (salvo que nos pongamos de acuerdo en el corto plazo, algo que tampoco va a ocurrir).

Les dejo el trailer, como para que vayan tomando una idea de lo que se trata. El documental completo lo pueden encontrar subtitulado en línea con San Google.


Como siempre, recomiendo tomar estos materiales con cierta sospecha y en lo posible ir a las fuentes para comprobar la veracidad. Aún así, el film no tiene desperdicio.