Articles and columns

I have been a columnist in some printed magazines. The columns are on quite broad topics, and their length is quite limited. Although I cannot see them as full articles, they can be interesting as discussion starters, or for further ellaboration.

And, although less in number than the columns, I have also published some articles along the years. Here you will find them as well.

He participado como columnista en algunas revistas impresas. Las columnas son de temas bastante generales, y de longitud limitada - No son trabajos a los que pueda referirme como artículos completos, pero pueden resultar interesantes para iniciar discusiones y elaborar más.

Además de las columnas, aunque mucho menos en número, también he publicado algunos artículos con el pasar de los años. Aquí podrás también encontrarlos.

2005

Columnas publicadas en 2005

Herramientas en órden

TitleHerramientas en órden
Publication TypeMagazine Article
Year of Publication2005
AuthorsWolf G
MagazinePC Magazine en español
Date Published09/2005
Type of ArticleColumn
ISSN1665-4897
Keywordscontrol de versiones, editor, evangelizacion, herramientas de programación
Full Text

Como es de esperarse, una de las ramas en que más y mejores programas libres vamos a encontrar es en la de herramientas para la programación. Esto es de esperarse, si recordamos que el Software Libre es creado por entusiastas de la programación. Asomándonos a cómo piensa un típico programador: Si me gusta escribir código, obviamente, lo voy a hacer de la manera en que más natural me sea, en que menos me tenga que esforzar - aún si para eso tengo que trabajar varios meses o años.
El tema que elegí para esta columna es muy amplio, y engloba una muy amplia gama de categorías. Vamos, pues, de lo más básico a lo más sofisticado. Me permito recordarles que, como con casi todos los programas libres, no es indispensable utilizar Linux para emplearlas - Las herramientas libres típicamente funcionan en cualquier sistema
operativo.

Editores

La herramienta básica para todo programador, para todo administrador de sistemas, e incluso de todo usuario entusiasta de un sistema operativo libre es un simple editor de texto. Ahora... ¿Simple? No, un editor de texto puede ser cualquier cosa, menos simple.
Lo primero que todo usuario serio de un sistema tipo Unix debe aprender es el uso del editor vi, o de alguno de sus derivados. En su versión básica, no tiene mayor atractivo - pero siempre está ahí. Es muy simple, muy ágil, y nos puede salvar fácilmente el pellejo.
El editor multiusos por experiencia es Emacs. Tiene más de 25 años de historia a cuestas, y sigue siendo la herramienta favorita para programar de miles de personas. Para ser sólo un editor, Emacs sufre de una benigna pero tremenda obesidad: Desde este programa, y gracias a lo enormemente extensible que es (incluye un intérprete completo de Lisp) es posible programar, depurar, leer correo, manejar depósitos de código, manejar bases de datos, navegar, e incluso jugar.
[IMAGEN: emacs.png]
Gedit es un sencillo pero potente editor, integrado al entorno Gnome, que nos brinda muchas de las bondades de emacs y de vi, pero integrado a un entorno que a muchos resultará más familiar.
[IMAGEN: gedit.png]

Herramientas de modelado

Tan pronto como nos enfrentamos con una tarea que nos tomará más de unos cuantos cientos de líneas de código, nos confrontamos con la innegable necesidad de una herramienta de modelado, donde podamos hacer los diferentes esquemas que representen nuestra aplicación, facilitándonos tanto explicarla a otras personas como encontrar posibles errores de diseño con mucho mayor facilidad. Es, incluso, una muy buena práctica de programación ayudarnos de estas herramientas antes de iniciar siquiera a escribir código.
Probablemente el programa de modelado más común sea Dia, una herramienta Gtk+ que permite la creación de muy diversos tipos de diagrama, como los tradicionales diagramas de flujo, entidad-relación, UML, hasta diagramas eléctricos, de red, y varias categorías más específicas a dominios especializados. Y si bien Dia es únicamente una herramienta de modelado, a través de diversas herramientas como dia2sql o dia2code puede utilizarse como generador de código.
[IMAGEN: dia.png]
ArgoUML es un modelador muy completo y muy bien logrado, capaz de generar y analizar código. Está, sin embargo, completamente enfocado a UML y a Java, por lo cual su utilidad queda limitada a quienes utilicen estas tecnologías.
[IMAGEN: argouml.png]

Generadores de interfaces

Crear una interfaz de usuario gráfica (GUI) puede ser una tarea terriblemente compleja, y depurarla peor aún. Hay dos maneras de atacar a esta problemática: A través de un generador de interfaces, que limita su rol a definir la interfaz usuario, permitiendo al programador usar las herramientas que más le gusten para la generación del código (en este caso, probablemente un editor como los mencionados hace unos párrafos), o a través de un entorno integrado de desarrollo (IDE). En lo que respecta a generadores de interfaces, desde hace varios años contamos con varias opciones - Menciono sólamente los dos más conocidos.
El proyecto Gnome creó a Glade. Siguiendo la filosofía general de Gnome, Glade es muy peculiar comparándolo con herramientas similares: Está hecho para no estar atado a ningún lenguaje de programación. Glade describe la interfaz que creamos en XML, y -vía libglade, una biblioteca disponible para prácticamente cualquier lenguaje- nos permite llamarla desde nuestro programa. Además de esto, hay varios generadores de código para algunos de dichos lenguajes que nos evitan incluso la tarea manual de escribir el esqueleto de nuestro programa.
[IMAGEN: glade.png]
Qt Designer, de Trolltech, es la contraparte de Glade para el mundo de KDE - Y, nuevamente, nos deja ver claramente la ideología general de su proyecto. Qt Designer nos da mayor integración y mayor funcionalidad que la de Glade, sin embargo -y si bien también utiliza a XML como representación interna- está más enfocado a desarrollo de proyectos en C++.
[IMAGEN: qtdesigner.png]

Control de versiones

Un sistema de control de versiones nos permite dar seguimiento al desarrollo de nuestros proyectos a lo largo del tiempo, registrando las modificaciones que vamos haciendo, y permitiendo que trabajemos el mismo código desde diferentes computadoras, incluso entre diferentes personas, y proveyendo mecanismos para la resolución de conflictos (esto es, saber cómo resolver cuando dos personas modifican la misma sección del mismo archivo). Los sistemas de control de versiones han sido una pieza fundamental para el desarrollo del Software Libre en el mundo, permitiendo que miles de personas a lo largo del mundo compartan su código de manera ágil y sencilla.
La herramienta de este estilo más utilizada es CVS - Con más de quince años de desarrollo, casi todos los proyectos importantes han pasado por un depósito CVS. Y si bien CVS se maneja como las tradicionales herramientas Unix, a través de la línea de comando, hay una gran cantidad de herramientas gráficas o de Web que nos facilitan grandemente su uso.
Una muy buena herramienta para el uso de CVS es lincvs - Ligera, potente y fácil de utilizar, partiendo de una familiar interfaz de navegación de archivos, nos brinda acceso a toda la funcionalidad de CVS sin tener que aprender o interpretar la salida de la interfaz de línea de comando.
[IMAGEN: lincvs.png]
Siendo el control de versiones una tarea naturalmente cliente-servidor, podemos encontrar también interfaces para manejarlo vía Web. Frecuentemente, incluso, los desarrollos de software libre cuentan con estas herramientas con acceso público, para que todo quien esté interesado pueda dar seguimiento a la evolución de su proyecto. Uno de los programas más socorridosque nos permite el uso de CVS via Web es Chora - nos brinda funcionalidad similar (para la consulta, no para la modificación) a la de lincvs, con la posibilidad de utilizarlo desde cualquier punto del mundo.
Ahora, con la edad que tiene, obviamente hay varios puntos en que CVS comienza a mostrar carencias. Si bien nadie cuestionaba la supremacía de CVS hasta hace cinco años, hoy tenemos una gran cantidad de propuestas alternativas que nos traen mayor funcionalidad que CVS. Los principales contendientes son -y, claro está, enfocados a diferentes necesidades- Subversion, GNU Arch, Monotone y Git.
El control de versiones, de hecho, es una herramienta muy poderosa para manejar prácticamente cualquier tipo de información, y no sólo puede ser utilizado como parte de un esfuerzo colaborativo - En mi caso, todos los documentos que escribo desde hace cerca de cinco años son parte de mi árbol CVS personal, y la flexibilidad y robustez que esto me brinda me han salvado el cuello en varias ocasiones.
[IMAGEN: chora.png]
En el mundo del software libre hay, obviamente, muchísimas más opciones de las que aquí alcanzo a mencionar. Hay herramientas más completas, más especializadas, más generales, más verdes o más maduras - Pero a fin de cuentas, todo eso se traduce a una cuestión muy simple: Si nos gusta programar, tenemos todo lo necesario para ser productivos y (¿por qué no?) divertirnos con las herramientas que tenemos a nuestra disposición.

IMAGENES

argouml.png: Editando un diagrama de clases en ArgoUML
chora.png: Chora mostrando las diferencias en un árbol CVS por Web
dia.png: Diferentes tipos de diagramas en Dia
emacs.png: Editando SQL y Perl en Emacs
gedit.png: El entorno de edición en gedit
glade.png: Creando un GUI en Glade
lincvs.png: LinCVS mostrando la diferencia entre dos versiones de un proyecto
qtdesigner.png: Creando un GUI con QT Designer

AttachmentSize
Texto original enviado para su publicación8.55 KB
200509_pcmag_1.jpg89.99 KB
200509_pcmag_2.jpg118.17 KB

Menos paranoia y más Linux

TitleMenos paranoia y más Linux
Publication TypeMagazine Article
Year of Publication2005
AuthorsWolf G
MagazinePC Magazine en español
Issue NumberAug 2005
Date Published08/2005
Type of ArticleColumn
ISSN1665-4897
Keywordsevangelizacion, firewall, Seguridad
Full Text

Afortunadamente, la época en que era indispensable hacer entender a los usuarios de Internet que hay más peligros acechando a su conexión de los que pueden imaginar ya pasaron - hoy todo mundo se conecta a Internet por lo menos con un granito de cautela y paranoia. La situación actual no es buena aún: Incluso con esta paranoia en su lugar, muchos usuarios no saben qué hacer respecto a los siempre inminentes virus, troyanos, gusanos y atacantes más que entrar en pánico. Claro está, hoy ya no sólo tenemos que defendernos contra atacantes humanos, hay cualquier cantidad de virus, gusanos y troyanos esperando que dejemos la más mínima puerta abierta para adueñarse de nuestro sistema y posiblemente de nuestra información. Por si esto fuera poco, por más cuidadosos que seamos con nuestro sistema, es muy difícil dictaminar qué tan bien hemos hecho nuestra tarea, qué tanto podemos confiar en la seguridad que hemos implementado.
Hay una gran cantidad de herramientas libres que podemos usar mejorar la seguridad de nuestra red, a muy diferentes niveles - Prevención, monitoreo y detección de intrusos. El espacio del que aquí disponemos es demasiado corto para entrar en detalle en cada uno de estos puntos, por lo que en este artículo presentaremos una visión general de cada uno de estos aspectos, y en futuras ediciones entraremos más a detalle en cada uno de ellos.

Prevención

Uno de los puntos en los que con mayor frecuencia encontraremos pequeñas máquinas con Linux en una gran cantidad de redes medianas y grandes es en la entrada, actuando como firewall. Un firewall es una suerte de policía de las comunicaciones, que inspecciona a grandes rasgos cada uno de los paquetes entrantes, descartando todo aquello que no cumpla con los patrones de tráfico que esperamos para nuestra red.
En Linux, un firewall se configura a través de IPtables. Podemos hacerlo a mano a través de una serie de comandos simples pero a veces algo engorrosos, o podemos utilizar asistentes como Firestarter [1], muy simple de utilizar y suficientemente poderoso para configurar una red mediana. Una característica muy atractiva de Firestarter es que, además de ayudarnos a configurar el firewall, puede ayudarnos con el monitoreo de nuestra red en tiempo real.
Para configuraciones más complejas de lo que firestarter sabe manejar, podemos utilizar Shorewall [2], describiendo nuestra red a través de archivos de configuración bastante simples de entender, o directamente aprender la lógic de IPtables. Uno de los mejores documentos para aprender acerca de IPtables es el tutorial creado por Oskar Andreasson [3].
Cabe mencionar que el software que utilizamos para configurar un firewall global para nuestra red es el mismo que el que utilizaremos si queremos configurar un firewall personal, y que viene incluído en todas las distribuciones de Linux.

Monitoreo

Si sentimos que el rendimiento de la red o de nuestra computadora no está en niveles normales, es fundamental que podamos revisar exactamente qué está viajando por la red. El programa más simple y socorrido para este tipo de monitoreo es tcpdump [4], una simple utilería de consola que nos muestra un resumen de la actividad. Sin embargo, para hacer un verdadero diagnóstico, es mucho más cómodo trabajar con un programa como Ethereal [5] - Un analizador de protocolos muy completo y muy simple de utilizar, que nos permite aislar los diversos factores que afectan a nuestra conexión.
El monitoreo no sólo debe realizarse cuando sentimos que algo anda mal - El monitoreo debe ser una actividad constante, para poder encontrar a simple vista patrones de actividad anormal. Una de mis aplicaciones favoritas para este fin es el ya venerable MRTG [6]. Este programa reside en nuestro servidor y es ejecutado automáticamente cada cinco minutos. Depende de cómo lo hayamos configurado, recolectará los datos acerca de la carga de la red, el uso del CPU, memoria, o lo que le indiquemos. Estos datos nos son posteriormente presentados a través de nuestro navegador como una gráfica, guardando el histórico anual. Con esta información, tomada de un par de fuentes diferentes, es muy fácil determinar si el patrón de actividad actual es realmente normal o no.

Detección de intrusos

Un firewall es una parte fundamental de toda infraestructura de seguridad - Sin embargo, hay muchas cosas que un firewall es incapaz de hacer. Un firewall tiene que tomar decisiones extremadamente rápidas y basadas en tan poca información como sea posible, para evitar aletargar la red. Su tarea se limita a ver si una conexión es legal o no, pero no entra a revisar el contenido de cada una de estas conexiones - Para eso debemos emplear un sistema de detección de intrusos (IDS, por sus siglas en inglés). En el mundo del Software Libre, Snort [7] es definitivamente el motor de detección más potente y más utilizado.
Snort divide las tareas relativas a su trabajo de modo que -como es la norma en el Software Libre- puedan surgir varios proyectos relacionados, cada uno de ellos enfocándose en la excelencia de sus propias funciones específicas. Snort, además, simplifica la integración de un IDS completo en una red compleja, permitiendo colocar sensores independientes en los distintos puntos administrativos de la red, concentrando los datos en una base de datos central, la cual servirá de fuente de información a las consolas de alerta y de reporte.
Un recurso fundamental que nos proporciona Snort es, además, una muy completa serie de documentos relativos a la implementación de sistemas de detección de intrusos [8], tanto a nivel práctico como teórico, y tanto con Snort como con otros motores.
Una de las consolas de reporte más populares es ACIDlab [9]. Esta aplicación se utiliza via Web, y nos permite un acceso simple y completo a la base de datos que los sensores Snort han llenado. Para cada tipo de ataque reportado, nos da ligas a una explicación completa al respecto, y nos permite incluso ver el detalle -byte por byte- de la conexión que generó esta alerta.
Sguil [10] es otra consola de reporte que se ha ido popularizando por su mucho mayor interactividad que ACID. En vez de correr como un juego de scripts en un servidor Web, Sguil es una aplicación GUI escrita en tcl/tk, y que funciona nativamente en Linux, otros Unixes (*BSD, Solaris), MacOS y Windows. El único pero que podemos ponerle a Sguil es que no está tan maduro, y llega a presentar algunos problemas para correr en ciertos sistemas.

En resumen

En el mundo del Software Libre encontraremos una tremenda cantidad de herramientas que pueden ayudarnos a brindar seguridad a nuestra red, independientemente de qué sistemas estemos ejecutando en esta. Muchos de los programas aquí mencionados son multiplataforma (esto es, corren tanto en Linux y otros sistemas Unix como en Windows o Mac), y sin duda serán una gran ayuda para el mantenimiento de la seguridad de nuestras redes.
------------
LIGAS:
[1] http://www.fs-security.com/
[2] http://www.shorewall.net/
[3] http://www.faqs.org/docs/iptables/
[4] http://www.tcpdump.org/
[5] http://www.ethereal.com/
[6] http://people.ee.ethz.ch/~oetiker/webtools/mrtg/
[7] http://www.snort.org/
[8] http://www.snort.org/docs/
[9] http://acidlab.sourceforge.net/
[10] http://sguil.sourceforge.net/
-------------
IMAGENES:
acid_decode.png: Detalles de una alerta de ACID
acid_main.png: Página principal de ACID
ethereal_follow.png: Ethereal reensambla los paquetes y permite seguir
una conexión TCP completa
ethereal_main.png: Pantalla principal de Ethereal, mostrando los
paquetes capturados
ethereal_graph.png: Gráfica de intercambio de paquetes sobre el tiempo
en Ethereal
firestarter_events.png: Monitoreo en tiempo real de las conexiones
activas con Firestarter
firestarter_main.png: Pangalla principal de Firestarter
firestarter_wizard.png: El asistente de configuración de Firestarter
mrtg_index.png: Página principal de MRTG
mrtg_ppp0.png: Monitoreo histórico de la conexión hacia Internet con
MRTG
sguil_main.png: Pantalla principal de Sguil
tcpdump.png: Corrida de tcpdump

AttachmentSize
Página 1 (scanneada)95.9 KB
Página 2 (scanneada)118.81 KB
Texto original enviado a publicación8.02 KB

2006

Columnas publicadas en 2006

Con corazón de Linux

TitleCon corazón de Linux
Publication TypeMagazine Article
Year of Publication2006
AuthorsWolf G
MagazinePC Magazine en español
Date Published12/2006
Type of ArticleColumn
ISSN1665-4897
KeywordsEmbedded, evangelizacion, gadget
Full Text

Los pingüinos son animales muy interesantes. Son sorprendentes no sólo por lo que hacen, sino por lo distintos que son de lo que imaginamos de ellos en muy diversos aspectos.
[imagen: pinguino.jpg]
Hoy en día hay 17 especies de pingüino, habitando buena parte de los litorales del Hemisferio Sur. Si bien muchos asociamos directamente la amistosa imágen de "Chilly Willy" al gélido modo de vida de los pingüinos, algunos viven hasta en las Islas Galápagos, sobre la mismísima línea del Ecuador.
Hay pingüinos de todos tamaños, desde los pequeños Pingüinos Azules (Eudyptula minor), de 40 cm de altura y 1Kg de peso, hasta los Pingüinos Emperador (Aptenodytes forsteri), de 1.20m de altura y hasta 35 Kg. Los arqueólogos han encontrado incluso fósiles de pingüinos prehistóricos que alcanzaban 1.70m de altura.
[imagen: gentoo.jpg]
En tierra, parecen animales torpes. Caminan bamboleándose de lado a lado, por sus cortas piernas. Sin embargo, verlos nadar es increíble - Tienen la velocidad y destreza del ave voladora más elegante. Están perfectamente adecuados a su hábitat. A diferencia de otras aves capaces de zambullirse, los pingüinos no vuelan, por lo que pueden darse el lujo de tener un esqueleto macizo, pesado, que les proporciona la estabilidad y la capacidad de bucear más profundo y rápido que ningún otra ave.
Hay muchas otras características interesantes de los pingüinos - Vamos a dejarlas de lado por ahora. Esta es una revista, a fin de cuentas, dedicada a la computación, no a la zoología. Permítanme comentar un último punto del que pueden enorgullecerse los pingüinos: El pingüino Tux es la mascota oficial de Linux. ¿Por qué? Les invito a leer la explicación por parte nada menos que de Linus Torvalds, en http://www.linux.org/info/penguin.html
[imagen: tux.png]
...Y vamos sobre las similitudes que describí, para demostrarles que todo esto es cierto, no sólo en las costas del hemisferio sur, sino que en todo centro tecnológico que se precie de serlo.
Linux es un sistema operativo ideal para crear todo tipo de aplicaciones embebidas, todo tipo de sistemas miniatura que se dediquen a una tarea delimitada. Pero esto no es así sólamente por que un convencido de las virtudes de Linux como yo lo diga - Es inherente a la naturaleza modular, libre y abierta del modo en que fue concebido y desarrollado el sistema. Explico brevemente.
A diferencia de sistemas desarrollados de manera propietaria como Windows, una distribución de Linux es un gran conjunto de paquetes individuales, desarrollados de manera independiente. Linux no se refiere más que al mero núcleo, a la interfaz entre el hardware y cualquier otro programa que corra en la computadora. Linux es, pues, un sistema operativo tipo Unix, que implementa el estándar POSIX, sobre del cual corren decenas de miles de programas. Linux fue creado desde un principio para correr en sistemas reducidos - Cuando Linus Torvalds comenzó con su implementación en 1991, tenía una computadora relativamente potente, una 386, aunque era definitivamente mucho más reducida que cualquier estación de trabajo disponible comercialmente para correr sistemas Unix. La primer arquitectura a la que fue "portado" Linux fue la familia de CPUs Motorola 68000, que disfrutó de gran popularidad en los años 80 en computadoras como la Macintosh, Amiga o Atari ST, y que fue utilizado como corazón de las primeras generaciones de Palm. Claro está, Linux creció también en la dirección de las familias de procesadores más grandes, como el Digital Alpha o, más recientemente, a la arquitectura IBM s390. Con las distribuciones actuales de Linux,
Vamos, pues, a revisar algunos dispositivos embebidos que corren con Linux.
Lo más obvio y notorio, lo que más usuarios encontrarán atractivo a primera vista, son los handhelds. Agrego únicamente una nota: Si buscan en Internet, encontrarán reportes de cientos de usuarios que lograron correr Linux en diversos sistemas Palm o PocketPC - En esta ocasión, me concentro únicamente en aquellos sistemas que de fábrica vienen con Linux instalado.
La familia más popular de PDAs basada en Linux es la Sharp Zaurus, que desde el 2002 con su modelo 5000 corre con Linux, utilizando un conjunto de aplicaciones que se integran sobre el entorno Qtopia. Los modelos actuales, como la C3200, son verdaderamente computadoras portátiles completas, que si bien vienen con las aplicaciones que uno esperaría encontrar en una buena PDA, tienen el espacio y el poder de cómputo necesario para correr prácticamente cualquier programa que requiramos.
[imagen: sharp5000.png]
[imagen: sharp_c3200.jpg]
Uno de los productos que más ha llamado la atención, por presentar una propuesta claramente distinta de cualquier PDA, es la tableta Internet 770 de Nokia. Aunque a primera vista parece un organizador personal, su foco es muy distinto: Ofrecer acceso cómodo y móvil a todo tipo de contenido de Internet, a través de una plataforma cómoda y fácilmente extensible. El entorno operativo, Maemo, está fuertemente basado en Debian GNU/Linux - de hecho, varios de los desarrolladores de Maemo son también integrantes de Debian, y Nokia fue el principal patrocinador del congreso Debconf en Helsinki, Finlandia. A través de la página de Maemo podemos encontrar cientos de aplicaciones disponibles para el 770. Su pantalla cómoda y de alta resolución lo convierte además en uno de los dispositivos más cómodos y atractivos del mercado.
[imagen: nokia.jpg]
Y partiendo de una idea similar, pero enfocado a niños y adolescentes, tenemos a Zipit: Un cliente de mensajería instantánea (MSN, AOL y Yahoo) con un sencillo reproductor de MP3 del tamaño (y con apariencia similar) a la de cualquier videojuego portátil, que se conecta a través de cualquier red inalámbrica, de bajo costo (US$99).
[imagen: zipit.jpg]
Ahora bien, Linux siempre ha tenido especial fortaleza en los servidores - ¿Por qué enfocarnos únicamente en los pequeños aparatos que utilizamos para comunicarnos? Linux está también en los aparatos cuyo funcionamiento damos por sentado y a los que ni siquiera volteamos a ver.
La cantidad de funciones que puede realizar el Access Point de cualquier red inalámbrica es sorprendente: Ya quedó atrás la época en que los concentradores de red eran simples cajas haciendo puenteos eléctricos - Hoy en día, además de los roles básicos de comunicación, una simple cajita es capaz de manejar nuestra conectividad de banda ancha, convirtiéndose en un ruteador que hace menos de diez años podría valer varios miles de dólares. Por sí sólo, eso ya requiere de una computadora de propósito general. Linksys se dió cuenta de esto, y en vez de reinventar la rueda, construyó su Access Point y ruteador WRT54GL sobre una computadora basada en arquitectura MIPS - Que además de un AP es más que suficiente como servidor casero y, aunque apretado, tiene suficiente espacio para ser una divertida máquina para aprendizaje. La red comunitaria de Seattle, SeattleWireless, ha
recopilado en su sitio, http://www.seattlewireless.net/index.cgi/LinksysWrt54g, una gran cantidad de información y recomendaciones respecto a cómo aprovechar y jugar con nuestro AP.
[imagen: linksys_wrt54gl.jpg]
Con la flexibilidad que nos da un sistema tan modular como Linux, y con acceso completo a su código fuente, literalmente no hay límites a dónde este pequeño pingüino puede llegar.
Si este tema les interesa, los invito a visitar los sitios Web dedicados al desarrollo y promoción de dispositivos embebidos basados en Linux, como Linux Devices (http://www.linuxdevices.com) o Handhelds.org (http://www.handhelds.org).

Imágenes

pinguino.jpg: Pygoscelis antarctica, el tradicional pingüino de la Antártica
gentoo.jpg: Pygoscelis papua, el pingüino Gentoo
tux.png: Tux, la mascota oficial de Linux
sharp5000.png: El Sharp Zaurus 5000, el primero de la serie que corre
con Linux nativamente
sharp_c3200.png: El Sharp Zaurus C3200
nokia.jpg: La tableta de Internet Nokia 770
zipit.jpg: Zipit Wireless
linksys_wrt54gl.jpg: Linksys WRT54GL

Ligas

AttachmentSize
Texto original enviado para publicación8.72 KB
200612_pcmag_1.jpg106.27 KB
200612_pcmag_2.jpg110.19 KB

TV, audio y video

TitleTV, audio y video
Publication TypeMagazine Article
Year of Publication2006
AuthorsWolf G
MagazinePC Magazine en español
Date Published11/2006
Type of ArticleColumn
ISSN1665-4897
Keywordsevangelizacion, Multimedia
Full Text

Todos damos su lugar a Linux cuando hablamos de aplicaciones en servidor - Es un sistema operativo estable, robusto, modular, confiable... Pero es común que la gente siga dudando de si es lo más adecuado para las aplicaciones de todos los días en el escritorio, y mucho más aún para las aplicaciones multimedia. Vamos a ver un par de ejemplos que nos muestran, nuevamente, que Linux es un sistema operativo apto para cualquier tipo de necesidades con que nos encontremos.
¿Qué aplicaciones vamos a usar para ver películas o escuchar música en Linux? Eso cada día importa menos - Al irse convirtiendo una computadora de escritorio en un simple aparato doméstico, podemos simplemente asumir que cuando abramos un archivo, el reproductor adecuado brincará entusiasta para reproducirlo. Y claro, los usuarios más entusiastas siempre encontrarán características especiales que les ofrece algún otro reproductor - hay una gran cantidad de ellos de donde podemos elegir, pero hoy en día, lo más probable es que comencemos con Totem (para los usuarios de Gnome) o con Amarok (para los usuarios de KDE).
Lo divertido viene cuando nos ponemos a integrar soluciones para llegar más allá.

El centro casero de entretenimiento

El ambicioso proyecto MythTV nació en el 2002, cuando Isaac Richards se cansó de lo poco flexible que resultaba el equipo de televisión por cable que tenía. Cambiar canales resultaba muy lento, tenía más publicidad de la que él estaba dispuesto a ver, y no le permitía grabar los programas tal y como él quería verlos. Además, la tan prometida "convergencia tecnológica" se ha mantenido meramente como una promesa - y decidió hacer algo al respecto.
[Imagen: Menú principal de MythTV - mythtv_principal.png]
MythTV (http://www.mythtv.org/) es un conjunto de programas que nos proporcionan todo lo que buscamos en un centro casero de entretenimiento, operado a través de un control remoto estándar (pues, claro está, ¿quién quiere un teclado y un mouse en el sillón de ver películas?). Requiere, claro, que equipemos a nuestra computadora con hardware poco común, como una o más tarjetas sintonizadoras de TV, receptor infrarojo, tal vez un carrusel para cambiar automáticamente nuestros DVDs, y -muy importante- un gabinete elegante y silencioso que deslumbre a nuestros amigos.
MythTV es muy flexible, y por tanto usarlo no es tan simple como instalar un programa - Pero si usted gusta de pasar tardes viendo películas, si encuentra frustrante el que pasen dos programas de televisión que quiere ver al mismo tiempo, si desea tener un aparatito mágico que borre los comerciales de los programas de televisión, o si le gustaría tener a la mano un navegador Web dentro de la televisión para aquellas consultas repentinas, le sugiero evaluar MythTV. Le recomiendo instalarlo en una computadora dedicada por completo a este propósito usando la distribución KnoppMyth (http://mysettopbox.tv/).
[Imagen: Navegando en la programación de TV con MythTV - mythtv_programacion.png]
Si le interesa ver un video completo explicando cómo instalar y demostrando el uso de MythTV, entre a http://revision3.com/systm/mythtv/

Creación de audio

En Linux no sólo podemos consumir audio y video de la manera más cómoda y profesional - podemos también producirlo. Como siempre, la cantidad de opciones que tenemos es impresionante, y el espacio me obliga a reseñar únicamente a unas cuántas. Si quiere investigar acerca de otros programas, le invito a entrar al directorio de
alternativas libres, en http://alts.homelinux.net/task.php?task=multimedia
Crear y producir audio es un campo muy grande, en el que hay una tremenda variedad de necesidades específicas. Posiblemente la necesidad más recurrente para la creación de audio digital es un programa que combine las funciones de grabación, edición, mezcla y conversión de formatos de audio - Mi recomendación en este rubro va sin duda, y desde hace muchos años, por Audacity (http://audacity.sourceforge.net/), que permite todo esto, además de la aplicación de diversos efectos a nuestros archivos de audio. Además de soportar prácticamente todos los formatos de audio que podamos encontrar, es un programa muy ligero y que permite una ágil edición, incluso con archivos muy grandes. Su interfaz es simple e intuitiva, y por si fuera poco, no se limita a Linux - Es software libre que podemos utilizar sobre cualquier sistema operativo.
[Imagen: Audacity - audacity.jpg]
Una aplicación específica para la cual la computadora es un gran auxiliar, capaz de reemplazar equipo profesional y generar resultado sorprendente, es para remezclar audio tal como lo hace un DJ de grandes vuelos. TerminatorX (http://www-stud.fht-esslingen.de/~alex/tX/) es un sintetizador de audio en tiempo real, con una gran cantidad de filtros, enfocado a permitir mezclar y "scratchear" archivos de audio de cualquier formato. Y si bien al escuchar esta descripción probablemente piensen en música hip-hop, en la página de ejemplos de mezclas generadas con TerminatorX (http://www-stud.fht-esslingen.de/~alex/tX/scratches.html) tiene ejemplos que llegan mucho más allá - Hay incluso algunas piezas producidas comercialmente que nacieron con este programa, así como insturcciones para convertir tornamesas tradicionales en herramientas de control digital - con resultados de mayor precisión incluso que los obtenidos con las tornamesas comerciales con interfaz USB.
[Imagen: TerminatorX - terminatorx.jpg]

Edición de video

Una tarea que puede presentarse mucho más compleja, sin embargo, que la edición de audio es la edición de video. Para esto tenemos también varias herramientas disponibles, con altos grados de sofisticación. Los principales programas para hacer la edición no lineal de video (esto es, que nos permite mezclar varias fuentes de video, audio e incluso de imágenes estáticas, brincando entre puntos en el tiempo de cada una de ellas conforme lo consideremos necesario, sin estar ceñidos al proceso de avance/rebobinado de las herramientas diseñadas para trabajar sobre cintas de video digital) son Kino (http://www.kinodv.org/) y Cinelerra (http://heroinewarrior.com/cinelerra.php3).
El foco de cada una de ellas es diferente - Kino es principalmente utilizado para la adquisición de datos a partir de diversas fuentes (por ejemplo, a partir de cámaras con interfaz DV IEEE1394, el estándar en los equipos de uso profesional), y para un primer mezclado. Una de sus mayores virtudes es que nos permite combinar diversas fuentes de video y guardar los resultados en función de los archivos fuente, pero sin modificarlos, guardando en un archivo SMIL XML las transiciones y efectos a realizar.
Cinelerra normalmente es utilizado una vez que el primer acercamiento fue hecho a través de Kino. Busca ser una herramienta potente y completa, aunque requiere trabajar con un sistemas de altas prestaciones - de hecho, tiene la capacidad de manejar "granjas" de procesamiento, cientos de computadoras trabajando al unísono para generar el video deseado (aunque, claro está, si queremos darle un uso más casero, basta con que no hagamos demasiados efectos y mezclas, y en una computadora potente de escritorio podremos sacarle provecho). Procesa audio y video nativamente a 64 bits, generando video incluso apto para el cine - y tiene una cantidad increíble de documentación. Si le interesa la producción seria y profesional de contenido multimedia, Cinelerra es una de las mejores herramientas del mundo.
Las herramientas que presentamos en esta ocasión requieren que les invirtamos tiempo, que nos dediquemos a conocerlas para poderles sacar jugo - pero sin duda nos pueden dar resultados tan profesionales e impresionantes como para convencer al más incrédulo.

Ligas

Totem: http://www.gnome.org/projects/totem/
Amarok: http://amarok.kde.org/
MythTV: http://www.mythtv.org/
KnoppMyth: http://mysettopbox.tv/
Guía de instalación de KnoppMyth: http://mysettopbox.tv/pamphlet.html
Episodio de "Systm" explicando la instalación de MythTV: http://revision3.com/systm/mythtv/
Alternativas libres a programas de multimedia: http://alts.homelinux.net/task.php?task=multimedia
Audacity: http://audacity.sourceforge.net/
TerminatorX: http://www-stud.fht-esslingen.de/~alex/tX/
Mezclas generadas con TerminatorX: http://www-stud.fht-esslingen.de/~alex/tX/scratches.html
Tornamesas consturidos para TerminatorX: http://www-stud.fht-esslingen.de/~alex/tX/turntable.html
Kino: http://www.kinodv.org/
Cinelerra: http://heroinewarrior.com/cinelerra.php3

Imágenes

Menú principal de MythTV: mythtv_principal.png
Navegando en la programación de TV con MythTV: mythtv_programacion.png
Audacity: audacity.jpg
TerminatorX: terminatorx.jpg
Kino: kino.png
Cinelerra: cinelerra.jpg

AttachmentSize
200611_pcmag_1.jpg108.99 KB
200611_pcmag_2.jpg117.14 KB
Texto original enviado para publicación8.79 KB

2007

Columnas publicadas en 2007

Cambia a un escritorio 3D

TitleCambia a un escritorio 3D
Publication TypeMagazine Article
Year of Publication2007
AuthorsWolf G
MagazinePC Magazine en español
Date Published04/2007
Type of ArticleColumn
ISSN1665-4897
Keywords3D, Beryl, efectos, evangelizacion
Full Text

Hay mucho movimiento a últimas fechas en el mundo del Software Libre, ese extraño mundo que nos brinda tantas posibilidades que llegan incluso a marearnos. Hablemos en esta ocasión de las últimas tendencias en entornos de escritorio: Revisaremos la tecnología que promete exprimir hasta la última gota de nuestras tarjetas de video por medio de entornos cargados de impresionantes efectos 3D, a través de Beryl.
Beryl (http://www.beryl-project.org/) toma su nombre del término con el que los conocedores designan al mineral base de varias piedras preciosas, entre las que destaca la esmeralda. Y el nombre es muy adecuado - La primera vez que veas Beryl en acción quedarás absorto, jugando con sus efectos tal como si estuvieras observando una finísima gema. ¿De qué se trata? De un entorno hecho para explotar al máximo la aceleración 3D que desde hace un par de años viene con prácticamente todas las computadoras de escritorio, empleándolo ya no sólo para jugar, sino para el uso cotidiano. Y tiene todo el sentido del mundo - Ya que tenemos el hardware, hay que sacarle provecho, ¿o no?
Beryl opera sobre las extensiones gráficas GLX y AIXGL, desarrolladas respectivamente por los equipos de RedHat y de Novell, y en el corto lapso de vida que lleva ha logrado ya avances extraordinarios - Hoy está listo para ser tu entorno primario de trabajo. ¿Qué te ofrece? Transparencias, animaciones, efectos especiales para facilitarte el trabajo con muchos programas simultáneos - y un rendimiento impresionante.
Instalar Beryl aún requiere de algo de manipulación a los archivos de configuración del entorno gráfico para activar las extensiones correspondientes - Te recomiendo seguir un mini-tutorial, acorde a la distribución de Linux que uses: Debian (http://fixxxer.cc/blog-es/?p=6), Ubuntu (http://www.biodesign.com.ar/blog/?p=23), Fedora
(http://wiki.beryl-project.org/index.php?title=Install/Fedora_Core), Gentoo (http://gentoo-wiki.com/Beryl) - Y, claro, ahora que Beryl es "lo de hoy", seguramente encontrarás más sin ningún problema. Claro está, puedes también probar Beryl sin instalarlo en tu sistema, utilizando un Live CD: La versión 5.1 de Knoppix (http://www.knoppix.org/) viene lista para correr Beryl, y Sabayon (http://www.sabayonlinux.org/) es un CD vivo pensado desde un principio para servir como herramienta de demostración de Beryl.
¿A qué me refiero, sin embargo, con "explotar la aceleración"? Esta vez más que nunca, los refiero a las capturas de pantalla que acompañan a este artículo: Prácticamente todo el manejo que hagamos de nuestras ventanas va acompañado de efectos 3D - Si movemos una ventana por nuestro escritorio, ésta parecerá hecha de gelatina, temblando hasta colocarse en la posición deseada. Al maximizar o minimizar una ventana, hay diferentes efectos que podemos elegir con los que la ventana "brinca" hasta ocupar la pantalla completa o se dobla sobre sí misma para minimizarse.
En el mundo de los escritorios Linux, desde hace más de una década ha sido común el uso de los escritorios virtuales - Un concepto muy sencillo, y que se vuelve tan importante para trabajar de manera inteligente y organizada que, al enfrentarnos ante un entorno Windows o MacOS, nos es imposible entender cómo la mayor parte de los usuarios del mundo no lo conocen. En vez de tener un sólo espacio donde abrir las aplicaciones, utilizamos varios escritorios distintos, y en cada uno de ellos abrimos las aplicaciones que correspondan. Por ejemplo, yo típicamente tengo abierto mi navegador y correo en un escritorio, los programas relativos a mi trabajo en otro, y la música en un tercero. ¿A qué viene esto? A que una de las características más promocionadas de Beryl es la representación del conjunto de escritorios como un cubo, en el que cada una de las caras es un escritorio, y al pasar de uno al otro lo hacemos rotar. Esto va más allá de una demostración meramente - Nos permite ver rápidamente el estado de algún proceso que tengamos pendiente, sin siquiera tener que
enfocarnos en ese programa, y volver a lo que estábamos haciendo. Además, activando la opción de ventanas 3D, al entrar al modo de cubo, las ventanas "vuelan" permitiéndonos verlas completas, no únicamente como están representadas en la cara plana sobre la cual estamos trabajando.
Beryl también es de gran utilidad para la gente con diferentes discapacidades físicas: Para personas con cansancio o debilidad visual, le podemos indicar que queremos trabajar con la pantalla amplificada, de modo que sólo veamos una porción de la misma, pero con mayor detalle. Le podemos indicar que nos presente determinada ventana en negativo, para aumentar su legibilidad. Para las personas con discapacidad motora, Beryl puede amplificar o reducir el movimiento del mouse - Y todo esto, de manera simple y configurable a través de combinaciones de teclas o de mouse que no presentarán problema para los usuarios discapacitados.
En suma, Beryl nos proporciona entorno sumamente ligero, sencillo de utilizar, y que sin duda impresionará a quien se lo muestres. Lo que es mejor, es un entorno que puede ayudarte a alcanzar una mucho mayor productividad. Sólo me resta hacer una advertencia: ¡Cuidado! Puede ser adictivo.

¿Cómo lo hacen?: Off-Screen Rendering

Viendo las capturas de pantalla en este artículo, probablemente creerás que es indispensable tener el último grito de la moda en hardware para utilizar Beryl, ¿me equivoco? Muy al contrario: aunque suene increíble, el sistema corre incluso más ligero que bajo los entornos tradicionales. ¿Por qué?
Recuerda que Linux, siendo un sistema tipo Unix, tiene un entorno gráfico orientado a red (lo que significa que puedes correr programas gráficos en diferentes computadoras y desplegarlos transparentemente en un sólo escritorio). Claro, eso significa que, para ahorrar ancho de banda, sólo las ventanas que en determinado momento están activas se dibujan por completo en la memoria de video.
Hoy en día, sin embargo, casi siempre trabajamos con la totalidad de las aplicaciones dentro de un sólo sistema, y lo que requerimos es más bien de mayor velocidad al cambiar entre aplicaciones - Para lograrlo, conviene que todas las ventanas estén en memoria de video todo el tiempo. ¿Pero cómo tenerlas en memoria de video sin que aparezcan en pantalla?
Es aquí donde entra en juego la aceleración 3D: La información de las ventanas se "dibuja" no directamente en el escritorio, sino que como texturas, y las ventanas son simples rectángulos planos, que pueden sufrir deformaciones como cualquier objeto 3D - Y es a éstos rectángulos a los que, claro, la tarjeta de video les aplica la textura de cada una de las aplicaciones. A esta técnica se le llama "Off-Screen Rendering", o "Representación fuera de pantalla".

Imagenes>

  • beryl_logo.png - Logotipo del proyecto Beryl
  • beryl_anim_minimiza.png - Podemos elegir entre varios efectos cuál nos aparecerá al minimizar una ventana. En este caso vemos a "Magic Lamp" en acción.
  • beryl_cubo_solido.png - Una de las características favoritas de Beryl es el cubo del escritorio.
  • beryl_cubo_transparente.png - Nuevamente el cubo del escritorio, pero con la transparencia habilitada, lo que nos permite ver las caras ocultas del cubo. Habilitamos también una separación 3D entre las ventanas, que de otro modo aparecerían una sobre otra (tal como están realmente en el escritorio)
  • beryl_dobla_ventana.png - ¿Estamos trabajando con una ventana maximizada, y queremos rápidamente qué hay detrás? No hay problema: La jalamos del borde para doblarla
  • beryl_multi_escritorios.png - Además de cambiar de escritorio por medio del cubo, podemos pedir que éste se "desdoble" y nos muestre en conjunto nuestros diferentes escritorios
  • beryl_transparencia.png - Vemos el efecto de transparencia y de fijar encima: El medidor de recursos del sistema no es en este momento la ventana activa, pero "flota" por encima del navegador. Además, le pedimos que fuera transparente, permitiéndonos tenerlo siempre a la vista, sin dejar de ver a nuestra aplicación

Ligas

AttachmentSize
Texto original para publicación8.77 KB
200704_pcmag_1.jpg249.9 KB
200704_pcmag_2.jpg263.27 KB

Cifrando nuestro disco duro

TitleCifrando nuestro disco duro
Publication TypeMagazine Article
Year of Publication2007
AuthorsWolf G
MagazinePC Magazine en español
Date Published02/2007
Type of ArticleColumn
ISSN1665-4897
Keywordscifrado, Debian, evangelizacion, instalación, Seguridad
Full Text

Sea cual sea nuestro perfil, no hace falta buscar justificaciones para cifrar (o, como también se le dice, "encriptar") nuestra información - La privacidad es nuestro derecho. El presente número de PC Magazine está dedicado a hacer una comparativa entre diferentes computadoras portátiles, y prefiero ser visto como pingüino paranóico y no como ave de mal agüero - Un punto importante a considerar al adquirir una laptop es qué ocurrirá en caso de que nos la roben o que la olvidemos en el lugar equivocado. ¡Recuerda que en la oficina algún colega malintencionado puede querer dañar tu impecable avance, o que en un descuido en casa tu celosa novia puede ponerse a leer el registro de tus conversaciones por mensajería! No está por demás, pues, el considerar cifrar nuestra información.
Hago aquí un paréntesis: Desde hace años, hay muchas herramientas disponibles -para Linux, Windows, MacOS y para cualquier sistema operativo- para cifrar archivos en nuestro sistema, como el famosísimo PGP, de Phil Zimmerman (http://www.pgp.com/), originalmente declarado ilegal por usar algoritmos que ni el Departamento de Defensa de los Estados Unidos podía "romper" o GnuPG (http://www.gnupg.org), que reimplementó PGP de una manera completamente libre. Además, claro, hay versiones para Windows, como la de Coresecure (http://www.coresecure.com/v5/gnupg.html), que ofrecen una interfaz amigable a GnuPG, escondiendo parte de su complejidad. Estas son muy buenas y útiles, por ejemplo, cuando enviamos documentos confidenciales por correo - Pero si realmente nos importa nuestra privacidad, debemos ir un paso más allá.
¿A qué me refiero? A que si tenemos que cifrar cada uno de los archivos que consideramos confidenciales, seguramente terminaremos dejando archivos sin cifrar por mera omisión. Afortunadamente, Linux nos ofrece aquí una muy buena opción - y no sólo eso, nos la ofrece sin complejidad adicional.
Esta no es una característica en Linux, y sin embargo, muy poca gente la usa. ¿Por qué? Porque hasta hace muy poco, el proceso necesario para configurar el cifrado de particiones tenía que ser configurado manualmente, una tarea no tan fácil. Esta situación cambió con la reciente liberación de Debian "Etch" 4.0 (http://www.debian.org/), la más reciente versión de esta importante distribución de Linux. Una de sus novedades más importantes es el soporte, desde la misma instalación, de cifrado a nivel partición para todo el sistema. No entro en detalles técnicos, pero para quien esté interesado, basta mencionar que en el corazón de este sistema está LUKS (Linux Unified Key Setup, http://luks.endorphin.org/), un esquema que está en camino a estandarizarse entre las diferentes distribuciones de Linux, y permite guardar en la tabla de particiones toda la información relevante al cifrado. LUKS trabajará sobre de el Manejador de Volúmenes Lógicos, LVM, otro subsistema de acceso a los dispositivos de nivel profesional que sin duda merece que lo desmenucemos en otra ocasión.
Uno de los pasos ineludibles al instalar Linux es indicarle al particionador cómo queremos manejar nuestras particiones - Este es un paso que asusta a muchos novatos, dado que puede presentarnos demasiada información - Tipos de sistema de archivo, puntos de montaje, opciones de todo tipo. ¡No temas! Por lo general, los valores por omisión son los adecuados para la generalidad de los usuarios.
En el instalador de Debian, al llegar al paso del particionado, el sistema nos presenta cuatro opciones [IMAGEN: debian_1.png]. Si seleccionamos la tercera ("Guiado - utilizar todo el disco y configurar LVM cifrado), el instalador creará una pequeña partición no cifrada, en la que exclusivamente guardará lo necesario para iniciar Linux: El núcleo y las herramientas básicas para montar al resto del sistema. Tras un par de preguntas (y, reitero, basta responder "siguiente" si no tenemos una necesidad real de hacerlo de otro modo), nos pide la contraseña de cifrado, con la que estará protegida nuestra información. Sobra decirlo: Esta es una contraseña de grandísima importancia. Si la pierdes, la información en tu disco quedará completamente inutilizable. Pero bueno, ¿qué no es eso precisamente lo que estamos buscando? ;-)
Una vez que le indicamos nuestra contraseña, el instalador nos muestra cómo quedarán configuradas las particiones [IMAGEN: debian_2.png]. La instalación continúa sin mayor sobresalto, y tras reiniciar el sistema, como uno de los primeros pasos (y aún desde la consola de texto - Recuerda, el sistema completo está cifrado) nos pide que le proporcionemos la contraseña.
Tras responder a un par más de preguntas, relativas a qué tipo de programas nos interesa instalar, y de esperar unos minutos, el instalador terminará con su tarea. ¡Eso es todo! ¡Felicidades! Nuestro sistema Debian recién instalado está completamente cifrado. Cuando encendamos nuestra computadora, lo primero que encontraremos es que el sistema nos pide nuestra contraseña para entrar [IMAGEN: debian_3.png].
Claro está, podemos configurar el cifrado sobre discos duros, llaves USB, o particiones independientes en cualquier momento, no sólo a la hora de instalar el sistema. Para hacerlo, podemos emplear herramientas como LUKS-tools [IMAGEN: luks-tools.png] (http://www.flyn.org/projects/luks-tools/), y su manejo está ya integrado en el escritorio Gnome [IMAGEN: gnome-mount.png]. Cada vez más distribuciones están incluyendo como parte de su sistema básico el soporte para particiones cifradas, e incluso el equipo de LUKS está trabajando para agregar este soporte a Windows, a través de FreeOTFE (http://www.freeotfe.org/) [IMAGEN: freeotfe.png].
El camino andado por los programadores que tomaron para sí la tarea de crear un esquema robusto y seguro de cifrado de particiones o discos completos ha sido largo, pero a través de las herramientas que aquí reseñamos, hoy en día el contar con un esquema profesional de seguridad sobre de nuestra información queda ya al alcance de nuestras manos.

Ligas

Imagenes

  • debian_1.png - Dentro del instalador de Debian, seleciconando el particionador con cifrado automático
  • debian_2.png - Dentro del instalador de Debian, revisando las particiones a instalar
  • debian_3.png - Una vez instalado el sistema, al reiniciar, lo primero que nos pide es la contraseña para acceder al disco cifrado
  • luks-tools.png - LUKS-tools, herramientas para crear, montar y desmontar volúmenes cifrados con LUKS
  • gnome-mount.png - Gnome Mount, integrado con el escritorio Gnome, tiene ya soporte para identificar y montar discos cifrados
  • freeotfe.png - FreeOTFE, implementación de cifrado de discos en Windows, compatible con LUKS
AttachmentSize
Texto original para publicación7.5 KB
200702_pcmag_1.jpg103.71 KB
200702_pcmag_2.jpg112.22 KB

Comparte tus fotos

TitleComparte tus fotos
Publication TypeMagazine Article
Year of Publication2007
AuthorsWolf G
MagazinePC Magazine en español
Date Published05/2007
Type of ArticleColumn
Keywordsevangelizacion, fotografía, galería, Multimedia, Web
Full Text

Una de las principales razones por las que las cámaras digitales se han popularizado tan rápidamente es la facilidad que nos dan para compartir nuestras vivencias de manera fácil y rápida con amigos y familia en todo el mundo. Muchas veces defendemos como principal ventaja de las cámaras digitales el que ya no tenemos que esperar para ver nuestras fotografías, o el que no es ya necesario pagar por el revelado - ¡Piensa tan sólo en lo incómodo que era antes llevar tu álbum de fotos para mostrárselo a un amigo o familiar! Más aún, ¿no temías que, por olvido o accidente, perdieras la única copia de las fotos de ese irrepetible momento? Es en este punto donde radica el gran cambio de la fotografía de los últimos años. No sólo nos hemos acostumbrado a cargar con nosotros una o varias cámaras, sino que la función de las fotografías mismas ha cambiado: Ya no sirven principalmente para registrar nuestra historia, sino para compartir nuestro presente.
Ahora bien, ¿cómo vamos a compartir nuestras fotos? Es común enviarlas por correo electrónico, sí, pero es también muy incómodo: A mucha gente no le gusta recibir mensajes con adjuntos muy grandes, y si queremos enviar la misma foto a varios amigos, el pecado se repite muchas veces. Y, claro, si no cuentas con una conexión de banda ancha, cada correo tomará el mismo tiempo en ser enviado. Puedes también usar servicios en línea de álbumes fotográficos, como el Flickr de Yahoo! (http://www.flickr.com/), Fotosite (http://www.photosite.com/) o muchos otros - pero tus fotos siempre irán acompañadas por publicidad, hay que aguantar límites de uso por mes, y... Bueno, muchas veces querrás compartir tus fotos sin depositarlas en un sitio administrado por desconocidos. Hoy en día, ser paranóico es ya la segunda naturaleza del internauta. Además, es de todos sabido que una de las principales características de los linuxeros es que nos gusta resolver los problemas con nuestras propias herramientas, que nos gusta hacer más que depender de terceros. ¡Manos a la obra!
En esta ocasión, vamos a revisar un programa muy popular para organizar y compartir nuestras fotos: Gallery (http://gallery.menalto.com/). Gallery es un programa escrito en PHP, hecho para funcionar con prácticamente cualquier servidor Web - Sí, para nuestros lectores menos aventureros, puedes instalar Gallery en Windows al igual que en Linux, aunque el proceso es un poco más tortuoso. En Debian, basta pedirle al gestor de paquetes que instale gallery2 (con "aptitude install gallery2"), y éste bajará automáticamente todos los paquetes de los que Gallery depende, y lo deja instalado y listo para usar. Hay, claro está, paquetes preparados para las demás las distribuciones de Linux - Mi recomendación va por Debian dado que es la distribución que más empeño pone en automatizar la instalación de modo que el usuario requiera del menor tiempo posible para tenerlo funcionando. Podemos usar a Gallery para compartir nuestras fotos ya sea si tenemos una conexión de banda ancha en casa y montamos un servidor Linux para controlarla, o en un servidor dedicado en el que tengamos acceso. Podemos también acudir a alguno de los proveedores de hosting que ofrecen instalaciones de Gallery como parte de su paquete de servicios - En la página de sitios referidos (http://gallery.menalto.com/wiki/Web_Hosting_Referral_Page) mencionan a varios.
Una vez que tenemos a Gallery instalado en nuestro sistema, entramos con nuestro navegador a http://localhost/gallery2 (u otra dirección, si es que así lo configuramos - Claro, si estamos trabajando con un servidor remoto y no estamos montando Gallery sobre nuestra propia computadora, tendremos que dar la dirección de dicho servidor en vez de "localhost"), y pasamos por una simple instalación con 11 pasos (muchos de los cuales son principalmente de confirmación, en los que basta con seleccionar "siguiente"). [imagen: config.png]. Gallery guarda la información relativa a nuestras fotografías en una base de datos, típicamente MySQL (puedes configurarlo para que use PostgreSQL, Oracle o DB2) - puede resultarte interesante asomarte a la estructura para aprender cómo está estructurado. Como parte del proceso de instalación, Gallery nos pide que le indiquemos los datos para crear una cuenta de usuario administrador [imagen: config_login.png].
Tras terminar la etapa de configuración, Gallery está listo para recibir visitas en la misma dirección con la que recién hicimos la configuración. Podemos entrar como nuevo usuario seleccionando "Login" en la esquina superior derecha [imagen: primer_login.png] y comenzar a subir nuestras fotos.
En Gallery podemos simplemente subir las fotos una tras otra, podemos organizarlas en álbumes, o incluso mezclar ambos estilos. Además, un álbum puede contener a otros varios álbumes, tal cual si fueran más bien directorios dentro de nuestro disco duro. [imagen: raiz.png]
Cada uno de los elementos en Gallery (sea un álbum o una fotografía) pueden tener nombre, título y descripción. Además, puedes permitir que los visitantes publiquen comentarios - Puedes convertir a Gallery prácticamente en un photoblog. Y hablando de blogs - Si quieres que tus amigos se enteren automáticamente de las fotos que vas subiendo a tu Gallery, basta con que den de alta al RSS que genera en su agregador de noticias favorito.
Ahora, ¿quedarás tú como responsable único de tu galería? ¡Claro que no! Gallery permite que participen en tu sitio tantos usuarios como quieras. El usuario que creaste al instalar el sistema es meramente el administrador de la galería - Puedes crear cuentas para tus amigos o familiares, para que ellos también puedan compartir sus fotografías. Y, claro, como administrador del sitio puedes agrupar los usuarios según diferentes criterios y configurar los permisos que tendrá cada uno de los grupos - Por ejemplo, permitir que todos puedan subir fotos a su álbum personal y a un álbum común a todos, pero que sólo puedan poner comentarios en las fotos de los demás usuarios. Un usuario puede inclusive definir "marcas de agua", que Gallery agregará automáticamente a todas las fotos que suba, identificándolas y evitando que terceros las usen sin su autorización. [imagen:
usuarios.png]
Cuando tienes un álbum con decenas de fotos, probablemente no quieras irle apretando "siguiente" a una tras otra. Puedes pedir a Gallery que te las muestre una por una ("ver presentación"), con demora de entre uno y veinte segundos entre foto y foto, y tanto en órden como de manera aleatoria. [imagen: slideshow.png]
Casi todas las cámaras digitales hoy en día manejan el campo Exif, que da información adicional respecto a cada una de las fotografías, como los parámetros de exposición, la cámara con que fue tomada, la hora y fecha, y mucho más. No tienes que preocuparte por poner todos estos detalles en la descripción de tus fotos, ya que Gallery los mostrará cuando el usuario le pida ver los detalles.
Podría seguirte describiendo las características de Gallery por muchas páginas más, y lo más probable es que no acabaría. Entre los criterios de diseño del sistema está el invitar a los usuarios a escribir plug-ins ofreciendo funcionalidad adicional - De este modo, si bien el núcleo de Gallery es relativamente pequeño y fácil de comprender, hay una enorme cantidad de plug-ins disponible que extiende la funcionalidad de Gallery en direcciones posiblemente nunca previstas por sus autores. [imagen: modulos.png]
Seguramente a lo largo de este artículo te encontraste con muchas características que ya te son conocidas, ya sea de otros programas que puedes emplear localmente en tu computadora (en Linux, Windows o MacOS) o de servicios en línea. En resumen, ¿qué ventajas nos ofrece sobre éstos Gallery? Primero que nada, el tener el control absoluto de tu información, sin depender de terceros. En segundo lugar, Gallery es un sistema muy eficiente, cómodo y ligero para el manejo de tu información - Conozco incluso gente que instala Gallery en sus computadoras personales pues les resulta más simple organizar su colección de imágenes que a través de los programas tradicionalmente utilizados para este fin. Y en tercer lugar, Gallery está programado de una manera muy clara y amigable, es un buen ejemplo de cómo se pueden hacer bien las cosas con PHP. Si quieres saber a detalle cómo se gestiona una gran cantidad de imágenes, cómo se transforman, cómo relacionarlas con sus usuarios, y un largo etcétera, no tengas miedo en asomarte a leer su código - Seguramente te sorprenderá de lo fácil que te resulta comprenderlo. Y, quién sabe, ¡puede que la siguiente versión de Gallery incluya ya cambios propuestos por tí!

Imagenes

  • config.png: Iniciando el proceso de configuración de Gallery
  • config_login.png: Durante el proceso de instalación, tenemos que crear una cuenta de usuario para administrar Gallery
  • primer_login.png: Gallery, recién configurado y listo para recibir nuestras fotos
  • raiz.png: La vista de nuestros álbumes ante un usuario
  • usuarios.png: Podemos definir cuantos grupos de usuarios queramos, y asignar permisos para que cada grupo tenga acceso a diferentes áreas de nuestra galería
  • slideshow.png: Podemos pedir a Gallery que muestre una presentación contínua con todas nuestras fotos, sin que tengamos que estarle picando "siguiente"
  • modulos.png: Gallery cuenta con una gran cantidad de plug-ins que extienden su funcionalidad mucho más allá de lo previsto por los autores
AttachmentSize
200705_pcmag_1.jpg114.84 KB
200705_pcmag_2.jpg103.57 KB
Texto original para publicación9.49 KB

Linux para seres humanos

TitleLinux para seres humanos
Publication TypeMagazine Article
Year of Publication2007
AuthorsWolf G
MagazinePC Magazine en español
Date Published03/2007
Type of ArticleColumn
ISSN1665-4897
Keywordsdistribuciones, evangelizacion, Ubuntu
Full Text

[imagen: logo_ubuntu.png]
Varios de nuestros lectores han expresado inquietud por leer acerca de la distribucion de Linux más popular hoy en día: Ubuntu (http://www.ubuntu.com/). Esta distribucion, contrario a lo que podrían imaginar, es relativamente nueva: Debutó apenas en octubre del 2004, e inmediatamente alcanzó los principales niveles de popularidad entre los usuarios. ¿Qué lo hace tan especial? ¿Qué lo impulsó para alcanzar tal éxito? Comencemos por lo más obvio: La identidad y filosofía básicas detrás de su creación.
El padre de Ubuntu, tanto en lo ideológico como en lo técnico y en lo financiero, es Mark Shuttleworth [imagen: shuttleworth.png] (https://wiki.ubuntu.com/MarkShuttleworth), un jóven sudafricano que, tras hacerse millonario al vender la empresa Thawte a Verisign y cumplir el sueño de su vida (¿Y cómo culparlo? ¡Debe ser el sueño de la vida de todos nosotros!) de viajar al espacio, a la Estación Espacial Internacional, ha financiado ya varios proyectos orientados a acercar a la población en general a la tecnología. El cargo oficial que desempeña Mark Shuttleworth en Ubuntu es el de Autoproclamado y Benevolente Dictador Vitalicio - Y fiel a la visión de Mark, Ubuntu (cuyo nombre proviene de una palabra africana que significa "humanidad hacia los otros"), busca crear una distribución de Linux que apunta no únicamente hacia la excelencia técnica, sino que de utilización fácil y natural para cualquiera, sin importar su nivel técnico.
Por otro lado, Ubuntu deriva -y mantiene una relación muy cercana- con otra muy importante distribución de Linux: El proyecto Debian. Debian, fiel a su lema "el sistema operativo universal", es un gran depósito de software de todo tipo, y si bien la calidad de empaquetamiento y de integración que tiene es probablemente la más alta de entre todas las distribuciones de Linux, el ser un proyecto completamente desarrollado por voluntarios con visiones del mundo tan distintas, ofrece tal variedad de software que puede dejar perplejos a los novatos. Además de esto, por los estándares de control de calidad y por la cantidad de paquetes que ofrece, Debian tiene ciclos de liberación muy largos. Ubuntu toma la rama de desarrollo de Debian cada seis meses, pule y personaliza su instalación, y ofrece un producto muy consistente y bien integrado.
Claro está, una de tus principales dudas para poder aprovechar este artículo debe ser cómo conseguir Ubuntu. Tienes dos opciones principales: bajarlo o pedir que te lo envíen. Si tienes una conexión a Internet suficicentemente rápida, definitivamente te recomiendo bajarlo desde http://www.ubuntu.com/products/GetUbuntu - En caso contrario, puedes pedir, desde esta misma página que te lo envíen.

Un primer vistazo

Visualmente [inicio.png], Ubuntu es muy diferente tanto de las otras distribuciones de Linux como de Windows y de MacOS - Mientras que casi todos usan combinaciones de colores basados en el azul, los desarrolladores de Ubuntu ofrecen un tema con mayor sensación de humanidad y calidez, con un color café-naranja. Y aunque esto a muchos parece un detalle menor, es una muestra dela importancia de estos pequeños detalles en su grupo de desarrolladores.
Otra característica fundamental de la filosofía de Ubuntu, siguiendo la línea de un sistema apto para ser utilizado por personas de carne y hueso, sin necesidad de preparación técnica, es la importancia que da a que el sistema entero esté disponible en la mayor cantidad posible de idiomas. Al iniciar con el CD de instalación de Ubuntu [imagen: seleccion_idioma.png], al realizar una instalación, o inclusive en cualquier momento con el sistema ya instalado, podemos elegir el idioma en que el sistema se presentará a nosotros. ¡Podemos arrancar el CD de instalación en cualquiera de sus 64 idiomas soportados, y en cualquier momento podemos elegir cambiar a otro! Lo que es más importante aún, especialmente en computadoras que son compartidas entre varios usuarios: Cada quién puede configurar en qué idioma prefiere que el sistema se dirija a él, y el sistema con todo gusto así lo hará. Cabe señalar que esta característica es común a todas las distribuciones de Linux - Pero Ubuntu hace especialmente fácil el instalar los paquetes necesarios para dar soporte a idiomas adicionales, a literalmente sólo un click de distancia.
El CD de instalación de Ubuntu es toda una obra de ingeniería: Además de ser un CD vivo (ver la columna publicada respecto a los CDs vivos en enero) que nos permite utilizar un entorno virtualmente idéntico al de un Ubuntu -aunque, claro está, sensiblemente más lento por tener que correr desde el CD- incluye todos los archivos necesarios para instalar un sistema que, como veremos a continuación, puede ser utilizado directamente para casi cualquier propósito. Y, por si esto fuera poco, ¡incluye también los programas libres más populares e importantes para Windows, por si aún no estás listo para cambiar, para que puedas irlos conociendo! La suite de oficina OpenOffice completa, el popular navegador Firefox, el lector de correo Thunderbird... Todo dentro de un CD de tan sólo 650MB. Impresionante.
Ubuntu busca proveer un entorno completo para el promedio de los usuarios, y en general, las aplicaciones y el entorno que viene configurado son muy atinados. Si estás familiarizado con otras distribuciones de Linux, te darás cuenta de que el entorno instalado por default es Gnome. Ahora bien, hay quien se siente más a gusto con el entorno de escritorio KDE. Puede ser, especialmente si tu computadora no es muy reciente, que prefieras usar un entorno más limitado, como XFCE - Puedes bajar versiones derivadas de Ubuntu, con soporte oficial, pero construídas con estos entornos - Kubuntu (http://www.kubuntu.org) o Xubuntu (http://www.xubuntu.org).
Como es ya la norma en los sistemas Linux, la instalación de Ubuntu es rápida y sencilla. Una vez que arrancamos con nuestro CD, basta dar doble click en el icono "Install" del escritorio, y responder a cinco sencillas pantallas: El idioma en que queremos que quede instalado por defecto el sistema, la región del mundo en que vivimos [imagen: inst_elige_ubicacion.png], la distribución de nuestro teclado, el nombre y contraseña que deseamos emplear, y cómo queremos particionar nuestro disco (no te espantes, basta indicarle que se encargue automáticamente de este paso). Nos muestra por último un resumen con nuestras elecciones para confirmarlas, y comienza a instalar el sistema. La instalación no dura más de media hora, y mientras la efectúa, podemos seguir usando la computadora -por decir algo- para navegar por Internet o para jugar uno de tantos jueguitos que incluye.

Navegando

Hoy en día, si acabas de instalar un sistema operativo nuevo, ¿cuál es tu prioridad? ¡Claro! Ver qué programas te ofrece para navegar en Internet, para leer tu correo, para chatear, etc. La instalación estándar de Ubuntu viene con todo lo necesario, aunque -como veremos más adelante- hay mucho software adicional que puedes instalar.
El navegador preconfigurado [imagen: firefox.png] no sorprenderá a nadie: Hay poca gente ya hoy en día que no conozca a Firefox, un navegador ágil y seguro, disponible en cualquier sistema operativo.
Para leer tu correo, gestionar tus contactos y calendario [imagen: evolution_calendario.png], Ubuntu viene con Evolution, el potente y amigable cliente de correo diseñado por el equipo de Ximian-Novell.
El programa para manejar los mensajeros es muy interesante: Gaim. No se limita, como es la norma, a funcionar como mensajero con un sólo protocolo (digamos, MSN, Yahoo! o ICQ), sino que nos ofrece desde un sólo programa podemos manejar todas las cuentas que utilicemos. [imagen: gaim.png] Y aprovechando que mencionamos a Gaim: Recuerda que uno de los componentes más importantes tanto de Ubuntu como de cualquier distribución de Linux es su comunidad. Uno de los mejores recursos en caso de que tengas alguna duda es el canal #ubuntu en la red de IRC irc.ubuntu.com.

Herramientas de oficina

Después de navegar un rato, encontrar información interesante y platicar con los amigos, querrás trabajar un rato - Ubuntu viene cargado con OpenOffice, [imagen: openoffice.png] una suite libre de oficina con todas las herramientas de productividad de oficina que necesites - Hoja de cálculo, procesador de palabras, presentaciones, base de datos, dibujos 3D, páginas Web, y más. Obviamente, estas aplicaciones -además de trabajar nativamente con los formatos estándar OpenDocument- son perfectamente compatibles con los documentos de
Microsoft Office.
Y si lo tuyo es la edición de imágenes o el retoque fotográfico, no puedes dejar de usar Gimp [imagen: gimp.png]. Es muy simple y potente para la edición de imágenes, y a través de sus "plug-ins" Script-Fu te permite la creación y automatización de interesantes y originales efectos.

Entretenimiento

La instalación por default de Ubuntu viene cargada con todo el software necesario para usar a nuestra computadora como estación básica de entretenimiento - Para multimedia [imagen: multimedia.png], con Totem podemos ver videos y películas; Rythmbox nos da todas las facilidades para organizar y utilizar nuestra colección de música, sintonizar estaciones de radio en línea y escuchar podcasts; Serpentine nos permite crear fácilmente CDs de audio; con Sound Juicer podemos leer nuestros CDs de música y convertirlos a una colección en nuestra computadora.
¿Juegos? Claro, ningún sistema operativo puede preciarse de completo sin su generosa dotación de jueguitos para matar el tiempo y romper el stress diario. Con la selección de juegos básicos de Gnome que viene instalada en Ubuntu, te garantizo horas de... ¿Entretenimiento? ¿Vicio? De tí depende cómo lo veas - Como sea, como parte de la instalación base de Ubuntu tienes 16 juegos para elegir. [imagen: juegos.png]

Instalando otros programas

Claro está, lo que hasta aquí platicamos no es más que la instalación básica de Ubuntu - Aunque para muchísima gente esto será suficiente para cubrir todas sus necesidades para el trabajo diario, tenemos a nuestro alcance una gran cantidad de software listo para ser utilizado. Basta con seleccionar la opción «añadir y quitar» desde el menú de aplicaciones, y tendrás frente a tí a Synaptic [imagen: synaptic.png], desde donde podrás elegir lo que te interese de entre literalmente miles de programas listos para instalar y utilizar.

Ligas

Imagenes

  • shuttleworth.png: Mark Shuttleworth, creador de Ubuntu
  • inicio.png: La pantalla de inicio tras instalación de Ubuntu
  • logo_ubuntu.png: El logotipo de Ubuntu
  • seleccion_idioma.png: Al arrancar con el CD de instalación, podemos elegir cualquiera de estos 64 idiomas
  • paquetes_idiomas.png: Para instalar paquetes de idiomas adicionales en Ubuntu, basta con indicar en las preferencias del sistema qué idioma queremos emplear. Los archivos necesarios serán descargados automáticamente.
  • inst_elige_ubicacion.png: Selecciona la parte del mundo donde vives, dando click sobre la ciudad más cercana. Esto le indica a Ubuntu cuál de sus servidores está más cerca de tí, permitiéndote descargar los archivos con comodidad, y en qué huso horario estás ubicado, para que no tengas que preocuparte por cambiar la hora de tu sistema al iniciar o terminar el horario de verano.
  • firefox.png: Para navegar en Internet, nada como el popular navegador Firefox
  • evolution.png: El calendario de Evolution es fácil de usar, pero nos da todo el poder necesario para usarlo como herramienta colaborativa con nuestro grupo de trabajo
  • gaim.png: El cliente de mensajería instantánea Gaim nos permite, desde un sólo programa, platicar con todos nuestros contactos de MSN, Yahoo!, ICQ, IRC, Jabber, y prácticamente cualquier otro esquema de mensajería instantánea
  • openoffice.png: OpenOffice tiene prácticamente todos los programas de productividad de oficina con los que trabaja el 90% de la gente. Su manejo no te representará ninguna diferencia, y tiene excelente compatibilidad con los formatos de otras herramientas de oficina.
  • gimp.png: Uno de los primeros y más maduros programas que no puede faltar en todo escritorio Linux: Gimp, para la edición de imágenes y retoque fotográfico
  • multimedia.png: Tienes preinstaladas las herramientas de multimedia necesarias para disfrutar de tu PC como una completa estación multimedia
  • juegos.png: Como parte de la instalación estándar de Ubuntu vienen 16 simples pero adictivos juegos
  • synaptic.png: Si quieres instalar software adicional -miles de programas a un click de distancia- entra a Synaptic
AttachmentSize
200703_pcmag_1.jpg107.58 KB
200703_pcmag_2.jpg110.57 KB
Texto original para publicación13.32 KB

Los CDs vivos

TitleLos CDs vivos
Publication TypeMagazine Article
Year of Publication2007
AuthorsWolf G
MagazinePC Magazine en español
Date Published01/2007
Type of ArticleColumn
ISSN1665-4897
Keywordsdistribuciones, evangelizacion, Live CD
Full Text

"¿Qué Linux me conviene instalarle a mi computadora", dice un amigo. "¿Conviene instalar Debian, Gentoo, RedHat o qué?", me pregunta otro. Alguien más, "Es que mi Linux viene más bonito que el tuyo". ¿A qué se debe esto?
Si bien, tal cual es lógico, hay un sólo proyecto llamado Linux, existen alrededor de éste -literalmente- cientos de distribuciones - grandes conjuntos de software integrados de manera consistente para brindar al usuario lo que requiere. Linux es, a fin de cuentas, únicamente el núcleo del sistema operativo, la parte más medular de la interacción entre los programas y el hardware. Todos los demás programas que utilizamos en conjunto con él -que rondan ya las decenas de miles, y eso contando únicamente los que están disponibles como software libre- los integramos normalmente a través de una distribución.
Sin embargo, elegir qué distribución usar no siempre es asunto fácil - Y es mucho menos atractivo aún si cada una que queramos probar nos significa llevar a cabo una instalación completa del sistema operativo a nuestro disco duro, con el siempre presente temor de que elijamos la opción equivocada y perdamos nuestra información. Además, lo más probable es que en primer instancia lo que nos interese es básicamente es ver si Linux es suficientemente cómodo, si los programas que vienen en una distribución son realmente lo que requerimos? Los CDs vivos son la solución: Son CDs con todo el software instalado y utilizable, que no requieren ser instalados al disco duro, y que típicamente ofrecen un programa para ser instalados en caso de que realmente nos convenzan. Los CDs vivos han sido uno de los principales mecanismos de la popularización de Linux en el escritorio en los últimos años.
Por otro lado, a través de los CDs vivos podemos responder a otra necesidad muy frecuente de todos los aficionados al cómputo: Podemos tener todas las herramientas necesarias para la recuperación de información, desde si se dañó nuestro sistema operativo -sea este Linux, Windows, MacOS o cualquier otro- hasta lo necesario para hacer un análisis forense tras una intrusión en la seguridad de nuestra red.
Veamos, pues, algunas de las distribuciones más representativas. Uno de los mejores recursos para encontrar más distribuciones de este tipo es la página de Frozentech (http://www.frozentech.com/content/livecd.php), donde encontramos más de 300 CDs vivos y categorizados.
La primer distribución viva en tener gran difusión, en gran medida por ser la primera en efectuar una exhaustiva autodetección de hardware y funcionar correctamente en prácticamente cualquier computadora tipo PC, es Knoppix (http://www.knopper.net/knoppix/index-en.html), creada por Klaus Knopper. Su última versión, 5.0.1, está disponible tanto en CD como en DVD. Ofrece un escritorio Linux con una cantidad y variedad tremenda de software instalado (he de ser franco: Nunca he usado una computadora con tanto software listo para ser utilizado como con el DVD de Knoppix - Incluso el CD tiene más de lo que uso día a día). Knoppix es una excelente herramienta para tener siempre a la mano en caso de que necesitemos recuperar un sistema dañado - Viene con soporte para prácticamente cualquier sistema de archivos, con herramientas para recuperación de datos, monitoreo de red, y un largo etcétera. Por omisión nos presenta un entorno de escritorio KDE, aunque podemos optar por usarlo con Gnome o con XFCE. Knoppix está basado completamente en Debian, y de hecho, si solicitamos la instalación al disco duro, se convierte simplemente en una instalación personalizada de Debian.
[imagen: knoppix.png]
Basándose en las ideas principales de Knoppix (su mecanismo de detección y configuración de hardware y el empaquetamiento de software derivado de Debian), Alex de Landgraaf inició el proyecto Morphix (http://www.morphix.org/), presentando ya no sólo una distribución viva, sino que un entorno que permite la generación de distribuciones a la medida, de una manera mucho más modular. Como ejemplo, tienen para descarga desde su sitio oficial MorphixLightGui (escritorio simple para computadoras de prestaciones limitadas), MorphixGnome, MorphixKDE (entornos completos de escritorio basados respectivamente en Gnome y KDE), MorphixLiveKiosk (orientado a quioscos, cibercafés y otros entornos en que buscamos ofrecer al usuario un entorno limitado a la navegación), MorphixGame (una gran cantidad de juegos instalados sobre un entorno ligero) y MorphingMorphix (con todas las herramientas necesarias para crear un Morphix a nuestra medida, sin siquiera tener que instalar al disco). Además de todo, tiene ligas hacia varios proyectos derivados de Morphix.
[imagen: morphix.jpg]
Freeloader, de Privare Systems (http://freeloaderlinux.sourceforge.net/), responde a un reclamo muy común: Puede que Linux sea muy fácil de usar, pero es simplemente diferente. Privare preparó una serie de videos instructivos, acompañados de textos escritos en formato de tutorial, enfocados a enseñar a los nuevos usuarios a dar los primeros pasos con Linux, partiendo de un entorno simple y sin distracciones. Puede ser un recurso muy útil para todo a quien la perspectiva de cambiar por completo de entorno le provoque nerviosismo.
[imagen: freeloaderlinux.png]
Muchos asiduos de Linux disfrutan mostrándole a sus amistades de lo similar que puede éste ser a Windows - No sólo en lo relativo a su uso, sino que inclusive a su apariencia. Entre la Faculdade Metropolitana de Guaramirim, Brasil, y la Universidad Austral de Chile diseñaron Famelix (http://www.famelix.uach.cl/es/), con la intención frontal de que la barrera psicológica que impone este cambio sea lo más baja posible, permitiendo a los usuarios más novatos y conservadores iniciar una migración sin siquiera darse cuenta. Buena parte de su trabajo se ha centrado en la automatización de detección de hardware, no sólo en el conectado directamente a la computadora en que corre Famelix, sino que a otros sistemas en la red local.
[imagen: famelix.jpg]
La distribución de Linux que, sin duda, encontraremos con mayor frecuencia en el ámbito empresarial es RedHat (http://www.redhat.com), en gran medida por los contratos de mantenimiento que ofrece y por las alianzas que esta empresa ha celebrado con diferentes proveedores independientes de software propietario. Si vamos a evaluar a Linux para aplicaciones empresariales, probablemente valga la pena acercarnos a través de CentOS (http://www.centos.org/), que sigue muy de cerca a RedHat, y que ofrece también un CD vivo (http://isoredirect.centos.org/centos/4/isos/i386/) con una instalación muestra.
[imagen: centos.png]
Claro está, no podemos olvidar al actual líder indiscutible en la popularidad de entre las distribuciones de Linux: Ubuntu (http://www.ubuntu.com/). Desde su aparición en 2004, basándose en una sincronización semestral con Debian (para asegurar a sus usuarios una gran selección de paquetes y una muy alta calidad) y en una política de sacar una nueva versión de su sistema cada seis meses con lo último de los programas libres, Ubuntu basa su instalación también en un CD vivo. Este CD no es tan ambicioso como muchos de los que aquí menciono, dado que debe incluir los paquetes para instalarse dentro del mismo disco, lo que limita el espacio total disponible, pero aún así es una alternativa interesante - Nos permite probar de primera mano su concepto de "Linux para seres humanos". Además, a través de su servicio Shipit (http://shipit.ubuntu.com/), no tenemos ni siquiera que bajar el CD; podemos pedirlo, y Ubuntu nos lo envía sin costo alguno.
[imagen: ubuntu.png]
Quantian (http://dirk.eddelbuettel.com/quantian.html) es una distribución en CD vivo con un propósito muy específico: Convertir a cualquier computadora en una estación de trabajo de alto rendimiento, lista para ser integrada a una red de procesamiento paralelo, para cómputo científico - Y claro, nuevamente, sin tener que instalar nada. No es ya tanto para el usuario casual que puede interesarse en Linux, sino para gente que requiere de una herramienta completa para solucionar problemas de estadística, bioinformática, matemática, física o visualización. Y no sólo cuenta con las aplicaciones necesarias para realizar los cálculos más pesados en todos estos ámbitos - Desde las herramientas de oficina tradicionales hasta aquellas necesarias para diseñar y controlar un cluster de cómputo masivo bajo Mosix, LVM o MPI.
[imagen: quantian.jpg]
¿Cómo diagnosticar una computadora que se está portando raro? ¿El problema es la memoria, el CPU, la comunicación entre estos, o algún componente adicional que está metiendo ruido? ¿O los componentes del sistema funcionan bien, y tengo más bien que buscar si el culpable es el software? ¿Cuál es la causa de la lentitud en el sistema o en su conexión a red? StressLinux (http://www.stresslinux.org/) busca servir como herramienta de diagnóstico de hardware, en una distribución realmente mínima (mide únicamente 33MB) para evitar cualquier elemento que pueda modificar el diagnóstico, y se antoja como una herramienta indispensable para todo quien se dedique al mantenimiento de equipo. Además, por su tamaño, podemos grabarlo directo a un llavero USB y usarlo como disco de arranque, lo cual nos libera de estar cargando nuestro CD a todos lados.
[imagen: stresslinux.png]
¿Y si el problema no está en el hardware, sino que en la red? Posiblemente estemos siendo víctimas de algún ataque de negación de servicio, de algún virus especialmente agresivo, o un atacante esté utilizando nuestros recursos para -¡horror!- atacar a terceros. Debemos tener las herramientas que nos permitan inspeccionar el tráfico en la red, analizar los patrones anómalos y aislar a los componentes hostiles. Un muy buen aliado para esto es Backtrack (http://www.remote-exploit.org/index.php/BackTrack), un verdadero arsenal para el auditor en seguridad, que nos permite no sólo buscar patrones hostiles en nuestra red, sino que encontrar qué equipos son vulnerables, permitiéndonos anticiparnos y prevenir otros posibles ataques.
[imagen: backtrack.png]
Como pueden ver, con este breve panorama describimos suficientes herramientas (y, claro, juguetes) para mantenernos ocupados más que un par de días. Hay muchas distribuciones vivas más, con todas las orientaciones que puedan imaginarse. Y todas sirven a la perfección, además, para disipar cualquier duda o miedo que podamos tener respecto a la conveniencia de usar Linux de manera cotidiana.

AttachmentSize
200701_pcmag_1.jpg107.37 KB
200701_pcmag_2.jpg113.38 KB
Texto original enviado para publicación11 KB

LyX: Para documentos

TitleLyX: Para documentos
Publication TypeMagazine Article
Year of Publication2007
AuthorsWolf G
MagazinePC Magazine en español
Date Published07/2007
Type of ArticleColumn
ISSN1665-4897
Keywordsevangelizacion, LaTeX, LyX, procesador de documentos, TeX
Full Text

Hay muchas áreas de las interfaces comunes con las que la mayor parte de los usuarios de computadoras trabaja a diario que damos por buenas simplemente por ser las más comunmente utilizadas, sin que necesariamente sean óptimas - y los procesadores de textos, una de las herramientas que más decididamente catapultaron la revolución de las computadoras personales.
¿Qué? ¿Este artículo pone en jaque la superiordad de una de las herramientas más comunes y más exitosas del mundo? En efecto. Y no me voy a limitar a recomendar una alternativa libre al procesador de textos más difundido del mundo Windows, Microsoft Word - A estas alturas, los lectores asiduos de la columna Linux de PC Magazine deben estar más que familiarizados con OpenOffice, Abiword o KWord. Seamos ambiciosos - Como siempre, en la Sección Linux presentaremos una alternativa a la manera tradicional de hacer las cosas. Hoy hablaremos acerca de LyX (http://www.lyx.org/), el procesador de documentos.
Comencemos por el principio: ¿Qué es LyX? ¿Qué lo diferencía de un procesador de textos? ¿Sobre qué base tecnológica está creado?
A mediados de los 70, el computólogo Donald Knuth descubrió, frustrado, que con la tecnología existente era imposible publicar con la calidad que él esperaba su ahora clásica serie de libros, "The Art of Computer Programming". En 1977, arrancó un proyecto que estimó que le llevaría parte de su año sabático en la universidad de Stanford: El lenguaje tipográfico TeX.
El proyecto no fue tan rápido ni sencillo como originalmente lo había previsto - El desarrollo duró más de diez años y se extendió con la ayuda de expertos en diversas áreas de la edición y tipografía de todo el mundo, terminó cubriendo muchas áreas a las que no preveía llegar originalmente, desde un lenguaje para la definición matemática de fonts (MetaFont) hasta un poderoso lenguaje de macros (LaTeX). Y si bien desde 1990 no ha habido cambios fundamentales al sistema TeX, ese no es más que el punto de partida de nuestro tema de este mes.
LaTeX es un sistema muy poderoso, apto para escribir desde simples notas, pero especialmente orientado a documentos complejos y largos, sobre los cuales se vuelve necesario aplicar un estilo consistente de principio a fin, y tal vez separarlos en diferentes archivos, como en el caso de libros donde diferentes autores escriben diferentes artículos. Sin embargo, escribir directamente en LaTeX comunmente espanta a los novatos, pues la definición de los elementos de un documento se debe indicar por medio de un lenguaje, como lo pueden observar en la primer captura de pantalla [IMAGEN: emacs_latex.png], y no es posible ver los resultados de inmediato, sino que tenemos que compilar nuestros textos fuente para poder ver el documento terminado. El lenguaje es simple de aprender (personalmente, lo aprendí siendo aún un niño en 1983), pero no tiene el grado de usabilidad al que estarás acostumbrados hoy en día. Un documento de LaTeX tiene un preámbulo que, si bien puede ser reducido, requiere que le declares -a través de comandos textuales- el tipo de documento que quieres escribir, y sólo no nos permite conocer cómo será el documento una vez terminado, sino que no puedes saber si tecleaste un comando equivocado sino hasta el momento de preparar una versión del documento terminado (de compilarlo). No es terrible, pero fácilmente cansa incluso a los usuarios novatos.
Hacia 1995, Matthias Ettrich inició un proyecto que proporciona a los usuarios la flexibilidad y potencia de LaTeX, y la sencillez de uso de un procesador de textos, LyX. Probablemente conozcas el nombre de Matthias gracias al otro importante proyecto que él inició: El entorno de escritorio KDE. LyX es básicamente una interfaz gráfica que nos permite trabajar con él como lo haríamos con un procesador de textos, y genera el código LaTeX adecuado para nuestros documentos.
Bueno, pero... ¿Cómo puede ser un sencillo programa como LyX superior a los procesadores de textos WYSIWYG ("What You See Is What You Get" - Lo que ves en pantalla es exactamente igual al resultado que obtendrás en papel)? ¿Cómo puede LyX retar a la interfaz de usuario que ha demostrado ser imprescindible en toda computadora? La respuesta inicia con que LyX parte de una filosofía diferente, a la que llama WYSIWYM ("What you see is what you mean" - Lo que ves en pantalla es lo que quieres que LyX y LaTeX hagan por tí). [IMAGENES: wysiwym.png y wysiwym-2.png] Como pueden apreciar en las capturas de pantalla, mientras escribes nuestro documento no tienes que preocuparnos por cosas triviales (cómo queda el acomodo de párrafos por página, si quieres aumentar el interlineaedo o tamaño de letra, si las secciones del documento van de determinado tamaño o en negritas, etc.) Basta con que nos concentrarte en generar el contenido del documento; todo lo relativo a cómo se va a ver cada uno de los componentes del mismo se lo puedes confiar a LaTeX.
Los actuales procesadores de textos evolucionaron para cubrir las necesidades del trabajo en las oficinas - podemos verlo claramente tan sólo porque todos ellos forman parte de una "suite de oficina" como OpenOffice, Microsoft Office, Gnome Office o KOffice. LaTeX, por el contrario, evolucionó de las necesidades de tipógrafos profesionales, y los programas resultantes nos lo hacen ver claramente: Aún cuando hace años ya es poco común ver las antiguas máquinas de escribir en la mayor parte de las oficinas, los procesadores de textos siguen trabajando con ese modelo en mente, mostrándonos una página sobre la cual podemos escribir directamente, y el estilo que elegimos para cada elemento del texto nos es retroalimentado visualmente de inmediato.
Cabe aquí anotar que, desde hace años ya, los principales procesadores de texto nos ofrecen también un marcado semántico de los párrafos (esto es, indicar la función de cada elemento, más que su apariencia), buscando llegar a la eficiencia que LyX nos brinda; pueden ver en las capturas de pantalla de AbiWord y OpenOffice [IMAGENES: esitlo_abiword.png y estilo_openoffice.png] dónde están ubicados tradicionalmente esos elementos. Sin embargo, aún teniendo esta herramienta a la mano, los usuarios están acostumbrados a la "interfaz máquina de escribir", a marcar un encabezado de sección como "18 puntos, negritas, Times New Roman"
Un procesador de documentos como LyX parte, en cambio, del tipo de trabajo que realizan los tipógrafos, en la cual partimos de que quien escribe el documento es el experto en el tema - pero no en la apariencia visual. Esto va mucho más allá de dictar que el usuario no debe elegir el tamaño o tipo de letra a utilizar para un título de artículo o de sección, sino que en detalles mucho más sutiles, que muchos de nosotros de otro modo ignoraríamos - Detalles tipográficos como el manejo de ligaturas, palabras o líneas viudas y huérfanas, tipos de comillas a utilizar, e incluso los diferentes tipos de espacio en blanco a dejar después de diferentes signos de puntuación. En pocas palabras, LaTeX se encarga de que nuestros documentos brillen por su tipografía. [IMAGEN: ligaturas.png]
LaTeX, y por tanto LyX, está orientado principalmente a trabajar con documentos largos. Está especialmente enfocado a facilitar el manejo de la estructura - Partes, capítulos, secciones y subsecciones; listas numeradas, listas simples, descripciones; etiquetas y referencias cruzadas, manejo de bibliografía, notas al pie; tablas de contenido generales, de figuras, índices de conceptos; y muy especialmente los elementos propios de libros y artículos científicos, como fórmulas, definiciones, citas, figuras, tablas, y un larguísimo etcétera. ¿Qué tienen todos estos elementos en común? Todos ellos son elementos estructurales de un documento. Claro, si requieres hacerlo, es posible especificar elementos de diseño directamente (por ejemplo, cambiar el tipo o tamaño de letra), pero la misma lógica general de uso del programa sugiere al usuario no boicotear a su propio trabajo haciendo esto.
Claro está, LyX no es el programa adecuado para todo tipo de documentos - Por ejemplo, si quieres diseñar un cartel o una invitación, seguramente querrás tener control completo del diseño de la página. El espacio en el cual LyX realmente brilla es en la preparación de documentos de varias páginas, con una estructura. ¡Y claro, cómo olvidarlo! con tablas de contenido, índices bibliográficos y demás elementos que, si bien en otros sistemas requieren de una fuerte cantidad de trabajo y mantenimiento, en LyX literalmente se vuelven cuestión de tres clicks.
Ahora bien, ¿cómo compartir el documento con terceros? Hoy en día sonaría anacrónico sugerirte que imprimas tu documento y se lo envíes físicamente a su destinatario, y obviamente, la mayor parte de los usuarios no cuentan con una instalación de LyX. ¿Qué hacer? Muy simple: Del mismo modo que LyX procesa un documento para imprimirlo, puede guardar ese documento en muy diversos formatos. Como primer ejemplo, seleccionando Archivo -> Exportar -> PDF, LyX nos genera un archivo PDF apto para que lo compartamos. Por otro lado, si quieres subir el documento a tu página Web, selecciona Archivo -> Exportar -> HTML, y se generará un árbol de páginas siguiendo la estructura de tu documento (no, no será una sóla página interminable, como resulta con otros productos).
En resumen: LyX es un sistema completamente diferente, que puede ayudarte a generar documentos con un grado de profesionalidad que poca gente puede lograr en un procesador de textos. He visto varios libros (incluso libros dedicados al arte de la correcta tipografía) que son impresos sin modificación alguna sobre de los estilos base de LaTeX. En este artículo me falta espacio para abundar en las virtudes de este programa, pero espero que con los puntos que les he mencionado sea suficiente para picarte la curiosidad acerca de una nueva manera de hacer el trabajo de todos los días.

Imagenes

  • emacs_latex.png: La edición directa de un documento en LaTeX (arriba) y el documento generado (abajo)
  • lyx_inicio.png: LyX nos da la bienvenida
  • wysiwym.png y wysiwym-2.png: Respectivamente, preparación y resultado final de un documento. Estas dos imagenes nos ilustran claramente qué significa WYSIWYM: Al no preocuparnos directamente por cómo queda el resultado final, escribir el documento no nos significa tanta distracción: Podemos concentrarnos en el contenido.
  • estilo_abiword.png y estilo_openoffice.png: Los procesadores de textos ahora presentan también la opción de edición por categorías semánticas y estilos - Sin embargo, al también presentar las tradicionales barras de tamaño, tipo y atributos de letra, la mayor parte de los usuarios no aprenden siquiera las bondades del marcado semántico.
  • ligaturas.png: Mostramos la edición en LyX en la parte superior, y el documento generado en la inferior. Como ejemplo de las sutilezas tipográficas que maneja LaTeX, puedes apreciar cómo varias letras se ligan en un sólo elemento al aparecer después de la 'f' - y cómo podemos "romper" estas ligaturas si así lo requerimos intercalándoles un elemento nulo
AttachmentSize
Texto original para publicación11.14 KB
200707_pcmag_1.jpg109.88 KB
200707_pcmag_2.jpg122.44 KB

Para mis documentos, movilidad y administración

TitlePara mis documentos, movilidad y administración
Publication TypeMagazine Article
Year of Publication2007
AuthorsWolf G
MagazinePC Magazine en español
Date Published06/2007
Type of ArticleColumn
ISSN1665-4897
Keywordscontrol de versiones, evangelizacion
Full Text

Hay más de una manera de abordar el tema de la movilidad - Podemos pensar, por un lado, en los dispositivos que nos permiten movernos junto con nuestra información (PDAs, teléfonos celulares cada vez más inteligentes, Tablet PCs, computadoras portátiles cada vez más compactas y potentes - Incluso la ya omnipresente "llave" USB es un dispositivo fundamental para la movilidad diaria), o por otro lado podemos referirnos a las aplicaciones que permiten que nuestros datos se muevan a donde nosotros vayamos, dándonos la posibilidad de asumir la movilidad como un hecho, aún si salimos de casa sin un sólo artículo electrónico - A fin de cuentas, lo que buscamos es no tener que acordarnos de nuestros datos, sino que saber que están resguardados y a nuestra disposición en todo momento que los necesitemos.
En esta ocasión voy a platicarles acerca de una herramienta que cambió mi vida como pocas lo han hecho, y se ha vuelto desde hace ya varios años mi fiel compañera a donde sea que yo viaje: Subversion (http://subversion.tigris.org/).
Antes de conocer a Subversion y herramientas similares, nos acostumbramos a ver a nuestros documentos como pedazos independientes de información. Cada archivo es un universo aparte, y cada vez que lo modificamos, en realidad nuestra computadora está creando un archivo nuevo que simplemente coloca en el lugar del anterior. Lo que es peor, ¿a quién no le ha pasado que sale de casa muy confiado con todos los archivos en la memoria USB... Tan sólo para toparse con que traemos una versión anterior de los archivos a la que nos tomó tantas horas de trabajo? O cuando somos varias personas trabajando en un proyecto grande, ¿cómo podemos trabajar cada cual a sus anchas sin el constante temor de estar pisoteando los cambios que hizo alguien más? Todos estos problemas los resuelven los diversos VCS (Version Control Systems, sistemas de control de versiones) - Y mi VCS favorito es Subversion.
Subversion opera bajo un esquema cliente-servidor - Debemos instalarlo en una computadora fija, que será el punto central, y podemos trabajar con él desde la cantidad que queramos de dispositivos fijos o móviles. Claro, podemos permitir el acceso a cuantos usuarios queramos, ya sea sólo para lectura o incluso con derecho a modificar la información.
Con Subversion, ya no vamos a hablar de nuestros documentos meramente como un conjunto no organizado de archivos - Manejaremos un depósito, que tiene -como un todo- diferentes versiones que nos permiten consultar "fotografías" de nuestro trabajo en el tiempo. Puede incluso llevar ramas y etiquetas. Las diferentes ramas, claro, pueden bifurcarse o unirse cuando lo juzguemos necesario. ¿Qué significan todos estos conceptos?

Depósito
El directorio que contiene a todos los archivos relacionados, así como la información interna de Subversion para manejarlos
Documento
Cada uno de los archivos que existen dentro de nuestro depósito, independientemente del tipo de archivo de que se trate.
Versión
Siempre que hacemos un cambio a nuestro depósito, aumentará el número de versión del depósito completo. Esto nos permite ver, por ejemplo, cómo estaba nuestro proyecto completo en determinada fecha, o qué archivos fueron modificados ese fatídico día en que no nos tomamos nuestra taza matutina de café.
Rama
Muchas veces se nos presenta la disyuntiva de qué dirección tomar en un proyecto - Al crear una rama (o, siguiendo el argot del sistema, al bifurcar un proyecto), con Subversion no sacrificamos a una posible salida por otra. Podemos continuar desarrollando en ambos sentidos, y posteriormente evaluar los resultados para volver a unificar las ramas.
Etiqueta
Cuando llegamos a un punto importante en un proyecto, es importante marcar a nuestro depósito con una etiqueta - De este modo, podemos rápidamente volver a exactamente esa versión sin tener que estarla buscando.

¿Cómo se usa? Es muy sencillo - Lo mejor es que la mayor parte del tiempo simplemente trabajaremos como si no estuviera ahí. Sólo debemos recordar tres reglas: Actualizar nuestra copia local al inicio de toda sesión de trabajo, y "empujar" los cambios al servidor tan pronto estén listos. La manera más simple de hacer esto es por medio del cliente de línea de comando, por medio respectivamente de las órdenes "svn update" y "svn commit" - Pero, claro, no es la única manera.
Un componente muy interesante de los sistemas de control de versiones es el de búsqueda de diferencias - ¿Qué archivos modificamos en nuestro depósito en determinado periodo? Y lo que es más, ¿Qué cambios hicimos en ellos? Subversion nos facilita esta información de un sólo golpe, como podemos apreciar en las imágenes que acompañan al artículo. Claro está, toda herramienta tiene su un nicho para el cual funciona de forma óptima; notarán que para utilizar la funcionalidad de comparación entre versiones, los archivos que maneje Subversion deben ser basados en texto - Nuestras páginas Web escritas en HTML, documentos XML, los programas que escribamos en nuestro lenguaje favorito - Obviamente, Subversion no está diseñado para mostrarnos las diferencias entre dos imágenes o entre dos hojas de cálculo.
Uno de los puntos más importantes de su desarrollo es que, más allá de ser sencillamente una aplicación completa y cerrada, Subversion sigue claramente las directrices de diseño en el software libre: Está diseñado como un conjunto de bibliotecas, pensado para ser embebido en programas que puedan aprovechar su potencial y presentarlo de una forma unificada y adecuada para sus usuarios - Hay muy diferentes programas cliente que, utilizando el mismo código (y, por tanto, sin tenernos que preocupar acerca de su interoperabilidad) nos permiten tener acceso a toda la funcionalidad de Subversion.
El primer cliente con el que nos encontraremos, y el más conveniente para consultas cortas y rápidas, es el de línea de comando. Nos permite hacer rápidamente actualizaciones, envíos y comparaciones simples entre versiones - Sí, tendrás que aprenderte unos cuantos comanditos, pero verás que es, en muchas ocasiones, la manera más fácil y rápida de obtener información.
El poderoso y veterano entorno de desarrollo Emacs incluye un modo de trabajo que nos permite manejar la mayor parte de las funciones de Subversion. Podemos ver en la captura de pantalla una sesión típica.
Emacs no es el único entorno de desarrollo que ofrece integración con Subversion. Eric (http://www.die-offenbachs.de/detlev/eric.html), el IDE de Python, ofrece una interfaz muy limpia, pulida y amigable. Podemos también instalar Subclipse (http://subclipse.tigris.org/) para integrarlo a Eclipse, un robusto y completo IDE libre orientado a Java.
Pero incluso si lo tuyo es trabajar con herramientas más tradicionales, que no incluyan aún soporte para Subversion, hay clientes sencillos y completos que se encargarán de mantener nuestros archivos en el depósito. Uno de los más cómodos en Linux es eSvn (http://esvn.umputun.com/). Desde MacOS, svnX (http://www.lachoseinteractive.net/en/community/subversion/svnx/features/) es el que mejor integración nos ofrece con el entorno de Panther.
En Windows, la alternativa más cómoda y completa es TortoiseSVN (http://tortoisesvn.net/), una extensión al explorador del sistema que nos permite administrar nuestros depósitos con toda la naturalidad con que normalmente trabajamos. Además de esto, TortoiseSVN nos proporciona cómodas herramientas para entender de una sóla mirada cómo ha ido avanzando nuestro proyecto, con sus ramas y etiquetas, o las estadísticas de actividad de cada uno de los participantes. Una de las herramientas hermanas de TortoiseSVN nos permite dar, además de todo esto, un importante paso adelante - Con TortoiseDiff (http://tortoisesvn.tigris.org/TortoiseIDiff.html) podemos ver las diferencias de manera intuitiva, incluso entre archivos de contenido binario como las imágenes.
¿Suena ya demasiado bueno para ser cierto? ¡Pero si eso no es todo! Podemos también interactuar con Subversion utilizando simplemente un navegador Web - Y en esta categoría me limitaré a mencionar a algunos de los proyectos más conocidos, como WebSvn (http://websvn.tigris.org/), Insurrection (http://insurrection.tigris.org/) o Chora
(http://www.horde.org/chora/); su uso es bastante similar, y elegirás uno u otro dependiendo de las otras herramientas que emplees para trabajar en tu proyecto.
Subversion implementa un esquema de trabajo tremendamente potente, y al poco tiempo de que comiences a usarlo, te costará trabajo voltear atrás y entender cómo viviste sin él hasta ahora. Es, además, un proyecto excelentemente documentado - Tenemos a nuestra disposición hasta libros completos disponibles en línea detallando su diseño y funcionamiento. Si te interesa estudiarlo a fondo, te recomiendo el libro oficial, "Version Control with Subversion", que está disponible libremente en http://svnbook.red-bean.com/

Imagenes

  • desde_consola.png: Desde consola podemos realizar las operaciones más comunes de manera rápida y sencilla, con sólo aprender un par de comandos
  • emacs.png: El poderoso entorno Emacs incluye un modo para el manejo de proyectos en Subversion
  • eric_diff.png: Mostrando las diferencias entre dos versiones de un depósito, desde Eric, un IDE libre para el desarrollo en Python
  • esvn_diff.png: Mostrando las diferencias entre dos versiones de un depósito, desde eSVN, un cliente de Subversion gráfico y ligero
  • tortoisesvn_arbol.png: TortoiseSVN nos proporciona excelente integración de SVN dentro de un entorno Windows
  • chora.png: Viendo los cambios en uno de nuestros archivos desde Chora, un cliente Web de Subversion
  • insurrection.png: Revisando la bitácora de cambios desde Insurrection, un cliente Web de Subversion
AttachmentSize
Texto original para publicación9.84 KB

2008

Columnas publicadas en 2008

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

TitleCoordinación de esfuerzos en grupos de desarrollo e integración de Software Libre
Publication TypeMagazine Article
Year of Publication2008
AuthorsWolf G
MagazineSoftware Gurú
FrequencyQuarterly
Issue Number21
Pagination62-63
Date Published08/2008
Type of ArticleColumn
ISSN1870-0888
Keywordscomunidad, organización, Software libre
Full Text

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 [1] - Perl [2] 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 [3] (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 [4] y un sistema de organización, búsqueda y consulta de la documentación de dichos módulos [5].
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 [6] 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 [7] 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 [8], 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 [9], 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 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 Hermann, de Austria, y Damyan Ivanov, de Bulgaria) hemos creado un script [10] 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.
LIGAS:
[1] Debian GNU/Linux: http://www.debian.org/
[2] Perl: http://www.perl.com/
[3] CPAN (Comprehensive Perl Archive Network): http://www.cpan.org/
[4] Sistema de seguimiento de fallos del CPAN: https://rt.cpan.org/
[5] Sistema de búsqueda y consulta de documentación del CPAN,
http://search.cpan.org/
[6] Grupo de empaquetamiento de módulos de Perl para Debian:
http://pkg-perl.alioth.debian.org/
[7] Sistema de seguimiento de fallos de Debian:
http://bugs.debian.org/
[8] Alioth, sistema de desarrollo y coordinación de proyectos,
http://alioth.debian.org/
[9] Base del depósito Subversion del grupo pkg-perl,
http://svn.debian.org/wsvn/pkg-perl/
[10] Resumen de estado de los paquetes de Perl en Debian
http://pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi

AttachmentSize
200808_softwareguru_1.jpg819.2 KB
200808_softwareguru_2.jpg3.07 MB

La metaprogramación y los lenguajes dinámicos

TitleLa metaprogramación y los lenguajes dinámicos
Publication TypeWeb Article
Year of Publication2008
AuthorsWolf G
Access Date2009/03/27
KeywordsMetaprogramación, programación, Ruby
Abstract

La metaprogramación es una técnica muy poderosa, y muy socorrida en el terreno de los lenguajes dinámicos. Puede llevarnos a reducir muy fuertemente el total de código que escribimos - Y lo que es mucho más importante, a minimizar la cantidad de código repetido innecesariamente. Nos lleva claramente a aumentar la calidad y mantenibilidad de nuestro código.

URLhttp://www.sg.com.mx/content/view/718/1/
Full Text

La metaprogramación es una técnica muy poderosa, y muy socorrida en el terreno de los lenguajes dinámicos. Puede llevarnos a reducir muy fuertemente el total de código que escribimos - Y lo que es mucho más importante, a minimizar la cantidad de código repetido innecesariamente. Nos lleva claramente a aumentar la calidad y mantenibilidad de nuestro código.

Programas que escriben programas

La metaprogramación consiste en escribir código que no ataca directamente al dominio del problema que queremos atacar, sino que al código que lo resolvería. Dicho sea de otro modo, el código que escribimos no modifica los datos o el estado de nuestra información, sino que el del programa.

Las ventajas de los lenguajes dinámicos

La metaprogramación no es una nueva idea - Nació hace ya más de 40 años, con el lenguaje Lisp, y se popularizó tremendamente en el lenguaje Smalltalk, a principios de los 80.
Ambos lenguajes fueron revolucionarios en diversos aspectos, y si no gozan hoy en dí­a de mayor popularidad, se debe a que, en sus implementaciones originales sufrí­an de problemas de rendimiento en el hardware de su época. Sin embargo, sus ideas básicas han servido para conformar a una gran cantidad de lenguajes que han ido adquiriendo una cada vez mayor popularidad y aceptación: Los lenguajes dinámicos.
Podemos categorizar a un lenguaje de dinámico cuando no requiere de ciclos determinados y claramente separados de compilación y ejecución. Mucha gente cree erróneamente que los lenguajes dinámicos (por ejemplo, Perl, Ruby, Python o PHP, ampliamente utilizados en el mundo del Software Libre) son interpretados - La realidad es completamente distinta, son lenguajes que cuentan con compiladores tremendamente eficientes, que en fracciones de segundo pueden convertir decenas de miles de ­líneas de código en una representación binaria (bytecode para sus respectivas máquinas virtuales).
La caracterí­stica definitoria de estos lenguajes como dinámicos no es el compilador ágil (aunque, claro está, lo requieren) - Es la presencia de la instrucción (o familia de instrucciones) «eval». En resumidas cuentas, eval recibe un parámetro, tí­picamente una cadena, y lo evalúa como código fuente - Como una primer probadita de metaprogramación, consideren el siguiente código de Ruby:

  1. def crea_clase(nombre, clase_padre)
  2. eval "class #{nombre} < #{clase_padre} ; end"
  3. end

Al invocar a este método -claro está, en tiempo de ejecución- puedo ampliar la jerarquí­a de clases existente. Por ejemplo, si quiero definir suficientes clases para representar los muebles de una oficina, podrí­a decirle a Ruby:

  1. ['Mesa', 'Silla', 'Archivero', 'Librero'].each do |tipo|
  2. crea_clase(tipo, 'Mueble')
  3. end

Obviamente, la lista de objetos no necesariamente la tengo representada en mi código fuente - puede ser proporcionada por el usuario o determinada a partir del entorno de ejecución. Y a partir de este punto, para todos los propósitos de nuestro código, sería como si en tiempo de compilación hubiéramos incluido explí­citamente en el código:

  1. class Mesa < Mueble; end
  2. class Silla < Mueble; end
  3. class Archivero < Mueble; end
  4. class Librero < Mueble; end

Pero esto va mucho más allá de una manera cómoda y reducida de especificar clases.
Lenguajes específicos de dominio
A partir del número noviembre-diciembre de 2007 de SoftwareGurú hemos recibido entregas del tutorial de Ruby on Rails escrito por Carlos Ortega. Cuando nos acercamos por primera vez a Rails, lo primero que encontramos es una serie de declaraciones que no pertenecen a Ruby, y aparentan un estilo de programación declarativo. Por ejemplo, al definir un modelo:

  1. class Person < ActiveRecord::Base
  2. validates_presence_of :name
  3. validates_numericality_of :age, :greater_than => 0, :less_than => 100
  4. end

ActiveRecord es el ORM de Ruby on Rails - presenta una abstracción de los datos en las tablas de la base de datos, dándoles una interfaz natural orientada a objetos. El módulo ActiveRecord::Validations::ClassMethods extiende al lenguaje a través de la metaprogramación, y expone una serie de validadores, que presentan una sintaxis natural de escribir y fácil de leer - Un lenguaje especí­fico al dominio de las validaciones.

Reflectividad

La mayor parte de los lenguajes dinámicos son también reflectivos. Los objetos (y, recuerden, en los lenguajes completamente orientados a objetos, todo es un objeto - Incluyendo las clases, no sólo los objetos instanciados) pueden ser interrogados respecto a los métodos que ofrecen. Un ejemplo simple que muestra el poder combinado de la reflectividad junto con la metaprogramación es este simple rastreador universal:

  1. def trace(obj)
  2. obj.methods.each do |meth|
  3. eval "def obj.#{meth}(*args)
  4. warn 'Llamando al método #{meth} en #{obj.class}'
  5. super(*args)
  6. end"
  7.  
  8. end
  9. end

Basta llamar a nuestra función «trace» con cualquier objeto del sistema para que nos muestre un rastreo completo de cada una de las acciones que éste realice. Por ejemplo (desde la consola interactiva de Ruby):

  1. >> p = Person.find(:first)
  2.  
  3. >> trace(p)
  4. >> p.name
  5. Llamando al método method_missing en Person
  6. Llamando al método class en Person
  7. Llamando al método class en Person
  8. Llamando al método class en Person
  9.  
  10. Llamando al método send en Person
  11. => "Fulano D. Tal"

Aquí podemos encontrar cómo es que incluso la misma clase Person (que no es otra que la que declaramos hace algunas líneas) recibe sus métodos: ¡A través de la reflexibilidad, preguntándole a la base de datos acerca de su propia estructura!
El espacio no permite, tristemente, dar más ejemplos de cómo podemos explotar estas técnicas - Pero espero que con esta sencilla muestra puedan comprender la riqueza que esta técnica nos proporciona, y lo conciso que puede hacer a nuestro código.

AttachmentSize
200805_softwareguru_1.jpg496.65 KB
200805_softwareguru_2.jpg469.31 KB
200805_softwareguru_3.jpg145.62 KB

¿Cómo enseñar a los programadores del futuro?

Title¿Cómo enseñar a los programadores del futuro?
Publication TypeMagazine Article
Year of Publication2008
AuthorsWolf G
MagazineSoftware Gurú
Issue Number22
Pagination64
Date Published11/2008
Type of ArticleColumn
ISSN1870-0888
Keywordsautodidacta, enseñanza, motivación, paradigmas
Full Text

Nuestro gremio se caracteriza por conformarse por dos principales perfiles: Autodidactas y escolarizados. Esto obedece en no pequeña medida a que el campo es aún novedoso, y es aún posible para un aficionado ir obteniendo de manera gradual e independiente los conocimientos necesarios para llegar a un nivel de competencia comparable con quien estudió una carrera formalmente.
El programador autodidacta típicamente es un miembro muy valioso del equipo de desarrollo, dado que llegó a acumular sus conocimientos -teóricos y prácticos- por interés y motivación propia. Si bien es común que su formación muestre importantes "agujeros" cognitivos, especialmente en aquellos campos que requieren mayor rigor teórico/matemático, o sencillamente en aquellos por donde el interés no lo llevó, comunmente los subsanará tan pronto se enfrente a situaciones que los requieran. Sin embargo, es digno de mención que justamente es en las áreas más teóricas y aparentemente áridas del cómputo donde hay una mayor proporción de profesionales con éste
perfil.
No puede ser casualidad que dentro de los desarrolladores de Software Libre haya una tan alta proporción de autodidactas, gente formada en otras disciplinas y que ha ido encontrando su nicho de interés y trabajo en el cómputo, encontrando en la creación de herramientas que cubran sus necesidades particulares una nueva vocación.
Podríamos dedicar un muy amplio espacio a analizar la relación entre el conocimiento adquirido formal e informalmente, y en cómo insertar a estos en un esquema académicamente más formal... Pero el tema del que quiero ocuparme en esta ocasión es de quien viene de una enseñanza escolarizada.
¿Cómo transmitir el conocimiento, el interés, el entusiasmo, a los programadores escolarizados, para que alcancen un nivel de habilidad similar al de los autodidactas? Para esto, es fundamental que nos preguntemos, ¿qué y cómo enseñan a sus alumnos las universidades en nuestro país en cada una de las opciones de formación profesional relacionadas con el cómputo? ¿Qué perfiles reales de egreso hay de cada una de estas carreras (desde la muy aterrizada Licenciatura en Informática Administrativa, pasando por las muy variadas Ingenierías, con perfiles orientados más hacia Sistemas, Electrónica u otras variantes, y hasta el purismo teórico de las Ciencias de la Computación)? ¿Y cómo explicamos que, a la hora de buscar un trabajo, tan frecuentemente todos son puestos dentro de la misma gran bolsa?
El primer gran obstáculo al que creo todos los programas académicos deben reaccionar es a que muchos alumnos sienten que programar es una tarea tediosa, un rol que se verán forzado a desempeñar durante los primeros años de su trabajo, en lo que logra un ascenso a un puesto de "responsabilidad". Esto es, en buena medida, por lo torpe que resulta la enseñanza de los conceptos y habilidades básicos de la programación.
Hay dos escuelas básicas: Comenzar enseñando programación utilizando un lenguaje mínimo aunque completo, apto para transmitir los rudimentos de la estructura y el control de flujo (al estilo de C o del venerable Pascal). En contraposición a ellos, muchos otros académicos defienden comenzar enseñando con un paradigma completamente POO, con lenguajes como Java o como C#. Y ambas alternativas nos dejan importantes huecos por llenar.
Para alguien que inició con lenguajes de muy alto nivel, resulta más dificil comprender la traducción a código de más bajo nivel y la implementación en hardware del mismo, especialmente lo relativo a administración de memoria y el órden de complejidad; en este sentido, una de las más brillantes exposiciones la hace Ulrich Drepper, en su detallado y muy recomendable texto "What Every Programmer Should Know About Memory" [1]. Para todas las aplicaciones que corren "cerca del metal", como desarrollos de sistemas tiempo real, embebidos, controladores de hardware o software orientado al alto rendimiento, es fundamental dominar estos temas.
Por otro lado, para los programadores que parten de un entorno meramente procedimental, la POO se presenta como una complejidad adicional, como un obstáculo para la manera que ya tienen -y ya conocen- de soluciónar los problemas.
Si bien la discusión académica respecto a estas dos escuelas está tan viva como cuando se planteó por primera vez hace más de 20 años (p.ej. [2] y sus respuestas en [3]), creo yo que el problema de la motivación reside en no enfocarnos en lenguajes y marcos /simples/ (sin ser de juguete), que no permiten al alumno experimentar la /gratificación instantánea/ de lograr resultados atractivos tras apenas un primer acercamiento. Los lenguajes denominados /de scripts/ (Python, Ruby, Perl, y un largo etcétera) deben, claro, ser enseñados de otra manera, mucho más gradual, pero sin duda ayudan a mantener alta la motivación y baja la frustración.
Pero... ¿No son lenguajes con relativamente baja penetración corporativa? Así es, y eso representa otra ventaja - Una de las principales cualificaciones de un programador debe ser la capacidad de aprender tecnologías nuevas. Al enseñar con herramientas distintas, ayudamos a que los alumnos desarrollen la importante habilidad de /aprender a aprender/, no encasillarse en una herramienta. ¡Que se hagan del hábito de aprender nuevos lenguajes para diferentes retos!
[1] "What Every Programmer Should Know About Memory", Ulrich Drepper,
Red Hat, noviembre 2007,
http://people.redhat.com/drepper/cpumemory.pdf
[2] "Just say 'A Class Defines a Data Type'", Chenglie Hu,
Communications of the ACM vol. 51 No. 3, marzo 2008,
http://mags.acm.org/communications/200803/
[3] "Forum" (respuestas de los lectores), Peter Froehlich, Jack Cain,
Chuhg-Chih Li, Mark Hanna, Communications of the ACM vol. 51
No. 5, mayo 2008, http://mags.acm.org/communications/200805/

AttachmentSize
200811_softwareguru.jpg284.52 KB

¿Y por qué cambiar?

Title¿Y por qué cambiar?
Publication TypeMagazine Article
Year of Publication2008
AuthorsWolf G
MagazinePC Magazine en español
Date Published04/2008
Type of ArticleInterview
ISSN1665-4897
Keywordsevangelizacion, motivación, Software libre
Full Text

Tiene más de diez años que dí el brinco y migré a Linux - Ya no sólo como mi entorno primario, sino como el único sistema operativo que tengo instalado en cualquiera de mis computadoras.
En 1997, obviamente, hacer esto no estaba exento de problemas o retos. Yo soy del grupo de usuarios que decidieron migrar en primer término por razones ideológicas, a partir de la convicción de que el Software Libre es superior moralmente a cualquier sistema propietario, como Windows o MacOS.
Claro, ya desde hace diez años -e incluso para los más convencidos- era muy importante el argumento de la calidad y la estabilidad. Linux -heredero de la familia de sistemas operativos Unix y más de 35 años de historia- mantuvo desde sus humildes principios al ser desarrollado en la computadora personal de un estudiante finlandés de posgrado la que posiblemente aún hoy es su principal característica: La modularidad. Una computadora que corre con Linux tiene siempre en ejecución a cientos de pequeños programas, cada uno de ellos altamente especializado y de propósito claramente limitado, pero orientados a la integración - con interfaces públicas claras y bien documentadas. ¿Qué significa esto?
Todos los programas que utilizamos son, obviamente, escritos por seres humanos. Por más talentoso que sea un programador, no queda exento de equivocaciones. Estas son, sin entrar en demasiados detalles, las que llevan a errores en el comportamiento de nuestros programas. La gran ventaja, pues, que tienen los sistemas operativos tipo Unix es que, al ser tan modulares, no sólo nos es muchísimo más fácil localizar qué es lo que causa determinado fallo, sino ayudan a asegurar que, una vez corregido éste, su impacto será el menor posible. Esta es una de las grandes razones por las que el entorno GNU/Linux, incluso en su infancia (en que era desarrollado meramente como hobby, no tenía detrás a todas las empresas que hoy en día lo impulsan), fuera claramente más confiable para aplicaciones de servidor que Windows, que cuenta con la empresa de software más grande del mundo.
Desde 1997, claro, ya hemos avanzado muchísimo: Hoy en día hay gente que comienza a usar programas libres (como los reseñados en esta revista) o se muda por completo a Linux ya no sólo por ideología o por ganas de aprender, sino porque el entorno es más atractivo, estético, funcional o incluso compatible con su forma de trabajo - ¡sí! Hoy en día, programas como OpenOffice o Gimp son compatibles con una gama de formatos mucho más amplia que sus contrapartes propietarias, y sus interfaces de usuario se han vuelto más intuitivas que las últimas versiones de la competencia, sobre-cargada de funcionalidad rara vez utilizada.
Otra ventaja central de Linux es que es Software Libre - Y no, con esto no me refiero a que Linux sea gratuito (aunque típicamente lo sea, hay una industria muy importante construída alrededor del Software Libre). Si bien al día de hoy tengo más de diez años con Linux, tengo más de 25 como usuario frecuente de computadoras.
Me inicié aún con las "minicomputadoras" de principios de los 80, con decenas de terminales, y me tocó vivir y aprender la época de las Apple II y de las Commodore 64, las primeras PC... Y si bien todas ellas brindaban conocimiento y experiencias importantísimas para todo quien, como yo, a la postre se dedicaría al cómputo como actividad profesional, siempre partían de la lógica de que había un núcleo operativo cerrado, casi sagrado, que La Empresa (fuera en este caso Apple, Commodore, IBM o Microsoft) nos daba, sobre del cual podríamos construir. Con el software libre, sin embargo, lo que recibimos es una invitación a asomarnos a cada uno de los componentes del sistema - Una invitación con toda la documentación necesaria, con todas las herramientas de desarrollo y depuración para lograrlo.
La diferencia es tremenda: Un usuario de Linux con algo de curiosidad científica no se enfrenta a la "magia negra" de cómo funciona el sistema, y no acepta el argumento de que "la computadora no quiere" o que "la computadora está lenta". Un usuario de Linux, con el paso del tiempo, va comprendiendo las funciones y relaciones entre los componentes del sistema, y se vuelve capaz de corregir un problema. No sólo eso; a través de todo tipo de foros de intercambio, podemos participar en el desarrollo, mantenimiento o soporte de todos esos programas que tanto nos han dado.
Entonces, en resumen... ¿Por qué me mudé al Software Libre, y por qué sigo ahí? Porque me dio herramientas indispensables para ser un usuario más feliz, más profesional - y una mejor persona, miembro activo de una comunidad que me ha dado todo lo necesario para mi desarrollo profesional.

AttachmentSize
Texto original para publicación4.71 KB
200804_pcmag_1.jpg229.25 KB
200804_pcmag_2.jpg299.04 KB

2009

Columnas publicadas en 2009

La seguridad en cómputo: ¿Con qué se come?

TitleLa seguridad en cómputo: ¿Con qué se come?
Publication TypeMagazine Article
Year of Publication2009
AuthorsWolf G
MagazineSoftware Gurú
FrequencyQuarterly
Issue Number23
Pagination47
Date Published02/2009
Type of ArticleColumn
ISSN1870-0888
KeywordsSeguridad
URLhttp://www.sg.com.mx/content/view/825
Full Text

La evolución del rol que cumplen los sistemas en las organizaciones ha cambiado por completo -afortunadamente- el punto de vista que la mayor parte de los desarrolladores tiene con respecto a la seguridad.
Hace una o dos décadas, el tema de la seguridad en cómputo era frecuentemente evitado. Y hasta cierto punto, esto era muy justificable: ¿Intrusos? ¿Integridad? ¿Validaciones? En la década de los 80 había muy poco software diseñado para su operación en red, y mucho menos para la idea de red que tenemos hoy en día. Y si bien es cierto que la mayor parte de los ataques se origina -y siempre se ha originado- dentro del perímetro de confianza de nuestra organización, hace 20 años sencillamente había menos información sensible alojada en medios electrónicos, menos gente con el conocimiento necesario para manipularla, e incluso la manipulación tenía efectos más nocivos: Si bien hace años la infraestructura de cómputo era el soporte facilitador, la copia maestra estaba en papel - Hoy en día estamos transitando hacia la situación opuesta, en que la versión electrónica es la primaria. Hoy, una intrusión en nuestros sistemas puede poner en jaque la integridad de la información primaria.
Mantener la seguridad en los sistemas que desarrollamos implica un alto costo: Los programadores tienen que aprender a evitar errores comunes; tenemos que concientizarnos y acostumbrarnos a dedicar recursos a implementar baterías de pruebas; tienen que entrar en juego validaciones y conversiones sobre los datos que manipulamos, con costos en tiempos de procesamiento de cada solicitud... Pero, afortunadamente, ha crecido también la conciencia de la importancia de destinar a la seguridad la atención y recursos que requiere.
El problema sigue siendo, coloquialmente... /¿con qué se come?/ La seguridad en cómputo sigue siendo un campo dificil de entender, con muchas aristas ocultas. Es por esto que, en las siguientes ediciones de SoftwareGurú, iré abordando algunos temas fundamentales en esta columna.
Para iniciar con esta serie, ataquemos lo fundamental: ¿Qué debemos entender por seguridad en cómputo?
A riesgo de que parezca que me limito a perogrulladas, un /sistema seguro/ es sencillamente un sistema /que responde como debe/. Claro, a esta pregunta hay que verla a la luz de varios criterios para que en verdad signifique algo. Intentemos nuevamente. Un sistema seguro presenta:

Consistencia:
Ante las mismas circunstancias, debe presentar el mismo comportamiento. Ante un sistema /seguro/, el tradicional remedio "¿ya intentaste reniciarlo?" no surte efecto. Si nos hemos acostumbrado a que un reinicio resuelve las cosas, no es sino porque el ambiente de ejecución se ensucia con elementos que debería haber descartado.
Protección y separación:
Los datos, instrucciones y espacio de memoria de un programa, componente o usuario no deben interferir ni permitir interferencia de otros. Las condiciones anormales ocurridas en uno de los componentes -sean accidentales o expresas- deben tener un impacto mínimo en el sistema como un conjunto.
Autenticación:
El sistema debe poseer los mecanismos necesarios para asegurarse que un usuario es realmente quien dice ser
Control de acceso:
Nuestro sistema debe poder controlar con toda la granularidad necesaria los permisos de acceso a sus datos - Quién tiene acceso a qué recursos, y qué tipo de acceso tiene.
Auditoría:
El sistema debe ser capaz de registrar, así como de notificar a quien sea necesario de cualquier anomalía o evento importante.

Claro está, todos estos atributos deben ir matizados, priorizándolos al nivel /adecuado/ a nuestras necesidades. Ir demasiado lejos en uno de estos objetivos puede ser de hecho perjudicial para los fines de nuestro sistema - Por poner un ejemplo, es de todos bien conocido que el tradicional esquema de autenticación basado en usuario y contraseña es fácil de engañar; basta adivinar (o conseguir) un pedazo de información, típicamente de muy débil complejidad, para estar autenticado como determinado usuario. En México, los bancos -por poner un ejemplo- ahora exigen la identificación del cliente a través de dispositivos que presenten una mucho mayor complejidad, generando cadenas de números que cambian periódicamente. Pero, obviamente, poca gente requerirá un nivel de seguridad similar a éste, o basado en parámetros biométricos, para abrir su cuenta de correo.
Y otra anotación: Nos es natural aspirar a la perfección, al 100%. Sin embargo, dice el refrán que "lo perfecto es enemigo de lo bueno". Es importante que, en toda etapa de la planeación, desarrollo, implantación y tiempo de vida de un sistema recordemos que un 100% de seguridad es una utopía, un objetivo que sólo puede servir para guiar nuestro trabajo diario.
Los programas son escritos por humanos, y son también humanos quienes administran los sistemas en que corren. Hay una gran cantidad de interacciones entre los elementos de un programa y el sistema, y un cambio en cualquiera de ellos puede tener consecuencias inesperadas si no se hace con cuidado y conciencia. Constantemente aparecen nuevas categorías de errores capaces de llevar a problemas de seguridad. Parte fundamental de nuestra actuación como profesionales en nuestro campo debe ser el mantenernos al día con los últimos desarrollos y las últimas amenazas.
Un par de días antes de la entrega de esta columna, dos de las organizaciones más influyentes en la investigación y respuesta a incidentes de seguridad informática, SANS y MITRE, publicaron su lista de los 25 errores de seguridad más importantes:
http://www.sans.org/top25errors/
Este listado incluye muchos temas de fundamental relevancia, algunos de los cuales abordaré en mis posteriores columnas. Vienen explicados con un buen nivel de detalle, detallando cómo evitar o mitigar sus efectos. Les recomiendo fuertemente familiarizarse con estos temas.

AttachmentSize
200902_softwareguru.jpg598.21 KB

Evitando las Inyecciones de SQL

TitleEvitando las Inyecciones de SQL
Publication TypeMagazine Article
Year of Publication2009
AuthorsWolf G
MagazineSoftware Gurú
FrequencyQuarterly
Issue Number24
Pagination50-51
Date Published05/2009
Type of ArticleColumn
ISSN1870-0888
Keywordsinyección, Seguridad, SQL
URLhttp://www.sg.com.mx/content/view/874
Full Text

En la edición anterior de SoftwareGurú prometí que en esta columna trataría temas relativos a la seguridad en cómputo, a cómo escribir código más confiable y más robusto.
Las vulnerabilidades más comunes son también las más fáciles de explotar para un atacante - Y utilizando algunas prácticas base, son también las más fáciles de evitar o corregir: Casi todas ellas se originan en la falta de validación (o exceso de confianza) en los datos que nos proporciona el usuario.
Prácticamente la totalidad de los sistemas que desarrollemos procesarán datos provenientes de terceros. Ya sea mostrando o grabando lo expresado en formas HTML, determinando el flujo de nuestra aplicación a través de rutas y parámetros o «galletas» HTTP, o incluso -considerando la tendencia de migración hacia un esquema de «cloud computing»- tomando resultados de procedimientos remotos en sistemas no controlados por nosotros, a cada paso debemos emplear datos en los que no confiamos.
Esta puerta de entrada permite a un atacante una amplia variedad de modalidades de intrusión. En general, podemos hablar de ellas como inyección de código interpretado - Y en esta ocasión hablaremos específicamente de inyección de SQL.
En el desarrollo de sistemas debemos partir siempre del principio de mínima confianza: No debemos confiar en ningún dato proveniente de fuera de nuestro sistema, independientemente de quién sea el usuario. Esto es especialmente importante cuando requerimos que un elemento cruce entre las principales barreras de las diversas capas de nuestro sistema.
Tomemos como primer ejemplo al sistema de gestión de contenido que usa SoftwareGurú. Si quisieran leer la edición anterior de esta columna, a la que hice referencia hace algunas líneas, pueden encontrarla en:
http://www.sg.com.mx/content/view/825
Todos hemos analizado URLs, y resultará obvio que «825» corresponda al ID de la nota en la base de datos, y que los componentes «content» y «view» indiquen la operación que el sistema debe realizar ante una solicitud. Ahora bien, ¿a qué me refiero a que cruzamos las barreras entre las capas? ¿Y cuáles son las principales?
Enfoquémonos en el ID. Al analizar el URL, el ID es un pedazo de texto (formalmente es una cadena que es recibida como parte del método GET, uno de los métodos definidos para el protocolo HTTP). El servidor Web Apache que recibe mi solicitud interpreta este método GET y encuentra -utilizando mod_rewrite, indicado por el archivo htaccess- que el contenido indicado por la ruta /content/view/* debe ser procesado por el archivo index.php, que a su vez es manejado por el lenguaje PHP. El archivo index.php corresponde en este caso al sistema Joomla, que reconoce la ruta, convierte al ID en su representación numérica y lo utiliza para pedir a la base de datos le entregue los datos relacionados con determinado artículo. Entonces, aquí podemos reconocer los siguientes puntos principales de manipulación de la solicitud:

  • Apache recibe una solicitud HTTP, y (via mod_rewrite) la reescribe, indicando «content», «view» y «825» como parámetros a index.php
  • PHP analiza, separa y estructura los parámetros recibidos para ser utilizados por Joomla
  • Joomla solicita el artículo 825 a la base de datos

La variabilidad de los primeros pasos es en realidad menor - Pero al solicitar a la base de datos el artículo «825» (y este es el caso base, el más sencillo de todos) deben pasar muchas cosas. Primero que nada, «825» es una cadena de caracteres. PHP es un lenguaje débilmente tipificado (los números se convierten en cadenas y viceversa automáticamente según sea requerido), pero una base de datos maneja tipos estrictamente. Como atacante, puedo buscar qué pasa si le pido al sistema algo que no se espere - Por ejemplo, «825aaa». En este caso (¡felicidades!), el código PHP que invoca a la base de datos sí verifica que el tipo de datos sea correcto: Hace una conversión a entero, y descarta lo que sobra. Sin embargo (y no doy URLs por razones obvias), en muchas ocasiones esto me llevaría a recibir un mensaje como el siguiente:

Warning: pg_execute() [function.pg-execute]: Query failed: ERROR:
invalid input syntax for integer: "825aaa" in
/home/(...)/index.php on line 192

Esto indica que uno de los parámetros fue pasado sin verificación de PHP al motor de base de datos, y fue éste el que reconoció al error.
Ahora, esto no califica aún como inyección de SQL (dado que el motor de bases de datos supo reaccionar ante esta situación), pero estamos prácticamente a las puertas. Podemos generalizar que cuando un desarrollador no validó la entrada en un punto, habrá muchos otros en que no lo haya hecho. Este error en particular nos indica que el código contiene alguna construcción parecida a la siguiente:

"SELECT * FROM articulo WHERE id = $id_art"

La vulnerabilidad aquí consiste en que el programador no tomó en cuenta que $id_art puede contener cualquier cosa enviada por el usuario - Por el atacante en potencia. ¿Cómo puedo aprovecharme de esto? La imaginación es lo único que me limita.
Presentaré a continuación algunos ejemplos, evitando enfocarme a ningún lenguaje en específico - Lo importante es cómo tratamos al SQL generado.
Para estos ejemplos, cambiemos un poco el caso de uso: En vez de ubicar recursos, hablemos acerca de una de las operaciones más comunes: La identificación de un usuario vía login y contraseña. Supongamos que el mismo sistema del código recién mencionado utiliza la siguiente función para validar a sus usuarios:

$data = $db->fetch("SELECT id FROM usuarios WHERE login = '$login' AND passwd = '$passwd'");
if ($data) { $uid = $data[0];
} else { print "<h1>Usuario inválido!</h1>";
}

Aquí pueden apreciar la práctica muy cómoda y común de interpolar variables dentro de una cadena - Muchos lenguajes permiten construir cadenas donde se expande el contenido de determinadas variables. En caso de que su lenguaje favorito no maneje esta característica, concatenar las sub-cadenas y las variables nos lleva al mismo efecto.
Sin embargo... ¿Qué pasaría aquí si el usuario nos jugara un pequeño truco? Si nos dijera, por ejemplo, que el login es «fulano';--», esto llevaría al sistema a ignorar lo que nos diera por contraseña: Estaríamos ejecutando la siguiente solicitud:

SELECT id FROM usuarios WHERE login = 'fulano';--' AND PASSWD = ''

La clave de este ataque es confundir a la base de datos para aceptar comandos generados por el usuario - El ataque completo se limita a cuatro caracteres: «';--». Al cerrar la comilla e indicar (con el punto y coma) que termina el comando, la base de datos entiende que la solicitud se da por terminada y lo que siga es otro comando. Podríamos enviarle más de un comando consecutivo que concluyera de forma coherente, pero lo más sencillo es utilizar el doble guión indicando que inicia un comentario. De este modo, logramos vulnerar la seguridad del sistema, entrando como un usuario cuyo login conocemos, aún desconociendo su contraseña.
Pero podemos ir más allá - Siguiendo con este ejemplo, típicamente el ID del administrador de un sistema es el más bajo. Imaginen el resultado de los siguientes nombres de usuario falsos:

  • ninguno' OR id = 1;--
  • '; INSERT INTO usuarios (login, passwd) VALUES ('fulano', 'de tal'); --
  • '; DROP TABLE usuarios; --

No puedo dejar de sugerirles visitar al ya famoso «Bobby Tables»1.
¿Y qué podemos hacer? Protegerse de inyección de SQL es sencillo, pero hay que hacerlo en prácticamente todas nuestras consultas, y convertir nuestra manera natural de escribir código en una segura.
La regla de oro es nunca cruzar fronteras incorporando datos no confiables - Y esto no sólo es muy sencillo, sino que muchas veces (específicamente cuando iteramos sobre un conjunto de valores, efectuando la misma consulta para cada uno de ellos) hará los tiempos de respuesta de nuestro sistema sensiblemente mejores. La respuesta es separar preparación y ejecución de las consultas. Al preparar una consulta, nuestro motor de bases de datos la compila y prepara las estructuras necesarias para recibir los parámetros a través de «placeholders», marcadores que serán substituídos por los valores que indiquemos en una solicitud posterior. Volvamos al ejemplo del login/contraseña:

$query = $db->prepare('SELECT id FROM usuarios WHERE login = ? AND PASSWD = ?');
$data = $query->execute($login, $passwd);

Los símbolos de interrogación son enviados como literales a nuestra base de datos, que sabe ya qué le pediremos y prepara los índices para respondernos. Podemos enviar contenido arbitrario como login y password, ya sin preocuparnos de si el motor lo intentará interpretar.
Revisar todas las cadenas que enviamos a nuestra base de datos puede parecer una tarea tediosa, pero ante la facilidad de encontrar y explotar este tipo de vulnerabilidades, bien vale la pena. En las referencias a continuación podrán leer mucho más acerca de la anatomía de las inyecciones SQL, y diversas maneras de explotarlas incluso cuando existe cierto grado de validación.
El tema de la inyección de código da mucho más de qué hablar - Lo abordaremos en la próxima columna, desde otro punto de vista.
Referencias:

AttachmentSize
200905_softwareguru_1.jpg697.55 KB
200905_softwareguru_2.jpg674.18 KB

Manteniendo el estado en nuestras aplicaciones Web: Una historia de galletas y de resúmenes

TitleManteniendo el estado en nuestras aplicaciones Web: Una historia de galletas y de resúmenes
Publication TypeMagazine Article
Year of Publication2009
AuthorsWolf G
MagazineSoftware Gurú
FrequencyQuarterly
Issue Number25
Date Published08/2009
Type of ArticleColumn
ISSN1870-0888
Keywordscookies, firma criptográfica, galletas, http, Seguridad, Web
URLhttp://www.sg.com.mx/content/view/916
Full Text

Una grandísima proporción de los sistemas desarrollados hoy en día, siguen el paradigma cliente-servidor. Y si bien hay muy diferentes maneras de implementar sistemas cliente-servidor, indudablemente la más difundida hoy por hoy es la de los sistemas Web.
La conjunción de un protocolo verdaderamente simple para la distribución de contenido (HTTP) con un esquema de marcado suficientemente simple pero suficientemente rico para presentar una interfaz de usuario con la mayor parte de las funciones requeridas por los usuarios (HTML) crearon el entorno ideal para el despliegue de aplicaciones distribuídas.
Desde sus principios, el estándar de HTTP menciona cuatro verbos por medio de los cuales se puede acceder a la información: GET (solicitud de información sin requerir cambio de estado), POST (interacción por medio de la cual el cliente manda información compleja y que determinará la naturaleza de la respuesta), PUT (creación de un nuevo objeto en el servidor) y DELETE (destrucción de un determinado objeto en el servidor). Sin embargo, por muchos años, éstos fueron mayormente ignorados — La mayor parte de los sistemas hace caso omiso a través de qué verbo llegó una solicitud determinada; muchos navegadores no implementan siquiera PUT y DELETE, dado su bajísimo nivel de uso — Aunque con la popularización del paradigma REST, esto probablemente esté por cambiar.
El protocolo HTTP, sin embargo, junto con su gran simplicidad aportó un gran peligro — No una vulnerabilidad inherente a los sistemas Web, sino que un peligro derivado de que muchos programadores no presten atención a un aspecto fundamental de los sistemas Web: Cómo manejar la interacción repetida sobre de un protocolo que delega el mantener el estado o sesión a una capa superior. Esto es, para un servidor HTTP, toda solicitud es única. En especial, un criterio de diseño debe ser que toda solicitud GET sea idempotente — Esto significa que un GET no debe alterar de manera significativa1 el estado de los datos.
HTTP fue concebido [1] como un protocolo a través del cual se solicitaría información estática. Al implementar las primeras aplicaciones sobre HTTP2, nos topamos con que cada solicitud debía incluir la totalidad del estado. Es por esto que los muchos sistemas Web hacen un uso extensivo de los campos ocultos (hidden) en todos sus formularios y ligas internas, transportando los valores de interacciones previas que forman parte conceptualmente de una sóla interacción distribuída a lo largo de varios formularios, o números mágicos que permiten al servidor recordar desde quién es el usuario en cuestión hasta todo tipo de preferencias que ha manifestado a lo largo de su interacción.
Sin embargo, éste mecanismo resulta no sólo muy engorroso, sino que muy frágil: Un usuario malicioso o curioso (llamémosle genéricamente «atacante») puede verse tentado a modificar estos valores; es fácil capturar y alterar los campos de una solicitud HTTP a través de herramientas muy útiles para la depuración. E incluso sin estas herramientas, el protocolo HTTP es muy simple, y puede "codificarse" a mano, sin más armas que un telnet abierto al puerto donde escucha nuestro sistema. Cada uno de los campos y sus valores se indican en texto plano, y modificar el campo «user_id» es tan fácil como decirlo.
En 1994, Netscape introdujo un mecanismo denominado galletas (cookies) que permite al sistema almacenar valores arbitrarios en el cliente3. Un año más tarde, Microsoft lo incluye en su Internet Explorer; el mecanismo fue estandarizado en 1997 y extendido en el 2000 con los RFCs 2109 y 2965 [2]. El uso de las galletas libera al desarrollador del engorro antes mencionado, y le permite implementar fácilmente un esquema verdadero de manejo de sesiones — Pero, ante programadores poco cuidadosos, abre muchas nuevas maneras de —adivinaron— cometer errores.
Dentro del cliente (típicamente un navegador) las galletas están guardadas bajo una estructura de doble diccionario — En primer término, toda galleta pertenece a un determinado servidor (esto es, al servidor que la envió). La mayor parte de los usuarios tienen configurados a sus navegadores, por privacidad y por seguridad, para entregar el valor de una galleta únicamente a su dominio origen (de modo que al entrar a un determinado sitio hostil éste no pueda robar nuestra sesión en el banco); sin embargo, nuestros sistemas pueden solicitar galletas arbitrarias guardadas en el cliente. Para cada servidor, podemos guardar varias galletas, cada una con una diferente llave, un nombre que la identifica dentro del espacio del servidor. Además de estos datos, cada galleta guarda la ruta a la que ésta pertenece, si requiere seguridad en la conexión (permitiendo sólo su envío a través de conexiones cifradas), y su periodo de validez, pasado el cual serán consideradas "rancias" y ya no se enviarán. El periodo de validez se mide según el reloj del cliente.
Guardar la información de estado del lado del cliente es riesgoso, especialmente si es sobre un protocolo tan simple como HTTP. No es dificil para un atacante modificar la información que enviaremos al servidor, y si bien en un principio los desarrolladores guardaban en las galletas la información de formas parciales, llegamos a una regla de oro: Nunca guardar información real en ellas. En vez, guardemos algo que apunte a la información. Esto es, por ejemplo, en vez de guardar el ID de nuestro usuario, una cadena criptográficamente fuerte [3] que apunte a un registro en nuestra base de datos. ¿A qué me refiero con esto? A que tampoco grabe directamente el ID de la sesión (dado que siendo sencillamente un número, sería para un atacante trivial probar con diferentes valores hasta "aterrizar" en una sesión interesante), sino una cadena aparentemente aleatoria, creada con un algoritmo que garantice una muy baja posibilidad de colisión y un espacio de búsqueda demasiado grande como para que un atacante lo encuentre a través de la fuerza bruta.
Los algoritmos más comunes para este tipo de uso son los llamados funciones de resumen (digest) [3]. Estos generan una cadena de longitud fija; dependiendo del algoritmo hoy en día van de los 128 a los 512 bits. Las funciones de resumen más comunes hoy en día son las variaciones del algoritmo SHA desarrollado por el NIST y publicado en 1994; usar las bibliotecas que los implementan es verdaderamente trivial. Por ejemplo, usando Perl:

  1. use Digest::SHA1;
  2. print Digest::SHA1->sha1_hex("Esta es mi llave");

nos entrega la cadena:
c3b6603b8f841444bca1740b4ffc585aef7bc5fa
Pero, ¿qué valor usar para enviar como llave? Definitivamente no queremos enviar, por ejemplo, el ID de la sesión - Esto nos pondría en una situación igual de riesgosa que incluir el ID del usuario. Un atacante puede fácilmente crear un diccionario del resultado de aplicar SHA1 a la conversión de los diferentes números en cadenas. La representacíon hexadecimal del SHA1 de '1' siempre será d688d9b3d3ba401b25095389262a3ecd2ad5ad68, y del de 100 siempre será daaaa8121aa28fca0edb4b3e1f7b7c23d6152eed. El identificador de nuestra sesión debe contener elementos que varíen según algún dato no adivinable por el atacante (como la hora exacta del día, con precisión a centésimas de segundo) o, mejor aún, con datos aleatorios.
Este mecanismo nos lleva a asociar una cadena suficientemente aleatoria como para que asumamos que las sesiones de nuestros usuarios no serán fácilmente "secuestradas" (esto es, que un atacante no le atinará al ID de la sesión de otro usuario), permitiéndonos dormir tranquilos sabiendo que el sistema de manejo de sesiones en nuestro sistema es prácticamente inmune al ataque por fuerza bruta.
Como último punto: Recuerden que algunas personas, por consideraciones de privacidad, han elegido desactivar el uso de galletas en su navegación diaria, a excepción de los sitios que expresamente autoricen. Tomen en cuenta que una galleta puede no haber sido guardada en el navegador cliente, y esto desembocará en una experiencia de navegación interrumpida y errática para dichos usuarios. Es importante detectar si, en el momento de establecer una galleta, ésta no fue aceptada, para dar la información pertinente al usuario, para que sepa qué hacer y no se encuentre frente a un sistema inoperativo más.
REFERENCIAS

  • 1. Es aceptable que a través de un GET, por ejemplo, aumente el contador de visitas, esto es, que haya un cambio no substantivo — Pero muchos desarrolladores han sufrido por enlazar a través de un GET (generado por una liga HTML estándar), por ejemplo, el botón para eliminar cierto objeto. Toda acción que genere un cambio en el estado substantivo de nuestra base debe llevarse a cabo a través de POST. ¿Qué pasa en caso contrario? Que diversas aplicaciones, desde los robots indexadores de buscadores como Google y hasta aceleradores de descargas ingenuos que buscan hacer más ágil la navegación de un usuario (siguiendo de modo preventivo todas las ligas GET de nuestro sistema para que el usuario no tenga que esperar en el momento de seleccionar alguna de las acciones en la página) van a disparar éstos eventos de manera inesperada e indiscriminada.
  • 2. En términos de redes, HTTP implementa exclusivamente la capa 4 del modelo OSI, y si bien TCP mantiene varios rasgos que nos permiten hablar tambien de sesiones a nivel conexión, estas son sencillamente descartadas. Las capas 5 y superiores deben ser implementadas a nivel aplicación.
  • 3. La galleta será enviada en cada solicitud que se haga, por lo que se recomienda mantenerla corta. Varias implementaciones no soportan más de 4KB.
AttachmentSize
Versión impresa en SG (primer página)614.01 KB
Versión impresa en SG (segunda página)544.73 KB

Codificación de Caracteres

TitleCodificación de Caracteres
Publication TypeMagazine Article
Year of Publication2009
AuthorsWolf G
MagazineSoftware Gurú
FrequencyQuarterly
Issue Number26
Pagination48-49
Date Published11/2009
Type of ArticleColumn
ISSN1870-0888
KeywordsASCII, caracteres, codificiación, Unicode, UTF
URLhttp://www.sg.com.mx/content/view/954
Full Text

NOTA: Al preparar este texto, excedí el límite de espacio que me asignan, por lo cual después de terminar de escribir tuve que ver qué párrafos eran más prescindibles. Acá reproduzco el artículo completo, y adjunto como archivo la versión tal cual apareció impresa.

Hace un par de días recibí uno de esos correos que parecen venir de una época ya superada y olvidada hace años: Un correo que comenzaba con la frase:

Para evitar problemas de compatibilidad, este correo no incluye acentos ni enies

En efecto, este problema casi ha desaparecido del correo, y ese pretexto sencillamente ya no resulta ni siquiera una excusa adecuada para quien le da flojera escribir el español correctamente.
Sin embargo, no en todos los campos podemos hablar de un éxito tan grande como en el manejo del correo electrónico — Y es de esperarse. La naturaleza misma del correo lo requiere. Cada mensaje individual debe ser transportado, sin que le sean inflingidas modificaciones por agentes externos, entre los equipos de los participantes en una conversación — que pueden estar configuradas con referentes culturales completamente distintos.
Y si bien para los hispanoparlantes, especialmente para aquellos que sienten que el uso de símbolos internacionales (acentos, tildes y signos de apertura de interrogación/exclamación) es opcional, el correo funcionó casi bien desde un principio (y a continuación detallaremos el por qué), cuando el uso de Internet dio su gran salto cuantitativo en los 1990s y llegó a la población en general, para los nativos de muchas otras culturas alrededor del mundo se hizo imperativo encontrar cómo comunicarse confiablemente.
Pero el problema viene de mucho más atrás. Repasemos rápidamente la historia de los esquemas de codificación de caracteres.

Repaso histórico

La codificación a partir de la cual se originan todos los esquemas en uso hoy en día nació en 1963, revisado/ratificado en 1967 con el nombre de ASCII: Código Estándar Americano para el Intercambio de Información. ASCII es un código de 7 bits, permitiendo la representación de hasta 128 caracteres, y en su versión definitiva incluye 32 caracteres de control, 34 símbolos, 52 caracteres de texto (mayúsculas y minúsculas) y 10 dígitos.
Sobra decir que el ámbito cómputo ha cambiado drásticamente desde 1963. La computadora debía representar apenas la información indispensable para ser comprendida por sus operadores, y en la propuesta original, ASCII no incluía ni siquiera letras minúsculas . Pero ya en 1964 aparecieron las máquinas de escribir IBM MT/ST: Una máquina de escribir electrónica, con la capacidad de guardar (y corregir) páginas en cinta magnética. Fue sólo cuestión de tiempo (y del necesario paso de popularización que siguió a la revolución de las computadoras personales hacia fines de los 1970) para que estas capacidades quedaran al alcance de todo mundo.
Y es ahí donde se hizo obvio que haría falta extender ASCII: Todos los idiomas europeos que utilizan el alfabeto latino a excepción del inglés requieren de diferentes tipos de diacríticos para ser representados; tras varias ideas descartadas, se aprovechó el hecho de que hacia fines de los 1970 todas las computadoras ampliamente desplegadas tenían un tamaño de palabra de 8 bits para utilizar un ASCII ampliado que daría 128 caracteres adicionales. Sin embargo, la idea resonó rápidamente… Y no surgió un estándar para su uso. Además, muchos de estos caracteres fueron empleados para incluir caracteres gráficos, para permitir construir interfaces amigables al usuario.
En 1981, IBM puso a la venta su primer computadora personal - La IBM 5051, o como se popularizó, la PC. Entre sus características contaba con una tarjeta de video con páginas de códigos reprogramables — La mitad superior del espacio de caracteres podía ser definida por software; los caracteres cargados por omisión eran los de la página de códigos 437 (CP437), con soporte parcial para algunos lenguajes europeos, pero –debido al espacio empleado por los caracteres semigráficos para representar interfaces al usuario– nunca fueron suficientes, por lo que en general era necesario activar una página de código alternativa — Para el español, la CP850. La situación mejoró al popularizarse los entornos gráficos y dejar de depender de los caracteres semigráficos; varias hojas de código relacionadas pudieron agruparse en un menor número — En este caso, para lenguajes europeos occindentales, la ISO-8859-1.
El problema se presenta al intercambiar archivos con usuarios de otras páginas: Los datos que usan una página son indistinguibles que los que usan otra. Si compartiera un archivo ISO-8859-1 con una persona de Europa oriental (ISO-8859-2), los caracteres acentuados aparecerían modificados, aparentemente corruptos. La situación de los lenguajes de Asia oriental era mucho peor aún, dado que por la cantidad de glifos, plantear el uso de un alfabeto de 256 caracteres resultó imposible — y por muchos años, la interoperabilidad fue meramente un sueño.
En 1988, Joe Becker, Lee Collins y Mark Davis, de Xerox y Apple, se reunieron para atacar este problema de raiz: Lanzaron la iniciativa del sistema Unicode, buscando aprovechar los grandes avances de más de 20 años del cómputo para lograr un conjunto de caracteres apto para todo el mundo. Pronto su iniciativa logró captar la atención y el respaldo de otros líderes del desarrollo del cómputo.
El desarrollo de Unicode no está libre de desaciertos y peleas políticas, pero el resultado bien lo valió: Para 1996 se publicó la especificación Unicode 2.0, permitiendo un espacio de más de un millón (216+220) de puntos de código independientes, reteniendo compatibilidad hacia atrás completa con el principal esquema heredado (ISO-8859-1), derivado de CP850.
Unicode es tan grande que su representación interna no está libre de polémica e interpretaciones. Sin entrar en detalles técnicos, las dos principales representaciones son UTF-8 (utilizada en sistemas basados en Unix, y en general, para toda transmisión sobre redes de datos) y UTF-16, descendiente de UCS-2 (en uso principalmente en sistemas Windows).
No entraré mucho en detalles respecto a estas dos representaciones — Es sólo importante estar conscientes de que una cadena Unicode puede estar representada internamente de diferentes maneras; UTF-8 está basado en elementos individuales de 8 bits, mientras que el átomo en UTF-16 es de 16 bits, por lo que –especialmente con idiomas basados en el alfabeto latino– UTF-8 es más compacto (con UTF-16, el byte superior consistirá sólamente de ceros) y es sensiblemente más robusto para transmisiones sobre la red (una corrupción de datos afecta un punto mínimo, mientras que con UTF-16 puede hacer ilegible todo el texto a partir de ese punto).
Un punto importante a mantener en cuenta es que la representación binaria de texto ASCII heredado es idéntica a su representación en UTF-8 — No así con UTF-16. Para más detalles respecto a estas dos representaciones, así como las otras varias posibles, sugiero leer (Wikipedia Comparación).

¿Qué hace diferente al tratamiento de Unicode?

Hasta antes de Unicode, todo lo que teníamos que saber respecto a un esquema de codificación se limitaba a elegir la salida adecuada, o interpretar la entrada como debía ser. Y Unicode agrega muchos puntos a la mezcla. algunos de ellos:

Longitud de una cadena
Como programadores, estamos acostumbrados a que la longitud caracteres de una cadena es igual a su tamaño entes. Unicode rompe con este supuesto — Para medir langitud ahora tenemos que evaluar la cadena completa ycontrar cuáles partículas son de qué tamaño — Un caracterede medir entre uno y seis bytes, y hay además caracteresm>combinantes, que no ocupan un espacio por sí sólosno que modifican al anterior.
No todas las cadenas son válidas
Con los esquemas tradicionales de 8 bits, todo conjunto deracteres es válido. Al hablar de las representaciones deicode, hay cadenas que resultan inválidas.
Si han visto una página Web donde los caracteres con diacríticos aparecen substituídos por caracteres en forma de rombo con un signo de interrogación dentro (�, punto de código U+FFFD), éste caracter denota que el procesamiento de Unicode no pudo completarse. Sin embargo, no todas las aplicaciones son tan benignas como un navegador — Una base de datos, por ejemplo, debe negarse a guardar datos mal-formados, por lo cual debemos estar conscientes del tipo de excepciones que posiblemente recibiremos si nuestro usuario nos da datos inválidos.
Caracteres definidos semánticamente, no visualmente
Los caracteres en Unicode no buscan únicamente representar un grupo de grafías, sino que su significado. En tiempos del ASCII nos acostumbramos a utilizar la representación gráfica más cercana a un caracter. Por ejemplo, nos acostumbramos a representar a la multiplicación con el asterisco ya sea con la letra «x» o con el asterisco; con Unicode podemos usar –cual debe ser– el símbolo ✕ (U+2715). Los alemanes ya no se ven forzados a usar la β (beta griega, U+0392) en vez de la ß (Eszett o S fuerte, U+00DF).
Si bien esto es más una ventaja que nada, puede llevarnos a confusiones. Por ejemplo, si bien en ASCII con CodePage 850 sólo podemos representar a una letra acentuada de una manera (la letra á está en la posición 160), en Unicode puede representarse en este mismo punto, o como la combinación de una a minúscula (caracter 95, U+0061) y un caracter combinante de acento agudo (U+0300): á. Esto permite la gran expresividad que requieren algunos idiomas o alfabetos (ver (Wood 1999-2009) con una clara ejemplificación de la expresividad que otorgan), pero nos obliga a considerar más casos especiales al enfrentarnos a Unicode desde el punto de vista del desarrollador de sistemas.

Promesas, promesas…

Como ya lo hemos discutido en este mismo espacio, el punto que más debemos cuidar como desarrolladores son los puntos de cruce — Las barreras, las costuras en la realidad. Lo ideal sería que no hiciera falta que un componente le dijera explícitamente al otro que está listo y dispuesto para usar Unicode. Un sistema operativo instalado limpiamente el día de hoy, así como casi cualquier aplicación que instalemos sobre de éste, debe funcionar bien –y de manera predeterminada– con Unicode. Claro está, la realidad siempre se interpone — Por un lado, podemos tener que interactuar con componentes heredados. Por otro lado, no podemos olvidar el hecho de que muy rara vez podemos controlar el entorno de nuestros usuarios — Y por último, un punto donde nos toparemos ineludiblemente con problemas de codificación es al hablar con dispositivos externos.
Si bien es posible aplicar reglas heurísticas para determinar si una cadena es válida o no como UTF-8 (Dürst 1997), prácticamente cualquier protocolo que utilicemos hoy en día para transmitir contenido que deba ser interpretado como texto proporciona un campo en su encabezado para indicar el tipo de contenido a utilizar — Sin olvidar tomar en cuenta que muchos protocolos contemplan la transmisión de datos multipartes, ¡y cada una de las partes puede llevar codificaciones diferentes!

Conclusiones

Viendo sólamente estos puntos, puede que muchos de ustedes los vayan poniendo en la balanza, y les parezca que migrar a Unicode es demasiado dificil y no vale la pena. Sin embargo, sencillamente, no nos queda opción: El mundo entero va avanzando en ese sentido.
Si bien nos toca la parte más simple, por ser nativos de una cultura basada en el alfabeto dominante en Internet, no podemos ignorar que formamos parte de un mundo plenamente globalizado, y que los días de vivir en nuestra islita feliz de un sólo alfabeto han terminado.
Del mismo modo que sencillamente ya no es aceptable que una aplicación falle cuando le enviamos datos escritos correctamente acentuados, tampoco es aceptable que rechacemos registrar a personas cuyo nombre tiene origen extranjero, o que tienen una dirección de destinatario no representable con caracteres latinos. Ni es aceptable, en un mundo que tiende a la presentación de software como servicio «en la nube», no ofrecer una solución capaz de manejar los datos enviados por usuarios de todo el mundo es ofrecer una solución con baja calidad de servicio.

Referencias

AttachmentSize
Versión del artículo publicada en la revista1.3 MB

2010

Columnas publicadas en 2010

Voto electrónico

TitleVoto electrónico
Publication TypeMagazine Article
Year of Publication2010
AuthorsWolf G
MagazineSoftware Gurú
FrequencyQuarterly
Issue Number27
Date Published02/2010
Type of ArticleColumn
ISSN1870-0888
Keywordsconfiabilidad, democracia, Seguridad, voto electrónico
URLhttp://www.sg.com.mx/content/view/919
Full Text

Nota: Este artículo lo comencé a trabajar para publicarlo como parte del trabajo del Seminario Construcción Colaborativa del Conocimiento. Al ver que era pertinente e indicado para su inclusión en mi columna para la revista SoftwareGurú, lo utilicé ahí también — Pero tuve que reducirlo a menos de la mitad de su extensión original. Aquí lo presento completo, en una versión muy similar a la que será publicada como resultado del Seminario, refiriendo hacia aquí a los lectores interesados de la revista. Como archivos adjuntos (al final) encontrarán también la versión de SoftwareGurú.

Voto electrónico

La postura que ante las votaciones electrónicas han tomado diversos grupos relacionados con la creación y escrutinio de software y de procesos sociales ilustra muy bien varios de los puntos delineados en otros capítulos de la presente obra. Este capítulo formaba parte originalmente del capítulo «Software Libre y Construcción Democrática de la Sociedad», e ilustra uno de los puntos y de las maneras en que las comunidades de creación de conocimiento tanto de seguridad en cómputo como de Software Libre han abordado un punto de gran importancia para la vida en sociedades democráticas actuales, insertándose en el entorno político imperante. Hemos decidido, tanto por la extensión como por la relación de este tema con varios otros de los presentados en esta obra, hacer del presente apartado un capítulo independiente.
Los promotores de las diferentes vertientes del Conocimiento Libre son los primeros en recalcar los tremendos fallos –conceptuales y de implementación– que hacen que las estaciones computarizadas de emisión y contabilización de votos sean, desde su planteamiento, una causa perdida [1] — Ninguna de las numerosas implementaciones a la fecha han salido airosas ante el escrutinio (incluso casual) de expertos en seguridad [2], a veces con resultados verdaderamente nefastos [3], [4]. Los escrutinios generalmente han sido dirigidos por grupos de activistas independientes buscando señalar las deficiencias del proceso, con la muy notable excepción del ejemplo puesto por el Tribunal Superior Electoral de Brasil, al cual abordaremos más adelante.
Obviamente, estos resultados no son del agrado de las compañías que buscan vender máquinas supuestamente seguras, diseñadas ex-profeso para el conteo de votos. Se han dado a conocer incluso amenazas hechas contra dichos equipos de investigadores [5] por desarrollar estos trabajos. En este caso, la demanda es que, en asuntos tan sensibles, relevantes e intervenibles como la vida democrática, es sencillamente imposible asegurar los elementos básicos de confiabilidad y auditabilidad.
Diversos argumentos han sido esgrimidos a favor del voto electrónico, pero pueden ser resumidos en tres:

  • Disminución de costos: Un adecuado proceso democrático es caro. La papelería electoral debe ser impresa con mecanismos suficientes para asegurar su unicidad, deben proveerse mecanismos para garantizar que sólo los electores autorizados emitan su voto, y debe haber garantías de no manipulación para todos los componentes involucrados en el proceso. La automatización del proceso ayuda a implementar estos candados a un menor costo.
  • Agilidad en la obtención de resultados: No hay nada que genere mayor falta de confianza y suspicacia en los procesos que una demora en la publicación de los resultados. Se ha argumentado que a través del voto electrónico, los resultados pueden ser anunciados prácticamente de inmediato tras haberse cerrado la casilla.
  • Confiabilidad de los actores: La experiencia de muchos países en torno a los fraudes electorales apunta dolorosamente a la falta de integridad de los actores involucrados en el proceso — Personas susceptibles ya sea a la compra de concienicas, a la extorsión, o directamente a la violencia física; si todo el proceso es controlado por computadoras, éstos factores deberían perder peso.

En las siguientes secciones analizamos por qué los tres argumentos caen por su propio peso.

Agilidad en la obtención de resultados

Una de las principales obsesiones de la sociedad actual es la velocidad del acceso a la información. Los medios electrónicos de comunicación y el uso de Internet nos han acostumbrado a que la información debe estar disponible tan pronto ocurren los hechos, y debe llegar a toda la sociedad tan pronto está disponible.
Los sistemas electorales en general estipulan que, para no manipular los resultados de una elección en proceso, no deben darse a conocer sus resultados parciales hasta que haya cerrado la última de las urnas – No hacerlo de esta manera significaría que la tendencia influiría en los resultados de muchas maneras indeseables. Sin embargo, una vez que cierra ésta última urna, en la mayor parte de las democracias modernas hay un periodo típicamente de un par de horas en que es necesario esperar a que las autoridades electorales recopilen la información generada por típicamente decenas de miles de casillas y den a conocer el resultado. Hay una gran presión por parte de los ciudadanos, y muy especialmente de los medios, para que las autoridades electorales publiquen los resultados de inmediato. Además del apetito por la información expedita, ésto viene fundamentado en ejemplos de ocultamientos de información que eran realizados conforme los números comenzaban a fluir — Ejemplo de esto son las declaraciones que hizo veinte años más tarde Manuel Bartlett Díaz, quien fuera en 1988 Secretario de Gobernación y presidente de la Comisión Federal Electoral durante las muy cuestionadas elecciones presidenciales de 1988 [6]: La decisión de no dar a conocer datos preliminares fue tomada por el presidente Miguel de la Madrid, dado que, cito: si se oficializaba en ese momento –con datos parciales– que Cárdenas Solórzano iba ganando, al final nadie aceptaría un resultado distinto.
En la experiencia mexicana, la situación ha cambiado radicalmente de la imperante hace tan sólo dos décadas, como claro resulado de las frecuentes acusaciones de fraude electoral que nuestro sistema electoral ha sufrido — En vez de una demora cercana a una semana, el Instituto Federal Electoral y las autoridades correspondientes de cada uno de las entidades federativas publican los resultados de las encuestas de salida y los conteos rápidos típicamente dentro de las dos primeras horas tras haber concluído la votación, siempre que haya suficiente márgen estadístico para no causar confusión en la población.
Impulsar una solución con tantos riesgos como una urna electrónica para ganar como tope estas dos horas sencillamente no tiene sentido. Además, el tiempo invertido por los funcionarios electorales en cada casilla en el conteo de votos emitidos es sólo una fracción del dedicado a las tareas de verificación y protocolización que deben llevarse a cabo antes de declarar concluída una elección. Sumando ésto a que –por consideraciones de seguridad– las estaciones de voto no están pensadas para contar con conectividad a red (y que ni los países más industrializados cuentan con una cobertura de Internet del 100% de su territorio), por lo cual debe haber forzosamente un paso manual de comunicación de resultados al centro de control de la autoridad electoral, el argumento de reducción de tiempos queda descartado.
Federico Heinz cierra su texto «¿El voto electrónico mejora la democracia?» [7] con la siguiente idea:

Una alternativa factible es realizar la votación mediante formularios que contengan a todos los partidos, dejar que los votantes marquen su elección con tinta, y usar un scanner óptico para hacer un escrutinio automático, verificable mediante un simple recuento manual. No hay nada en contra de un escrutinio electrónico, pero digitalizar el acto mismo de la emisión del voto es extremadamente peligroso para la democracia.

El uso de boletas a papel y tinta aptas para ser scanneadas por equipo de reconocimiento óptico puede ser la opción más adecuada en este sentido. Permite la verificación de cientos de boletas en apenas un par de minutos, y permite conservar todos los atributos positivos del sistema tradicional.

Confiabilidad de los actores

Algunos proponentes del voto electrónico mencionan que con el voto tradicional en papel todos estos fraudes siempre han existidohttp://seminario.edusol.info/resena/beatriz-ramirez/2009/03-1 (requiere registro)" href="#footnote1_7xgw9ph">1, y que éste no agrava los riesgos — Sin embargo, más que reducir las posibilidades de los agentes fraudulentos, al implementar el voto electrónico estaríamos aumentando la profundidad a la que podrían llegar, e imposibilitando cualquier acción de auditoría o rendición de cuentas.
La votación electrónica tiene muchas modalidades y muchas aristas. En líneas generales, y contrario a lo que muchos esperarían, los expertos en seguridad informática y los activistas sociales involucrados en esta lucha no recomiendan exigir que las urnas electrónicas estén basadas en Software Libre para su funcionamiento, sino que sencillamente recomiendan en contra de su utilización. Citando a Heinz, [7]:

El mecanismo de auditar completamente el funcionamiento de las urnas es impracticable. Esta es una tarea que sólo podría ser ejecutada por una elite de especialistas, de los que hay muy pocos en el mundo, y requiere la cooperación de las empresas que proveen las urnas así como de todos sus proveedores. Y aún si consiguiéramos todo eso, la eficacia de una auditoría sería más que dudosa: no sólo debemos garantizar que todo el software es correcto (lo que es imposible), sino que además debemos verificar que el software presente en las urnas el día de la elección es idéntico al auditado, tarea que nuevamente requiere de especialistas. ¿Y por qué hemos de confiar en los especialistas, si no queremos confiar en sacerdotes ni en empresas? Una de las muchas virtudes del "anticuado" sistema de escrutino tradicional es que cualquier persona que sepa leer, escribir y hacer operaciones de aritmética elemental está en condiciones de controlarlo. Esta es una característica esencial y no debemos renunciar a ella.

Uno de los más interesantes argumentos que ilustran por qué las urnas electrónicas carecen inherentemente de confiabilidad es el presentado —sin aplicarlo en éste ramo específico— por Ken Thompson en 1983 [8], en su discurso al recibir el Premio Turing de la ACM2. Thompson hace una sencilla demostración de por qué un sistema que llega al usuario final (y esto es mucho más cierto hoy en día que en 1983, en que los lenguajes y marcos de desarrollo utilizados suben increíblemente en la escala de la abstracción comparado con lo existente entonces) es prácticamente imposible de auditar por completo un programa, ni siquiera teniendo su código fuente, ni siquiera teniendo el código fuente del compilador. Traduciendo de las conclusiones de Thompson:

La moraleja es obvia. No puedes confiar en el código que no creaste tú mismo. (Especialmente código proveniente de compañías que emplean a gente como yo). No hay un nivel suficiente de verificación o escrutinio de código fuente que te proteja de utilizar código no confiable. En el proceso de demostrar la posibilidad de este tipo de ataque, elegí al compilador de C. Podría haber elegido a cualquier programa que manipule a otros programas, como al ensamblador, cargador, o incluso microcódigo embebido en el hardware. Conforme el nivel de programación se vuelve más bajo, éstos fallos se volverán más y más difíciles de detectar. Esta vulnerabilidad bien instalada en microcódigo será prácticamente imposible de detectar.

Éste argumento ha sido clave para llegar a conclusiones como la adoptada en marzo del 2009 por la Corte Suprema de Alemania [9],[10]:

Un procedimiento electoral en el que el elector no puede verificar de manera confiable si su voto fue registrado sin falsificación e incluido en el cálculo del resultado de la elección, así como comprender cabalmente de qué manera los votos totales emitidos son asignados y contados, excluye del control público a componentes centrales de la elección, y por lo tanto no alcanza a satisfacer las exigencias constitucionales.

El punto de la confiabilidad es el que más fervientemente se sigue debatiendo. El caso brasileño resulta muy esperanzador: A diferencia de la mayor parte de los gobiernos de países supuestamente desarrollados, en Brasil la tecnología utilizada para el voto electrónico está completamente basada en tecnología desarrollada localmente, empleando software libre. En noviembre del 2009, el Tribunal Superior Electoral brasileño convocó a la comunidad de seguridad a encontrar vulnerabilidades sobre las estaciones receptoras de votos, a cambio de una recompensa económica para los mejores análisis[11]. Dentro de los términos estipulados, sólo uno de los participantes (Sergio Freitas da Silva) logró su propósito [12]. Y si bien no logró vulnerar los resultados de éste sistema, sí logró –mediante un monitoreo de las radiaciones electromagnéticas– averiguar por quién emitía su voto cada uno de los electores, rompiendo el principio de secrecía electoral, empleando únicamente equipo casero de bajo costo al buscar que esto fuera meramente una prueba de concepto; un atacante determinado podría utilizar equipo mucho más sofisticado para intervenir las votaciones a mucha mayor distancia.
Y si bien el sistema empleado por Brasil sale mucho mejor parado que los empleados en Europa y Estados Unidos, no debemos tomar la ausencia de evidencia por evidencia de ausencia: Lo único que demostraron es que ninguno de los atacantes pudo demostrar una vulnerabilidad en el periodo estipulado, o no quiso hacerlo por el precio ofrecido, pero nada indica que no haya fallas no encontradas — O peor aún, puertas traseras intencionales.

Disminución de costos

La sociedad está acostumbrada a lidiar con los bemoles del voto tradicional, utilizando al papel como su medio primario. Una crítica muy común a éstos procesos, especialmente en los países cuyas democracias no están bien consolidadas (y por tanto, requieren de mucho mayor inversión tanto en la vigilancia como en la promoción de la participación de las elecciones) es el costo — En México, citando a un caso extremo (el sistema electoral más caro de América Latina [13]), cada sufragio emitido en las elecciones intermedias del 2009 tuvo un costo superior a los 17 dólares, aunque hay estimaciones que lo llegan a ubicar en hasta 50 dólares, tomando en cuenta gastos ocultos.
Como mencionamos anteriormente, un rubro que en el sin duda podrían presentarse importantes ahorros es en la generación, el manejo y la custodia del material electoral. Sin embargo, como queda demostrado tras el estudio realizado por Feldman, Halderman y Felten a las estaciones de votación Diebold AccuVote-TS [14], las más difundidas en los Estados Unidos y que han sido responsables de la recopilación de votos de hasta el 10% de los electores de dicho país, con conocimiento técnico especializado éstas máquinas presentan un nivel de confiabilidad ante ataques verdaderamente bajo, y permiten —requiriendo de un tiempo mínimo de acceso— la reprogramación resultando en resultados fraudulentos que serían prácticamente imposibles de lograr en una elección tradicional sin recurrir a métodos violentos.
Las vulnerabilidades descritas por Feldman, Halderman y Felten no son privativas a los equipos Diebold — En el sitio Web en el cual está publicado su artículo junto con un video de diez minutos demostrando su ataque y una lista de preguntas frecuentes mencionan: (traducido)

¿Por qué estudiaron éstas máquinas Diebold? ¿Por qué no otras tecnologías para votos?
Estudiamos estas máquinas porque son las que conseguimos. Si hubiésemos tenido acceso a otro tipo de máquinas, probablemente las hubiéramos estudiado.
¿Son otras máquinas más seguras que las que estudiaron?
No lo sabemos. Esperamos que así lo sean —las elecciones dependen ya de ellas— pero no hay suficiente evidencia para responder a esta pregunta
Un rastro impreso verificado por cada votante es la protección más importante que puede hacer más seguras a las máquinas de voto electrónico.

El último punto mencionado es de especial relevancia: Un rastro impreso verificado por cada votante. La única garantía que un votante puede tener de que su voto fue registrado correctamente es que el sistema genere una boleta impresa y de caracter irrevocable, misma que sea verificada por el votante al instante, la cual se convertirá en el documento probatorio de la elección3. No hay manera —ver la cita de [8] en la sección Confiabilidad de los actores— de que el estado interno de una computadora sea confiable, y muchísimo menos cuando hablamos del proceso más importante y más sensible de la vida política de un país.
Llegamos entonces a una contradicción: El equipo de votación no es barato, en términos absolutos. Su adquisición por parte de un gobierno o ente de autoridad podría justificarse si se plantea prorratear a lo largo de varias elecciones — pero si éste tiene que estar sujeto a una estricta vigilancia contínua, incluso en los años en que no será utilizado. Debe recibir mantenimiento, y debe abastecerse con una cantidad no despreciable de insumos, para asegurar un rastro impreso verificado. Además, en caso de sufrir un desperfecto, todas las casillas deben tener un plan de respaldo: Casi indefectiblemente, esto significaría tener papelería tradicional para enfrentar desde un desperfecto del equipo hasta un sabotaje, por ejemplo, en el suminstro eléctrico. Por tanto, el supuesto ahorro puede volverse en contra nuestra, convirtiéndose en un gasto mucho mayor al que implican las votaciones tradicionales.

Referencias

  • [1.] ¿El voto electrónico mejora la democracia?, Heinz, Federico , (2006)
  • [2.] Evidence of New Jersey Election Discrepancies, Felten, Ed , (2008)
  • [3.] Are Your Votes Really Counted? Testing the Security of Real-world Electronic Voting Systems, Balzarotti, D., Banks G., Cova M., Felmetsger V., Kemmerer R., Robertson W., Valeur F., and Vigna G. , International Symposium on Software Testing and Analysis, 20/07/2008, Seattle, WA, (2008)
  • [4.] Evaluating the Security of Electronic Voting Systems, Balzarotti, D., Banks G., Cova M., Felmetsger V., Kemmerer R., Robertson W., Valeur F., and Vigna G. , The Computer Security Group at UCSB, (2008)
  • [5.] Interesting Email from Sequoia, Felten, Ed , (2008)
  • [6.] De la Madrid me ordenó no informar que Cárdenas iba ganando, asegura Bartlett, , La Jornada, 2008/07/03, Volume 2008, Mexico, (2008)
  • [7.] ¿El voto electrónico mejora la democracia?, Heinz, Federico , (2006)
  • [8.] Reflections on trusting trust, Thompson, Ken , Communications of the ACM, 08/1984, Volume 27, Number 8, p.761-763, (1984)
  • [9.] Beim Einsatz elektronischer Wahlgeräte müssen die wesentlichen Schritte der Wahlhandlung und der Ergebnisermittlung vom Bürger zuverlässig und ohne besondere Sachkenntnis überprüft werden können., BVerfG , p.paragraph 1-163, (2009)
  • [10.] Alemania: urnas electrónicas anticonstitucionales, Heinz, Federico , 2009/03/06, Volume 2009, Number 2009/03/06, (2009)
  • [11.] Teste de segurança do sistema eletrônico de votação, , Volume 2009, Number 2009/12/29, (2009)
  • [12.] Un investigador logra violar el secreto del voto en las urnas brasileñas, Busaniche, Beatriz , Voto electrónico, Volume 2009, Number 2009/12/29, Buenos Aires, Argentina, (2009)
  • [13.] Cuesta el voto en México 18 veces más que el promedio en AL, dicen expertos, Urrutia, Alonso, and Martínez Fabiola , La Jornada, 2009/06/19, (2009)
  • [14.] Security Analysis of the Diebold AccuVote-TS Voting Machine, Feldman, Ariel J., Halderman Alex J., and Felten Ed , 2007 USENIX/ACCURATE Electronic Voting Technology Workshop (EVT’07), 08/2007, (2007)
  • 1. p.ej. http://seminario.edusol.info/resena/beatriz-ramirez/2009/03-1 (requiere registro)
  • 2. Premio al que comunmente se hace referencia como el nóbel del cómputo
  • 3. Y claro está, es fundamental que cada una de estas boletas sea generada por separado, recortada de la inmediata anterior y posterior, con garantía de que no haya un patrón seguible en el corte, para garantizar el anonimato del elector
AttachmentSize
Versión del artículo tal como fue enviada a SoftwareGurú11.91 KB
Versión impresa en SG (primer página)533 KB
Versión impresa en SG (segunda página)465.55 KB
Presentación en PDF908.54 KB

Arquitecturas de paquetes al rescate

TitleArquitecturas de paquetes al rescate
Publication TypeMagazine Article
Year of Publication2010
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
FrequencyQuarterly
Issue Number28
Date Published05/2010
Type of ArticleColumn
ISSN1870-0888
KeywordsArquitectura de paquetes, Linux, modularización
URLhttp://www.sg.com.mx/content/view/1054
Short TitleArquitecturas de paquetes al rescate
Full Text

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?

AttachmentSize
Texto del artículo enviado para su publicación10.82 KB
Fotografía de la primera página (publicada)965.07 KB
Fotografía de la segunda página (publicada)1.05 MB

Historia y futuro de la interfaz hombre-máquina

TitleHistoria y futuro de la interfaz hombre-máquina
Publication TypeMagazine Article
Year of Publication2010
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
FrequencyQuarterly
Issue Number29
Pagination46-47
Date Published2010-08-01
Type of ArticleColumn
ISSN1870-0888
Keywordshistoria, interfaz hombre máquina, interfaz usuario
URLhttp://www.sg.com.mx/content/view/1087
Full Text

Historia y futuro de la interfaz hombre-máquina

Frecuentemente nos mostramos maravillados de cómo ha avanzado la manera en que interactuamos con la computadora en los últimos años, sin detenernos a pensar cuánta verdad hay –o no– detrás de esta afirmación. A fin de cuentas, hace apenas unos años el uso de las computadoras era verdaderamente limitado, y hoy en día están en todos lados, y parecería que cualquiera es capaz de manejarlas — Al menos, en sus funciones básicas.

Yo sostengo que esta es una afirmación falsa, basada en las apreciaciones de gente ajena a nuestro campo, y producto más de la popularización que de un verdadero cambio cualitativo. Claro está, al poner en duda lo universalmente aceptado, recae en mí sustentar mi afirmación.

Vamos, pues, con un breve recorrido de cómo evolucionó la interacción hasta el día de hoy.

Los inicios

Las primeras décadas del desarrollo de la computación como una disciplina aplicada de la ingeniería (tomando como punto de partida de forma un tanto arbitraria a la primer computadora electrónica en 1943, ENIAC) verdaderamente vieron un cambio radical en la manera en que los usuarios se aproximaban a la computadora — Esto resulta poco más que una obviedad, dado que antes de 1943 no existían las computadoras siquiera.

Las primeras computadoras no tenían nada que hoy reconoceríamos como interfaz — Tanto instrucciones como datos eran introducidos directamente a las ubicaciones de memoria al iniciar la ejecución a través de tarjetas perforadas, y eran leídos de los registros del procesador, mostrándolos directamente en un volcado binario, hacia tarjetas o cintas perforadas, que debían ser traducidas a algo legible empleando dispositivos mecánicos independientes.

Teletipos y terminales

El primer avance resultó en una dirección obvia, pero facilitó tremendamente tanto el uso como el aprovechamiento de los resultados: La interfaz textual. No hablo aún de una pantalla, sino de la adecuación del teletipo, híbrido de teclado e impresora, que comenzó su existencia como un reemplazo más ágil y confiable que el código Morse para la comunicación a larga distancia. El teletipo permitía ingresar programas mucho más complejos a memoria, lo cual llevó a que naciera y popularizara un concepto que nos parece muy ajeno a las interfaces de usuario: El de los archivos. Aparecieron los primeros editores (obviamente, mucho más espartanos de lo que conocemos hoy, y orientados a trabajo línea por línea), y como consecuencia directa, los programas pudieron comenzar a presentar una mucho mayor complejidad – llevando a la introducción de bibliotecas de código y a las diversas abstracciones y estrategias para manejar la complejidad.

La transición del teletipo a la pantalla no es tan simple como podría parecer. Dejando de lado la mera complejidad técnica (relativa al estado del arte de la época) de crear dispositivos independientes y de relativo bajo costo capaces de mantener comunicación con la computadora central, generando la imagen en pantalla del texto que iban recibiendo — lo cual implicaba que tuvieran una memoria interna, aunque mínima para estándares modernos1, las ventajas de tener terminales con cierto grado de inteligencia se hicieron obvias, y comenzaron a aparecer terminales con diferentes estándares2 capaces de reposicionar el cursor, o de desplegar texto con atributos (negritas, subrayado, colores), caracteres semi-gráficos, hasta verdaderas capacidades de formularios como las que manejaban las IBM 3270, que comenzaron a permitir desacoplar la lógica de un programa de su presentación tal como hoy lo vemos en los navegadores Web.

Las terminales además fueron centrales para la aparición de computadoras multitarea/multiusuario. Quienes gustamos de utilizar sistemas Unix utilizamos como una de nuestras herramientas más poderosas al emulador de terminal, o como le dice el resto del mundo, la ventana negra. Si bien las terminales como producto de hardware hace mucho tiempo que ya no existen para propósitos prácticos, la interfaz de línea de comandos programable permite un grado de expresividad tan rico que no ha podido ser reemplazado por ningún otro medio.

WIMP: Window, Icon, Menu, Pointer

En diciembre de 1968, en los laboratorios de Palo Alto de Xerox, Douglas Engelbart presentó la que al día de hoy se conoce como la madre de todas las demos: La introducción de la interfaz gráfica básica que seguimos utilizando hoy en día, manejada a través de un apuntador controlado por un mouse, presentando ventanas para la visualización de las diferentes aplicaciones en uso (o vistas de una misma aplicación), iconos representando atajos a las acciones de sistema disponibles, y con un menú como elemento estándar presentando las acciones relacionadas con cada aplicación activa. Y, claro, para la entrada y manipulación de datos dentro de cada aplicación, el dispositivo primario seguirá siendo el teclado.

La demostración de Engelbart incluía ejemplos de aplicaciones verdaderamente revolucionarias en esa época, como la videoconferencia, el correo electrónico, el hipertexto o un editor colaborativo de tiempo real.

Y aunque ha habido refinamientos sucesivos y grandes cambios en la parte estética de esta propuesta, para las computadoras de uso general seguimos utilizando este esquema de interacción — Con más de cuarenta años de antigüedad.

Interfaces de propósito acotado

Posiblemente el mayor cambio en las interfaces de usuario viene de que, cada vez con mayor fuerza, tenemos dispositivos con gran poder de proceso de cómputo sin un formato de computadora de propósito general. No veo como casualidad que hoy veamos con entusiasmo a las interfaces tan revolucionarias como las presentes en teléfonos celulares o consolas de videojuego — Estamos llegando al punto en que vamos encontrando formas muy convenientes de interactuar con computadoras de propósito acotado, aunque éstas no sean adecuadas para aquellas de propósito general. Ilustro esto con dos ejemplos:

Con la generación actual de consolas de videojuegos, Nintendo se anotó el mayor éxito al introducir su Wii: Una consola de relativamente bajas prestaciones y muy inferior a su competencia en las áreas en que típicamente competían, la capacidad gráfica. Sin embargo, su apuesta más fuerte fue hacia una interfaz novedosa: Los controles basados en acelerómetros, que permitieron modelar diferentes actividades como nunca antes se habían presentado en videojuegos.

Por otro lado, el iPod de Apple introdujo una interfaz largamente prometida, basada en una pantalla táctil de tamaño reducido, y orientada a equipos destinados al entretenimiento, a la consulta rápida de información, y especialmente popularizada a través del teléfono aparecido poco tiempo después. Sin embargo, si bien esta interfaz ha resultado natural para una gran cantidad de personas, resultaría indudablemente impráctica y antiergonómica para una computadora de propósito general.

Y claro, seguiremos viendo nuevas interfaces dedicadas a tareas específicas — Las más exitosas serán, sin duda, las más transparentes: Las que se integren de manera transparente a las tareas, mejorando nuestra vida sin requerir que reparemos siquiera en su existencia. Por ejemplo, ¿cuánta gente está consciente de la cantidad de cálculos que se realizan en un automóvil? ¿No es acaso uno de los mejores ejemplos de cómputo ubicuo que se ha insertado silenciosamente en nuestras vidas?

Otras ideas

Han habido, claro, otras muchas propuestas de interfaces para uso general. En general no han sido bien aceptadas, o han sido empleadas sólo en contextos muy específicos. Algunos ejemplos son:

Pantallas táctiles
Desde mediados de los 1980, Hewlett-Packard introdujo su línea de computadoras HP110, con una pantalla sensible al tacto. Esta interfaz prometía ser más ágil y natural que el mouse (que requiere un nivel de coordinación no trivial). Y si bien esta interfaz tuvo un moderado éxito en áreas como los kioscos (cajeros automáticos, puntos de toma de pedido en restaurantes de comida rápida, etc.), nunca fue del todo aceptada para un uso general por lo poco ergonómico que resulta tener que levantar la mano constantemente para apuntar a puntos de la pantalla.
Reconocimiento de voz
La ciencia ficción de los 1970 (piensen en HAL de 2001 o en la serie Star Trek) presentó a la voz como la principal forma de interacción hacia la computadora (y un combinación de voz y despliegue en pantallas para los resultados). Se han ensayado interfaces de reconocimiento de voz, pero han fallado una tras otra por la dificultad que presenta el lenguaje humano, la alta variabilidad de los elementos que permiten reconocer las palabras en diferentes idiomas e incluso con diferentes acentos. Además de esto, fuera de dar comandos puntuales, "dictar" un texto a la computadora no es una tarea tan simple como podría parecer: Al redactar un texto, el proceso normal que seguimos implica ir hacia atrás y hacia adelante, corrigiendo el texto, reemplazando y reformulando las frases. Una interfaz de dictado deberá saber discriminar el texto de las órdenes, lo cual requerirá un entrenamiento nada trivial al usuario.
Manipulación 3D
Presentar la información como objetos del mundo real, manipulables a través de guantes o gestos, aparece como muy atractivo. Podemos ver un ejemplo muy cuidadosamente desarrollado de una interfaz basada en estas ideas en la película Minority Report (Steven Spielberg, 2002). El poder de procesamiento y el hardware especializado para hacer este tipo de manipulaciones, sin embargo, no justifica –al día de hoy– el costo que significaría. Hay aplicaciones, claro, para las que este costo sí se justifica; en México, la Dirección General de Servicios de Cómputo Académico de la UNAM cuenta con la computadora especializada Ixtli para simulación y visualización, y si están interesados en conocer esta tecnología pueden solicitar visitas guiadas demostrando su funcionamiento.

Claro, hay muchas más ideas en el tintero, y en los años por venir seguro veremos varias más. Sin embargo, no ha habido cambios substantivos en las interfaces para interactuar con una computadora de propósito general en los últimos 40 años. Me resisto a creeer que esto sea porque el modelo actual sea perfecto; como desarrolladores, tenemos la tarea de proponer, adoptar y evaluar nuevos modelos de interacción.

1 Una terminal tonta, la categoría más simple de terminal, requiere de una memoria interna a partir de unos 2KB en anillo para representar los 80x25 caracteres que puede presentar en pantalla; (no olvidemos que las primeras computadoras personales que se vendieron al público, ya en los 1970, tenían típicamente una memoria total de 4Kb)

2 Estándares como ANSI, VT100, VT220, Wyse, y muchos otros que aún a 40 años de su introducción siguen en amplio uso

AttachmentSize
Versión impresa en la revista94.96 KB

Los muchos significados del «cómputo en la nube»: Desmitificando el concepto

TitleLos muchos significados del «cómputo en la nube»: Desmitificando el concepto
Publication TypeMagazine Article
Year of Publication2010
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
FrequencyQuarterly
Issue Number30
Pagination48-49
Date Published12/2010
Type of ArticleColumn
ISSN1870-0888
Keywordscloud computing, cómputo en la nube, IaaS, PaaS, SaaS
URLhttp://www.sg.com.mx/content/view/1125
Full Text

Uno de los términos ampliamente en boga en nuestro campo hoy en día es el cómputo en la nube. Tan en boga que me parece que se ha convertido en una palabra mágica, bastante hueca y sintomática de querer parecer en sintonía con los últimos desarrollos tecnológicos, sin comprenderlos en realidad. Además, al ser una frase que de golpe comenzó a escucharse con tanta insistencia, asumimos que es una estrategia nueva, una idea posibilitada por los nuevos avances tecnológicos — Y esto dista de ser el caso. En esta columna busco clarificar los conceptos y tipos básicos de cómputo en la nube, sus principales ventjas y desventajas, y brevemente encontrar paralelos con casos documentados de estos ”novedosos” conceptos
No critico, ojo, a las estrategias que están detrás de este sonoro término — Muy por el contrario, resultan muy convenientes a la hora de implementar, y como profesionales del desarrollo de software tenemos la obligación de estar familiarizados con ellas. Lo que critico es el abuso de un término ambíguo, que suele poner en problemas a los implementadores, al no estar claramente comprendido.
La mayor parte de las referencias que consulté mencionan a tres capas o niveles principales: El software –o la aplicación– como un servicio (Software as a Service, SaaS), la plataforma como un servicio (Platform as a Service, PaaS) y la infraestructura o el hardware como un servicio (Infrastructure as a Service, IaaS). Mi punto de vista, es que más que un nivel distinto, IaaS es un conjunto de cualidades adicionales que dan valor agregado a una oferta de PaaS.

SaaS: Bloques de construcción

Cuando uno de nuestros sistemas utiliza un API público remoto, o cuando para nuestro flujo de trabajo empleamos a una aplicación que reside y es administrada fuera de nuestra organización, estamos empleando SaaS. Nuestro proveedor puede cobrar su servicio de diversas maneras: A través de una renta directa, requiriendo del despliegue de publicidad, recibiendo autorización para recolectar nuestra información y hacer minería de datos sobre de ella — Hay una enorme variedad de esquemas, que refleja la gran variedad de niveles de integración que se puede dar a los servicios.
Notarán que la principal diferencia con los esquemas tradicionales cliente-servidor con que hemos trabajado desde hace décadas es el uso explícito de un proveedor externo — Sin embargo, técnicamente, nuestros sistemas no seguirán una lógica o un proceso de desarrollo diferente de como lo vienen haciendo por décadas.
Al mismo tiempo, sí hay una importante diferencia: Al no controlar nosotros el proceso que ocurre dentro de uno de nuestros subsistemas, nos vemos forzados a hacer bien lo que ya deberíamos estar haciendo: Implementar una separación limpia de responsabilidades entre los componentes, utiilzar exclusivamente las interfaces publicadas explícitamente — No brincarnos las capas de abstracción, como muchas veces estaríamos tentados a hacerlo en un proyecto meramente interno.
Hay un punto que no podemos perder de vista cuando empleamos un servicio de aplicaciones como parte de nuestra infraestructura en sistemas: Al depender de un tercero, ponemos en sus manos parte importante de nuestras promesas (y, por tanto, requerimientos), en tanto a disponibilidad, protección de datos y continuidad de la operación. Tocando el primer punto, resulta natural: Una falla en el servicio de cualquiera de nuestros proveedores de aplicaciones llevará a que nuestro sistema presente información incompleta o errónea a sus usuarios.
Respecto al segundo, no sólo debemos tener en cuenta las implicaciones directas (el proveedor tendrá acceso a todos los datos específicos que le enviemos para operar), sino que las indirectas: Todo ataque por medio del cual un agente hostil pueda llevar a cabo recolección de información sobre de nuestros proveedores resultará en la probable divulgación de información interna nuestra, e incluso el mismo proveedor puede estar realizando un seguimiento estadístico de nuestros patrones de uso, revelando mucho más de lo que podríamos querer darle.
En tanto a la continuidad de operación, si el proveedor del servicio decide cambiar los términos bajo los cuales brinda sus recursos, o si sencillamente deja de operar, podemos quedar sin una alternativa disponible para parte importante de nuestro flujo de trabajo.
Como corolario de la dependencia de terceros, al depender de aplicaciones como servicio perdemos la capacidad de planear las actualizaciones de nuestra infraestructura — Al depender de proveedores externos, en el momento en que cualquiera de sus APIs cambia, nos vemos forzados a actualizar de inmediato. Nuestros servicios en producción pueden fallar, y el mero concepto de rama estable pierde buena parte de su atractivo1.

PaaS+IaaS: Flexibilidad en el uso de recursos

Mientras que en el apartado anterior partíamos de que –desde el punto de vista del usuario– hay una aplicación central que corre en sus instalaciones y consume procesamiento realizado por componentes distribuídos por el mundo (”en la nube”), aquí la aplicación completa será desplegada en el proveedor de servicios. El usuario deja de emplear un servidor –o una granja de servidores– para consumir sólo los recursos. Y, consecuentemente, el esquema de utilidad para un proveedor de servicios bajo esta modalidad puede ir desde la renta a costo fijo hasta un cobro por uso de recursos, típicamente permitiendo reconfiguraciones dinámicas del paquete (del conjunto máximo de recursos) como respuesta a la demanda del sistema.
La justificación detrás de este concepto es que los servidores ”en casa” representan un gasto demasiado grande — Compra y actualización periódica de equipo, consumo eléctrico, uso de espacio físico y de ancho de banda, siendo que las instalaciones de la mayor parte de los usuarios no cuentan siquiera con un centro de datos. Además, todo servidor debe ser adquirido contemplando la carga estimada que sostendrá, pero contemplando un espacio para sobreconsumo en picos de actividad no planificable. En cambio, un proveedor masivo de servicios balancea el exceso de demanda de un usuario con la reducción de demanda de otro, permitiendo un menor sobredimensionamiento — Y una reducción neta de precios.
Nuevamente, apreciarán que la idea no es nueva — Los proveedores de presencia o de hosting existen desde hace muchos años en Internet. Más allá aún, precisamente este esquema fue planteado a mediados de los 1960, cuando fue desarrollado el sistema MULTICS2.
La principal diferencia con el esquema tradicional de renta de servidores es que bajo este esquema, el usuario deja de ser responsable de la administración incluso del servidor en el que se ejecutarán sus aplicaciones; el proveedor de servicios ofrece una cartera de plataformas administradas. Las plataformas pueden ser desde aplicaciones medianamente complejas, como plataformas Web que llevan un grado no trivial de configuración y representan una solución completa e integrada, hasta marcos para el desarrollo de sistemas (como Rails, Struts, Django, GWT), para los cuales los clientes sólo proveen el código específico de su aplicación, y aprovechan todo el andamiaje común que ya existe para una amplia base de clientes.
Respecto a consideraciones de seguridad y confiabilidad: Si bien al emplear PaaS no caemos ya en la trampa descrita en el primer apartado respecto a emplear código del cual no tenemos más conocimiento que el API, éste esquema sigue depositando todos nuestros datos en control del proveedor, en infraestructura compartida, con lo cual la probabilidad de que un ataque a un sistema sin relación aparente con el nuestro puede dar a un intruso acceso pleno a nuestra información.
El riesgo de que el proveedor cambie sus políticas de cobro a un esquema que no nos convenga se reduce también fuertemente, dado que en principio tenemos todo lo necesario para replicar la instalación con cualquier otro proveedor, o incluso migrar a una solución ”en casa”. Sin embargo, seguiremos sujetos a los días bandera de actualización forzada, dado que el proveedor típicamente ofrecerá la misma versión base a todos sus clientes — Y este factor puede dificultarnos una migración entre proveedores.
Hablando meramente de la conveniencia: Podemos enviar a uno de nuestros sistemas a la nube dados sus requisitos de almacenamiento de información, o de ancho de banda. Ahora bien, ¿cómo estamos realizando nuestros respaldos? Para poder hacer frente a contingencias, contar con una estrategia de respaldos buena y probada es mucho más importante aún que cuando hablamos de despliegues en infraestructura propia.
Por último, respecto al IaaS: Este resulta el más nebuloso y ambiguo — Ya no se trata de sistemas o entornos para que éstos se ejecuten, sino que de recursos de cómputo que están a nuestra disposición: Espacio en disco o en memoria, ”ticks” de procesador, ajuste de ancho de banda, como componentes discretos y ajustables en vivo — Atributos que se apoyan fuertemente en la virtualización para poder ser desplegados y controlados.
Hay quien incluye la virtualización de escritorios dentro de la definición de IaaS, pero si mucho, eso debe ser visto como consolidación de recursos y mejoría en el aprovechamiento de recursos, pero por calidad en el servicio debe hacerse utilizando recursos internos a la organización — Y por tanto, se aleja de las definiciones básicas de en la nube.
Llevamos años haciendo cómputo en la nube de un tipo o de otro. Al desmitificarlo un poco, espero abonar a una mejor utilización. Y al hablar acerca de los nada ignorables riesgos que conlleva, apunto a la cautela que debemos tener al adoptarlo, no entrar de lleno sólo porque es la moda.

AttachmentSize
PDF, versión publicada en la revista2.35 MB

2011

Columnas y artículos publicados en 2011

Identidad y reputación en línea: Esquemas de confianza

TitleIdentidad y reputación en línea: Esquemas de confianza
Publication TypeMagazine Article
Year of Publication2011
AuthorsWolf G
MagazineSoftware Gurú
Volume31
FrequencyQuarterly
Issue Number31
Pagination48-49
Date Published03/2011
Type of ArticleColumn
ISSN1870-0888
Keywordsconfianza, identidad, reputación
URLhttp://www.sg.com.mx/content/view/1159
Full Text

Querido amigo: Soy la señora Mariam Abacha1, viuda del finado General Sani Abacha, ex-jefe de gobierno de Nigeria. (…) Para salvar a mi familia de una total bancarrota, estoy buscando transferir el total de US$24,000,000 a través de una institución bancaria confiable. (…) Como pago por su ayuda, le ofrezco el 30% de lo que podamos rescatar de la fortuna de mi querido esposo.

El tema conducente del presente ejemplar de SG, Pagos en línea, cruza necesariamente por el tema de los esquemas de establecimiento de reputación en línea. Cada vez menos gente asume confiable cualquier dato que encuentra en Internet sencillamente por estar ahí. Un logro del que puede enorgullecerse la comunidad de expertos que apuntan a la necesidad de concientización en nuestro quehacer en red es que la generalidad de los usuarios, por lo menos, ya desconfía cuando le piden datos para tener acceso a su dinero. Sin embargo, ¿qué es lo que nos lleva a confiar en determinados proveedores?
El problema de establecer la reputación de un tercero puede presentarse como un muy interesante ejercicio académico, con anclas en muy diversas áreas del conocimiento, desde las ciencias sociales hasta las matemáticas.
En un plano mucho más aplicado, todo el problema de la reputación puede resumirse en las preguntas, ¿Puedo confiar en que la contraparte es quien dice ser?, y ¿Puedo confiar en que dice la verdad?. Enfocándonos a las aplicaciones actuales, podemos principalmente traducir estas preguntas en:

Confianza en la identidad

Seguramente habrán recibido alguna vez un correo similar a aquel cuyas primeras líneas reproduje. Afortunadamente, es poca la gente que cae en estos esquemas2. Lo primero que debe venir a nuestra mente es, ¿estoy realmente intercambiando correo con la Sra. Abacha?
Hemos aprendido a desconfiar de la identidad de los extraños. Y cuando un extraño nos propone una transacción económica, nuestra primer reacción es desconfiar. Cuando efectuamos transacciones a través del navegador, nos hemos acostumbrado a buscar indicaciones de que estemos hablando con un servidor seguro. ¿Qué es esto? ¿Cómo lo valida el navegador?
Más allá de aplicar el sentido común, hay dos esquemas principales que nos permiten confiar la identidad de una entidad –individuo o empresa– con la que podamos tener un intercambio que incluya información confidencial (que requiera mantenerse a resguardo de terceros, como el número de nuestra tarjeta de credito) o no-repudiable (que nos interese tener un comprobante de haber realizado determinada transacción¸ sea pública o privada, con la persona o entidad en cuestión; lo que se ha dado por llamar firma electrónica): El esquema centralizado, basado en autoridades certificadoras (CAs) y firmas corporativas, y el esquema descentralizado, basado en llaveros de confianza y firmas personales. Ambos están basados en la criptografía de llave pública, con implementaciones derivadas de la criptografía de llave pública. No profundizaré en cómo estos pueden utilizarse para el intercambio de información, sino sobre la metainformación: Cómo apuntan a la confiabilidad sobre la identidad de un actor.
Por un lado, tenemos a la infraestructura de llave pública (PKI). Este es el esquema que siguen los navegadores Web, punto de contacto que casi todos tendremos con los pagos en línea. Además de los navegadores, y el ocasional cliente de correo, muchos otros servicios pueden emplear certificados de esta naturaleza para realizar autenticación o cifrado3 — Pero estos dos son los más visibles a los usuarios en general.
Bajo un esquema PKI, nuestro navegador confiará ciegamente en la identidad de un conjunto de CAs centrales, definidas por el proveedor del softare4. Mientras un certificado esté firmado por una autoridad conocida, el navegador mostrará la conexión como segura.
Tenemos por otro lado a los esquemas basados en el esquema de llaveros de confianza. Éste esquema fue dado a conocer en los 1990, con el sistema de criptografía PGP, de Phil Zimmermann. Un llavero de confianza podría definirse como un sistema colaborativo, par a par: Cada participante del llavero firma la llave de los otros participantes a los que conoce personalmente, certificando confianza en que su identidad es verdadera5. Cuando un usuario quiere comunicarse con otro, puede ver cuál es el camino de confianza yendo entre individuos, y en base a la distancia y grado de conexión (y, por tanto, de certificación) que tiene determianda identidad, decidir el nivel de confianza que depositará en ésta.
Entonces, un servidor seguro no es sólo el que implementa una conexión cifrada, sino que aquél en cuya identidad puedo confiar. Emplear cifrado sólo tiene sentido cuando podemos confiar en la identidad de nuestra contraparte. De muy poco serviría que garantizáramos que toda nuestra comunicación llega cifrada hasta nuestra contraparte si dicho sistema no es el sistema destino — Si no verificamos la identidad de nuestra contraparte, un atacante podría interponer un servidor entre nosotros y nuestro destino, descifrando y cifrando nuevamente la comunicación, modificando o guardando los datos que juzgara necesario.
En un esquema PKI, basta con engañar a una CA respecto a nuestra identidad para tener la puerta abierta a interceptar las solicitudes de usuarios. Y, tristemente, esto ya hace mucho tiempo pasó del terreno del discurso académico al del mundo real: En 2001 fue detectado un certificado firmado por Verisign a nombre de Microsoft, otorgado a un individuo sin relación alguna con dicha compañía6.
A diferencia de PKI, en que un conjunto de firmas se ve como una serie de árboles con raíces en cada una de las CAs certificadas, una red de firmas basada en las ideas de Zimmermann nos aparece como una red fuertemente interconectada, y nos permite validar varios caminos de confianza entre dos participantes de esta red, y evaluar cada a uno de ellos basado en la confianza subjetiva que damos a los actores involucrados7.
No hay un esquema indiscutiblemente mejor que el otro — Son utilizados con fines distintos. Ambos tienen su ámbito de aplicación — Y si hoy podemos confiar en la confidencialidad, integridad y seguridad de las transacciones en línea, es por estos esquemas. Nuevamente, de muy poco nos serviría cifrar nuestras transacciones en un entorno hostil sin tener confianza en que la contraparte es quien esperamos que sea.

Reputación del individuo

Asumamos, sin embargo, que la Sra. Abacha nos convenció plenamente de ser ella. ¿Debemos por ello confiar en su oferta?
Es aquí donde entra en juego la reputación: Ya que tengo certeza de estar interactuando con la entidad deseada, saber si es una entidad con la que me conviene mantener una transacción es el siguiente albur. Y, en este caso, la reputación es algo que debe establecerse bidireccionalmente. No sólo al comprador le interesa saber que el vendedor le entregará un producto genuino y a tiempo, sino que al proveedor le interesa saber si el comprador tiene cómo pagarlo. No sólo al solicitante de un préstamo le interesa que el banco confíe en su capacidad crediticia, sino que al banco le importa saber si éste no ha faltado a sus obligaciones de pago. Si entro a un sitio de intercambio entre particulares, sea de venta directa o a través de subastas (y seguramente en ambos casos todos habrán pensado en cuál sitio pensé al escribir tan amplia categoría — Eso también entra en el amplio ámbito de la reputación), los individuos participantes tienen una calificación indicando su confiabilidad basada en su comportamiento previo.
O, saliéndonos del árido tema de las transacciones económicas, en un foro de discusión puede interesarme filtrar los mensajes para sólo ver los que más vale la pena leer — Y, sin recurrir a un sistema que requiera involucramiento masivo de los editores, la mayor parte de estos sitios basan este filtro dando un valor inicial dependiente de la reputación del autor.
La asignación de reputación es un área completamente dependiente del campo de aplicación, por lo que resulta imposible hablar de implementaciones como en la sección anterior.
Nuevamente, las restricciones de espacio me dejan apenas arañando el campo, apuntando a un gran área a tener en consideración para cualquier desarrollo que emprendamos en que pueda involucrarse el peso o la complejidad de las relaciones entre entidades complejas. Tomar estos elementos en cuenta de forma transversal a los diferentes dominios de aplicación nos llevará a variadas e interesantes consideraciones, que seguramente mejorarán no sólo la confiabilidad de nuestras transacciones, sino incluso la oportunidad y el valor de la información que presentamos a nuestros usuarios.

Notas al pie

1 El nombre de la Sra. Abacha es el más prevalente en los fraudes de pago anticipado; tristemente, su identidad y reputación son ya demasiado bajos. Mi intención no es dañarlo más, claro está, sino señalar un fenómeno preexistente
2 Sin embargo, una pequeña proporción de una cantidad absurdamente grande de correos enviados sigue resultando en buen negocio… Y es por ello que estos defraudadores siguen saturando nuestros buzones.
3 Encontraremos referencias a estos certificados como X.509; si vamos a implementar directamente opeaciones sobre los certificados, conviene hacerlo empleando la biblioteca libre openssl.
4 Por ejemplo, puede consultar la lista de CAs autorizadas por Mozilla en http://www.mozilla.org/projects/security/certs/included/index.xml
5 Es muy importante tener en cuenta que lo único que aquí se certifica es la identidad, no la confianza en la entidad en cuestión. La confianza será tratada en la siguiente sección.
6 Bruce Schneier: Fake Microsoft certificates, http://www.schneier.com/crypto-gram-0104.html#7
7 Por poner un ejemplo, si yo (llave C1DB921F) obtengo un documento firmado por Marcelo Tosatti (llave E8E1FE55), desarrollador del kernel de Linux, encuentro que (al día en que escribo este texto) estamos a tres "brincos" de distancia: http://pgp.cs.uu.nl/paths/C1DB921F/to/E8E1FE55.html, http://webware.lysator.liu.se/jc/wotsap/wots/latest/paths/0xC1DB921F-0xE...

AttachmentSize
Versión publicada por la revista (PDF)104.42 KB

Interoperabilidad: ¿A qué aspiramos cuando hablamos de ella?

TitleInteroperabilidad: ¿A qué aspiramos cuando hablamos de ella?
Publication TypeMagazine Article
Year of Publication2011
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
FrequencyQuarterly
Issue Number33
Pagination50-51
Date Published08/2011
Type of ArticleColumn
ISSN1870-0888
URLhttp://www.sg.com.mx/content/view/1216
Full Text

El pasado 2 de junio, participé en el foro «Software Libre en México, reflexiones y oportunidades», organizado por la Comisión de Ciencia y Tecnología del Senado de la República. En este foro tocamos cuatro temas principales (Educación, gobierno, industria y sociedad).
Si bien el objetivo explícito central del foro fue presentar ante los legisladores y medios interesados tanto los puntos de vista que tenemos los activistas del software libre como las historias de éxito, los avances y problemas con que nos hemos encontrado en los ya más de quince años que llevamos de existencia en nuestro país, posiblemente lo más importante que nos llevamos los participantes fue la reactivación de un grupo de discusión para tratar temas políticos relacionados con la tecnología, y con el factor cohesivo de estar interesados en la difusión del software libre.
Este grupo, coordinándose a través de una lista de correo pública1, está actualmente en proceso de definir los puntos de la agenda digital a presentar; el primero de ellos es el de la interoperabilidad.
El tema coincide con la presentación de la versión preliminar de un acuerdo de la Secretaría de la Función Pública (SFP), a ser discutido y –esperamos– aprobado en las próximas semanas o meses. Nos resulta de gran importancia no sólo analizar y proponer en lo relativo a esta temática hacia el interior de nuestro grupo (y de las instancias gubernamentales involucradas), sino que hacia los demás profesionales en el tema — Como lo son los lectores de esta revista. Dada la imposibilidad de proporcionar referencias a un documento aún inexistente y motivado por el interés que seguramente ésto causará a más de uno de ustedes, coloqué a su disposición una copia de una versión preliminar de este texto en mi sitio Web2.

Definición

¿A qué nos referimos con interoperabilidad?
Al enfrentar un desarrollo, un punto fundamental a considerar desde muy temprano es cuál será su límite o interfaz — Sea un sistema, un API sobre la nube, un servicio, un componente o una biblioteca, debemos delimitar por qué mecanismo recibiremos las solicitudes de los usuarios y por cuál le entregaremos los resultados. Del mismo modo, nuestro sistema parte de un contrato con diversos elementos (nuevamente, de cualquiera de los niveles antes descritos) que le brindarán facilidades, por ejemplo, de conectividad a red o de manejo de bases de datos. Hablar de interoperabilidad significa que en cada uno de dichos puntos, en cada una de las interfaces, el intercambio de datos se realice de forma tal que evite imponer dependencia en algún paquete específico, en los designios de algún producto que a futuro pudiera –de cierto modo– mantener como rehén sea al usuario final, al desarrollador, o a la entidad que requirió del desarrollo en cuestión.
En palabras del Grupo de Trabajo para la Interoperabilidad, de la Asociación Francófona de Usuarios de Software Libre3:

La interoperabilidad es la capacidad que tiene un producto o un sistema, cuyas interfaces son totalmente conocidas, para funcionar con otros productos o sistemas existentes o futuros y eso sin restricción de acceso o de implementación.

El borrador de la SFP divide la definición de interoperabilidad en cinco sub-definiciones:

Interoperabilidad
Definición del concepto global
Interoperabilidad organizacional
Homologar criterios y procedimientos entre distintas dependencias
Interoperabilidad semántica
Un manejo estandarizado del significado de los diversos conceptos
Interoperabilidad técnica
A las especificaciones técnicas que garantizan que los componentes tecnológicos de los sistemas de información están preparados para interactuar de manera conjunta
Neutralidad tecnológica
Busca que cada dependencia pueda elegir los programas y mecanismos más adecuados para su desarrollo sin que se favorezca o penalice a ninguno por criterios más allá de los puramente técnicos.

Del dicho al hecho

Quien pegue una etiqueta que diga "esta página Web se ve mejor con el navegador X" en una página Web es un nostálgico por los días viejos y malos, antes de la Web, cuando tenías muy pocas probabilidades de leer un documento escrito en otra computadora, otro procesador de textos u otra red.
— Tim Berners-Lee, Technology Review, julio 1996

El documento presentado por la SFP nos parece muy esperanzador, está escrito de forma clara y bastante exhaustiva. El cuidado que debemos ahora poner va principalmente hacia que el acuerdo no quede en letra muerta — Debe ser del conocimiento de las diversas dependencias y ser tomado en serio para beneficio no sólo de la población toda, sino que de cada una de dichas dependencias. Además, debe ser conocido y comprendido por la industria nacional de desarrolladores de software, dado que interoperar sin restricciones no únicamente beneficia al sector público, sino que –a fin de cuentas– a todos los implicados. Escribir software que no dependa de implementaciones específicas es sencillamente escribir mejor software.
Al día de hoy, como usuarios, tristemente nos resulta muy común encontrar, una y otra vez, ejemplos de cosas que podrían trivialmente ser interoperables, pero resultan no serlo — Y lo que es peor, sin razón alguna.
Ejemplos de lo que digo son demasiado comunes. Desde la aplicación desarrollada por el SAT para presentar la declaración de impuestos (desarrollada en Java, plataforma que se popularizó al ser la primera en impulsar explícitamente la interoperabilidad como su principal promesa), que sencillamente se niega a operar al ser llamada con cualquier navegador que no sea Internet Explorer, hasta el SUA del IMSS, única manera en que una empresa puede dar de alta y administrar a su plantilla de trabajadores ante IMSS e INFONAVIT, que requiere ser ejecutada en computadoras corriendo Windows. Y al igual que estos dos casos de altísima visibiliad, seguramente ustedes podrán citar a ejemplos adicionales que obligan a sus usuarios a emplear tecnologías específicas, sin justificación técnica alguna para hacerlo.
El pretexto más frecuente que encontramos ante cualquier solicitud de que algún sistema sea utilizable desde una plataforma distinta es el consabido eso es lo que hay y no podemos hacer nada al respecto; modificar la base de software ya desarrollado e instalado significaría una tarea titánica. Sin embargo, los servicios fundamentales que deben estar disponibles para toda la población deben ser priorizados — Resulta inaceptable que a la población en general se le imponga el requisito de emplear una tecnología específica (independientemente del papel dominante que ésta tenga actualmente en el mercado), especialmente dado el desarrollo y rápida adopción de estándares como HTML5, que permiten un despliegue extensivo de interfaces de usuario ricas y completamente multiplataforma.

Las múltiples facetas de la interoperabilidad

Pero hablar de interoperabilidad no se limita a permitir que usuarios con configuraciones diversas puedan usar los sistemas de gobierno — Como lo mencionamos en el primer apartado, parte importante de la interoperabilidad se refiere a cómo facilitar el intercambio de información entre entidades del mismo gobierno, a la creación de modelos estandarizados (la ya citada interoperabilidad semántica) con los que puedan representarse e intercambiarse datos acerca de las estructuras más comunmente encontradas y repetidas — Y que posiblemente facilite que paulatinamente se vaya creando, en vez de una colección de sistemas que conforman al e-gobierno, una nube de información con un mínimo de duplicación de información.
¿Y cómo elegir entre tantos estándares disponibles? ¿Qué formatos, protocolos y lenguajes son los más adecuados? ¿Cómo podemos determinar cuál es un estándar abierto? Este es un tema que da para largas discusiones, y motivo de los diferentes foros referidos. Cito lo que marca el Proyecto de Acuerdo al respecto:

Los estándares abiertos deberán tener, como mínimo, las características siguientes:

  1. Disponibilidad;
  2. Que los derechos de autor estén disponibles, libres de
    regalías y condiciones;
  3. Maduros;
  4. Internacionalmente aceptados;
  5. De fácil distribución, y
  6. Con amplio soporte en el mercado;

El sólo hecho de reducir la cantidad de datos redundantes (y por consiguiente avanzar en la larga lucha contra los peregrinares a mil ventanillas para cualquier trámite trivial) ya por sí sólo lo valdría. Agreguemos a esto que reducirá fuertemente la dependencia de proveedores únicos y de la permanencia en el mercado de productos específicos, fomentando el crecimiento de una verdadera industria de desarrollo de software.
Sigamos, pues, la discusión que se presentará sobre estos temas en los próximos meses. Este es un tema que indudablemente impactará el trabajo de todos nosotros, y en el que todos tendremos algo que aportar.

Referencias

1 Archivo público de la lista de correo
«discusion-softlibre-senado»

2 Proyecto del Acuerdo por el que se establece el Esquema de Interoperabilidad y de Datos Abiertos de la Administración Pública Federal
3 Grupo de Trabajo para la Interoperabilidad, AFUL

AttachmentSize
Versión del artículo (en PDF) como apareció impresa en la revista141.78 KB

Georeferenciación a nuestras espaldas

TitleGeoreferenciación a nuestras espaldas
Publication TypeMagazine Article
Year of Publication2011
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
Volume32
FrequencyQuarterly
Pagination46-47
Date Published05/2011
Type of ArticleColumn
ISSN1870-0888
URLhttp://www.sg.com.mx/content/view/1181
Full Text

La idea para la columna de este número surgió de una plática con mi padre, comentando acerca de un texto que él presentó, como parte del espacio de la Academia de Ciencias de Morelos en el periódico La Unión de Morelos el pasado 18 de abril1. En éste, habla acerca de la disparidad de las cifras reportadas ante la manifestación dirigida por Javier Sicilia en la ciudad de Cuernavaca (ésta, el miércoles 6 de abril), y acerca de métodos que podrían utilizarse para tener una estimación más precisa. Yo, como buen consultor, le sugerí algo bonito y preciso en teoría, pero impracticable para todos los que no contamos con el poder coercitivo gubernamental: Acceder a los registros de las compañías de telefonía celular, para averiguar cuántas personas entraron durante el periodo de nuestro interés a la región por donde cruzó la marcha. A fin de cuentas, una muy alta proporcionón de la población hoy en día cuenta con teléfono celular, y podría ser una buena manera no sólo de estimar la magnitud de la marcha, sino de hacerlo a lo largo del tiempo que duró.
Ahora, dado que la información que poseen las telefónicas no es pública, dejamos la conversación a un nivel puramente especulativo — Seguros de que las autoridades de Seguridad Pública tienen acceso a estos datos, pero que a la mayor parte de nosotros nos resultan inalcanzables, como no sea a través de una órden judicial.
En los días siguientes a esta conversación, sin embargo, se presentaron varias noticias que se me hicieron interesantes, y que vinculan a esta discusión relativa a la participación ciudadana en la política nacional con temáticas más cercanas a las que toca esta revista: El cómputo ubicuo, la rastreabilidad de un dispositivo móvil, la seguridad de la información de geolocalización, y nuestro derecho a controlar quién tiene acceso a ella.

Compañías telefónicas

Me encontré con un artículo publicado por el diario alemán «Zeit Online» el 26 de marzo2, que ilustra precisamente la profundidad de esta información: Malte Spitz, del Partido Verde alemán, presentó una demanda judicial para obligar a Deutsche Telekom a entregarle todos los datos suyos que tuvieran registrados en los últimos seis meses. Los datos están disponibles en crudo — Y adicionalmente, gracias a una simple aplicación Web3 realizada para presentar esta información de una manera fácil de comprender, nos hace ver la profundidad de los patrones de comportamiento que puede construirse de cada uno de nosotros: Ubicación geográfica, llamadas y mensajes recibidos/enviados, conexión de datos...
Si bien la geolocalización es mucho menos precisa que la que arrojaría un GPS (es obtenida por triangulación entre las torres de telefonía celular, resultando en una precisión de unos cien metros), el punto más importante es que esta información se genera y almacena centralmente, en las instalaciones del proveedor de telecomunicaciones, e independientemente de las capacidades tecnológicas de nuestro teléfono.
Y si bien Malte Spitz tuvo acceso a sus datos a través de los canales legales, ¿qué tanto podemos confiar en que dichos datos estén adecuadamente protegidos de los ojos de atacantes capaces de vulnerar servidores conectados a Internet? Precisamente, el experimento de Spitz fue llevado a cabo para sustentar el peligro de la ordenanza de 2008 que obliga (y por tanto permite) a las compañías de telecomunicaciones guardar esta información por medio año — Ordenanza que en marzo de 2010 fue declarada inconstitucional. En México nos hemos topado una y otra vez con casos en que datos confidenciales han sido encontrados en el mercado negro. ¿Qué nos indica que esta información, escalofriantemente precisa acerca de nuestros hábitos no está disponible al mejor postor?

Proveedores de hardware

Otro conjunto de noticias que aparecieron en los días recientes son los relacionados a la información de ubicación que guardan diversos teléfonos inteligentes y equipos similares: Los equipos iPhone e iPad de Apple que corren el iOS versión 4 o superior, guardan un registro histórico de los puntos por los que ha pasado el usuario4,5 (al igual que lo mencionado anteriormente, mayormente basado en triangulación contra las antenas celulares, aunque de mucho mayor precisión cuando el GPS está activado). Y si bien esto no debería sorprendernos, hay tres puntos clave en lo revelado:

  • Los datos son guardados sin cifrado, y son incluídos en todo respaldo hecho al dispositivo.
  • La licencia de uso del software permite expresamente a Apple recolectar, usar y compartir información precisa respecto a la ubicación, incluyendo la ubicación geográfica en tiempo real de tu computadora o dispositivo Apple.
  • La información recopilada no se limita a una ventana de tiempo preestablecida, sino que durará la vida entera del equipo.

Para verificar (y/o jugar) con esta funcionalidad, pueden instalar en cualquier computadora con la que hayan sincronizado un iPhone o iPad el iPhoneTracker (MacOS)6 o el iPhoneTrackerWin (Windows)7. En el sitio del iPhoneTracker hay una interesante lista de preguntas muy interesantes para entender este problema.
Claro, pero el que Apple controle los dispositivos que los usuarios han comprado no es novedad. Quienes me conozcan, probablemente esperan que haga a continuación una apología de por qué el software libre es más seguro, y por qué deberían todos cambiar a un teléfono basado en el sistema Android, de Google. Sin embargo, la situación no es tan distinta ahí.
Con la salvedad de que para que éste archivo exista el usuario tiene que haber aceptado previamente que el teléfono provea servicios relacionados con los datos de geolocalización (sin duda una muy importante característica de los equipos, y que poca gente dejará desactivada), los teléfonos Android guardan también información con nivel de detalle muy similar8. Esta información además no se mantiene a largo plazo: Los dispositivos Android guardan únicamente un número limitado de ubicaciones — Hasta 50 entradas derivadas de torres celulares, y hasta 200 derivadas de redes WiFi.
Ahora, de este último punto podemos aún jalar más hilo: Si bien el contrato de licencia del software de Apple permite que reciban todos los datos de ubicación, hasta el momento han negado estar utilizándolos. Sin embargo, al autorizar a Android, explícitamente estamos autorizando que esta información sea reportada a Google9 — ¿Y qué uso directo le dan? Los dispositivos con Android notifican a Google la ubicación de cada red inalámbrica que encuentran, como lo demuestra el sitio Web desarrollado por Samy Kamkar10: Los dispositivos informan a Google de la ubicación geográfica de cada red WiFi que encuentran.
Ahora bien, sé que este texto puede ser leído como una carta escrita por un paranóico de las teorías de la conspiración. No es así, estoy consciente de que la tecnología va cambiando nuestra vida, y que lo que para muchos puede ser visto como una invasión a la privacidad, para muchos otros representa la gran conveniencia tanto de contar con una ubicación razonablemente precisa en un tiempo aceptable como de poder compartirla con nuestros contactos en un tiempo pertinente.
Mi convocatoria, claro, al tiempo que lleva a que tengamos conciencia de los insospechados ojos que pueden estar aprendiendo de nuestras vidas con cualquier tipo de fines, también lleva a que, como desarrolladores de aplicaciones, sepamos ser creativos y aprovechar la información que tenemos a nuestro alcance — ¡Porque sin duda podrán encontrar también maneras lícitas y atractivas de emplear estas fuentes de información!

Referencias

  1. ¿Cuántos miles marchamos? — http://www.launion.com.mx/images/stories/Hemeroteca%20Virtual/2011/abril-2011/18-abr.pdf (pag. 34)
  2. Betrayed by our own data — http://www.zeit.de/digital/datenschutz/2011-03/data-protection-malte-spitz
  3. Tell-all telephone — http://www.zeit.de/datenschutz/malte-spitz-data-retention
  4. Secret iPhone location tracking — http://www.theregister.co.uk/2011/04/20/secret_iphone_location_tracking/
  5. How to See the Secret tracking Data in Your iPhone — http://www.pcmag.com/article2/0,2817,2383943,00.asp
  6. iPhoneTracker — http://petewarden.github.com/iPhoneTracker/
  7. iPhoneTrackerWin — http://huseyint.com/iPhoneTrackerWin/
  8. It’s not just the iPhone, Android stores your location data too — http://thenextweb.com/google/2011/04/21/its-not-just-the-iphone-android-stores-your-location-data-too/
  9. Google Android privacy concerns — http://www.theregister.co.uk/2011/04/22/google_android_privacy_concerns/
  10. Android Map http://samy.pl/androidmap/
AttachmentSize
Versión publicada en Software Gurú106.29 KB

Software libre, cultura libre

TitleSoftware libre, cultura libre
Publication TypeMagazine Article
Year of Publication2011
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineRevista Zocalo
VolumeXI
Frequencymonthly
Issue Number137
Pagination42-43
Date Published07-2011
ISSN1665-8698
Full Text

Software libre

Cada vez es más común escuchar el concepto software libre en medios destinados a la sociedad en general, y ya no sólo ante quienes nos dedicamos al cómputo. Pero no teman — En el presente texto, abordaré el tema enfatizando en él en tanto movimiento social, enfocándome en cómo ha comenzado a influir en la sociedad toda.
Desde un punto de vista meramente técnico, puede llamarse software libre a todo programa que no imponga un licenciamiento restrictivo a sus usuarios — Todo programa que nos permita utilizarlo con cualquier fin, comprender cómo está hecho (tener acceso a su código fuente), adecuarlo a nuestras necesidades, y compartirlo con otras personas. Entre los programas más conocidos que califican como software libre encontramos al sistema operativo Linux en sus muchas variantes, la herramienta ofimática OpenOffice, el navegador Web Firefox, una gran variedad de programas de rango servidor, y un larguísimo etcétera.
Pero el software libre va mucho más allá de un producto técnico: Es un movimiento social en toda forma. A mediados de los 1980, Richard Stallman acuñó el concepto, formalizó los requisitos arriba descritos, y creó a la Free Software Foundation y al Proyecto GNU, que habría de convertirse en el sistema operativo completo; es a partir de esto que consideramos que una forma de desarrollar y compartir se convierte en movimiento. Su planteamiento partió de una fuerte base ideológica, de la necesidad del libre acceso al conocimiento. Por años, la FSF se enfrentó a las críticas y escepticismo respecto a la viabilidad del proyecto. Específicamente, ¿Por qué miles de programadores donarían de su esfuerzo de desarrollo de software en beneficio de la humanidad?
El proyecto GNU sobrevivió lo suficiente para crear una base mínima utilizable, y obtuvo una masa crítica suficiente para impulsar con cada vez más fuerza su desarrollo hasta el día de hoy. Pero lo fundamental es que el fenómeno trascendió a la comunidad original, y creó a todo un abanico de ideologías, en lo técnico y en lo social. Al día de hoy, habemos decenas de miles de desarrolladores trabajando de manera completamente descentralizada, cada quién persiguiendo sus propios incentivos (que si bien en algunos casos son económicos, directos o indirectos, en otros son por afición, por diversión, incluso de inspiración artística).

¿Por qué funciona?

Ahora, ¿por qué éste cambio cultural se presentó antes que en ningún otro lado en el desarrollo de software?
El proceso natural humano de construcción de conocimiento (la forma en que aprendemos, pensamos y reelaboramos los avances) atraviesa necesariamente por la socialización — Por compartir los avances, los pensamientos, por que un experto corrija al otro. El software libre no puede explicarse sin Internet, sin comunicación ágil y directa entre los participantes.
Internet no es un fenómeno nuevo. Tiene ya más de 40 años de edad — Obviamente, en primer término se difundió en los círculos militares y académicos. Y naturalmente, la convocatoria del proyecto GNU se difundió inicialmente dentro de Internet, cayendo y difundiéndose en un campo fértil.

Hacia la cultura libre

El movimiento del software libre ha encontrado grandes puntos de coincidencia con diversos grupos sociales y culturales, y conforme van encontrando puntos de coincidencia, se arma un movimiento que promete ser mucho mayor, e incluso cambiar la forma en que opera la creación del conocimiento en el mundo entero: La cultura libre. Y es aquí donde comienza el engranaje hacia lo que sostengo que es la evolución natural del movimiento.
Podemos ya encontrar varios ejemplos de éxito. Posiblemente el más notorio hoy en día sea Wikipedia, un proyecto de construcción de un cuerpo de conocimiento libre y carente de la noción tradicional de autoría: Una enciclopedia escrita por todos, corregida por todos, mejorada con todos. No está exenta, claro, de problemas de control de calidad, pero va encontrando mecanismos que cada vez más aumentan su confiabilidad.
Wikipedia tiene, por cierto, un antecedente que muestra la importancia de la participación abierta en un proyecto colaborativo: La Nupedia. El proyecto Nupedia fue lanzado en el año 2000 (un año antes del de Wikipedia), buscando crear una enciclopedia de libre acceso y redistribución que garantizaba la calidad de sus contenidos por medio de la revisión por pares. Sin embargo, pese a las buenas intenciones, en los primeros 18 meses sólo se publicaron 20 artículos. Buscando de nuevas fórmulas para involucrar a más personas en la producción de contenidos, se pensó que los usuarios de crearan los contenidos que luego los editores y expertos revisarían. Mientras tanto, nació el proyecto Wikipedia, y en tan sólo su primer mes de existencia llegó a los 1000 artículos — Cierto, algunos de no muy buena calidad, pero todos constituyeron una semilla a partir de la cual cualquiera podía participar para mejorarla. Y el resultado es lo que hoy ya conocemos: Una enciclopedia verdaderamente universal, con más de 3 millones de artículos, y con más de 30 lenguajes cuya versión local supera los 100,000.
La iniciativa Creative Commons es otra digna de nota: Toda creación intelectual o artística recibe protección automática de derechos de autor. Muchos queremos que nuestras creaciones sean libremente redistribuibles, pero puede desmotivarnos el obstáculo del lenguaje legal que implica elegir una licencia adecuada. En 2001, el abogado estadounidence Larry Lessig creó a Creative Commons. Esta organización ofrece un marco legal para que gente no experta en estos temas pueda elegir los términos de licenciamiento que juzgue más adecuados para su creación, sin tener que ahondar de más en las áridas estepas legales, y se mantiene asesorada y liderada por un grupo de abogados, cuya principal labor es traducir y adecuar sus licencias base para cada una de las jurisdicciones en que sean aplicables.
Han nacido también una gran cantidad de servicios en línea que buscan ser centro de contacto para que creadores independientes puedan distribuir su material sin depender de casas editoriales. Jamendo es una comunidad en línea dedicada a promover a artistas que publiquen música bajo licencias Creative Commons. Cualquiera puede entrar y bajar una gran cantidad de música de muy buena calidad, hacer donativos directos a los grupos de intérpretes y promover nuevo material.
Y no sólo las formas de compartir y colaborar que a lo largo de 30 años han dominado al desarrollo de Software Libre están permeando a las diversas áreas creativas de la humanidad: El conjunto de valores que impulsaron a Stallman a iniciar el movimiento resultan compartidos por estos creadores, y su ideología de a pocos va convirtiéndose en parte del fundamento cultural de la sociedad.

¿Y en qué radica el cambio?

No quiero cerrar este texto sin puntualizar algunos factores principales que determinan el sentido que está tomando esta revolución:
A diferencia de lo que ocurría hace pocos años (con las fotocopias o con los cassettes), los contenidos pueden reproducirse de manera fiel, sin pérdida alguna de calidad, y con costo casi-cero — Los contenidos se han liberado de sus soportes.
Además, distancia entre el creador y el consumidor se reduce fuertemente. Cualquiera puede hoy en día publicitar su material a través de su propia página Web (o de servicios de terceros), facilitándose la distribución de material y la retribución directa a los titulares.
El marco jurídico que norma a los diversos aspectos de la propiedad intangible tiene casi tres siglos, y requiere –por puntos como los aquí expuestos, y por muchos más que no sería a abordar en un texto como éste– de grandes adecuaciones y replanteamientos. Y sin lugar a dudas, el tema aquí abordado representa un cambio social imparable.
El avance de la humanidad ha sido históricamente determinado por la facilidad de comunicación — Estamos en un punto de quiebre, en un momento que determina un cambio fenomenal en nuestro desarrollo. Y éste movimiento, que nació en una esfera aparentemente muy aislada del resto de la sociedad, se ha configurado en una avalancha imparable que modificará muchos de los supuestos básicos alrededor de los cuales se estructura el sistema.

Referencias

Free Software Foundation
http://www.fsf.org/
Proyecto GNU
http://www.gnu.org/
GNU Manifesto
http://www.gnu.org/gnu/manifesto.html
Definición de licencias de cultura libre
http://freedomdefined.org/Definition/Es
Creative Commons
http://creativecommons.org/
Jamendo
http://www.jamendo.com/
AttachmentSize
Primera página del artículo tal como aparece publicado en la revista938.32 KB
Segunda página del artículo tal como aparece publicado en la revista944.04 KB

Monitoreo de PostgreSQL con Munin

TitleMonitoreo de PostgreSQL con Munin
Publication TypeJournal Article
Year of Publication2011
AuthorsWolf G
Refereed DesignationRefereed
Journal TitleRevista Cubana de Ciencias Informáticas
Volume5
Issue1
Pages1-8
Start Page1
Journal Date09/2011
ISSN1994-1536
Keywordsanálisis de tendencias, desarrollo, monitoreo, Munin
Abstract

Una de los principales tareas del trabajo diario de un administrador de sistemas, redes o bases de datos es el monitoreo de recursos. Con herramientas adecuadas de monitoreo, el administrador puede no sólo detectar un problema antes de que cause interrupciones en la operación de los sistemas, sino que puede prevenir que ocurran, conociendo la evolución histórica de los valores relevantes. En el presente trabajo presento el marco de recopilación y graficación de datos Munin, enfocándome a su uso para monitorear el gestor de base de datos relacional PostgreSQL, así como en la flexiblilidad y facilidad con que administradores y programadores pueden adecuarlo para desarrollar plugins específicos para el monitoreo de sus necesidades puntuales.

URLhttp://rcci.uci.cu/index.php/rcci/article/view/91/85
AttachmentSize
PDF file published in the journal391.24 KB

Producir y reproducir el conocimiento

TitleProducir y reproducir el conocimiento
Publication TypeMagazine Article
Year of Publication2011
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineHorizontes: Los nuevos saberes
Date Published09/2011
Full Text

Las culturas del denominado mundo occidental han transitado por grandes etapas claramente diferenciadas — Si bien no hay un criterio único, en líneas generales podríamos hablar de cinco: Prehistoria, antigüedad, edad media, edad moderna y era contemporánea. Uno de los principales factores de quiebre que marca el salto de una a otra es la forma que tiene la humanidad de difundir el conocimiento — Historia, cultura, nuevas ideas. Y hoy estamos sin duda alguna a las puertas de un nuevo cambio, que con toda seguridad replanteará el mismo funcionamiento de la sociedad.
La antigüedad, primer etapa de la civilización inicia con la invención de la escritura — Ya no es indispensable que el sabio en turno reúna todos los conocimientos de su cultura; al dejarlos por escrito, puede aumentarse el total de conocimiento sin que sea a la vez propiedad y responsabilidad de una persona o un reducido grupo. Además, la muerte del viejo sabio no significa volver al punto de partida.
La edad media inició con la caída del imperio romano: Al colapsar la red de caminos, al surgir bandas de ladrones que imposibilitaban el tránsito, y al no haber ya un idioma oficial para todas las comunicaciones del mundo conocido, el desarrollo del conocimiento sufrió un fuerte freno.
No podemos concebir que inicie la era moderna sin la invención de la imprenta: Durante siglos, el conocimiento fue patrimonio de muy pocos, principalmente de ecleciásticos, en una institución altamente conservadora. Al volverse posible la reproducción masiva de los documentos (en contraposición a esperar meses o años a que un copista reproduzca un único ejemplar), la explosión en el saber y en el contacto entre culturas sencillamente destruyó el órden establecido, y sólo a través de éste cambio llegamos a una sociedad que comienza a ser comparable con la actual.
Pero tardó aún varios siglos la formación de una masa crítica de gente capaz de leer y escribir. En un principio, los libros circulaban sólo entre científicos y religiosos. Poco a poco, más gente obtuvo acceso al conocimiento — y no es casual que en todo el mundo occidental inicie con pocos años de diferencia la era de las revoluciones, y con ella la era contemporánea: El tener acceso a debates, a ideas, el plantearse siquiera la existencia de derechos fundamentales, dieron inicio a la revolución francesa, la independencia de los Estados Unidos, seguidas por las de Latinoamérica, y continuaron con la mezcla de debates y guerras en que se convirtieron los siguientes dos siglos. Más enfocado a la temática que busco abordar: En 1710 apareció el Estatuto de la Reina Ana, el antecedente directo de las actuales leyes de derechos de autor, estableciendo un periodo de 14 a 28 años durante el cual tendría efecto un monopolio legal del autor sobre las reproducciones que pudieran hacerse de su obra, pasado el cual ésta pasaría a convertirse en dominio público.
Me atrevo a apuntar que un cambio tan grande como el que supuso la imprenta lo supuso también el mimeógrafo, inventado en los 1880: Montar un taller tradicional de imprenta, de tipos de plomo fundido, si bien es más fácil que copiar libros a mano y uno a uno, sigue requiriendo una gran inversión económica y de tiempo para cada obra. Un mimeógrafo es muy económico y portátil, y un original puede prepararse en minutos. Los mimeógrafos fueron un agente fundamental para las revoluciones ideológicas de inicios y mediados del siglo XX. En México, la época de la revolución vio el nacimiento de una gran cantidad de publicaciones, mini-periódicos, que reproducían caricaturas y corridos –la forma más fácil de llevar las noticias y la ideología a un abundante público– precisamente gracias al bajo costo y facilidad de operación de los mimeógrafos.
Claro está, estoy seguro de que al leer ustedes los elogios que hago al mimeógrafo, les resultará obvio hacia dónde es que quiero dirigirme: El punto de quiebre que estamos cruzando hoy está representado por el acceso prácticamente universal a Internet. Y este cambio se presenta por varios factores: Como nunca antes en la historia, hoy podemos reproducir y diseminar el conocimiento: 1) sin que importen límites o distancias geográficas; 2) con un costo de reproducción casi cero; 3) es posible publicar de inmediato, sin necesidad de un proceso editorial; 4) todo mundo puede publicar sus obras sin la intervención de intermediarios, sin controles impuestos, sin censura, y sin responder a criterios de mercado.
Estos cuatro puntos sacuden –nuevamente– los cimientos de grupos políticos y económicos muy poderosos en nuestra sociedad. Al cambiar la realidad, debe cambiar la normatividad. Específicamente, hoy nos encontramos con que las leyes de derecho de autor no se ajustan ya a la realidad actual — Si bien los legisladores han intentado actualizar las leyes que reglamentan a la propiedad intangible, los supuestos de la producción y la reproducción del conocimiento han cambiado de forma fundamental. En las últimas tres décadas han ido apareciendo grupos –desde los diferentes ámbitos de la creación cultural– que cuestionan la pertinencia de leyes ya obsoletas, definitivamente no adecuadas a la realidad actual.
La industria editorial es de gran importancia económica, pero se enfrenta a una irremediable obsolescencia. A lo largo de los últimos 80 años, el término de protección de derechos de autor se ha sextuplicado, protegiendo los primeros ejemplos de propiedad intangible masivos de la historia (los primeros personajes animados de Walt Disney — ¡Resulta triste descubrir que Mickey Mouse dirija las políticas públicas en materia de creación cultural!). Al mismo tiempo, sin embargo, han nacido grupos de creadores que defienden la libertad del conocimiento y de las artes — Organizaciones de todo tipo, como Free Software Foundation, Creative Commons, Wikipedia o Public Library of Science nos muestran una gran diversidad de conocimiento, de la más alta calidad, creado y distribuído sin pasar a través de los filtros de la industria editorial.
El momento histórico en el que nos ubicamos nos presenta grandes retos, grandes oportunidades, a la mayor escala posible. Está en juego el que podamos aprovechar la tecnología para crear una verdadera nueva etapa en el desarrollo de la humanidad toda. No podemos permitirnos desaprovecharlo.

AttachmentSize
Printed edition: first page (photo)874.28 KB
Printed edition: second page (photo)963.58 KB

Repensando las certificaciones

TitleRepensando las certificaciones
Publication TypeMagazine Article
Year of Publication2011
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
Issue Number34
Pagination50-51
Date Published11/2011
Type of ArticleColumn
ISSN1870-0888
URLhttp://www.sg.com.mx/content/view/1242
Full Text

Diversas personas me han preguntado qué certificaciones deberían buscar para afianzar su carrera o posición, o por otro lado, cuál conviene a una empresa buscar en un prospecto de contratación. Me llama la atención principalmente el que asuman la respuesta a un cuestionamiento previo y condicionante a éste: ¿Vale la pena buscar certificaciones? Esta pregunta me puso a pensar en lo relativo a quién las pide (tanto desde el punto de vista del individuo que las persigue como del contratante que las valúa); dado el público alcanzado por esta revista, creo que puede ser de interés enfocar la columna hacia este tema.

¿Qué es una certificación?

Para el presente análisis me centro en las certificaciones como un documento emitido por una entidad comercial no dedicada principalmente a la educación superior, validando que el sustentante posee el dominio de un conjunto específico de herramientas o tecnologías (típicamente, aunque no necesariamente, limitadas a las generadas por la organización certificadora).
Las certificaciones difieren de otros métodos de cualificación en que normalmente son otorgadas ante la presentación y aprobación de un examen; típicamente no requieren que el sustentante siga un curso.
Además de lo anterior, las certificaciones típicamente tienen –a diferencia de prácticamente cualquier programa académico– una validez determinada, ya sea por un tiempo preestablecido, o por estar atadas a tecnologías específicas, con un ciclo de vida y obsolescencia planificado.
Y un punto adicional: Las certificaciones, si bien se presentan a sus clientes potenciales como una oportunidad de obtener mejores cualificaciones para aumentar sus evaluaciones (redundando directamente en beneficios económicos), en ningún momento buscan ocultar que son para sus promotores un negocio antes que ninguna otra cosa. Lo cual, claro, no es ningún pecado — Pero sí es un punto a considerar al evaluarlas.
Consideremos dos perfiles en particular — Los dos antiperfiles donde, a mi forma de ver, las certificaciones juegan en contra de la mayor parte tanto de individuos como de empresas.

Antiperfil 1: El recién egresado

El argumento para buscar certificaciones es simple: Si cuando un postulante es evaluado para un puesto laboral, el entrevistador de primer contacto no tiene un perfil técnico, sino que busca descartar a quien no cumpla con las características básicas que busca la empresa, en realidad la primer entrevista "real" se presenta una vez pasado ese filtro. El Can Cerbero corporativo no permitirá el paso del postulante si no cuenta con el altero completo de papeles.
Este punto de vista apunta a un postulante novato, probablemente recién egresado de la universidad, sin experiencia laboral en el mundo real, que no ha tejido aún redes profesionales y no encuentra una mejor vía de acceso. Este punto crece especialmente cuando estos nuevos integrantes de la fuerza laboral buscan emplearse en una de las relativamente pocas grandes empresas consultoras de desarrollo que hay en nuestro país.
Las certificaciones que están al alcance de un recién egresado, sin experiencia en el campo, son relativamente pocas — Y el peso económico de perseguirlas resulta relativamente elevado. Muchas universidades han incorporado a los servicios que ofrecen a los alumnos el prepararlos para alguna certificación básica y reducir el precio a pagar por ella. Esto, a mi modo de ver, equivale a que dicha universidad se reconozca incapaz de ofrecer una formación suficiente para que sus egresados encuentren un puesto de trabajo adecuado, y –al impulsar una tecnología específica– demerita la universalidad de la formación que dio nombre a las universidades desde un principio.

Antiperfil 2: El experto en certificaciones

Un perfil que nace como consecuencia lógica del anterior es el del experto en certificaciones. Si por cada examen que presento crece mi elegibilidad laboral, ¿por qué no acumularlos? Aprender el material necesario para presentar un examen es, a fin de cuentas, una habilidad que puede ser aprendida y dominada. Si bien muchas certificaciones incluyen la resolución de problemas prácticos, siguen presentándose en un entorno donde, hasta cierto punto, las situaciones presentadas son muy distintas a las de la vida real.
Por otro lado, una persona altamente calificada no necesariamente sabrá presentar un examen, cosa que a ninguno de ustedes debe sorprender — Los ejemplos abundan; traigo ante ustedes a uno en particular, aunque sea sólo como evidencia anecdótica: He tenido oportunidad de trabajar con algunas personas veraderamente talentosas, referencia en el campo de la seguridad y administración de sistemas, que frecuentemente asesoran a los técnicos de empresas transnacionales. Uno de ellos intentó certificarse en uno de los temas en que es pionero en nuestro país, y no logró aprobarlo.
¿Significa esto acaso que su conocimiento de la tecnología, las herramientas y los procesos es menor que el de quien sí aprobó el curso? Definitivamente, no. Sólamente significa que los procesos mentales que ésta persona sigue no se alínean con los que la empresa certificadora sugiere. Y es precisamente esto lo que le ha permitido convertirse en su asesor: El seguir procesos creativos, no buscar dentro de lo predecible, y tener un verdadero conocimiento profundo del sistema como un todo.

Alternativas

Y pasando de la crítica a la propuesta, ¿qué puedo aportar tras mi crítica a este modelo?
Para un recién egresado, enfrentarse al mounstro corporativo sin experiencia real previa, cierto, no da espacio a la negociación. Mientras las empresas sigan imponiendo estos filtros previos a la entrevista real, ¿qué puede hacer quien inicia su carrera profesional?
Ser recién egresado no significa no tener experiencia real. Entrar a estudiar una carrera relacionada con la computación debería indicar una genuina afición al pensamiento analítico. En nuestro campo, tenemos la gran fortuna de que un aficionado puede –sin estudios, sin equipo profesional, sin cualificaciones formales– desarrollar proyectos en casi cualquier ámbito del campo. En el cómputo, todos ustedes podrán citar numerosos ejemplos que han contribuído al campo de forma decisiva, sin formación profesional.
Claro, sería iluso pensar que todos coordináramos proyectos de gran envergadura siendo aún adolescentes o que impulsar una idea exitosa nos lleve a abandonar los estudios profesionales y saltar a la fama como estrellas de la programación. Sí podemos, sin embargo, ir haciendo públicos los pequeños proyectitos que hacemos, los retos interesantes que vamos resolviendo, los programas que escribimos por gusto. Publicar código, especialmente como software libre, es una muy buena manera de demostrar capacidad profesional, compromiso, capacidad de documentar y de brindar soporte a los usuarios. Es más, si nuestro proyecto juguete fue adoptado por una distribución de Linux, esto resulta clara muestra de que otros expertos juzgan nuestro trabajo digno de ser promovido.
Respecto al segundo antiperfil, el caso presentado ilustra que las competencias laborales de un profesional con trayectoria no pueden ser juzgadas de manera meramente cuantitativa — Los diversos campos relacionados con el cómputo requieren de una gran creatividad, y no pueden ser juzgados como una materia de la escuela, en que el desarrollo del resultado debe ser idéntico al que nos fue impartido en clase.
Quien busca contratar a un profesional con trayectoria no puede limitarse a evaluar en base a los certificados presentados. En mi experiencia, las veces que mi recomendación ha sido requerida para un proceso de selección de personal, coloco en último lugar todos los currículos que presentan certificaciones de forma destacada. Nunca me he arrepentido de hacerlo — Estos tienden a ser los que menos conocimiento real tienen del campo.
El que una entrevista laboral para un puesto que requiere conocimientos especializados –sean de un estudiante recién graduado o de un experto– tenga que pasar por un filtro no conocedor de la materia es síntoma de un problema estructural: La tercerización a los corporativos de desarrollo de software ha crecido en detrimento de la capacidad de las entidades que las contratan. No con esto digo que deban desaparecer — Si bien debe ampliarse la capacidad de respuesta de los departamentos de sistemas de quienes típicamente contratan a estas empresas (entiéndase: Ampliarse su tamaño, sus áreas de especialización, y la seguridad laboral brindada a sus integrantes), muchos de los proyectos podrían perfectamente ser encargados ya sea a empresas de escala más humana (PyMEs), o contratar a grandes empresas verdaderamente especializadas en un ramo específico. Esto, claro, reduciría el tamaño de las consultoras — Pero aumentaría su calidad, y aumentaría las oportunidades laborales con una justa comparación basada en méritos reales, más cerca de quien verdaeramente requiera del servicio.
Por otro lado, no todos los proyectos en que participamos –por hobby o por encargo– puede ser publicado. Sin embargo, permítanme insistir en que la mejor carta de presentación es el trabajo realizado. En otras áreas laborales es común –incluso en algunos países, obligatoria– la pertenencia a colegios de profesionales — Cuerpos que establecen las normas mínimas de operación, calidad y cobro en el campo, y guardan registro de la actividad de sus agremiados. De tal suerte, en vez de requerir un certificado emitido por una empresamente claramente parcial y con innegables intereses económicos en el área, habría una entidad a la cual preguntar acerca de la experiencia comprobable de un postulante.
Los colegios citados nacieron dada la necesidad de una entidad que validara –y asumiera responsabilidad ante dicha validación– de profesiones en las que puede haber amplia responsabiliad civil, como la medicina o la arquitectura. La importancia que van adquiriendo los desarrollos hoy en día nos lleva a plantear si no es momento de una reglamentación similar en nuestra área.
Hay, sí, lugar para las certificaciones. Hay trabajos en que hace falta contratar a alguien que domine una tecnología específica, aún sin ser un –probablemente sobrecalificado– experto en el ramo entero. La distorsión, a mi opinión, está más en la escala que han adquirido. No pueden ser requeridas como carta de presentación, no puede dárselas un peso comparable al de un estudio prolongado y general (como un título universitario) o al de las capacidades demostradas con trabajo.

AttachmentSize
Versión facsimilar de la publicada111.92 KB

2012

Columnas y artículos publicados en 2012

Programación funcional: Enfrenta a la concurrencia

TitleProgramación funcional: Enfrenta a la concurrencia
Publication TypeMagazine Article
Year of Publication2012
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
Issue Number35
Pagination48-49
Date Published01/2012
Type of ArticleColumn
ISSN1870-0888
URLhttp://sg.com.mx/buzz/programar-es-un-estilo-vida
Full Text

El tema eje de el presente número de Software Gurú es el manejo de datos a muy gran escala (y disculparán que no use la frase más de moda en la industria, Big Data, habiendo otras igual de descriptivas en nuestro idioma). Al hablar de muy gran escala tenemos que entender que pueden ser juegos de datos mucho mayores de lo que acostumbramos — Estamos hablando de un aumento de por lo tres a seis órdenes de magnitud en la escala de los datos a analizar: Según las definiciones más comunes hoy en día, en el rango entre decenas de terabytes y petabytes.
Dar un salto tan grande nos presenta retos en muy diversas esferas. Para muchas de las necesidades que enfrentamos, tenemos que adecuar nuestros procesos de desarrollo, las herramientas que empleamos, el modelo con el cual almacenamos, solicitamos y procesamos la información, e incluso el hardware mismo. Enfocaré este texto a un paradigma de programación que permite enfrentar a la concurrencia de una forma más natural y menos traumática de lo que acostumbramos.
Una de las razones por las que este tema ha armado tanto alboroto en el campo del desarrollo de software es que, si bien la capacidad de cómputo a nuestro alcance ha crecido de forma francamente bestial desde casi cualquier métrica en el tiempo que nos ha tocado vivir como profesionales, nuestra formación sigue estando basada en un modelo de desarrollo muy difícil de escalar. Vamos, el problema no lo tienen las computadoras, sino nosotros los programadores: No sólo tenemos que explicar a la computadora lo que requerimos que haga, sino que además de ello tenemos que cuidar que no se tropiece –cual si fuera un ciempiés– con su propia marcha. Siempre que hablemos de muy gran escala debemos hablar, sí o sí, de un alto grado de paralelismo en nuestras aplicaciones. Y por muchos años, el paralelismo fue precisamente algo de lo que buena parte de los programadores buscaban escapar, por las complicaciones que conlleva ante una programación imperativa, necesariamente secuencial.
Las alarmas comenzaron a sonar fuertemente hacia el año 2005, en que los fabricantes de hardware tuvieron que cambiar su estrategia (y lograron, sorprendentemente, inyectarle algunos años más de vida a la ley de Moore, la cual indica que el número de transistores que componen a un chip se duplica aproximadamente cada dos años, ritmo que se ha mantenido por 40 años ya): Al migrar el desarrollo de procesadores una estrategia de multiprocesamiento (CPUs múltiples empaquetados como una sóla unidad), dejando de lado la carrera de los megahertz, aventaron la papa caliente hacia el lado de los desarrolladores: Tendríamos que adecuarnos a una realidad de concurrencia verdadera y ya no simulada.
Los sistemas multiprocesador no son, claro está, tan recientes. El gran cambio es que ahora prácticamente todas las computadoras de rango medio (incluso ya algunos teléfonos celulares) tienen esta tecnología disponible. Claro está, todo el software de infraestructura, desde los sistemas operativos, compiladores y bibliotecas tuvieron que irse adecuando gradualmente para poder administrar y ofrecer al usuario estos recursos.
Por muchos años, vivimos sabiéndolo en un mundo de falsa concurrencia: Una computadora sólo podía hacer una cosa a la vez, dado que contaba con un sólo procesador. Por la velocidad de su operación, y por el empeño que se puso en que los cambios de contexto fueran tan ágiles como fuese posible, nos daba la impresión de que varias cosas ocurrían al mismo tiempo. Esto, claro, no debe sorprender a ninguno de ustedes — El gran reto introducido por el paralelismo real es manejar correctamente escenarios mucho más complejos de condiciones de carrera que antes no se presentaban tan fácilmente. Antes del paralelismo, podíamos indicar al sistema operativo que nuestro programa estaba por entrar a una sección crítica, con lo cual éste podía decidir retirar el control a nuestro programa para entregarlo a otro si estaba cercano a finalizar su tiempo, o darle una prórroga hasta que saliera de dicha sección.
Cuando hay más de un procesador (un CPU multicore o multinúcleo alberga a varios procesadores, en ocasiones compartiendo elementos como uno de los niveles de memoria cache), la situación se complica: El sistema operativo puede, sí, mantener en ejecución a uno de los programas para reducir la probabilidad de conflictos, pero se hizo indispensable hacer la colaboración entre procesos algo explícito.
Claro, esto no fue un desarrollo repentino ni algo fundamentalmente novedoso. Los mutexes nos han acompañado por muy largos años, y la programación multihilos nos ha regalado dolores de cabeza desde hace muchos años. Sin embargo, en sistemas uniprocesador, la incidencia de condiciones de carrera era suficientemente baja como para que muchos las ignoraran.
Una de las razones por las que la concurrencia nos provoca esos dolores de cabeza es porque nos hemos acostumbrada a enfrentarnos a ella con las herramientas equivocadas. Un tornillo puede clavarse a martillazos, y no dudo que haya quien use destornilladores para meter clavos, pero tendremos mucho mayor éxito (y un tiempo de entrega mucho más aceptable) si usamos la herramienta correcta.
Los lenguajes basados en programación funcional resuelven en buena medida los problemas relacionados con la concurrencia, y pueden de manera natural desplegarse en un entorno masivamente paralelo. Sin embargo, requieren un cambio más profundo en la manera de pensar que, por ejemplo, cuando adoptamos la adopción de la programación orientada a objetos.
¿Cuál es la diferencia? Aprendimos a programar de forma imperativa, con el símil de la lista de instrucciones para una receta de cocina — Los lenguajes puramente funcionales son mucho más parecidos a una definición matemática, en que no hay una secuencia clara de resolución, sino que una definición de cómo se ve el problema una vez resuelto, y los datos se encargan de ir marcando el camino de ejecución. Los lenguajes puramente funcionales tienen una larga historia (Lisp fue creado en 1958), pero en la industria nunca han tenido la adopción de los lenguajes imperativos. Hay una tendencia en los últimos 20 años, sin embargo, de incorporar muchas de sus características en lenguajes mayormente imperativos.
La principal característica que diferencía a los lenguajes funcionales que nos hacen pensar en definiciones matemáticas es que la llamada a una función no tiene efectos secundarios — ¿Han depurado alguna vez código multihilos para darse cuenta que el problema venía de una variable que no había sido declarada como exclusiva? Con la programación funcional, este problema simplemente no se presentaría. Esto lleva a que podamos definir (en AliceML) el cálculo de la serie de Fibonacci como:

      fun fib 0 = 0
        | fib 1 = 1
        | fib n  if (n > 1) = spawn fib(n-1) + fib(n-2);
        | fib _ = raise Domain
    

A diferencia de una definición imperativa, la función es definida dependiendo de la entrada recibida, y la última línea nos muestra el comportamiento en caso de no estar contemplado por ninguna de las condiciones. Y el puro hecho de indicar la palabra «spawn» indica al intérprete que realice este cálculo en un hilo independiente (que podría ser enviado a otro procesador, o incluso a otro nodo, para su cálculo).
Otra de las propiedades de estos lenguajes, las funciones de órden superior (funciones que toman como argumentos a otras funciones). Por ejemplo, en Haskell:

      squareList = map (^2) list
    

Al darle una lista de números a la función squareList, nos entrega otra lista, con el cuadrado de cada uno de los elementos de la lista original. Y, obviamente, esto se puede generalizar a cualquier transformación que se aplicar iterativamente a cada uno de los elementos de la lista.
Hay varios tipos de funciones de órden superior, pero en líneas generales, pueden generalizarse al mapeo (repetir la misma función sobre los elementos de una lista, entregando otra lista como resultado) y la reducción (obtener un resultado único por aplicar la función en cuestión a todos los elementos de la lista). Y es, de hecho, basándose en juegos de mapeo/reducción que se ejecutan la mayor parte de las tareas intensivas en datos en Google.
Podemos encontrar frecuentemente otros dos patrones en estos lenguajes, aunque por simplicidad no los incluyo en estos ejemplos: Por un lado, al no tener efectos secundarios, tenemos la garantía de que toda llamada a una función con los mismos argumentos tendrá los mismos resultados, por lo que un cálculo ya realizado no tiene que recalcularse, y podemos guardar los resultados de las funciones (especialmente en casos altamente recursivos, como éste). En segundo, la evaluación postergada: Podemos indicar al intérprete que guarde un apuntador a un resultado, pero que no lo calcule hasta que éste sea requerido para una operación inmediata (por ejemplo, para desplegar un resultado, o para asignarlo a un cálculo no postergable).
Una de las grandes desventajas que enfrentó la programación funcional es que los lenguajes funcionales puros crecieron dentro de la burbuja académica, resultando imprácticos para su aplicación en la industria del desarrollo. Esto ha cambiado fuertemente. Hoy en día podemos ver lenguajes que gozan de gran popularidad y han adoptado muchas construcciones derivadas de la programación funcional, como Python, Ruby o Perl. Hay lenguajes funcionales que operan sobre las máquinas virtuales de Java (Clojure) y .NET (F#). Por otro lado, lenguajes como Erlang, OCaml y Scheme se mantienen más claramente adheridos a los principios funcionales, pero con bibliotecas estándar y construcciones más completas para el desarrollo de aplicaciones.
El manejo de cantidades masivas de datos están llevando a un pico de interés en la programación funcional. No dejen pasar a esta interesante manera de ver al mundo - Puede costar algo de trabajo ajustar nuestra mente para pensar en términos de este paradigma, pero los resultados seguramente valdrán la pena.

AttachmentSize
As printed in the magazine (page 1)990.48 KB
As printed in the magazine (page 2)982.7 KB

Los juegos: Clave para el desarrollo del cómputo

TitleLos juegos: Clave para el desarrollo del cómputo
Publication TypeMagazine Article
Year of Publication2012
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
Issue Number36
Pagination50-51
Date Published05/2012
Type of ArticleColumn
ISSN1870-0888
Full Text

En el principio era el tiro parabólico

El desarrollo de juegos está relacionado con el desarrollo del cómputo prácticamente desde sus inicios. A pesar de que durante décadas las computadoras estaban al alcance únicamente de algunas grandes (y muy serias) instituciones militares y académicas, ya desde la década de 1940 hubo acercamientos lúdicos a diversos temas con fines de investigación: En 1947, Thomas T. Goldsmith Jr. y Estle Ray Mann diseñaron un primitivo sistema (controlado por una computadora de únicamente ocho bulbos) que mostraba en una pantalla tipo televisión la trayectoria descrita por misiles, cuyos parámetros dependían de la posición de varias perillas. Este "juego" no implementaba lógica alguna de detección de colisiones: El usuario colocaba una plantilla con su objetivo sobre la pantalla. Y podríamos imaginar las hipotéticas discusiones de los niños acerca de si dió en el blanco o se pasó apenitas (hipotéticas, claro, porque el sistema, si bien fue patentado con tal fin, nunca llegó al mercado).
Este primer juego era prácticamente un desarrollo natural, si tomamos en cuenta que las primeras computadoras electrónicas funcionales fueron creadas durante la segunda guerra mundial precisamente para hacer cálculos de trayectorias balísticas. Pero no deja de llamar la atención que uno de los juegos que más se asocia con el éxito de las aplicaciones en plataformas móviles, Angry Birds de la compañía finlandesa Rovio Mobile (comercializado en 2009 — ¡60 años más tarde!) sigue siendo básicamente un juego de tiro parabólico, aderezado con elementos gráficos y humorísticos, y con un sinfin de nuevos niveles y actualizaciones.

¡Y en Cambridge se juega así!

Pocos años más tarde, en 1952, Alexander S. Douglas escribió una versión gráfica del juego del gato (muy atinadamente llamada OXO) como proyecto para su tesis doctoral de interacción hombre-máquina en la Universidad de Cambridge, en una época en que no existían aún los dispositivos de entrada y salida (teclados y pantallas) que hoy damos tan por sentado, modo de interacción que apenas comienza a sentir presión de cambio tras cerca de 50 años.
Para 1959 aparecieron los primeros juegos gráficos en el MIT: Otra implementación del gato y el ratón en el laberinto. Estos juegos eran controlados por una pluma lumínica, con una forma de interacción, aunque salvando las distancias que más de 40 años ponen en el medio, muy similar a la táctil, que se ha puesto de moda en dispositivos móviles.

Jaque al rey: Persiguiendo la inteligencia artificial

Otro de los grandes hitos del desarrollo del cómputo que fueron marcados a través de los juegos es una gran subrama de la inteligencia artificial que llevó al diseño de incontables algoritmos de exploración de árboles de decisión con demasiados estados posibles para una búsqueda exhaustiva: A diferencia del gato, donde hay un máximo de 26,830 juegos posibles, la explosión combinatoria de posibilidades en el ajedrez, y la importancia de seguir una estrategia con un horizonte a varios movimientos. Si bien ya ha quedado demostrado que jugar ajedrez no demuestra inteligencia, buscar cómo enfrentarse a un oponente humano con cierto grado de éxito sí marcó grandes hitos en el desarrollo de esta importante disciplina.
En 1950, Claude Shannon publicó el artículo "Programming a Computer for Playing Chess" en la revista "Philosophical magazine". En 1951, Dietrich Prinz presentó un programa capaz de encontrar si era posible llegar a un mate en dos jugadas (un gran logro, dados los límites de la memoria a esas alturas). Para 1958, Alex Bernstein programó un jugador de ajedrez capaz de llevar a cabo un partido completo, aunque bastante fácil de vencer.
Y desde ahí, continuó el perfeccionamiento de los jugadores automatizados de ajedrez, hasta que en 1997 IBM alcanzó el hito de derrotar al campeón mundial en esa época, Gary Kasparov, con su computadora Deep Blue. Y cabe mencionar que, si bien el motor que animó a la exploración y desarrollo de técnicas
automatizadas para jugar ajedrez como parte del avance de la inteligencia artificial, esto no significa que Deep Blue sea más inteligente que Kasparov o, de hecho, que sea calificable de inteligente: El hito que se logró es optimizar un algoritmo de búsqueda específico a un problema dentro de un campo con un espacio de posibilidades que puede considerarse efectivamente infinito.
Si les interesa leer específicamente acerca del desarrollo del ajedrez como disciplina computacional, les sugiero visitar http://chessprogramming.wikispaces.com/.
Para cerrar este apartado: Otra razón que da especial importancia al ajedrez dentro del listado que estoy presentando es que, de entre los juegos primigenios, éste es el primero en el que la computadora asume un rol activo: No se limita a presentar el tablero, llevar el estado del juego o asegurarse de que los jugadores efectúen movidas legales, sino que es el primer intento que se hace de sobrepasar competitivamente al humano, colocándolo en el lugar del contrincante.

Gráficas, redes... ¡A matar marcianitos!

En la década de 1960, las computadoras proliferaron en las universidades, y cada vez más, ya no eran sólo los profesores quienes podían utilizarlas, sino que los alumnos comenzaron a tener acceso y, obviamente, llegó un gran influjo de nuevas ideas. Para 1961, los alumnos del MIT Martin Graetz, Steve Russell y Wayne Witanen crearon el primer juego con uno de los temas más recurrentes de esta categoría: La guerra en el espacio, precisamente con el juego «Spacewar!» — Y en este caso, a diferencia de los mencionados anteriormente, lo hicieron puramente por diversión, para aprender a programar la unidad gráfica vectorial de la computadora DEC PDP-1 recién adquirida por su universidad.
Spacewar! era un juego hecho para dos jugadores que se enfrentaban en un duelo espacial, con interacción en tiempo real, aunque necesariamente frente a la misma consola. Este juego llegó a ser tan popular que se convirtió en uno de los programas empleados como demostración por el personal de DEC.
Paralelamente, eran cada vez más comunes los sistemas de tiempo compartido, donde varios usuarios podían sentarse cada uno frente a su propia terminal y usar la misma computadora. Estas computadoras además ofrecían normalmente la capacidad de comunicarse entre sesiones. No tardaron en aparecer los primeros juegos multijugador, en los que cada uno de los participantes asumía un rol distinto. En 1971 fueron desarrollados juegos como Star Trek o Baseball, en que los participantes tenían que actuar como equpios.
Los primeros juegos de acción multijugador con perspectiva 3D en primera persona (First-person Shooters) llegaron en 1974: Spasim (Space Simulator), en los sistemas PLATO de la Universidad de Illinois, y Maze War, en el centro AMES de Investigación de NASA en California.
Y hacia mediados de los 1970, ya con Internet floreciendo entre las principales universidades de Estados Unidos, comenzaron a aparecer varios MUDs, mundos en línea de aventuras interactivas, verdaderamente multijugador, presentando prácticamente todos los elementos que esperaríamos hoy de los juegos en plataformas de interacción social — Cierto, acorde a la tecnología disponible, pero con niveles de interacción social muy cercanos a los que conocemos hoy.

El BBS: Las redes para el resto de nosotros

Ya en los 1980, tras la explosión de la revolución de las computadoras personales, pero mucho antes de la masificación del acceso a Internet, grupos de aficionados de todo el mundo comenzaron a conectarse entre sí con los medios que la tecnología ofrecía: Comenzaron a aparecer Sistemas de Boletín Electrónico (Bulletin Board Systems o BBSes), computadoras personales de entusiastas conectadas a una línea telefónica, programadas para recibir llamadas de quien quisiera pasar un rato por ahí, para platicar en los foros, intercambiar archivos — O participar de los juegos multijugador, aunque en este caso, dado que las conexiones eran telefónicas, casi todos eran con una interacción basada en turnos.
No puedo dejar de mencionar a los BBSes dado que, hacia principios de los 1990, fui operador de uno de los aproximadamente 20 BBSes que hubo en la Ciudad de México por aquellos días. Llegamos a tener comunidades vibrantes, de aproximadamente mil usuarios, que poco a poco fuimos migrando a Internet. Algunos de los juegos BBSeros, como el TradeWars 2002, reaparecieron años más tarde en Internet, aunque manteniendo en su formato original basado en texto en una terminal de 80×25 caracteres.
Como en tantos otros casos, en el campo de los juegos por computadora el verdadero desarrollo e inovación se dio cuando no había aún referentes, en las primeras décadas. Y aunque el mundo de los juegos parece compeltamente distinto hoy de lo que era hace 5, 10 o 20 años, la principal diferencia es el uso de gráficos y sonido, o la capacidad de almacenamiento (y por tanto, de interacción) a disposición del usuario, no las ideas principales.
Hemos, a últimos años, visto muy interesantes cambios en la forma de interacción, con los controles basados en acelerómetros (Nintendo Wii) o en reconocimiento de imágenes (Kinect). Queda mucho por explorar, por inventar. Y dado cómo han ido de la mano el avance del cómputo y de los juegos, espero que los lectores de esta revista inyecten nueva vida y nuevas ideas en este campo. Estas ideas indudablemente terminarán alcanzando a nuestra disciplina completa.

AttachmentSize
Versión impresa — Primera página1.17 MB
Versión impresa — Segunda página1.23 MB

Voto Electrónico, 2012

TitleVoto Electrónico, 2012
Publication TypeMagazine Article
Year of Publication2012
AuthorsWolf G
MagazineSoftware Gurú
Issue Number37
Pagination44,45
Date Published08/2012
ISSN1870-0888
URLhttp://sg.com.mx/revista/voto-electr%C3%B3nico-2012
Full Text

¿Más acerca de votaciones? Sí, escucho el clamor de todos nuestros lectores, después de un proceso electoral más, de haber nuevamente soportado meses de saturación de candidatos en los medios. Sin embargo, este es el momento justo para analizar una importante parte del proceso electoral en la cual los desarrolladores de software, expertos en seguridad y administradores de sistemas podemos ejercer influencia sobre el rumbo que sigue el país — Y darnos el lujo de ignorar nuestro rol de profesionales hablaría muy mal de cada uno de nosotros. Es por esta razón que presento esta actualización de estado y reflexión acerca de lo que puede esperarle a nuestro país de avanzar las propuestas de adopción del voto electrónico.
Los lectores asiduos de Software Gurú podrán recordar que abordamos ya este tema en el número 27 (febrero del 2010)1. Desde entonces, tuve oportunidad de participar en algunas publicaciones2 en las que expliqué los puntos básicos acerca de por qué toda implementación que pueda hacerse de voto electrónico, sin importar las mejores intenciones o incluso la pericia técnica del equipo que entregue una solución, no hay manera de que ésta resulte más confiable y garantice mejor cuidado de los derechos del votante que una revisión hecha por humanos de votos emitidos en papel.

1 Urnas electrónicas

Cuando nos hablan del voto electrónico, casi siempre pensamos directamente en las urnas electrónicas, estaciones de propósito específico diseñadas y configuradas para recibir directamente cada uno de los votos de los electores. Sus proponentes argumentan a su favor principalmente por tres razones: Reducción de costos, tiempo de entrega de resultados y mayor confiabilidad en el proceso. Estos tres puntos, como lo explico en los artículos citados anteriormente, se vienen abajo incluso ante una revisión somera del tema.
En México, el tema de las urnas electrónicas no nos resulta nuevo. Los primeros intentos fueron pilotos limitados en el Distrito Federal, en el año de 2003, y en Coahuila, en 2005, para las elecciones locales. En ambos casos, las urnas fueron desarrolladas en casa, y aplicadas a muy pequeña escala.
Para Coahuila, en 2008 la experiencia se repitió en 11 municipios. Las urnas se emplearon en 10 de ellos, pero en San Buenaventura, los partidos PAN, PANAL y PT impidieron su implementación dado que, argumentaron podría resultar fraudulenta3.
Una muy extraña característica del voto en Coahuila es que, para ”asegurar” que todos los votos correspondieran con la voluntad ciudadana, los votantes tenían que emitirlo por vía electrónica y firmar el comprobante emitido por la urna, depositándolo en una segunda urna para el eventual caso de un recuento. Esto, obviamente, viola al principio de la secrecía del voto, y permite el control corporativo o la compra del voto.
En el Distrito Federal, tras años de aparente silencio, el Instituto Electoral local (IEDF) intentó implementar urnas electrónicas de
manufactura industrial. Tras haber firmado contrato con la empresa Pounce Consulting para la adquisición de 1000 urnas electrónicas, a mediados de abril tomó la decisión de rescindirlo4 por demoras injustificables en la entrega de los equipos, así como por 28 fallas como:

…Ensamblados incompletos, chapas trabadas, ranuras abiertas en el depósito de votos, micas transparentes, bases derrapantes, puertos extraíbles sin protección, compartimiento del cable sin tapa y carga lenta de la batería.

En este caso, lo destacable es que, si bien grupos de académicos de la UNAM y el IPN localizaron estas 28 fallas, lo que verdaderamente detuvo a la implementación de la urna electrónica fue la demora en la entrega de los equipos. Eso se traduce en que, muy probablemente, el IEDF continuará intentando implementar urnas electrónicas — Y nosotros como sociedad tenemos que mantenernos atentos.
Por último, veamos el caso de Jalisco: El Instituto Electoral y de Participación Ciudadana (IEPC) aprobó que para la votación local se empleen urnas electrónicas en los distritos 1 y 17 y en el municipio
de Gómez Farías, para un 11% del padrón total. Tras una licitación muy cuestionada5, la empresa ganadora fue también Pounce Consulting. En este caso, al igual que en el DF, la empresa demoró la entrega de las urnas en casi seis semanas, apenas entregando a tiempo cuando ya se analizaba la cancelación del contrato.
Previo a la elección, se realizaron cinco simulacros para presentar la urna a la población, y para ir corrigiendo los problemas que presentaran — Al que más seguimiento se le dió fue al que afectaba la secrecía del voto (podía verse el testigo impreso de los votantes anteriores). Las variaciones eléctricas han llegado causaron, al menos en una ocasión, impresión descontrolada de votos, y en los simulacros se han reportado urnas pre-cargadas6.
El modelo de urna empleado en Jalisco incluye no sólo el acopio de la votación, sino que la transmisión de los resultados por vía de telefonía celular a las cabeceras distritales. Esto, si bien está protegido por criptografía, abre nuevas vías de ataque: No sólo cada una de las urnas se conecta a la red celular (aunque sea sólo por breves instantes al cerrarse la votación), sino que los equipos centrales deben estar a la escucha. Esto permite no sólo un ataque que comprometa el sentido de los votos emitidos, sino que abre la puerta para ataques negación de servicio.
Un problema reportado en cerca del 20% de las urnas fue, precisamente, la falta de cobertura celular. El distrito 1 de Jalisco cubre la parte norte del estado, una zona de profundas barrancas y de una gran cantidad de poblados de muy difícil acceso — Y que no tienen cobertura de telefonía celular. El planteamiento de realizar las votaciones con urnas que contemplan la transmisión de datos por esta vía no sólo revela una profunda desconexión respecto a la población objetivo a cubrir, sino que –al presentar distintas vías para que se lleve a cabo el acopio de la información– abre un vector más para el ataque, ya no tanto técnico sino que a través de la ingeniería social.
Un punto alarmante de la implementación en Jalisco es el traslado de la figura legal de lo que constituye un voto. Si bien las urnas empleadas emiten testigos para asegurar la posibilidad de un recuento (cabe mencionar, no es universalmente aceptado que esto sea garantía suficiente), el documento de validez legal no es el papel testigo sino que el estado interno de la memoria de la urna electrónica. En caso de presentarse un recuento, citando al consejero electoral Carlos Martínez Maguey, ”existe la posibilidad de que […] se puedan contar los testigos de voto, no es vinculante el resultado del testigo de voto, pero siempre nos dará el mismo resultado que la base de datos”. Los votos están en la memoria, y el papel únicamente da fé de ello. Esto es, en Jalisco se ha legalizado la desmaterialización del voto. Y si bien el proceso electoral mexicano –como siempre– todavía da para muchas impugnaciones, hay reportes de inconsistencias7 entre el números de votantes del IFE y del IEPC en la misma casilla.

2 Voto no presencial

México es un país fuertemente expulsor de migrantes, principalmente a los Estados Unidos, pero a muy diversos puntos del mundo. Parte importante de los migrantes mexicanos, además, están en una situación de precariedad legal que les hace imposible registrarse como residentes legales o desplazarse libremente en su país de residencia, por lo cual el modelo que requiere registrarse y desplazarse hasta una embajada o consulado no aplican. Se han planteado dos modalidades para realizar el voto no presencial: El voto en línea y el voto postal.
Antes de analizar estas alternativas, es muy importante explicitar a lo que renunciamos con ambas: Perdemos la garantía de que el votante sea verdaderamente quien dice ser. En caso del voto postal, es bastante probable que el votante correcto reciba el paquete con las boletas en la dirección indicada, pero mantiene la necesidad de registrar una dirección postal permanente, lo cual rompe con el planteamiento de origen.
En el caso del voto electrónico, la perspectiva es peor aún, porque si bien el potencial elector podía registrarse presentando los datos de su credencial electoral, las instrucciones y contraseña le son enviadas por correo electrónico. La confiabilidad y la confidencialidad de los proveedores de servicios de correo electrónico, especialmente de los gratuitos (que son por mucho los más frecuentemente utilizados) no garantizan que sea genuinamente el votante quien los revisa, especialmente en el caso de la población con menor dominio de la tecnología. Lo que es más: En un escenario como el ampliamente impugnado en las elecciones recién ocurridas, la compra de votos se vuelve trivial: Basta con que el votante entregue su contraseña en los días previos al operador electoral, y que éste verifique el poder votar por su propio partido, para la entrega de los recursos económicos.
En una plática informal con personal del IEDF, me indicaron estar al tanto de esta realidad, pero –dada la cantidad de población registrada– era un riesgo aceptable: Para este año, hubo 10,786 empadronados — Únicamente el 0.13% del padrón, pese a la grandísima campaña en medios. De ellos, apenas 4192 optaron por hacerlo en línea.

3 Conclusiones

Si bien he definido mi postura al respecto desde hace tiempo ya, he buscado honestamente expertos en seguridad en cómputo independientes (no asociados con empresas vendedoras de sistemas del rubro) dispuestos a argumentar a favor del voto electrónico, y honestamente no he encontrado a ninguno. Sin embargo, el voto electrónico tiene un atractivo desde un punto de vista político — y hay un gran negocio en ofrecer soluciones basadas en él. Nosotros, como profesionales del ramo, más que buscar la oportunidad de negocio espero sepamos responder con los argumentos que hacen del voto electrónico un verdadero peligro para la democracia.
Los vendedores de urnas tienden a argumentar que ha habido elecciones exitosas con voto electrónico, y justifican los fracasos indicando que fueron fallos puntuales de implementación. Sin embargo, nuestro punto es que es precisamente imposible hacer una implementación tan segura y confiable como lo que plantean reemplazar.
En una prueba piloto, o incluso en una primera implementación, es muy poco probable que se presente un ataque. En ambos casos, estaríamos hablando de implementaciones muy controladas, en que prácticamente si se registra una falla es por un error más que por un ataque.
Desde hace algunos meses hemos estado alimentando al Observatorio del Voto Electrónico8. Invito a los interesados a emplearlo como fuente de información, y de unirse a nuestro trabajo de análisis y difusión.

Pies de página:

1 http://sg.com.mx/content/view/919
2 http://seminario.edusol.info/seco3/pdf/seco3_apend3.pdf
3 http://www.eluniversal.com.mx/notas/631827.html
4 http://www.eluniversal.com.mx/ciudad/111073.html
5 http://votodigital.wordpress.com/2011/11/11/notas-de-una-escandalosa-licitacion-que-arriesga-el-voto-electronico/
6 http://www.lajornadajalisco.com.mx/2012/05/15/todavia-es-viable-aplicar-el-voto-electronico-en-el-estado-figueroa/
7 http://www.informador.com.mx/jalisco/2012/388153/6/el-iepc-desmiente-irregularidades-en-votacion-electronica-de-distrito-1.htm
8 http://evoto.iiec.unam.mx/

AttachmentSize
PDF94.64 KB

México, el voto electrónico y el 2012

TitleMéxico, el voto electrónico y el 2012
Publication TypeMagazine Article
Year of Publication2012
AuthorsWolf G
Refereed DesignationNon-Refereed
Magazine.Seguridad: Cultura de prevención para TI
Issue Number14
Pagination27-30
Date Published08/2012
URLhttp://revista.seguridad.unam.mx/numero-14/m%C3%A9xico-el-voto-electr%C3%B3nico-y-el-2012
Full Text

México es un país que, a lo largo de su historia, ha sufrido fraudes y otros malos manejos electorales, por medio de diferentes esquemas. Los mexicanos frecuentemente nos sentimos autoridades mundiales en este tema; la constante respecto a nuestras autoridades electorales ha sido más de duda y cuestionamiento que de confianza. Hubo un breve periodo, los últimos años de la década de los 1990 y los primeros de los 2000, en que parecía que se consolidaba una institución sólida y confiable, pero las dudas –fundadas o no– que surgieron tras la elección del 2006 devolvieron a las autoridades electorales a los niveles desconfianza tradicional que han sostenido a lo largo de buena parte de nuestra historia como nación independiente.
Y un reclamo muchas veces escuchado es que, dado que es imposible confiar en los individuos, corruptibles por naturaleza, la responsabilidad del escrutinio de los votos debería recaer en un sistema computarizado, siempre limpio, eficiente y honesto.

Índice

1 ¿Qué hace una urna electrónica?

Las urnas electrónicas se han propuesto desde hace mucho tiempo ya, y muchos países (o jurisdicciones menores) las han adoptado.
En el corazón de todas las propuestas de voto electrónico está la urna electrónica. Esta es básicamente una computadora, con una interfaz usuario limitada para sólo permitir un conjunto específico de operaciones, construida dentro de una caja o maletín que dificulten el acceso a cualquiera de sus componentes fuera del expresamente autorizado, y encargado de recibir cada uno de los votos, convirtiéndolos en información almacenada de forma electrónica. Por medio de un procedimiento previamente diseñado, las autoridades electorales pueden indicarle que deje de recibir votos, y entregue los totales que cada una de las opciones recibió.
Las primeras urnas electrónicas que cumplen con esta definición, las llamadas DRE voting machines (Direct-Recording Electronic, máquinas de voto electrónico de grabación directa) fueron puestas en práctica ampliamente hacia 1996, y al día de hoy, la totalidad de votantes de países tan grandes como la India y Brasil, y amplios segmentos de otros países como los Estados Unidos, votan de esta manera.

2 La confianza y los aguafiestas

No perdamos de vista que si una cosa caracteriza al gremio de los desarrolladores de software es la cantidad de errores (tanto accidentales como, lo que es mucho más peligroso, inducidos) que pueden aparecer en un programa. El mero hecho de que exista un área de especialización tan importante como la seguridad informática lo hace patente: La complejidad hasta de los sistemas más sencillos hace imposible asegurar con toda certeza que una computadora haga lo que que debe hacer.
Para ilustrarlo: Pocas computadoras en el mundo corren hoy sin antivirus. Estos programas se hicieron necesarios dadas las grandes deficiencias de diseño que tuvo el sistema operativo más popular del mundo ante la realidad de estar hoy permanentemente conectados a una red hostil. Y hasta corriendo los sistemas más seguros, es necesario estar al tanto de todas las actualizaciones y notas de seguridad si queremos confiar en que nuestra computadora responde únicamente a nuestras órdenes, y lo hace de forma confiable.
Incluso ante el mismo programador, como proféticamente lo demostró en 1984 Ken Thompson al aceptar el premio Turing (reconocido en nuestro campo como el premio Nóbel de la Ciencia de la Computación) con el artículo /Reflexiones acerca de la confianza en la confianza/1 , un programador siempre confía ciegamente en un conjunto de programas sobre de los cuales construye (compilador, ligador, sistema operativo), y por tanto, un atacante determinado sólo tiene que bajar lo suficiente para plantar un troyano.

3 Desconfiando del DRE… Y de lo demás

Expertos en seguridad informática no tardaron en señalar diversos expertos diversas fallas elementales en el voto DRE; el principal, el de la confiabilidad. Si los votos únicamente son grabados en la memoria electrónica, ¿cómo puede asegurarse que reflejen fielmente el sentido del voto de cada individuo? O puesto de otro modo, ¿cómo podría asegurarse un recuento de los votos en caso de ser nacesario?
La respuesta no se hizo esperar: A cada voto emitido, sería impreso un comprobante o testigo del voto, mismo que serviría para contar los votos manualmente en caso de impugnación. Este esquema es conocido como VVPAT (Voter-verified paper audit trail, Rastro auditable en papel verificado por el votante).
Esto, si bien ha sido aceptado por numerosos sistemas electorales en el mundo, sigue sin ser suficiente. Como sugiere Federico Heinz2, hay varios esquemas que podrían reventar una elección con este planteamiento. Por ejemplo, si las personas interesadas en sabotear una urna, tras votar, reclaman ante la mesa de autoridades indicando que la urna registró un voto contrario a lo que le solicitaron, podrían llevar a que se anulen todos los sufragios emitidos por dicha urna, dado que son potencialmente ilegítimos.
Por otro lado, podría presentarse nuevamente el escenario que se dió en la ciudad de Nueva York en 20103: Al calentarse las urnas electrónicas, emitían votos aleatorios por error. Se estima que esto puede haber invalidado hasta el 30% de los votos efectivos de algunas
mesas.

4 La futilidad de los simulacros

Este 2012, el principal proyecto de implementación de voto electrónico en México será en las elecciones locales del Estado de Jalisco. Uno de los muchos puntos preocupantes de este ejercicio es que, como pruebas previas a la instalación de más de mil urnas electrónicas en dos distritos electorales y un municipio, las únicas pruebas de confiabilidad disponible para ser analizada públicamente son cinco simulacros.
¿Qué puede comprobarse en un simulacro? Que, en el mejor de los mundos posibles y sin ninguna intencionalidad maligna, las urnas funcionen como dicen funcionar. En caso de haber algún componente malicioso en las urnas, es del total interés de quien lo haya sembrado que no cause ningún comportamiento inusual (para no perder su agente encubierto sin obtener la ventaja que le llevó a introducirlo en primer lugar). Un simulacro busca demostrar que, bajo condiciones controladas, la elección no colapsa. Y lo peor del caso es que en este caso, 3 de los 4 simulacros que habían ocurrido hasta la fecha en que este documento fue escrito registraron fallos diversos que hacían –ya a menos de dos meses del proceso electoral– replantearse si se emplearían o no4. En el Distrito Federal, la implementación de urnas electrónicas licitadas a la misma empresa que las provee en Jalisco fue rescindida, en parte, por habérsele encontrado 28 fallas5.
¿Un simulacro exitoso aseguraría que no habrá fallas el día de la elección? ¡De ninguna manera!

5 Conclusión

Por restricciones de espacio, en este texto apenas me ha sido posible arañar algunos de los puntos más notorios del voto electrónico, y de por qué, comprendiendo puntos básicos de seguridad en cómputo y estando conscientes de la gran importancia que tiene el voto dentro de un sistema democrático representativo como el que aspiramos tener en nuestro país, resulta imposible confiar en que las urna electrónica resuelva nuestros problemas de confianza — Muy por el contrario.
Se ha hablado de emplear al voto electrónico para resolver otros problemas, como el del costo o la agilidad de la transmisión de resultados. Estos puntos pueden desmenuzarse y descartarse con todavía mayor facilidad que el aquí presentado.
Si este breve artículo resultó de su interés, les invito a leer el artículo publicado a fines del 20116 , así como el abundante material que al respecto ha generado la Fundación Vía Libre (Argentina)7, destacando el libro Voto electrónico: los riesgos de una ilusión, publicado en 20098.

Pies de página:

1 Reflections on Trusting Trust, Ken Thompson, Communications of the ACM, Vol. 27, No. 8, August 1984, pp. 761-763
2 Urnas electrónicas: con imprimir el voto no alcanza, Federico Heinz, Fundación Vía Libre, septiembre de 2010; http://www.vialibre.org.ar/2010/09/12/urnas-electronicas-con-imprimir-el-voto-no-alcanza/
3 Machine Casts Phantom Votes in the Bronx, Invalidating Real Ones: Report, The Empire, mayo de 2012; http://www.wnyc.org/blogs/empire/2012/may/09/reports-find-machine-errors-led-uncounted-votes-2010/
4 Pide diputada que IEPC esté listo a llevar a cabo elección tradicional, Zaira Ramírez, El Informador, 8 de mayo de 2012;
http://www.informador.com.mx/primera/2012/374801/6/pide-diputada-que-iepc-este-listo-a-llevar-a-cabo-eleccion-tradicional.htm
5 Urnas electrónicas tienen 28 fallas: IEDF, Jonathan Villanueva, El Universal, 13 de abril del 2012; http://www.eluniversal.com.mx/ciudad/111073.html
6 Voto electrónico: ¿Quién tiene realmente la decisión?, Construcción Colaborativa del Conocimiento (IIEc-UNAM), Gunnar Wolf, 2011; http://seminario.edusol.info/seco3/pdf/seco3_apend3.pdf
7 Fundación Vía Libre — Voto electrónico http://www.votoelectronico.org.ar/
8Voto electrónico: los riesgos de una ilusión, Fundación Via Libre, 2009; http://www.vialibre.org.ar/wp-content/uploads/2009/03/evoto.pdf

AttachmentSize
Revista .Seguridad - México, el voto electrónico y el 2012 - 2012-09-05.pdf249.44 KB

Programación en la escuela: ¿Para qué?

TitleProgramación en la escuela: ¿Para qué?
Publication TypeMagazine Article
Year of Publication2012
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
Issue Number38
Pagination50-51
Date Published11/2012
ISSN1870-0888
URLhttp://sg.com.mx/revista/38/programaci%C3%B3n-la-escuela-%C2%BFpara-qu%C3%A9
Full Text

En el número de agosto del 2012 de Software Gurú, Ignacio Cabral Perdomo presentó un interesante artículo titulado «Enseñando a niños a programar: ¿Imposible o una oportunidad?». La respuesta me parece clarísima: Claro que se puede. Esto viene siendo demostrado, con gran
éxito, desde los 1960s, empleando el lenguaje BASIC diseñado por Kemeny y Kurtz, y muy particularmente con el lenguaje Logo, conocido principalmente gracias al trabajo de uno de sus autores, Seymour Papert. El origen del planteamiento de estas tempranas experiencias, sin embargo, me parece radicalmente diferente del planteamiento de Ignacio — Y los argumentos, tanto hace 40 o 50 años como ahora, más convincentes.
El énfasis que presentan las conclusiones de Ignacio apuntan al mercado del desarrollo de cómputo. Cito,

Es muy clara la necesidad de más profesionistas en el área de la Computación y las Tecnologías de Información, en especial en los departamentos de desarrollo de software de diferentes corporaciones pero, desgraciadamente, el interés de los alumnos por carreras de este tipo está reduciéndose de una forma alarmante. Una posible solución es el inculcar desde temprana edad el pensamiento lógico y algorítmico en los niños siguiendo el itinerario de aprendizaje que propongo.

Si bien el artículo refiere que la enseñanza de programación a partir de nivel primaria «ayuda a los chicos a formar ese pensamiento lógico y algorítmico que tanto necesitan», no profundiza en este aspecto, que considero fundamental. ¿Por qué los chicos pueden necesitar un pensamiento lógico y algorítmico?

1 Los hijos de Logo

Soy parte de una minoría afortunada — Y pido disculpas anticipadas si el presente artículo se ve como un viaje a mi anecdotario personal.
Aprendí computación cuando el acceso al equipo de cómputo era extremadamente poco común — Mi primer experiencia fue en la minicomputadora Foonly que había en el IIMAS (UNAM) en 1983, a los 7 años, escribiendo LaTeX con el editor Emacs. Cabe mencionar que el presente artículo, casi 30 años más tarde, lo estoy escribiendo con las mismas herramientas. Tuve acceso a la Foonly gracias a que mi padre trabajaba como investigador en dicho Instituto, y a que tuvo la paciencia de enseñar a su ávido niño ese lenguaje cargado de símbolos y comandos.
Pero creo que mi experiencia con la Foonly se habría mantenido como meramente incidental de no ser porque, uno o dos años más tarde, me inscribieron en IDESE, una de las primeras escuelas de verano dedicadas al cómputo en México. IDESE era una apuesta pedagógica muy interesante; por tres semanas, alternábamos dos horas frente a la computadora con dos horas más con juegos de mesa. Si bien no recuerdo los detalles de la interacción, esta alternancia ilustra claramente cómo veían nuestros instructores su tarea: Llevar a los niños a
emplear sus habilidades cognitivas de una manera más completa.
IDESE derivó de la versión de Logo desarrollado por el MIT para la Apple ][, traduciendo todos sus comandos y mensajes al español. Sólo otra vez, también en los 1980, vi un esfuerzo similar: El hecho por la BBC al traducir el lenguaje BASIC de su BBC Micro para crear el EBASIC. Esto permitía enseñar a los niños a programar la computadora sin preocuparse al mismo tiempo de aprender otro idioma — El caso del EBASIC me resulta notorio porque, con un comando, se podía ver el código escrito en EBASIC en BASIC "normal". Para 1985, me tocó formar parte del taller de computación que se impartía en mi escuela a partir de 4° de primaria. A partir de 1986, estuve inscrito para varios cursos de los Centros Galileo. Tuve la suerte de haber pasado por escuelas muy buenas y muy motivantes, con lo cual a esas tempranas alturas ya estaba decidida mi vocación.
El gran acierto de Logo que lo hizo tan importante como lenguaje educativo fue eliminar las capas de abstracción que debía tener en mente un niño: Si bien el lenguaje permite un desarrollo complejo y formal de programación funcional1, el niño podía ver la concreción de sus programas graficándolos a través de una tortuga, originalmente un robot conectado a la computadora, posteriormente reemplazado por una tortuga en pantalla cuando la tecnología lo permitió. Permitir que el niño viera directa e inmediatamente sus resultados, hace 45 años, resultó un cambio fundamental y un gran motivador.
Cuando Logo fue planteado, así como cuando yo lo aprendí2, no existía el planteamiento de formar a los niños en programación por la gran demanda que dichas habilidades tendrían en la sociedad. La enseñanza de programación era vista como una forma de enseñar pensamento abstracto y algorítmico.
¿Y para qué enseñar pensamiento abstracto y algorítmico si no para formar profesionales que comprendan más fácil los paradigmas de cómputo? Bueno… Citando a un buen amigo, de lo que se trata no es de aprender más que a programar, aprender lo que significa programar. Dicho de otro modo, ¿Para qué se enseñan matemáticas, filosofía, historia o biología? Para formar personas más completas, no sólo en su cultura, sino que en la manera de estructurar el pensamento. Habilidades que indudablemente impactan en su crecimiento como adultos. Y sin poder extrapolar más allá de la experiencia personal, no puede pasarme desapercibido la gran proporción de colegas que me he encontrado de aproximadamente mi edad que pasaron por experiencias formativas similares.

2 La OLPC

Ninguna herramienta dura para siempre, sin embargo, y ni siquiera el gran Logo se salva de la obsolescencia que las nuevas tecnologías van causando. Hoy en día, sería iluso pensar que mover una "tortuga" por la pantalla pudiera impresionar a un niño. Afortunadamente, no han sido pocos los estudios en este campo que se han realizado — El artículo de Ignacio presentó cuatro entornos de programación orientados a la enseñanza en diferentes edades — Scratch, Alice, Greenfoot y BlueJ. Me sorprendió que no presentara a uno de los trabajos más comentados de los últimos años, que tiene un impacto muy medible: El proyecto OLPC (One Laptop Per Child, una computadora por niño)3 , iniciado –al igual que Logo– en el MIT y con el decidido apoyo de Seymour Papert, entre otras muchas personalidades.
La OLPC no es cualquier computadora: Fue planteada como el vehículo sobre del cual correría Sugar4. Yo no tengo experiencia de primera mano con el entorno, por lo cual prefiero dirigir a quienes estén interesados en una descripción más completa al artículo que publicó Werner Westermann5 dentro del libro «Construcción Colaborativa del Conocimiento»6.
En resumen, Sugar es un entorno dirigido a facilitar un aprendizaje construccionista, en que cada alumno debe ir explorando y construyendo su camino por medio de la experiencia personal, lo cual lleva a una mayor apropiación del contenido que cuando éste es dictado. A partir de una interfaz sencilla y una orientación más a actividades que a aplicaciones, y empleando a fondo la colaboración entre todos los alumnos, la computadora se vuelve un actor, un facilitador de la transmisión del conocimiento. Y una característica fundamental de Sugar es que el alumno no sólo puede utilizar las actividades, sino que puede (y está bienvenido a) modificarlas. Las actividades están escritas en Python, un lenguaje de sintaxis limpia y conceptualmente fácil de adoptar.
OLPC fue planteado como un proyecto necesariamente a gran escala: Está planteado para que una computadora sea entregada a cada niño en edad escolar en los países receptores. El proyecto busca además resolver problemáticas específicas de los países menos favorecidos; con ciertas modificaciones al planteamiento inicial, actualmente hay despliegues de OLPC en once países de escasos recursos7.
Y siguiendo con el tono personal que he mantenido en esta ocasión, relato lo que me contó Manuel Kauffman, un desarrollador argentino de Sugar, en una visita que hizo a una escuela en Uruguay: Un niño, de 11 o 12 años, le explicó que prefería editar en texto los iconos de las actividades que iba creando o modificando directamente en un editor de texto, en SVG8 porque le quedaban más limpios que utilizando un editor gráfico.
Este ejemplo habla como pocas cosas de apropiación de la herramienta y de la apreciación estética de la representación en código de un objeto. Hay programadores de larga carrera profesional que son incapaces de desarrollar estas habilidades.

3 Conclusiones

Enseñar a programar a un niño va mucho más allá de transmitirle una habilidad para su futuro profesional. La enseñanza básica no puede basarse sólamente en la transmisión de competencias medibles en el mercado.
Hay, sin embargo, puntos importantes a considerar. Si bien algunos tuvimos la gran suerte de aprender de la forma y en el momento correcto, es una materia con la que muchos se enfrentan con dificultad — El desarrollo de las capacidades de abstracción necesarias para esta materia se produce de forma muy desigual, y la frustración que esta materia puede causar en algunos alumnos puede ser muy grande. Cabe mencionar, claro, que esto mismo se presenta en varias otras materias que forman ya parte de la currícula básica.
Por otro lado, otro punto importante a considerar es la formación de los docentes. Para incorporar una materia a la currícula básica, es necesario contar con un cuerpo docente suficientemente amplio y capacitado, no sólo con las habilidades técnicas sino que pedagógicas. Esto, claro, debe presentarse como un proceso gradual, pero nada indica que sea de fácil resolución.

Pies de página:

1 Logo ha sido descrito como "Lisp, pero sin los paréntesis"
2 Con casi 20 años de distancia — ¡Una verdadera eternidad en el avance de la popularización del cómputo!
3 http://one.laptop.org/
4 http://sugarlabs.org/
5 http://seminario.edusol.info/seco3/pdf/seco3_apend2.pdf
6 http://seminario.edusol.info/seco3/
7 http://one.laptop.org/stories
8 Un lenguaje basado en XML para representar gráficos vectoriales

AttachmentSize
Programacion_en_la_escuela.pdf68.58 KB

2013

Columnas y artículos presentados en 2013

Aaron Swartz, el acceso abierto y los estándares

TitleAaron Swartz, el acceso abierto y los estándares
Publication TypeMagazine Article
Year of Publication2013
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
Issue Number39
Date Published02/2013
ISSN1870-0888
URLhttp://sg.com.mx/revista/39/aaron-swartz-el-acceso-abierto-y-los-est%C3%A1ndares
Full Text

Aaron Swartz, el acceso abierto y los estándares

Estoy seguro que la mayor parte de nuestros lectores estarán ya familiarizados con Aaron Swartz, así como del triste desenlace que tuvo su historia. En todo caso, hagamos un corto recuento antes de entrar en materia.

1 Aaron Swartz, breve reseña

Aaron Swartz fue un jóven entusiasta de la programación, firme creyente de la necesidad de la libre circulación de la información. Su vida tiene muchos momentos dignos de nota; los puntos más relevantes incluyen:

  • Participó en la creación de la especificación RSS 1.0 (W3C RFC 3870) a los 14 años de edad.
  • Fue co-autor del lenguaje de marcado Markdown, diseñado para hacer más natural a un usuario no técnico preparar páginas Web que
    lo que hasta entonces permitia el HTML.
  • Es uno de los creadores de la iniciativa Creative Commons, un conjunto de licencias orientadas a facilitar a los creadores elegir un marco que permita la libre circulación de los bienes culturales, sin renunciar a sus derechos autorales.
  • Participó en la creación del sitio sindicador de noticias sociales Reddit, uno de los primeros sitios en aprovechar la interacción viral y en definir lo que hoy conocemos como temas tendencia.
  • Estuvo involucrado en diversas campañas oponiéndose a las propuestas legislativas encaminadas a la restricción de las libertades individuales en línea, entre las cuales destaca SOPA
  • Creó la Open Library, y la pobló con la información bibliográfica completa de la Biblioteca del Congreso de los Estados Unidos, con un conjunto de información que hasta ese momento, si bien era legalmente del dominio público, cobraba cargos por acceso.
  • Descargó en 2008 la base de datos completa de registros judiciales públicos (PACER), otro caso de información legalmente del dominio público pero restringida por un cargo por acceso. Donó los archivos resultantes a http://public.resource.org/; este fue el primer caso que le mereció ser abiertamente investigado por el FBI, aunque el caso fue cerrado sin presentarle cargos después de dos meses.

Dentro de su lucha por la puesta a disposición irrestricta de la información pública, entre 2010 y 2011 descargó cerca de cuatro millones de artículos académicos del repositorio JSTOR, aprovechando la política de «campus abierto»1 que sostenía el MIT.
Los artículos en cuestión provenían mayormente de investigaciones realizadas con fondos públicos, por lo que deberían ser para beneficio de la sociedad toda, pero por las diversas distorsiones que sufre la publicación científica formal, para tener un factor de impacto deseable para sus autores, tienen que ser publicadas en revistas especializadas que (cada vez menos, pero aún por regla general) ejercen una política intransigente de control de derechos de autor.
En julio de 2011 fue acusado formalmente por esta descarga de actividad criminal. Si bien JSTOR retiró su demanda, las autoridades judiciales continuaron persiguiéndolo de oficio — La fiscal Carmen Ortiz buscó repetidamente fincarle una sentencia de hasta 35 años de cárcel y una multa de hasta un millón de dólares, equiparando sus acciones con actos terroristas. Ante esta presión (y con antecedentes de depresión severa), el pasado 11 de enero Aaron Swartz se suicidó.

2 Las ideas sobreviven

Aaron, del mismo modo que muchos de los activistas del movimiento del software libre, fue encontrando la necesidad ética de activar para fomentar la libre circulación y correcta preservación a largo plazo del conocimiento. Para muchos de nosotros, el movimiento del conocimiento libre es sencillamente la consecuencia lógica del movimiento del software libre, y surge naturalmente (y con las mismas premisas) una vez que el acceso a Internet llega a la sociedad toda.
A fin de cuentas, el código es sólo una herramienta de expresión y comunicación humana (aunque tenga la restricción de un lenguaje formal, de ser interpretable por una computadora). El ideario completo de la Fundación del Software Libre puede aplicarse a cualquier otra área del conocimiento — Y tenemos hoy las herramientas para que la circulación del conocimiento no sólo resulte irrestricta, sino que a un costo de reproducción prácticamente cero.
En sus 26 años de vida, Swartz contribuyó con buena parte de la implementación técnica y activismo social necesarios para impulsar al movimiento del Acceso Abierto (Open Access)2.
Los diversos protocolos y sitios agregadores con los cuales él contribuyó quedan no sólo como legado, sino como indicador de cómo y hacia dónde un jóven brillante vio que podríamos, y deberíamos, avanzar.

3 El acceso abierto — y estructurado

Un corolario fundamental del acceso abierto es que la información, para ser útil, debe estar adecuadamente organizada y clasificada. Simplemente volcar millones de artículos científicos (o programas de computadora, obras culturales o literarias, arte, etc.) en un espacio sin estructura no sirve de mucho — Ahogarse en un mar de información resulta casi tan inútil como no tener acceso a ella. Es por eso que el Open Access va casi siempre de la mano del empleo de herramientas de clasificación, redistribución y agregación basadas en estándares ampliamente reconocidos.
Hay muchos sitios –incluyo entre ellos, por cierto, al de nuestra revista– destinados a la difusión de información con importantes cuerpos históricos.
Si bien aplaudo y agradezco la decisión de Software Gurú de ofrecer el acervo histórico de ya ocho años de trabajo, para que esta información sea verdaderamente útil debería comprometerse a mantener URLs estables a largo plazo y adherirse a un esquema de publicación de material bibliográfico — Muy probablemente, el esquema más adecuado sería el DublinCore3. Este estándar permite la indexación, cosecha y agregación de repositorios por medio de protocolos como el OAI-PMH4.
¿Qué significa semejante verborragia de siglas? Que, para que la información resulte de utilidad para el avance técnico-científico, no podemos sólamente confiarnos al criterio de los indexadores de los motores de búsqueda. Siguiendo un poco la retórica de Tim Berners-Lee impulsada con el título de Web semántica,

Extiende la red de páginas hipervinculadas legibles por humanos, insertando metadatos legibles por computadora acerca de las páginas y sus interrelaciones, permitiendo a los agentes Web entenderlas más inteligentemente y realizar tareas en nombre de los usuarios.

Si bien hay críticas bien fundadas a la propuesta de Berners-Lee, para información tan estructurada como una revista de publicación periódica como esta, el modelo de metadatos DublinCore se ajusta perfectamente.
El Instituto de Investigaciones Económicas de la UNAM, donde trabajo, participa del proyecto de Red de Acervos Digitales (RAD-UNAM)5. Hemos ido creando un acervo interdisciplinario con diversas entidades universitarias que, por medio de OAI-PMH, ofrece una colección unificada y distribuida con miles de objetos académicos de gran diversidad, rescatándolos en buena medida del olvido y de la inaccesibilidad.
Software Gurú va más alla de ser una revista — El cuerpo de noticias del ramo, whitepapers y congresos presenciales y virtuales podrían sumarse al cuerpo de conocimiento disponible y sistematizado publicado en nuestro país, impulsando de este modo su visibilidad y el impacto de lo aquí publicado. Del mismo modo, otras revistas (sean más formales o menos formales, impresas o en línea), boletines, congresos y demás actividades de nuestra área de conocimiento podrían beneficiarse de adoptar estos estándares.
Un repositorio correctamente descrito puede ser cosechado enfatizando en diferentes facetas. El esfuerzo para lograrlo, cierto, no es despreciable — Pero tengo la certeza de que Software Gurú tendría mucho por ganar.
Y más que nuestra revista: Sé que muchos de quienes aquí escribimos, y quienes trabajan con dedicación brindándonos este espacio, más que por ganancia personal, lo hacemos en un afán de contribuir con nuestro granito de arena a la sociedad mexicana — Y si bien la revista tiene su carga técnica, muchos de nosotros aspiramos a contribuir a la profesionalización de nuestro gremio, a una introspección acerca del rol y la responsabilidad social que cargamos
A los pocos días de la muerte de Aaron Swartz, cientos de académicos hicieron públicas copias de sus artículos secuestrados por las editoriales científicas restrictivas como un tributo al trabajo de este jóven idealista y activista. En una especie de paralelo, espero poder impulsar un poco más a través de este texto el conocimiento de las herramientas (y no sólo los principios éticos) que puedan permitir que el acceso abierto y pleno al cuerpo de conocimiento generado por los especialistas sea puesto al servicio de la humanidad toda de forma más efectiva.

Pies de página:

1 Política que permitía a cualquier usuario externo conectar una computadora de su propiedad en la red universitaria y aprovechar los convenios que ésta tenía subscritos. Podemos encontrar políticas similares en todas las principales universidades, partiendo de la premisa de facilitar la labor académica y reducir tramitología.
2 Por si se van perdiendo en la sopa de letras de movimientos libertarios, Open Access busca el libre acceso a publicaciones académicas.
3 http://dublincore.org/
4 Open Access Initiative Protocol for Metadata Harvesting, http://www.openarchives.org/OAI/openarchivesprotocol.htm
5 http://rad.unam.mx

AttachmentSize
201303_softwareguru_1.jpg823.22 KB
201303_softwareguru_2.jpg826.67 KB

Lo que muchos no saben del voto electrónico

TitleLo que muchos no saben del voto electrónico
Publication TypeWeb Article
Year of Publication2013
AuthorsMartínez R, Wolf G
Refereed DesignationNon-Refereed
Access Year2013
Access Date2013-04-22
Last Update Date2013-04-22
PublisherOh My Geek!
URLhttp://www.ohmygeek.net/2013/04/22/lo-que-no-se-dice-del-voto-electronico/
Full Text

Hace unas semanas publicamos una entrevista con Edgardo Torres Caballero, gerente general en América Latina, Caribe y Portugal de Scytl, quien nos habló acerca de los beneficios del voto electrónico y de su adopción en la región.
Sin embargo, en OhMyGeek! recibimos un “derecho de respuesta” de Gunnar Wolf, académico de la Universidad Nacional Autónoma de México, y desarrollador de software libre.
Según Wolf, es de esperar que personeros de empresas de tecnología para la automatización electoral pinten una realidad tan perfecta del voto electrónico. Sin embargo, el académico comenta que, durante su trayectoria, no ha encontrado a ningún experto en seguridad informática que defienda al voto electrónico y que lo pinte como algo tan seguro, en comparación a una elección base-papel promedio.
En este caso, Wolf nos pidió poder dar su punto de vista respecto al voto electrónico, y esto fue lo que nos dijo:

Antes que nada, agradezco profundamente este claro –y muy sui-generis– derecho de réplica al lector que me dan, en primer término, Rosa Martínez Gómez (quien llevó la entrevista con Edgardo Torres) y, obviamente, a OhMyGeek! por el espacio por medio del cual esta llega a ustedes.
La invitación que me hizo Rosa fue a responder a las mismas preguntas que ella hizo a Edgardo Torres. Claro está, algunas de las preguntas son específicas a los equipos y planes de desarrollo de negocio de Scytl — No respondo a esas preguntas por razones obvias.
1. Hoy todo es crackeable y, por otro lado, los números de cibercrimen en Latinoamérica son alarmantes. Entonces, ¿cómo podría impedirse que un cracker altere los resultados electorales de un país?
Esta primer pregunta es precisamente el mayor “quid” del voto electrónico. La respuesta, por alarmante que parezca, es que es sencillamente imposible evitar un ataque de este tipo.
Analicémoslo brevemente: Un componente fundamenatal del foto es el secreto. Lo único que debe saberse de cada votante en particular es que emitió un voto (y, por tanto, no puede volver a hacerlo). Debe ser imposible demostrar por quién votó — Lo que es más, ni siquiera el mismo votante debe poder hacerlo, porque esto abriría la puerta a la presión, sea por compra de votos o por relaciones de dominación familiar, laboral, de grupo social, o de otra índole.
Muchas veces se nos presenta la siguiente comparación: ¿Por qué confiamos en la banca electrónica y no en el voto electrónico? La respuesta es esa: Las transacciones económicas deben tener perfectamente identificados a los actores, y deben estar sujetas a una auditoría completa. En el momento que se plantea como requisito la destrucción de parte de la información (se debe mantener el secreto electoral), no se puede bajo ninguna circunstancia asegurar la integridad de la misma.
Lo que es más: Este hecho se ha demostrado ya en repetidas ocasiones, empleando diferentes técnicas, en todo el mundo y en diferentes etapas del proceso. La modificación puede hacerse al grabar los resultados en las urnas (como lo ilustró el grupo “Wij vertrouwen stemcomputers niet” en 2008 en Holanda), al leer de ellas (como lo hicieron Hari K. Prasad, J. Alex Halderman y Rop Gonggrijp en La India en 2010) e incluso al transmitir los votos, sin siquiera tener acceso físico a las urnas electrónicas (como lo hizo Reinaldo Mendonça en Brasil en 2012). Y lo más preocupante es que sólo sabemos de los ataques hechos con fines académicos
¿Cuántos no habrán ya pasado bajo nuestras narices?
2. ¿Cómo se realiza la identificación de los electores?
Del mismo modo que hay distintos fabricantes de urnas y sistemas, también hay distintos esquemas de identificación. En primer término, hay urnas electrónicas que siguen dependiendo de que las autoridades de mesa electoral verifiquen la identidad del votante manualmente (por ejemplo, verificando su identificación contra el padrón) y lo habiliten para emitir un voto manualmente.
Hay urnas electrónicas equipadas con lectores biométricos, como las empleadas en las elecciones venezolanas, que verifican la huella digital del votante.
Por otro lado, cuando se realizan votaciones a distancia por Internet, hay dos mecanismos: Uno es dotar a todas las identificaciones de dispositivos criptográficos, como se hace desde hace varios años en Estonia y se está impulsando que ocurra también en Perú, y requerir que para emitir un voto la computadora cuente con un lector de dicho dispositivo.
Por último, la modalidad que han impulsado empresas como Scytl (y que fue empleada, por ejemplo, para los votantes de la Ciudad de México residentes en el extranjero en las elecciones del 2012) es la generación de una contraseña en las semanas previas a la elección, y la identificación por usuario/contraseña.
Y de nuevo, la fuerza relativa de cada modalidad se cae ante un simple análisis. La identificación personal, con todas sus fallas, sigue siendo la mejor puntuada. Una urna con lectores biométricos lleva a bien fundamentadas dudas acerca de si la urna verdaderamente mantendrá en secreto la relación entre el votante y el sentido del voto — Y hay casos escalofriantes, como la “Lista Tascón“: En 2004, tras el referendo revocatorio venezolano, en que Hugo Chávez logró una aprobación del 60% para seguir al frente del gobierno, se publicó la relación de quienes votaron en contra suya -Muchos de quienes fueron despedidos de puestos públicos o perdieron la cobertura de programas sociales-.
¿Y respecto al voto a distancia? Mucho peor. Ambos esquemas de identificación demuestran únicamente la posesión de determinado documento o información, no que la persona sea el auténtico votante. Si en mi país se permite el voto por Internet, y en mi empresa me ofrecen un aumento (o me amenazan con el despido) a cambio de que yo le “preste” mi documento electoral a mi jefe, puede hacerse una compra de votos a gran escala.
El no contar con un precinto desde donde pueda ejercer el voto secreto tiene un efecto similar: El jefe de familia o el grupo social pueden proponer/imponer una jornada de voto en conjunto, en que cada miembro del grupo pueda verificar el sentido en el cual votaron todos los demás.
3. ¿La adopción del voto electrónico ha incrementado la asistencia a las urnas?
Esto resulta muy dificil de responder, y depende de la modalidad del voto, y de las aprehensiones particulares de la población en cuestión. Del mismo modo que hay gente que resulta atraída, hay gente que, a pesar de todas las jornadas de sensibilización que se realicen al respecto, el uso de computadoras (por simplificada que sea su interfaz) le seguirá produciendo miedo, desconfianza o incomodidad.
No podemos ignorar casos como el ocurrido en Panamá en 2012, en que para las elecciones internas del partido PRD, con sólo 4200 delegados habilitados para votar, las urnas electrónicas causaron demoras superiores a las cinco horas. Y esto es relevante porque, aunque dicha demora no es un problema frecuente, ilustra cómo muchos factores adicionales pueden influir en que una elección sea un éxito o un fracaso: No es descabellado imaginar que una autoridad electoral parcial envíe a los distritos “políticamente confundidos” (esto es, que muestre preferencia al candidato ”equivocado”) máquinas que funcionen de forma correcta, aunque más lenta o presentando alguna otra incomodidad al votante.
4. En ocasiones el sistema no reconoce el 100% de las huellas digitales. ¿Qué sucede con las personas cuyas huellas no pueden ser reconocidas? 
Depende 100% del fabricante y la autoridad electoral.
5. ¿Cuáles son los principales beneficios del voto electrónico?
A decir de sus proponentes, los principales beneficios serían un menor tiempo de escrutinio, una mayor rapidez para conocer los resultados, y una mayor confiabilidad en los mismos. Con lo que hemos visto, sin embargo, resulta claro cómo en cada uno de esos casos el voto electrónico resulta reprobado.
No podemos dejar de ver como ejemplo claro y paradigmático a lo ocurrido apenas el 14 de abril en Venezuela: Por más que en el país se emplee del voto electrónico desde hace ya 14 años, y las empresas proveedoras de urnas lo citen como ejemplo de transparencia y confianza por parte de su ciudadanía, ante un resultado muy cerrado y con cerca de 3000 denuncias de irregularidades (un número bastante dentro de la norma en las elecciones en nuestro continente), no pudo evitarse la polarización y el enfrentamiento en su sociedad.
En los primeros días tras las elecciones hubo enfrentamientos callejeros que llevaron a siete muertos, una toma de posesión con la mitad de la población dudando de la legitimidad del nuevo gobierno — Y la imposibilidad fundamental (ver pregunta 9) de realizar un recuento.
6. ¿Cuáles son los principales riesgos del voto electrónico?
El principal riesgo es convertir a la democracia en un juego de ”capture la bandera”, de perder la legitimidad que da el voto popular, imposibilitando además a la población en general a convencerse de los resultados a través de una auditoría plena. No creo necesario repetir todo lo que he ido respondiendo a las demás preguntas ejemplificando por qué es tan peligroso y tan claro el peligro.
7. ¿Cuánto debemos esperar para tener urnas que puedan reconocer el iris del ojo de los electores?
Depende 100% del fabricante y la autoridad electoral.
8. Alemania, por ejemplo, prohibió el voto electrónico en 2009, después que un tribunal decidió que el proceso automatizado usado en los últimos 10 años era irregular. La misma prohibición ocurrió en los Países Bajos, en 2008. Entonces, ¿cómo regularizarlo?
Desde nuestra perspectiva, la regularización sería seguir los pasos de estos dos países, abandonando una tecnología que no resulta conveniente. Estos dos países han rechazado al voto electrónico de forma explícita y por completo, pero otros muchos otros países lo han rechazado para sus elecciones normales, relegando su aplicación únicamente para los votos desde el extranjero.
Como ya lo expuse, el voto por Internet desde el extranjero puede parecer una buena idea (e incluso un buen compromiso), pero incluso en dichos casos, es necesario enfrentar a la cuestión con mucha cautela y no dejarse engatusar por respuestas aparentemente sencillas, que resultan en pérdida de confiabilidad.
9. Si yo no tengo un comprobante impreso, ¿cómo sé que lo que voté realmente es lo que se registra dentro de la máquina?
No hay manera de saberlo, ni siquiera contando con un comprobante impreso. En caso de haber algún mecanismo que me permita validar que mi voto fue contado en el sentido que yo lo emití, este mismo mecanismo se hará disponible para los delincuentes electorales que extorsionan o dan dinero a cambio del voto. Incluso el mecanismo que se ha popularizado de generar el llamado ”rastro impreso” resulta insuficiente.
Se han hecho estudios estadísticos que apuntan a que una amplia proporción de la población no verifica el “recibo de supermercado” generado. Por poner sólo un ejemplo, los adultos mayores (y demás personas con debilidad visual) verán un mero comprobante, y no se detendrán a leer cada uno de sus renglones. Además, si la máquina emitiera u papelito contrario al voto emitido, ¿qué puede hacer el votante?
¿Le valdrá la pena registrar una queja ante las autoridades de mesa? ¿Lo hará, o lo dejará de lado? Para un mayor análisis al respecto, les sugiero leer el texto de Federico Heinz¹, “Con imprimir el voto no alcanza“.
Y hay otro punto importante a considerar: ¿Qué significa este papelito comprobante? En el Estado de Jalisco (México), para permitir la instalación de urnas electrónicas que realizaron en las elecciones del 2012, se hizo una modificación legal que traslada el peso documental legal de las papeletas emitidas a la memoria de la computadora: Esto es, incluso si se obtuviera un recuento “voto por voto” de cada uno de los comprobantes emitidos y el resultado fuera distinto del anunciado, la verdad legal es la que indique la computadora.
Y por las declaraciones que al día de hoy ha realizado el Tribunal Electoral venezolano, el caso es el mismo por allá: El documento legal es el acta emitida, y un recuento del 100% de los votos, independientemente de su resultado, no alterará el resultado legal de la elección. Esto es, el papelito denominado “testigo” es equiparable a un placebo médico.
10. ¿Qué niveles de encriptación, de codificación de seguridad alfanumérica, tienen los votos que yo emito?
Depende 100% del fabricante y la autoridad electoral.

Tan humano como la visualización, tan divino como la memoria

TitleTan humano como la visualización, tan divino como la memoria
Publication TypeMagazine Article
Year of Publication2013
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
Issue Number40
Pagination44-45
Date Published05/2013
ISSN1870-0888
URLhttp://sg.com.mx/revista/40/tan-humano-como-la-visualizaci%C3%B3n-tan-divino-como-la-memoria
AttachmentSize
SG40-gwolf.pdf1 MB

Voto electrónico: Es cuestión de confianza

TitleVoto electrónico: Es cuestión de confianza
Publication TypeWeb Article
Year of Publication2013
AuthorsWolf G
Refereed DesignationNon-Refereed
Access Date2013-05-09
Last Update Date2013-05-09
PublisherMoofMonster
URLhttp://www.moofmonster.com/opinion/voto-electronico-es-cuestion-de-confianza/
Full Text

Voto electrónico. La sociedad en general espera que nosotros los tecnólogos seamos los primeros en apoyarlo, sus principales promotores e impulsores. Lo que es más, por lo que he visto en diversos países… ¡Parece que la sociedad en general lo apoya!
Pero… ¿Qué es lo que apoyan? Hablar del voto electrónico así, como de un bien abstracto, no nos aclara lo suficiente el panorama como para entender cuál es la motivación real — Cuál es el problema que plantea resolver, y por qué esa respuesta se antoja deseable para la sociedad de nuestros países. Y mientras resolvemos esa pregunta, probablemente también encontraremos qué es lo que verdaderamente hay detrás de estas propuestas.
Los argumentos principales que se esgrimen a favor de migrar a un esquema de voto electrónico son la inmediatez de los resultados, la confiabilidad de los resultados, y el costo del material electoral. Y tristemente… adoptar esta forma de votación no presenta la menor mejoría en ninguno de ellos. En este texto abordaré los dos primeros apartados; el tema del costo no es menor, y también resulta profundamente engañoso, pero analizarlo nos llevaría por una temática distinta — Claro está, para los lectores interesados en profundizar sobre este tema, o cualquier otra arista de esta temática, me pongo a sus órdenes en mi dirección electrónica.
Emplearé como principal caso de referencia para este análisis a las pasadas elecciones generales en Venezuela, celebradas el 14 de abril. Hasta ahora, Venezuela ha sido visto como caso paradigmático del éxito del voto electrónico… Pero eso ha sido, precisamente, porque hasta ahora no se había presentado ningún caso disputable. Esto es, porque el resultado de la elección ha estado dentro del umbral aceptable para su sociedad. ¿Qué pasa cuando cruzamos el márgen mínimo de confianza? Ahora que tuvieron un resultado cerrado, con un márgen de sólo 1.5%, se ha presentado una crisis de credibilidad, movilizaciones sociales, e incluso ocho personas muertas en los disturbios.
Podemos comparar el desarrollo posterior de los acontecimientos con lo que ocurrió en México, un país de grado de desarrollo socioeconómico no demasiado distinto del venezolano, con aproximadamente el doble de superficie y cuatro veces la población de Venezuela, y que lleva su sistema electoral federal prácticamente de forma 100% manual, en las últimas dos elecciones federales (2006 y 2012). En la primera, el márgen oficial de diferencia fue del 0.5%, y en la segunda, del 6.5%.
En primer término, la inmediatez. Desconfiamos del periodo en que la autoridad tiene ya los resultados emitidos pero no ha emitido los resultados, porque son el periodo perfecto para instrumentar un fraude.
¿Cómo es el proceso en una elección “tradicional” con boletas de papel? En México, en 2006, la última casilla cerró a las 20:00 (hora del centro) autoridad electoral decidió no emitir resultados preliminares a las dos horas, como acostumbra hacerlo, porque la diferencia era demasiado estrecha y podía variar. Fue hasta las 3AM que el resultado preliminar fue hecho público, y no fue sino hasta tres días más tarde que se confirmó la cifra oficial — Y sí, la distancia entre el primer y segundo lugar se redujo de 1.2 a 0.5%. Sin embargo, lo fundamental en este sentido es que la autoridad electoral esperó hasta que, estadísticamente, el resultado era ya estadísticamente irreversible — Y esto ocurrió a las 3AM, esto es, 7 horas después de cerrada la última casilla.
Ahora, la tensión post-electoral tras un resultado tan cerrado fue tan grave en 2006 que para el 2012 se decidió que los resultados se harían públicos incluso antes de que se estableciera una tendencia clara. Desde las 20:00 podían consultarse los resultados parciales, y hacia las 22:00 el conteo había avanzado lo suficiente como para estabilizarse en lo que fue el resultado final — 2 horas después de cerrada la última casilla.
En Venezuela, en 2013, el cierre de casillas fue a las 18:00 el resultado fue publicado a las 22:00, esto es, 4 horas después del cierre del periodo legal. Si bien la diferencia con los procesos mexicano es el rango de oficial de los resultados (en el caso mexicano, el número total publicado fue del conteo rápido, mientras que el resultado oficial fue apenas confirmado tres días más tarde, y en Venezuela el dato tenía ya caracter de oficial), la diferencia resulta meramente semántica: En ambos casos, el primer resultado se presenta aún sujeto a ajustarse en base a las denuncias de irregularidades, y está sujeto a auditoría por parte de los actores relevantes. Y sí, también en Venezuela el resultado se ajustó levemente en los días posteriores.
Sin embargo, entramos aquí al tema fundamental que busco abordar: En un entorno de cuestionamiento y de votaciones cerradas, como podemos observara la población no le importa tanto si el conteo es hecho por máquinas o por personas. Si el entorno político no genera confianza, una elección cerrada llevará a movilizaciones callejeras y, si los políticos actores no lo manejan con prudencia, a violencia física.
Ahora bien, MoofMonster es un espacio para hablar de tecnología más que de política, ¿no es cierto? ¿A qué viene esta participación entonces? Lo que me interesa compartir con ustedes, de tecnólogo a tecnólogo, es por qué precisamente a nosotros debe preocuparnos que se plantee una adopción a ciegas, que esa sociedad en general de la que hablábamos al principio asuma que, sólo por contener tecnología, el voto electrónico representa una ventaja sobre del sistema electoral que conocemos de toda la vida.
Ilustremos esto con un símil: Frecuentemente, al presentar este tema, me han preguntado: «Yo confío en la seguridad electrónica para mis transacciones económicas. ¿Por qué no habría de confiar para mi voto?» Y la respuesta resulta obvia: La auditabilidad. El comprobante que liga a cada transacción — El banco relaciona al comprador y al vendedor, quienes pueden verificar por separado que la transacción haya o no sido realizada, así como la cantidad de que se trata. En caso de haber alguna anomalía en la transferencia respecto a lo que esperaban, incluso semanas más tarde, ambos pueden exigir al banco la revisión de la transacción.
Esto nos lleva a que el problema fundamental es que, sencillamente, no puede existir una implementación de voto electrónico que nos garantice un nivel de confiabilidad tan alto como el de un proceso basado en papel dos características básicas: La integridad y la secrecía del voto — Esto es, poder asegurar tanto al momento de la emisión como en una revisión posterior que el sentido de cada uno de los votos emitidos será siempre el que el votante decidió y, al mismo tiempo, imposibilitar que se revele el voto de una persona dada. ¿Por qué es tan importante el secreto electoral? Porque es la única manera en que la podemos evitar la compra de votos o el voto bajo presión: Nadie, ni siquiera el mismo votante, debe poder demostrar ante un tercero por quién votó.
Argumentan que respaldar cada voto en un comprobante impreso soluciona este problema. Esto es falso, por varias razones. La primera, y más importante, es que cuando es implementado un sistema electoral basado en voto electrónico, el documento de valor legal es la memoria de la computadora. Así es, contrario a nuestras expectativas, los papelitos testigo emitidos no son un documento legal. Podemos ver esto en Venezuela: Las solicitudes de recuento fueron desechadas; Luisa Estela Morales, presidenta del Tribunal Supremo de Justicia, aseguró que en Venezuela el voto manual no existe y que, por lo tanto, quienes dicen exigir un recuento voto por voto engañan a sus seguidores.
Hay otros argumentos relativos a la impresión de comprobantes — Desde estudios estadísticos que apuntan a que no todos verifican lo que aparece impreso en un pequeño papel (especialmente entre la población con debilidad visual). Otros datos apuntan a votantes que se llevan su recibo, confiando en que resultará irrelevante (y posiblemente para cerrar el círculo para una compra de votos). Otros más apuntan a la dificultad que enfrentaría un votante si quisiera demostrar que él quiso emitir su voto en un sentido, pero la máquina lo imprimió en otro: ¿Cómo debe reaccionar la mesa electoral ante ello?
Podría (y me gustaría) seguir argumentando, aunque sé que probablemente esto comenzaría a sumir a más de uno de los lectores en el aburrimiento — Les dejo sólo un último punto para reflexionar: Alemania fue uno de los primeros países en incursionar en el voto electrónico. En 2009, lo abandonó por completo.
El argumento esgrimido por la Suprema Corte Federal es tan demoledor como bello: ¿Quién está facultado para realizar el escrutinio? El proceso democrático tiene muchos ingredientes que invitan al involucramiento de la sociedad. Es por eso que, prácticamente en todos los países del mundo, los funcionarios electorales son ciudadanos sin afiliación partidaria o gubernamental, seleccionados por sorteo. Cualquier persona con escolaridad básica e interés en la vida de su país puede auditar la emisión del voto, conteo, llenado de actas, transmisión y totalización de resultados.
En el momento que involucramos a urnas electrónicas, estamos descalificando para la comprensión del proceso electoral a más del 99% de la población — Y lo que es peor, exige que ese 99% confíe no sólo en el 1% capaz de comprender el código, sino que en la mucho más pequeña porción de dicho 1% que diseñó el modelo específico de equipo de votación empleado.
La tecnología ha modificado prácticamente todos los aspectos de nuestras vidas. Hoy usamos computadoras prácticamente en todo momento, y la mayor parte de estos cambios han sido profunamente para bien. Sin embargo, en algunos aspectos, sencillamente no van. Espero que, al igual que yo, todos ustedes prefieran reunirse a tomar un café con sus amigos humanos que platicar con un agente de inteligencia artificial.
A pesar de ser una fantasía recurrente en la ciencia ficción, espero que nunca llegue el día en que nos enamoremos de robots en vez de tener una pareja, un compañero de vida, con sangre en las venas al igual que nosotros. Nuestra vida en sociedad merece ser mediada entre humanos, y merece que seamos humanos los actores en sus partes substantivas. El acto fundamental de una sociedad democrática no gana mucho si es puesto en manos de un equipo electrónico, y tiene muchísimo que perder.
Mantengámonos votando en papel. Es cuestión de confianza.

De single-boards y microcontroladores

TitleDe single-boards y microcontroladores
Publication TypeMagazine Article
Year of Publication2013
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
Issue Number41
Pagination18,19
Date Published08/2013
Type of Articlecolumn
ISSN1870-0888
URLhttp://sg.com.mx/revista/41/single-boards-y-microcontroladores
Full Text

Las promesas del Internet de las cosas han estado por décadas ya a la vuelta de la esquina, y cada vez parecen acercarse más. Imaginar un mundo de sub-artefactos inteligentes (me niego a darle el título de computadora completa a un empaque de leche, el típico ejemplo, por el simple hecho de que un microcontrolador en su empaque me permita leer «Contenido: 32%; Frescura: 4 días») nos ha resultado natural desde hace mucho, posiblemente por la prevalencia de estas ideas en las novelas de ciencia ficción por mucho más tiempo ya.
Como contraejemplo, la adopción, crecimiento y masificación de Internet, y lo fundamental que nos resulta hoy en día para comprender a la sociedad o participar en ella, nos tomó mucho más por sorpresa, y tal vez sea en parte porque era algo prácticamente nunca imaginado. Si revisamos la ciencia ficción entre los años 1950 y 1980, muchos relatos consideran como un hecho casi cotidiano el tema del viaje en el espacio y –dependiendo, claro, de las inclinaciones narrativas del autor– la inteligencia de las cosas que acompañan a los héroes del relato, pero muy frecuentemente las comunicaciones que describen se sienten, a nuestros ojos y a sólo 20 años de la masificación de Internet, como reliquias de tiempos hace mucho desaparecidos. Vamos, se sienten tan anacrónicas como hoy en día un fax, ese mágico e impresionante implemento que a tantos nos maravilló hace no tanto tiempo.
¿Y por qué el contraejemplo? Porque tuvieron que pasar varios años desde el inicio de la masificación del uso de Internet hasta que fuera terreno explorado y comprendido por el ecosistema que hoy la conforma.
Entonces, decíamos, parece que, ahora sí, las cosas (en contraposición de las computadoras, a quienes podemos ver como ciudadanos de pleno derecho en nuestra red de redes) están a punto de estar tan conectadas como nosotros, con nuestros lentos y analógicos cerebros que requieren de prótesis para participar en el intercambio global de información. ¿Por qué ahora sí?
Hay dos factores fundamentales que han demorado esta realidad, fuertemente interrelacionados: Costo y tamaño. El Internet de las cosas requiere que los miles de computadoras y microcontroladores que nos rodeen sean tan pequeños, y que lleven un precio unitario tan marginal, que podamos olvidarnos de ellos, que no nos acordemos de su existencia excepto cuando requiramos pedirles información (o cuando estos determinen, basados en los valores que les configuramos previamente, que ocurrió un evento de nuestro interés). Y en ambos casos, todo apunta a que ahora sí estamos a punto de dar el paso.
Me gustaría hacer predicciones acerca de cómo es que esto nacerá como un nicho, y se masificará tanto o más que lo que ha hecho Internet. Sería muy divertido ahondar en cómo resolver los problemas de autoconfiguración y de uso de ancho de banda cuando tengamos cientos de redes de área personal luchando por intercambiar mensajes de forma coordinada en un mismo vagón de metro, e imaginar las tremendas implicaciones que estos desarrollos tendrán para otra redefinición más de lo que constituye información íntima, privada, personal… Pero mi horóscopo el día de hoy apuntaba a que todas las predicciones que haga serán erróneas.
Entonces, para evitar caer en la futurología, toca la tarea de evitar que el futuro nos tome desprevenidos. ¿Cómo podemos comenzar a desarrollar habilidades y conocer las herramientas que emplearemos para no sólo utilizar, sino que ser partícipes de la creación del Internet de las cosas?
Los invito a voltear hacia el área denominada del Cómputo de ultra-bajo costo (Ultra Low Cost Computing, ULCC). En los últimos años han salido al mercado varios dispositivos con los que podemos irnos acercando a las restricciones y las realidades del entorno con el que trabajaremos. Sugiero mirar, con ojos muy distintos, en dos direcciones fundamentales: Por un lado, hacia el desarrollo de microcontroladores, y por el otro, hacia el desarrollo de computadoras mínimas (Single-board computers). Y en particular, a pesar de que hay ya una amplia gama de productos que cubren este espacio, los productos más definitorios del sector hoy en día son el Arduino y la Raspberry Pi.
Es dificil definir de forma clara y sin ambigüedad el punto en que deja de ser un microcontrolador y comienza a ser una computadora mínima. El punto que empleo es la existencia o falta de puertos para interfaces estándar de entrada/salida: Al trabajar con microcontroladores, en general interactuaremos con ellos exclusivamente a través de una serie de pines individuales que pueden ser programados y manipulados de forma independiente; en una computadora mínima normalmente es posible conectar por lo menos un teclado y un monitor.
Un punto, a mi entender, muy importante en ambos casos es que estas dos principales plataformas son productos desarrollados en primer término con fines educativos — Tema que abordaré brevemente.

La familia Arduino

La familia de microcontroladores Arduino nace desde modelos muy básicos, con 2KB de memoria y basados en un procesador de 8 bits, pero al ser diseños de hardware libre, diferentes diseños han ido apareciendo, incorporando todo tipo de interfaces, procesadores más avanzados y medios de adquisición de datos.
Pero incluso con los diseños más sencillos, ver lo que en unas cuantas tardes de ocio dedicado a programar puede lograr un aficionado a la electrónica es impresionante: Me tocó ver a un pequeño Arduino con 2.5KB de memoria controlando una pantalla de televisión analógica, empleando únicamente dos de sus hilos de salida. Con sólo usar como referencia los relojes que emplea el viejo estándar de televisión NTSC y un poco de ingenio, nos presentaron un pequeño videojuego. No, no utilizando una tarjeta de video, sino que modulando la frecuencia directamente con el procesador.
Los Arduinos se programan por medio de un lenguaje cercanamente derivado de C, que incluye macros facilitando el uso de las características del hardware.
El precio de los Arduino (a partir de unos 20 dólares) puede parecer elevado si consideramos que querremos embeberlo en todo tipo de productos. Pero una vez desarrollado el prototipo, puede contratarse la manufactura a gran escala de un microcontrolador dedicado, todavía más pequeño y más barato que éste. Los Arduinos están basados en arquitecturas de procesadores disponibles comercialmente, y sin duda los veremos poblando a muchas de esas cosas inteligentes conectadas a la red.

Raspberry Pi

La Raspberry Pi ha causado un gran revuelo e interés en la comunidad de aficionados: Es una pequeña computadora, con prestaciones equivalentes a los equipos de escritorio que estaban en el mercado hace 5 o 10 años, a un precio de apenas €30, y con suficientes puertos y capacidad para considerarla una computadora completa. Además, tiene –al igual que los Arduino– una serie de pines independientes para entrada y salida programable, pensados para manejar una serie de sensores y actuadores según lo requiera cada proyecto.
Lo que logra una Raspberry con su humilde procesador ARM y 256 o 512MB de memoria (depende del modelo) es notable: Puede correr una distribución estándar de Linux, con un entorno ligero de escritorio. El sistema Raspbian, promovido por sus desarrolladores, viene cargado con entornos de enseñanza de programación aptos para niños de diferentes edades, y con herramientas de cómputo en general — Navegador, suite de oficina, etc.
En mi opinión, resulta erróneo presentar a la Raspberry como un reemplazo de computadoras estándar para entornos económicamente desfavorecidos. A pesar de haber experiencias como la de un laboratorio de computación en una región rural de Camerún,1 y probablemente haya muchos otros, estas maquinitas están más bien enfocadas a la enseñanza de computación a otro nivel, enfocadas a crear nuevas soluciones, casos de uso aún no cubiertos. Convertir a una Raspberry en una computadora tradicional eleva fuertemente su costo (el impulsor europeo del proyecto de Camerún estima €250).

¿Fines educativos?

Como ya mencionamos, tanto los Arduinos como la Raspberry fueron creadas originalmente con fines educativos. ¿Por qué resulta esto relevante? Más allá de ser ejemplos de desarrollos exitosos de hardware libre, diseñados por una comunidad de entusiastas, un importante punto es que son proyectos que buscan despertar la creatividad, el asombro que muchos de nosotros sentimos hace tantos años, al tener la oportunidad de usar una computadora por primera vez, al darnos cuenta de que en realidad podíamos hacer que un artefacto mágico nos obedeciera.
Obviamente, esa época pasó, y describir la magia de algo hoy tan cotidiano no hace más que constatar la edad del que escribe. Sin embargo, yendo más allá de la importancia de estos dispositivos como parte de una estrategia comercial y de desarrollo de habilidades profesionales, me parece muy importante que estos "bichitos" pueden encender la curiosidad y atraer a nuevos entusiastas a nuestro campo.
El nivel de matriculación en las carreras que conducen a la formación de profesionales capaces de desarrollar sistemas e impulsar las nuevas tecnologías han ido cayendo a nivel mundial. Nuestra profesión ya no es vista como "la carrera del futuro", y cada vez es menor la proporción de jóvenes que deciden dedicarse al apasionante mundo del desarrollo de sistemas. Sin embargo, la ciencia ficción sigue llamando, seguimos queriendo traer la magia que nos prometieron para aquel nebuloso futuro que no termina de llegar. Estos modestos juguetes pueden también representar parte de la respuesta y traer a nuevos entusiastas.

Pies de página:

1 http://www.raspberrypi.org/archives/3634 — Bringing computing to rural Cameroon

AttachmentSize
201308_softwareguru_1.jpg2.63 MB
201308_softwareguru_2.jpg2.9 MB

Privacidad, vigilancia, filtraciones, y el resto de nosotros

TitlePrivacidad, vigilancia, filtraciones, y el resto de nosotros
Publication TypeMagazine Article
Year of Publication2013
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
Issue Number42
Date Published11/2013
Type of Articlecolumn
ISSN1870-0888
URLhttp://sg.com.mx/revista/42/privacidad-vigilancia-filtraciones-y-el-resto-nosotros
Full Text

Este año que va terminando tuvo una buena cantidad de sorpresas y de temas prevalentes con que podremos caracterizarlo al referirnos a él en el futuro. Pero muchos estarán de acuerdo en que si tuviéramos que elegir un solo tema que revele los cambios de percepción (y los resultantes cambios conductuales de la población toda), en particular en nuestra área de ocupación, muy probablemente será todo lo que se ha escrito y debatido alrededor de las filtraciones de Snowden. La confirmación de que la Agencia de Seguridad Nacional (NSA) de los Estados Unidos lleva a cabo un espionaje profundo y constante sobre los datos relativos a las comunicaciones, no sólo de sus 300 millones de habitantes, sino que de todo lo que pasa por las redes que cruzan su país (lo cual significa, con mucho, la mayor parte del tráfico de Internet del mundo), y de forma un tanto más selectiva, de tantas personas como sea posible en todo el mundo.
El lector cuidadoso habrá notado que no califico de revelador a las filtraciones mismas, sino que al fenómeno que ha surgido alrededor de ellas. Posiblemente uno de los hechos más fascinantes acerca de esto que muchos han bautizado de fantasía distópica vuelta realidad es que… El nivel y profundidad del espionaje no sorprenden a nadie. Los datos que reveló Snowden no nos revelan nada que no supusiéramos — Su impacto está en que nos lo confirman, nos detallan los mecanismos con que operan, algunos nombres clave, y poco más que eso. Y sin embargo, desde que las primeras filtraciones respecto a PRISM fueron publicadas el 5 de junio, tras la huída de Snowden a Hong Kong… Toneladas de tinta han corrido (electrónica y tradicional) reseñando tanto las filtraciones originales como a otras posteriores, tal vez de menor envergadura, pero de mayor impacto. Con estas me refiero a las revelaciones específicas que se han hecho acerca de los mecanismos de espionaje a actores políticos, particularmente de Alemania, Brasil, China, Francia, el Reino Unido — Y México.
Claro está, si bien son datos completamente independientes, estas filtraciones se engranaron perfectamente con las publicadas en 2010 por Wikileaks. Y el principal argumento que ha respondido el gobierno de los Estados Unidos ha sido también el mismo:1 Básicamente, «Si espiamos, es porque requerimos tener información acerca de los riesgos que nos acechan; cualquier gobierno tiene que hacerlo, y la NSA se mantiene dentro de su marco legal». Argumento, a ojos de muchos, falaz, incompleto e insatisfactorio — Pero no por eso inesperado.
Resulta interesante ver cuál ha sido la reacción de algunos de los gobiernos recién mencionados. Tristemente, el nuestro no ha presentado mayor muestra de incomodidad; al día de hoy, la mayores reacciones han sido las de Alemania y Brasil. Y si bien es aún muy temprano para hablar de resultados tangibles, el movimiento que se ha despertado –entre entidades gubernamentales– para crear un tendido de fibras que una a los países de Sudamérica directamente con los europeos, para dejar de depender de las telecomunicaciones estadounidenses, apuntan claramente en un sentido interesante.

Pero… ¡Son sólo metadatos!

Otra respuesta, que vimos particularmente en los primeros momentos tras estas revelaciones, resulta también muy interesante — Y es a partir de esta que quiero elaborar. La NSA justificó la información recabada por medio de PRISM como inocua indicando que no se ocupaban del registro de los datos (grabación de las llamadas telefónicas o correos electrónicos), sino que únicamente de los metadatos (quién habla con quién, a qué hora lo hace, por cuánto tiempo). Esto permite a la NSA enfocarse en quienes traban contacto regular con los actores más peligrosos, o presentan patrones más sospechosos. Esperaban con esto acallar a los defensores de la privacidad.
Lo que me sorprendió en este sentido no es que una o dos personas dijeran, "eso que dicen es falso". Cientos de aficionados al análisis de patrones por todo el mundo lo dijimos, en nuestros pequeños foros. Lo que me sorprendió es la cantidad de publicaciones que hubo, en espacio de apenas un par de días, demostrando el verdadero impacto de los datos que PRISM había recabado en términos claros y concisos, en claros artículos de divulgación. Un par de ejemplos:

  • El 7 de junio, la conocida organización de defensa de los derechos personales en el mundo digital, Electronic Frontier Foundation, publicó un texto corto, de menos de una cuartilla: «Why Metadata Matters».2 Por medio de cinco sencillísimos ejemplos demuestran que los metadatos son muchas veces más importantes que los mismos datos, revelan tanta información como la que revelaría el contenido mismo de las llamadas. Estos ejemplos aparecieron repetidos en decenas de otras publicaciones de los días subsecuentes.
  • El 9 de junio, Kieran Healy publicó en su blog «Using Metadata to find Paul Revere».3 Hace un paralelo de lo más simple e interesante, dando los fundamentos del análisis de redes sociales desde una perspectiva sociológica, que podría haber conducido al arresto de uno de los padres de la independencia de los Estados Unidos por parte de los ingleses.
  • Matt Blaze, investigador en criptografía de la Universidad de Pennsylvania, presentó el 13 de junio en la revista Wired el artículo «Phew, NSA Is Just Collecting Metadata. (You Should Still Worry)»;4 en un breve artículo cubre la profundidad de la información que puede obtenerse de sólo conocer los metadatos, y el por qué resulta tan difícil evitar dejar rastros, incluso siendo individuos plenamente informados.

Pero, de nuevo, estas filtraciones no son nada verdaderamente nuevo, sólo trajeron de vuelta (y con gran fuerza) a una arena más amplia el debate sobre lo que ya era bien conocido. Como ejemplo, me permito referirlos a la columna que publiqué en Software Gurú hace dos años y medio, «Georeferenciación a nuestras espaldas».5

La red toda: ¿En quién confiamos?

Ahora, ¿qué hay cuando nos enfocamos en algo más cercano a nuestra vida diaria? ¿Qué hay acerca de las empresas cuyos servicios empleamos en nuestro diario navegar? Algunas de las revelaciones más importantes que han seguido a las filtraciones originales se encaminan mucho más al cómo obtuvo el gobierno americano los datos en cuestión: A través de solicitudes (muchas veces más bien casuales, no necesariamente por los canales que demanda la justicia) hechas a los principales proveedores de servicios. Facebook, Google, Amazon, los proveedores de conectividad responden gustosamente a todas las solicitudes de información.6
Hay, claro, otras empresas que basan su operación y su reputación en asegurar la privacidad de sus usuarios. Y en agosto nos encontramos con algo muy parecido a la historia del cierre del anonimizador más famoso de la red, anon.penet.fi, allá por 1997:7 El proveedor de correo seguro Lavabit, en el cual tenía su cuenta Snowden, decidió cerrar operaciones por completo antes que otorgar a la NSA las llaves criptográficas que les permitirían tener acceso a la información de todos sus usuarios. Pero este caso de respeto a la privacidad es claramente minoritario.
A niveles intra-organizacionales, tras una primer etapa de emoción por emplear servicios en la nube, he visto un resurgimiento del interés por no perder la flexibilidad, pero operar dentro de nubes propias. Pongo como ejemplo a la UNAM, que tras algunos años de haber enviado la gestión del correo electrónico de decenas de miles de sus académicos a la nube de Microsoft, probablemente por presiones de los mismos, ahora está ofreciendo nuevamente trasladarlo a infraestructura propia.8

Privacidad y vigilancia… ¿De quién?

Supongo que hasta este punto, prácticamente todos los lectores van conmigo. Nadie quiere ser espiado, y mucho menos por el gobierno de una nación extranjera, un gobierno que ha demostrado una y otra vez que no conoce de límites.
Pero por otro lado, muchos de nosotros no tendremos mucho que temer en lo personal de dicho gobierno, o incluso del nuestro propio (que estaría mucho más directamente interesado en conocer algunas de nuestras peligrosas actividades, tal vez incluso de actuar en consecuencia). Pero… Como dicen, quien tiene la información tiene el poder. ¿Tenemos que pensar tal vez en otros actores que estén penetrando a la esfera de nuestros datos?
Si bien siempre ha habido quien intenta que comprendamos la gravedad del tema (¿Visionarios? ¿Activistas? ¿Obsesivos? ¿Paranóicos? El calificativo queda en manos de usted, querido lector), el tema apenas está entrando al debate público ahora. Sobra explicar a este público el potencial y la profundidad de lo que se puede obtener por medio de mecanismos de minería de datos, del famoso Big Data.
Hay una gran cantidad de razones por las cuales cada uno de nosotros como persona podría no querer brindar todos sus patrones de movimiento y comportamiento social — Ya no sólo a los gobiernos del mundo, sino que a las grandes empresas de publicidad dirigida (recordemos que el gigante tecnológico Google es en primer término una empresa de publicidad, y sólo despúés de ello todo lo demás).
Más allá de la publicidad: Los vendedores de servicios. Desde los más directos y honestos, como Amazon (¡pero recordemos lo importante que les resulta construir nuestros perfiles de consumo personal cuando les contratemos espacio en la nube!) hasta los más obscuros (Seguramente han visto que distintos sitios de relaciones discretas entre adultos
se toman la molestia de crear un perfil a su nombre al enviarles publicidad, facilitándoles emplear sus servicios).
Y para nosotros que hemos invertido tanto en convertirnos en tecnólogos respetados, ¿qué tanto podemos cuidar nuestra identidad sin convertirnos en ermitaños digitales, sin renunciar a las bondades de la red? Hay una gran cantidad de matices. Si les interesa profundizar en el tema, les invito a leer el texto publicado por Sarah Kessler en la revista electrónica Fast Company9.
Les sugiero también revisar varios de los artículos que publica este mismo mes la revista Communications of the ACM10, que tocan el tema desde muy distintos ángulos: Desde la editorial, que compara la realidad actual con el 1984 de George Orwell hasta explicar por qué una tecnología tan potencialmente invasiva como el Google Glass, que presenta ejemplos de cómo las expectativas de privacidad han cambiado en los últimos cien años con ejemplos que, a pesar de su seriedad hace décadas, hoy nos parecen francamente risibles.

Nota al pie

1 Encontrarán muchas fuentes, cito meramente como ejemplo a http://www.jornada.unam.mx/2013/10/26/index.php?section=mundo&article=016n1mun
2 https://www.eff.org/deeplinks/2013/06/why-metadata-matters
3 http://kieranhealy.org/blog/archives/2013/06/09/using-metadata-to-find-paul-revere/
4 http://www.wired.com/opinion/2013/06/phew-it-was-just-metadata-not-think-again/
5 http://gwolf.org/node/3089
6 Por ejemplo, a fines de agosto, Facebook publicó el «Reporte Global de Requisiciones Gubernamentales»,
https://www.facebook.com/about/government_requests
7 http://www.december.com/cmc/mag/1997/sep/helmers.html
8 http://infocorreo.unam.mx/
9 http://www.fastcompany.com/3019847/think-you-can-live-offline-without-being-tracked-heres-what-it-takes
10 http://cacm.acm.org/magazines/2013/11

AttachmentSize
Published in the magazine (pg. 1)1.32 MB
Published in the magazine (pg. 2)1.36 MB

2014

Artículos y columnas publicados en 2014

Nubes públicas, privadas y propias

TitleNubes públicas, privadas y propias
Publication TypeMagazine Article
Year of Publication2014
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
Issue Number43
Pagination28,29
Date Published04/2014
Type of Articlecolumn
ISSN1870-0888
URLhttp://sg.com.mx/revista/43/nubes-publicas-privadas-y-propias
Full Text

Hay dos ángulos principales desde los cuales podemos visualizar el uso de la nube: Por un lado, como desarrollador y proveedor de servicios, hablar de la nube nos hace pensar en escalabilidad, paralelización, distribución geográfica en redes de entrega de contenidos (CDNs), y demás aspectos técnicos, estoy seguro que la mayor parte de los textos en este número irán en ese sentido. Sin embargo, la nube es también, y cada vez más, un concepto que manejan los usuarios finales.
Nuestros usuarios, incluso los menos tecnófilos, están empleando los servicios en la nube con cada vez mayor frecuencia. De una forma muy diferente, claro, pero… ¿qué no es acaso lo mismo?
Quisiera entonces que hagamos una pausa para pensar en los tres modos clásicos en que nos referimos a la nube: IaaS, PaaS, SaaS —respectivamente, Infraestructura, Plataforma y Software como un servicio—, pero haciéndolo desde la perspectiva de cómo los usuarios finales interactúan con cada una de dichas modalidades.

SaaS

Esta modalidad resulta natural. El uso de aplicaciones medianamente interactivas desde un navegador web califica perfectamente para ser un ”software como servicio”. Teniendo los datos almacenados en la nube, la computadora local actúa básicamente como un cliente delgado, que no hospeda la lógica de la aplicación como tal.
El mismo término SaaS nació para describir lo que ya era práctica común: El uso masivo de software hecho para presentarse en un navegador Web. Hoy en día, ya asumimos que para poder trabajar cómodamente con una computadora, cualquier usuario requiere conectividad a Internet. El cliente de correo, los marcadores, las referencias para lo que estemos haciendo … Es cierto que todavía podemos trabajar desde lugares sin red, pero cada vez más tenemos que planear dichos periodos de desconexión.

IaaS

Parecería que esta categoría estaría reservada sólo para los administradores de sistemas a gran escala, y si acaso a sus usuarios corporativos, máquinas virtuales, configuración del equipo (virtual) de red entre ellas, almacenamiento común a dichos equipos, redes privadas virtuales, etcétera. Sin embargo, hagamos símiles: cada vez es más frecuente que nuestros usuarios empleen servicios de alojamiento y compartición de archivos. Además, parte de lo que ofrecen en este sentido varios de los proveedores es la instalación local de un programa para sincronizar automáticamente un directorio local con el almacenamiento remoto. ¿No es acaso esto, para todo propósito práctico, Infraestructura como un Servicio?

PaaS

Me costó un poco más de trabajo encontrar cómo el usuario final emplea plataformas. Una plataforma es algo que nos facilita nuestros desarrollos, que nos permite tomar piezas como bloques de construcción listos y construir sobre ellos. ¿Qué puede hacer un usuario final que pueda verse de este modo?
La respuesta se hace obvia cuando, nuevamente, extendemos las fronteras del significado. Viendo la cantidad de sitios Web que emplean mecanismos al estilo de OpenID u OAuth para la autenticación y autorización centralizada, ¿qué es esto sino el despliegue de una Plataforma como un Servicio?
Ahora bien, al hablar de cómputo en la nube, un tema que está siempre presente es el de la seguridad y protección de datos. Analicemos un poco la nube para usuarios finales desde este punto de vista.
Justamente en la columna que publiqué en la edición anterior de SG ya había comenzado a hablar de este tema (Cómo mantener un nivel aceptable de privacidad en nuestra vida en línea). No tiene caso reiterar esta conversación sobre privacidad que se ha vuelto parte de nuestra vida diaria, nuestros usuarios están ya mayormente al tanto de lo que significa depositar su confianza en sitios en red.

Se viene la tormenta: ¿Confiamos en nuestros proveedores?

Hay una gran cantidad de proveedores de servicios en la nube para los usuarios finales. Es más, casi todos ellos son gratuitos… tristemente, no podemos olvidar la máxima: ”En la nueva economía, no compras un producto, sino que Tú eres el producto”. Otorgar los datos de nuestros usuarios a Dropbox, Google, Slideshare o cualquier empresa de servicios puede vulnerar la confidencialidad de su información —lo cual resulta tan peligroso para ellos como individuos como para la organización entera.
Los proveedores que menciono no sólo representan un riesgo por las ya tan sonadas filtraciones que demuestran cómo agencias gubernamentales de todo tipo se han dedicado a la vigilancia invasiva, sino que también por la mera popularidad de dichos servicios: Los grandes proveedores son objetivo de ataques de forma prácticamente ininterrumpida. Y si bien el tiempo de respuesta ante incidentes es típicamente muy corto, la cantidad de documentos sustraídos al presentarse un ataque exitoso puede ser muy grande.
Con eso no quiero decir, obviamente, que el código que corramos en nuestro propio servidor sea más seguro o robusto que el que ejecutan los grandes proveedores. Sin embargo, al menos en el momento que se da a conocer un ataque, no dependemos de las prioridades de terceros para aplicar las medidas correctivas.

El borde plateado de mi propia nube

Dice el proverbio en inglés que ”toda nube tiene un borde plateado”, con lo que se refiere a que incluso los problemas tienen aspectos positivos. Teniendo esto en cuenta, podemos darle a nuestros usuarios las principales ventajas de muchas aplicaciones en la nube sin perder el control sobre nuestra información.
No acostumbro emplear el espacio que me brinda SG para promover productos específicos, pero en esta ocasión creo que vale la pena hacerlo, y es por ello que les platicaré sobre OwnCloud. OwnCloud es una respuesta a la necesidad de mantener el control de los datos de nuestros usuarios. Es una aplicación web muy fácil de instalar y utilizar que implementa una impresionante cantidad de servicios que nos permiten hospedar los datos de nuestros usuarios en casa. Y no es una solución artesanal, además de una aplicación Web limpia e intuitiva como pocas, hay clientes para el escritorio y dispositivos móviles. Es software libre, y la empresa que dirige su desarrollo ofrece también planes comerciales de servicio y desarrollo a medida.
OwnCloud también puede ser visto por nosotros los programadores como una plataforma de despliegue corporativo de aplicaciones: es una aplicación modular, escrita en PHP, con una extensa documentación para los desarrolladores de aplicaciones. Y respecto al núcleo de OwnCloud, su desarrollo se realiza en GitHub, con lo cual es fácil darle seguimiento y participar en su desarrollo. El equipo de desarrollo de OwnCloud ha logrado incorporar la responsividad y usabilidad de HTML5 a un nivel que me tiene francamente sorprendido.
¿Y qué tipo de aplicaciones podemos encontrar? Hay de todo. Probablemente la funcionalidad más socorrida es la de espacio de almacenamiento y sincronización de archivos, al estilo de Dropbox. La instalación por defecto de OwnCloud incluye una serie de aplicaciones básicas de productividad (calendario, contactos, gestor de marcadores, reproductor de medios). Si bien es cierto que todas son ya bastante comunes y que ninguna de ellas es ya un “killer app”, su valor está en que estos servicios, que ya asumimos como un lugar común, los podemos proveer desde nuestro propio equipo. Y en este sentido, cabe mencionar que, dado que implementa los protocolos CardDAV y CalDAV, OwnCloud puede operar como proveedor de datos para las principales aplicaciones de dispositivos móviles.
OwnCloud se va poniendo más interesante si planteamos su uso ya no sólo para un uso ocasional, sino como parte de los servicios centralizados de nuestra organización. Por ejemplo, puede manejar la autenticación de usuarios a través de LDAP, manejo de los archivos de los usuarios en los directorios en la red corporativa, y todo un largo etcétera. Una de las características más interesantes de la versión 6, liberada en diciembre del 2013, es la edición colaborativa de documentos.

Conclusión

A pesar de que esta columna parece en esta ocasión una inserción pagada (¡cosa que definitivamente no es!), espero aprecien por qué les presento esta alternativa en el número dedicado al cómputo en la nube. Nuestros usuarios tienen ya su concepción (y probablemente familiaridad) de cómo aprovechar a la famosa nube. Nosotros podemos, a través de herramientas como la que reseñé, contribuir de forma importante con la seguridad de su información. Aplicaciones que cubren algunos de los aspectos abordados hay muchas, pero —hasta donde tengo conocimiento— el nivel de integración y la variedad en la oferta de OwnCloud la hacen destacar.

AttachmentSize
Versión PDF publicada en la revista1.69 MB

Conforme las nieves del tiempo platean mi sien

TitleConforme las nieves del tiempo platean mi sien
Publication TypeMagazine Article
Year of Publication2014
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
Issue Number44
Pagination46
Date Published05/2014
Type of Articlecolumn
ISSN1870-0888
Full Text

Para este número, nuestra coordinadora editorial nos pidió enfocarnos a una retrospectiva de lo que significa esta década que se cumple. E inevitablemente, cada vez que comienzo a pensar al respecto, el plazo se me duplica, y termino tarareando una de dos melodías. Dos hermosas canciones que relatan, melancólicamente, a muy distinto ritmo y desde muy distintas ópticas, el recuerdo de un amor al paso de un largo intervalo de tiempo: La contradanza cubana ``Veinte años'', de María Teresa Vera, y el tango ``Volver'', de Le Pera y Gardel.
En ``Veinte años'', se recuerda algo que terminó de forma irremisible, volviendo a que el amor que ya ha pasado no se debe recordar. Sin embargo, en ``Volver'', si bien parte de una historia de desamor y distancia, culmina en la esperanza de un reencuentro — Y aunque el olvido, que todo destruye, haya matado mi vieja ilusión, guardo escondida una esperanza humilde que es toda la fortuna de mi corazón.
Ambas canciones son de las más identificables y definitorias de sus respectivos géneros. Tal vez sea por lo importantes que nos resultan (obviamente, muy por debajo de una relación amorosa de esperanza y de desgarre, pero sigamos el argumento) los números cerrados, los plazos que nos hacen recordar lo que hacíamos hace toda una vida… Y, en este caso, me quedo con ``Volver'', por la esperanza de seguir adelante, la expectativa ante el futuro.
Mucha gente insiste en que en nuestra área más que en otras el cambio es la única constante. Yo soy de la opinión contraria: Hay un gran desarrollo tecnológico, pero las cosas se mantienen igual mucho más de lo que cambian. Cambian, sí, los detalles, los sistemas específicos que empleamos, alguna metodología que esté de moda… Pero viendo la imagen en grande, nuestro ámbito de acción profesional no da los grandes saltos que algunos suponen. SG nos va dando una importante memoria histórica de lo que va ocurriendo en este campo, en nuestro país.
Revisando los temas de portada de una década de SG, hay una clara lista de temas recurrentes — Los temas candentes que representan la mayor parte de las dudas, necesidades y nuevos desarrollos. Estos temas seguramente nos seguirán dando de qué hablar en los próximos años. El cómputo en la nube (SG #22, #32, #43), metodologías y procesos, en particular los ágiles (SG #1, #9, #25, #26), móviles y embebidos (SG #5, #17, #24, #42, y de cierto modo #28 y #29). Obviamente, siendo el objeto primario declarado de SG, el análisis de la industria de software en nuestro país es uno de los temas más recurrentes (#21, #27, #33, incluyendo los estudios de salarios, #18, #30, #37). 18 de los 44 números que ha publicado SG, pues, tocan temas que se han abordado por lo menos en tres ocasiones.
Claro está, este agrupamiento temático que hago es simplista, y basado únicamente en el el título destacado visualmente en la portada; hacer un ejercicio con las editoriales, columnas y artículos que han formado parte de nuestra revista a lo largo de todo este tiempo sin duda nos arrojaría un interesante árbol temático del ramo con nuestras principales recurrencias.
Entonces, pues… Festejo un lustro. Festejamos una década. Y festejemos con la esperanza de seguir haciéndolo para los veinte años, y para después de ello. Este es el inicio de una historia. Software Gurú cubre un espacio importante y necesario para el desarrollo de nuestro país; el proyecto ha crecido desde su planteamiento original, y definir a SG es cada vez más difícil; revista, congresos, seminarios, y toda una comunidad de profesionales del desarrollo de sistemas. Una comunidad formada por empresarios, académicos, estudiantes, gente con intereses muy diversos, que aquí hemos ido encontrando nuestro espacio.
Nuestro campo demanda que nos mantengamos actualizados, que trabajemos en equipo, que compartamos conocimiento. El espacio que SG brinda a los desarrolladores de software en nuestro país es
fundamental. Sigamos haciendo historia juntos — No cinco o diez años más. Sigamos impulsando al desarrollo de software a largo plazo, como una vocación de vida.
¡Muchas felicidades!

AttachmentSize
As published in the magazine1.53 MB