Hace unos años pasé por la disyuntiva de elegir un nuevo lenguaje de programación y, como les pasará a unos cuantos, llegué a la definición entre python y ruby. En ese momento me decidí por python, ahora no recuerdo bien los motivos en detalle, pero hasta ahora no me arrepentí.
Hoy encontré este post (larguísimo) de por que ruby no es un buen lenguaje. Sinceramente, es la primera vez que leo algo escrito por este tipo, pero a menos que le haya puesto muy pocas ganas a la comparación (o al aprendizaje de ruby), ruby esta en problemas.
¿Es realmente ruby tan malo e inconsistente? Ya sabía que ruby no era muy bueno en cuanto a performance, pero e sorprende que maneje tan mal el soporte de unicode, y los metodos/funciones que hacen cosas similares con nombres diferentes, y peor aun los que hacen cosas diferentes con nombres similares...
Antes que lo lean, aclaro que al tipo le gusta python, y cada tanto manda algunos comentarios que no hacen más que meter ruido, pero mas allá de eso el post me parece muy bueno, y con muchos links a otros articulos relacionados, también interesantes.
Por supuesto, este post generó un montón de comentarios, críticas y también tenía algunos errores. La semana pasada publicó otro post con algunas correccciones y comentacios interesantes.
sábado, 17 de mayo de 2008
martes, 13 de mayo de 2008
Vulnerabilidad en openssh - como arreglarla
Aviso importante para los que usan Debian y sus derivados (entre ellos Ubuntu)!
Para el que todavía no se enteró, esta mañana se reportó una falla grave de seguridad en el OpenSSH para Debian y Ubuntu. Resumiendo, las claves generadas después del 2006 son potencialmente vulnerables dado que las función que genera números aleatorios en openssl era predecible.
Gracias a la velocidad de respuesta del software libre, ya están disponibles los paquetes de actualización para Debian y Ubuntu. Supongo que otras distribuciones pueden tener el mismo problema, pero no lo comprobé.
Para solucionar el problema de seguridad hay que seguir los siguientes pasos.
En primer lugar, actualicen sus sitemas:
$ sudo apt-get update
$ sudo apt-get upgrade
Con esto se arreglan los problemas de las futuras claves que se generen.
Para validar las claves actuales, los desarrolladores de Debian subieron un script para validar las claves personales y de host
$ wget -c http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
$ gunzip dowkd.pl.gz
$ chmod u+x dowkd.pl
$ ./dowkd.pl user
$ ./dowkd.pl host hostname
Si al script le pasamos el argumento user, chequea las claves del usuario. Con el argumento host, se puede indicar un nombre de host al cual se le quiere hacer el testeo.
Si las claves fueron generadas con esta versión defectuosa del openssl, seguro el script va a dar algun mensaje diciendo que la clave es débil. En este caso hay que regenerar las claves del usuario y del host.
Para regenerar las claves de usuario:
$ ssh-keygen -t dsa -b
Para regenerar las claves del host:
$ sudo rm /etc/ssh/ssh_host_{dsa,rsa}_key*
$ sudo dpkg-reconfigure -plow openssh-server
Recuerden que deben limpiar el archivo ~/.ssh/known_hosts y volver a transmitir su clave pública a sus servidores, o es posible que no puedan volver a entrar ;)
Para el que todavía no se enteró, esta mañana se reportó una falla grave de seguridad en el OpenSSH para Debian y Ubuntu. Resumiendo, las claves generadas después del 2006 son potencialmente vulnerables dado que las función que genera números aleatorios en openssl era predecible.
Gracias a la velocidad de respuesta del software libre, ya están disponibles los paquetes de actualización para Debian y Ubuntu. Supongo que otras distribuciones pueden tener el mismo problema, pero no lo comprobé.
Para solucionar el problema de seguridad hay que seguir los siguientes pasos.
En primer lugar, actualicen sus sitemas:
$ sudo apt-get update
$ sudo apt-get upgrade
Con esto se arreglan los problemas de las futuras claves que se generen.
Para validar las claves actuales, los desarrolladores de Debian subieron un script para validar las claves personales y de host
$ wget -c http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
$ gunzip dowkd.pl.gz
$ chmod u+x dowkd.pl
$ ./dowkd.pl user
$ ./dowkd.pl host hostname
Si al script le pasamos el argumento user, chequea las claves del usuario. Con el argumento host, se puede indicar un nombre de host al cual se le quiere hacer el testeo.
Si las claves fueron generadas con esta versión defectuosa del openssl, seguro el script va a dar algun mensaje diciendo que la clave es débil. En este caso hay que regenerar las claves del usuario y del host.
Para regenerar las claves de usuario:
$ ssh-keygen -t dsa -b
Para regenerar las claves del host:
$ sudo rm /etc/ssh/ssh_host_{dsa,rsa}_key*
$ sudo dpkg-reconfigure -plow openssh-server
Recuerden que deben limpiar el archivo ~/.ssh/known_hosts y volver a transmitir su clave pública a sus servidores, o es posible que no puedan volver a entrar ;)
sábado, 3 de mayo de 2008
Instalación de Hardy en la Macbook
Estuve probando la instalación de Ubuntu Hardy en modo 32 bits en la MacBook, ya que había encontrado algunos problemas con la paca wifi al actualizar la versión de 64 bits.
La instalación fue sorprendentemente rápida, en unos 25 minutos la máquina estaba instalada y corriendo con la versión de 32 bits, pero tuve los mismos problemas con la placa wifi. Tuve que compilar los módulos a mano, pero no se asusten que es algo muy simple, solo un par de comandos.
Por ahora parece que me quedo con los 32 bits. El consumo de memoria es un poco menor, y aparentemente debe haber alguna diferencia en los drives de video (placa intel) ya que el X levanta un poquito más rápido.
Más allá del problema de la placa wifi, cabe destacar lo fácil y rápido que es instalar Ubuntu. En menos de media hora tenés un sistema funcionando con un sistema operativo de última generación, en el idioma que hayas elegido, y con todas las aplicaciones que un usuario normal pueda necesitar: suite de oficina, un navegador como la gente, mensajería instantánea, reproductor de medios, etc, etc.
La instalación fue sorprendentemente rápida, en unos 25 minutos la máquina estaba instalada y corriendo con la versión de 32 bits, pero tuve los mismos problemas con la placa wifi. Tuve que compilar los módulos a mano, pero no se asusten que es algo muy simple, solo un par de comandos.
Por ahora parece que me quedo con los 32 bits. El consumo de memoria es un poco menor, y aparentemente debe haber alguna diferencia en los drives de video (placa intel) ya que el X levanta un poquito más rápido.
Más allá del problema de la placa wifi, cabe destacar lo fácil y rápido que es instalar Ubuntu. En menos de media hora tenés un sistema funcionando con un sistema operativo de última generación, en el idioma que hayas elegido, y con todas las aplicaciones que un usuario normal pueda necesitar: suite de oficina, un navegador como la gente, mensajería instantánea, reproductor de medios, etc, etc.
domingo, 27 de abril de 2008
Actualizando Ubuntu de Gutsy a Hardy
Finalmente, ayer me pasé a la nueva versión de Ubuntu: 8.04 LTS, Hardy Heron.
Para los que no están en el tema, Ubuntu es una de las distribuciones de Linux más populares, principalmente por su facilidad de instalación y soporte de hardware. Cada seis meses sacan una nueva versión, de ahí que los números de versión crezcan tan rápido: el primer número es el año, y el segundo el mes.
En el caso de Hardy, es una release especial ya que es una LTS: Long Term Support (Soporte a Largo Plazo). Las versiones comunes de Ubuntu tienen soporte por dieciocho meses, después de los cuales se dejan de liberar parches de seguridad y actualizaciones. En el caso de las LTS, el período de soporte es de tres años para el escritorio, y cinco para servidores.
La impaciencia y los embotellamientos
El año pasado, cuando salió Gutsy Gibbon (7.10), los servidores se habían saturado... bajar un imagen del cd o actualizar directamente había sido bastante tedioso. Este año, por lo menos para mí, fue directamente una tortura. Bajar 1Gb de paquetes para actualizar me llevo unas doce horas. Me da la sensación de que cada vez hay más gente ansiosa por probar las nuevas versiones de Ubuntu, lo cual es buenísimo, lástima que se arman unos embotellamientos como los de semana santa yendo para la costa ;)
Supongo que para la nueva release (8.10) deberíamos ser un poco más pacientes y no tratar de actualizar todos juntos en los primeros tres días, o lo que sería mejor, conseguir algo de fondos para configurar un mirror local ya que en Argentina no tenemos ninguno todavía. ¿Alguna empresa o universidad solidaria?
Para no esperar tanto, si consiguen un cd de instalación o un alternative de Hardy, pueden acelerar la descarga de paquetes copiando los archivos que están en el directorio pool del cd. Una vez dentro de ese directorio, ejecuten lo siguiente:
sudo -i
for file in `find ./ -iname '*.deb'`; do cp $file /var/cache/apt/cache/; done
exit
Luego lancen la actualización y solo tendrán que bajar los archivos que no estén en el CD.
Actualizando la notebook
En mi caso, no todo funcionó automáticamente ya que estoy usando la versión de 64 bits y no todos los drivers funcionan bien. Para los que no tengan ganas de andar resolviendo problemas menores, les recomiendo la versión de 32 bits.
La actualización la hice mediante el Update Manager, la utilidad de actualización de programas y versiones de Ubuntu. Luego de esperar esas 12 horas descargando paquetes de actualizaciones, comenzó el proceso de actualización propiamente dicho.
Este proceso tardó unos 35 minutos. Solo me preguntó si quería actualizar ciertos archivos de configuración o remplazarlos por los nuevos para algunos servicios determinados que dudo que utilice un usuario no técnico (webservers, bases de datos, etc)
Luego de reiniciar el sistema el nuevo Hardy estaba listo, aunque como me pasó en la instalación de Gutsy, la placa de wifi no funcionó automáticamente. Supongo que está relacionado con la instalación de 64bits, porque cuando había instalado Gutsy de 32bits funcionó de entrada. Cuando tenga tiempo pruebo la instalación de Hardy de 32bits.
De todas formas, hacer funcionar la placa fué simple. Solo tuve que instalar los drivers siguiendo los mismos pasos que para Gutsy.
La webcam tampoco funcionó, y encontré que hay un bug reportado en el que están trabajando activamente. Esperemos las primeras actualizaciones para ver si se arregla.
Actualizando un server
Hace rato tengo un server en SliceHost para hacer pruebas y mantenerme un poco al día en el trabajo de sysadmin, ya que ahora estoy trabajando sólo como programador.
En este server estaba corriendo MySQL, Lighttpd, TurboGears, y un par de cositas más, todo sobre Gutsy.
La actualización fue de lo más simple. Hay que bajar el actualizador con el siguiente comando:
sudo apt-get install update-manager-core
y luego, ejecutar la herramienta de actualización de consola:
sudo do-release-upgrade
Otra vez a esperar la descarga de paquetes, pero en este caso la velocidad fue increíble. Se nota la diferencia de acceso a internet que tenemos en sudamerica y la que tienen en EE.UU. En mi casa los paquetes se bajaron a unos miserables 30k/s, en el server, a unos 1000k/s de promedio con unos picos bastante mas altos. En menos de cinco minutos había bajado todos los paquetes para el server.
El proceso de actualización tardo unos 15-20 minutos, las mismas preguntas sobre archivos de configuración de servicios, reiniciar... y todo funcionando exactamente igual que antes: bases de datos, servicios, todo 10 puntos. Ahora tengo un server con 5 años de soporte! Aunque supongo que no me voy a aguantar y en octubre lo paso a la nueva release :)
Conclusión
Sacando los temas conocidos para las MacBook con la placa wifi en 64bits, la actualización fue excelente. Sólo tenemos que conseguir uno o dos mirrors locales en Argentina, porque con cada release, el embotellamiento es más grande.
Cuando pruebe la instalación de 32bits (recomendada para los menos experimentados), les cuento como me fué.
Para los que no están en el tema, Ubuntu es una de las distribuciones de Linux más populares, principalmente por su facilidad de instalación y soporte de hardware. Cada seis meses sacan una nueva versión, de ahí que los números de versión crezcan tan rápido: el primer número es el año, y el segundo el mes.
En el caso de Hardy, es una release especial ya que es una LTS: Long Term Support (Soporte a Largo Plazo). Las versiones comunes de Ubuntu tienen soporte por dieciocho meses, después de los cuales se dejan de liberar parches de seguridad y actualizaciones. En el caso de las LTS, el período de soporte es de tres años para el escritorio, y cinco para servidores.
La impaciencia y los embotellamientos
El año pasado, cuando salió Gutsy Gibbon (7.10), los servidores se habían saturado... bajar un imagen del cd o actualizar directamente había sido bastante tedioso. Este año, por lo menos para mí, fue directamente una tortura. Bajar 1Gb de paquetes para actualizar me llevo unas doce horas. Me da la sensación de que cada vez hay más gente ansiosa por probar las nuevas versiones de Ubuntu, lo cual es buenísimo, lástima que se arman unos embotellamientos como los de semana santa yendo para la costa ;)
Supongo que para la nueva release (8.10) deberíamos ser un poco más pacientes y no tratar de actualizar todos juntos en los primeros tres días, o lo que sería mejor, conseguir algo de fondos para configurar un mirror local ya que en Argentina no tenemos ninguno todavía. ¿Alguna empresa o universidad solidaria?
Para no esperar tanto, si consiguen un cd de instalación o un alternative de Hardy, pueden acelerar la descarga de paquetes copiando los archivos que están en el directorio pool del cd. Una vez dentro de ese directorio, ejecuten lo siguiente:
sudo -i
for file in `find ./ -iname '*.deb'`; do cp $file /var/cache/apt/cache/; done
exit
Luego lancen la actualización y solo tendrán que bajar los archivos que no estén en el CD.
Actualizando la notebook
En mi caso, no todo funcionó automáticamente ya que estoy usando la versión de 64 bits y no todos los drivers funcionan bien. Para los que no tengan ganas de andar resolviendo problemas menores, les recomiendo la versión de 32 bits.
La actualización la hice mediante el Update Manager, la utilidad de actualización de programas y versiones de Ubuntu. Luego de esperar esas 12 horas descargando paquetes de actualizaciones, comenzó el proceso de actualización propiamente dicho.
Este proceso tardó unos 35 minutos. Solo me preguntó si quería actualizar ciertos archivos de configuración o remplazarlos por los nuevos para algunos servicios determinados que dudo que utilice un usuario no técnico (webservers, bases de datos, etc)
Luego de reiniciar el sistema el nuevo Hardy estaba listo, aunque como me pasó en la instalación de Gutsy, la placa de wifi no funcionó automáticamente. Supongo que está relacionado con la instalación de 64bits, porque cuando había instalado Gutsy de 32bits funcionó de entrada. Cuando tenga tiempo pruebo la instalación de Hardy de 32bits.
De todas formas, hacer funcionar la placa fué simple. Solo tuve que instalar los drivers siguiendo los mismos pasos que para Gutsy.
La webcam tampoco funcionó, y encontré que hay un bug reportado en el que están trabajando activamente. Esperemos las primeras actualizaciones para ver si se arregla.
Actualizando un server
Hace rato tengo un server en SliceHost para hacer pruebas y mantenerme un poco al día en el trabajo de sysadmin, ya que ahora estoy trabajando sólo como programador.
En este server estaba corriendo MySQL, Lighttpd, TurboGears, y un par de cositas más, todo sobre Gutsy.
La actualización fue de lo más simple. Hay que bajar el actualizador con el siguiente comando:
sudo apt-get install update-manager-core
y luego, ejecutar la herramienta de actualización de consola:
sudo do-release-upgrade
Otra vez a esperar la descarga de paquetes, pero en este caso la velocidad fue increíble. Se nota la diferencia de acceso a internet que tenemos en sudamerica y la que tienen en EE.UU. En mi casa los paquetes se bajaron a unos miserables 30k/s, en el server, a unos 1000k/s de promedio con unos picos bastante mas altos. En menos de cinco minutos había bajado todos los paquetes para el server.
El proceso de actualización tardo unos 15-20 minutos, las mismas preguntas sobre archivos de configuración de servicios, reiniciar... y todo funcionando exactamente igual que antes: bases de datos, servicios, todo 10 puntos. Ahora tengo un server con 5 años de soporte! Aunque supongo que no me voy a aguantar y en octubre lo paso a la nueva release :)
Conclusión
Sacando los temas conocidos para las MacBook con la placa wifi en 64bits, la actualización fue excelente. Sólo tenemos que conseguir uno o dos mirrors locales en Argentina, porque con cada release, el embotellamiento es más grande.
Cuando pruebe la instalación de 32bits (recomendada para los menos experimentados), les cuento como me fué.
miércoles, 23 de abril de 2008
OpenStreetMap: Mapas libres tipo wiki
La semana pasada encontré un sitio que se está convirtiendo en mi nuevo vicio: OpenStreetMap.
Es un sitio donde se puede definir y consultar mapas de calles de todo el mundo. Tienen un editor de mapas muy fácil de usar, y lo más interesante es que resulta divertido... ok, supongo que soy un geek, pero me resulta divertido.
Lo bueno es que cualquiera puede registrarse y empezar a editar mapas de cualqueir parte del mundo: funciona como los wikis, cada uno es libre de modificar lo que quiera, por lo que el mapa va creciendo según las ganas de los que participan del mapeo.
Yo comencé jugando con el editor (tiene una opción para probar sin grabar los cambios) y a la hora ya estaba mapeando (esta vez en serio) el barrio de Ituzaingo donde me crié.
Supuestamente estos mapas se pueden descargar al GPS, y son navegables. Todavía no me compré uno de estos aparatos, pero ya tengo una excusa para hacerlo. ;)
Los invito a que mapeen sus barrios, además de ser entretenido, es útil para los que tengan un GPS.
Es un sitio donde se puede definir y consultar mapas de calles de todo el mundo. Tienen un editor de mapas muy fácil de usar, y lo más interesante es que resulta divertido... ok, supongo que soy un geek, pero me resulta divertido.Lo bueno es que cualquiera puede registrarse y empezar a editar mapas de cualqueir parte del mundo: funciona como los wikis, cada uno es libre de modificar lo que quiera, por lo que el mapa va creciendo según las ganas de los que participan del mapeo.
Yo comencé jugando con el editor (tiene una opción para probar sin grabar los cambios) y a la hora ya estaba mapeando (esta vez en serio) el barrio de Ituzaingo donde me crié.
Supuestamente estos mapas se pueden descargar al GPS, y son navegables. Todavía no me compré uno de estos aparatos, pero ya tengo una excusa para hacerlo. ;)
Los invito a que mapeen sus barrios, además de ser entretenido, es útil para los que tengan un GPS.
miércoles, 12 de marzo de 2008
Red social de fotógrafos
Gracias a un post que leí en el Planet Ubuntu, conocí un sitio muy interesante para los que gustan de la fotografía, sean fotógrafos profesionales, amateurs, o simples chapuceros como el que escribe.
El sitio en cuestión se llama JPG Magazine, y aparte de permitir crear tu perfil y subir fotos, podes poner a otros fotógrafos como tus contactos y luego ver las fotos que van posteando vía RSS. También el sitio organiza concursos regulares sobre temas determinados a los que podes subir tus fotos.
En algún momento me voy a dar el gusto de hacer un curso de fotografía, hasta ese momento estoy más que conforme con algunos fotos que me parecen lindas. No hay mucho crédito para mí, solo es cuestión de mirar y esperar, el resto es suerte, al menos en mi caso.
Si a alguien le interesa, pueden ver algunas fotos que subí en:
http://www.jpgmag.com/people/gepatino
miércoles, 27 de febrero de 2008
Gmail estilo Art Attack
domingo, 6 de enero de 2008
Configurando vim para Python
Este post es más que nada un ayuda memoria personal, ya que mil veces configuré el vim para programar en Python, y mil veces termino perdiendo la configuración por descuido, reinstalaciones, etc.
Encontré una página donde resumen perfectamente la configuración que me gusta usar. Acá va mi .vimrc:
Espero que a alguno le sirva. Por lo pronto espero acordarme que ahora dejo acá también esta configuración.
Encontré una página donde resumen perfectamente la configuración que me gusta usar. Acá va mi .vimrc:
syntax on
set tabstop=4
set shiftwidth=4
set expandtab
set softtabstop=4
set background=dark
set autoindent
autocmd BufRead *.py set smartindent cinwords=if,elif,else,for,while,try,except,finally,def,class
Espero que a alguno le sirva. Por lo pronto espero acordarme que ahora dejo acá también esta configuración.
jueves, 3 de enero de 2008
Actualizaciones cuando las necesitas
Una de las ventajas que frecuentemente se mencionan sobre el software libre, es la rapidez con la que se generan actualizaciones.La semana pasada, se aprobó la ley (en Argentina) que indica que tenemos que adelantar una hora durante el verano para ahorrar energía.
Todo fué muy rápido, y los archivos de configuración de zonas horarios no contemplaban este cambio. Actualizar las definiciones de estos archivos no fué nada problemática para los impacientes como yo, que queremos que todo esté como corresponde (gracias al post de Fer de soluciones3f)
Lo que sí me sorprende es que hoy, primer día hábil del año, veo que en mi Ubuntu tengo actualizaciones disponibles, y cuando abro el Update Manager veo que la actualización es justamente del paquete tzdata, que contiene las definiciones de las zonas horarias.
Quedé sorprendido con la velocidad de respuesta de la comunidad de software libre en general y de Ubuntu/Debian en particular. Teniendo en cuenta que se trataba del último fin de semana del año, y supongo que se debe haber festejado en todo el mundo, la comunidad lanzó el parche el 1ero de Enero a las 13hs GMT, según el changelog:
* Replace tzdata2007j.tar.gz with new version tzdata2007k:
- Updates DST rules for Argentina. (LP: #178924)
-- Martin Pitt
No es por buscar pelea, pero...
¿Ya salió el parche para Windows? ;)
jueves, 13 de diciembre de 2007
¿Es conveniente el voto electrónico?
En base a las irregularidades denunciadas durante las últimas elecciones nacionales, se comenzó a hablar de impulsar el voto electrónico ya que teóricamente estos problemas no pasarían si se usara esta forma de votar.
Como contrapartida, también hay mucha gente que se opone argumentando que el voto electrónico no haría otra cosa que facilitar el fraude escondido detrás del misterio de la tecnología, ya que la mayoría de la gente no podría auditar que ocurre realmente dentro de una máquina de voto electrónico.
En este artículo voy a tratar de contar mi experiencia haciendo una máquina de voto electrónico que se utilizó en las elecciones de presupuesto participativo de la ciudad de Rosario en el año 2006, y cuales son mis opiniones personales sobre el (posible) fraude en las elecciones.
Desde 1995 hasta mediados del 2007, trabajé en una empresa (MSA) que a partir del año 1999 participó en varios procesos de recuentos de votos, en un par de ocasiones implementando algún método de voto electrónico. Aclaro que mis opiniones no son las de la empresa, y no tengo una postura definida sobre si el voto electrónico es mejor o peor que el sistema tradicional (boleta y sobre).
Recuento de votos
Como primer punto, me gustaría comentar que en ninguno de los procesos electorales que hicimos recibimos ningún tipo de presión de partidos politicos, entidades gubernamentales, etc, para influir de alguna forma en el resultado del proceso.
Durante los procesos de recuento, constantemente hay fiscales informáticos de los diferentes partidos políticos pidiendo todo tipo de información, y luego del proceso, generalmente se les da una copia de la base de datos para que crucen los datos con sus propios recuentos. Por ende, no sería una buena idea hacer fraude en este punto ya que sería descubierto tarde o temprano.
Emisión del voto
En el caso de las máquinas de voto electrónico, no es tan fácil auditar todas las máquinas ya que seguramente van a estar distribuidas geográficamente, y se necesita personal capacitado para controlar que no haya fraude. En esto estoy de acuerdo, pero...
Algo que generalmente se deja de lado cuando se ennumeran las características negativas del voto electrónico, es que en realidad el voto electrónico puede ser tan seguro y secreto como se quiera hacer, y por otro lado, el sistema de voto tradicional tampoco asegura que los votos sean registrados correctamente.
Haciendo una analogía un poco apresurada, es como decir que viajar en avión es más peligroso que viajar en auto, porque si se cae no hay muchas chances de salvarse. Es verdad. Pero hay más accidentes de autos que de aviones. De echo, en Argentina cualquiera de las dos cosas son peligrosas... y ese me parece que es la base de ambos problemas: que estamos en Argentina. :(
La máquina de voto electrónico
Cuando hicimos la máquina de voto electrónico, tratamos de hacerla lo más segura, secreta y accesible que pudimos:
Como se puede ver en una foto que anda dando vueltas por la red, me comí todo el día en uno de los centros de votos asistiendo a la gente en la operación de las máquinas. Algunas de las cosas que pude observar:
En el sistema tradicional, se acostumbra a utilizar otros métodos como el voto cadena o las boletas dobladas de una forma determinada, o sea que este tipo de corrupción no se puede evitar.
Conclusión
Lamentablemente, cualquiera de los dos métodos permite más o menos los mismos métodos de fraude, ya que no hace falta que se hagan en el momento del voto, sino que el fraude ya viene hecho de antes, o se hace después, modificando las planillas de recuento antes que sean procesadas. Esos son los momentos donde es más dificil hacer una auditoria.
Por otro lado, si bien una persona sin conocimientos técnicos no puede auditar una máquina de voto electrónico, tengo entendido que tampoco puede estar presente cuando se abre la urna, se cuentan los votos, y se escribe la planilla de resultados en el sistema tradicional.
En este momento, me parece que la única gran diferencia entre un método y otro es el costo y la velocidad de proceso. Ambos son superiores en un sistema electrónico que en el tradicional: más caro pero más rápido. Supongo que para saber cual es mejor, habría que ver de cuanto dinero se dispone, o cual es el apuro para obtener los resultados.
Más allá de estar o no en contra, pienso que en el futuro el voto electrónico va a ser la norma, ya que toda la sociedad apunta al camino de la tecnología. En este punto me parece que la solución más acertada sería que las organizaciones promotoras de software libre se encarguen de proponer sistemas/máquinas de voto electrónico de código libre. Es sabido que el software libre tiene entre sus ventajas los miles de ojos que lo auditan, imaginense cuantos ojos van a querer auditar el código de una máquina de voto electrónico!!!
Por supuesto esto no asegura que el último código que se ejecute sea el mismo que se escribió, a menos que se usen lenguaje como Python, que permiten leer el mismo código que se está ejecutando.
La comunidad del software libre debería interesarse seriamente en este tema, antes que se haga moneda común que las máquinas de voto electrónico sean algo cerrado y propietario como las que existen actualmente. Ahí si que estaríamos en problemas. Si el único que puede ver que pasa dentro de la máquina es el que la hizo, estoy totalmente de acuerdo... el voto electrónico no sirve.
Gabriel E. Patiño
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 License.
Como contrapartida, también hay mucha gente que se opone argumentando que el voto electrónico no haría otra cosa que facilitar el fraude escondido detrás del misterio de la tecnología, ya que la mayoría de la gente no podría auditar que ocurre realmente dentro de una máquina de voto electrónico.
En este artículo voy a tratar de contar mi experiencia haciendo una máquina de voto electrónico que se utilizó en las elecciones de presupuesto participativo de la ciudad de Rosario en el año 2006, y cuales son mis opiniones personales sobre el (posible) fraude en las elecciones.
Desde 1995 hasta mediados del 2007, trabajé en una empresa (MSA) que a partir del año 1999 participó en varios procesos de recuentos de votos, en un par de ocasiones implementando algún método de voto electrónico. Aclaro que mis opiniones no son las de la empresa, y no tengo una postura definida sobre si el voto electrónico es mejor o peor que el sistema tradicional (boleta y sobre).
Recuento de votos
Como primer punto, me gustaría comentar que en ninguno de los procesos electorales que hicimos recibimos ningún tipo de presión de partidos politicos, entidades gubernamentales, etc, para influir de alguna forma en el resultado del proceso.
Durante los procesos de recuento, constantemente hay fiscales informáticos de los diferentes partidos políticos pidiendo todo tipo de información, y luego del proceso, generalmente se les da una copia de la base de datos para que crucen los datos con sus propios recuentos. Por ende, no sería una buena idea hacer fraude en este punto ya que sería descubierto tarde o temprano.
Emisión del voto
En el caso de las máquinas de voto electrónico, no es tan fácil auditar todas las máquinas ya que seguramente van a estar distribuidas geográficamente, y se necesita personal capacitado para controlar que no haya fraude. En esto estoy de acuerdo, pero...
Algo que generalmente se deja de lado cuando se ennumeran las características negativas del voto electrónico, es que en realidad el voto electrónico puede ser tan seguro y secreto como se quiera hacer, y por otro lado, el sistema de voto tradicional tampoco asegura que los votos sean registrados correctamente.
Haciendo una analogía un poco apresurada, es como decir que viajar en avión es más peligroso que viajar en auto, porque si se cae no hay muchas chances de salvarse. Es verdad. Pero hay más accidentes de autos que de aviones. De echo, en Argentina cualquiera de las dos cosas son peligrosas... y ese me parece que es la base de ambos problemas: que estamos en Argentina. :(
La máquina de voto electrónico
Cuando hicimos la máquina de voto electrónico, tratamos de hacerla lo más segura, secreta y accesible que pudimos:
- La máquina era un LiveCD que podía funcionar en cualquier PC. De esta forma nadie tenía acceso al software antes de iniciar las máquinas, a excepcion de los auditores del juzgado electoral. Es más fácil mantener seguros unos cuantos CDs no regrabables, firmados fisicamente, que la misma cantidad de máquinas.
- Al votar se emitía una boleta de papel con la selección impresa. La boleta era ingresada en una urna tradicional, y en el peor de los casos se podía hacer el recuento manualmente.
- Los votos no se registraban en la PC. Tampoco en medios remobibles. En la misma boleta de papel se almacenaban los datos del voto en un medio elecrónico no reescribible. No se si la empresa terminó patentando esto, pero a fines prácticos supongamos que imprimimos un código de barras con la información de los votos.
- El elector podía verificar el voto emitido. Aparte de leer el texto impreso en la boleta, ingresando la misma en un lector el sistema le muestra las opciones almacenadas, que deberían ser las mismas que están impresas.
- Se podían leer los fuentes del software en ejecución. Dado que el sistema estaba totalmente escrito en Python (que no necesita ser compilado) se daba la posibilidad de auditar el sistema de la máquina leyendo el CD desde cualquier PC.
- Accesibilidad. Gracias a la facilidad de integración de las herramientas que disponemos en el software libre, los usuarios con problemas de visión podían utilizar un modulo especial que leía las opciones sin mostrar nada en la pantalla. Por primera vez, una persona ciega tuvo la posibilidad de votar sin alguien que lo asista, simplemente usando auriculares y un teclado numérico con etiquetas braille.
Como se puede ver en una foto que anda dando vueltas por la red, me comí todo el día en uno de los centros de votos asistiendo a la gente en la operación de las máquinas. Algunas de las cosas que pude observar:- Curiosamente, la gente mayor era la más contenta estaba con el sistema. Los abuelos estaban fascinados, y nos pedían por favor que utilicemos este mecanismo para las elecciones presidenciales (como si fuera nuestra desición :) )
- Al igual que en el sistema tradicional, llegaban micros con gente para votar a quienes les habían dado un papelito con los números que tenían que votar.
En el sistema tradicional, se acostumbra a utilizar otros métodos como el voto cadena o las boletas dobladas de una forma determinada, o sea que este tipo de corrupción no se puede evitar.
Conclusión
Lamentablemente, cualquiera de los dos métodos permite más o menos los mismos métodos de fraude, ya que no hace falta que se hagan en el momento del voto, sino que el fraude ya viene hecho de antes, o se hace después, modificando las planillas de recuento antes que sean procesadas. Esos son los momentos donde es más dificil hacer una auditoria.
Por otro lado, si bien una persona sin conocimientos técnicos no puede auditar una máquina de voto electrónico, tengo entendido que tampoco puede estar presente cuando se abre la urna, se cuentan los votos, y se escribe la planilla de resultados en el sistema tradicional.
En este momento, me parece que la única gran diferencia entre un método y otro es el costo y la velocidad de proceso. Ambos son superiores en un sistema electrónico que en el tradicional: más caro pero más rápido. Supongo que para saber cual es mejor, habría que ver de cuanto dinero se dispone, o cual es el apuro para obtener los resultados.
Más allá de estar o no en contra, pienso que en el futuro el voto electrónico va a ser la norma, ya que toda la sociedad apunta al camino de la tecnología. En este punto me parece que la solución más acertada sería que las organizaciones promotoras de software libre se encarguen de proponer sistemas/máquinas de voto electrónico de código libre. Es sabido que el software libre tiene entre sus ventajas los miles de ojos que lo auditan, imaginense cuantos ojos van a querer auditar el código de una máquina de voto electrónico!!!
Por supuesto esto no asegura que el último código que se ejecute sea el mismo que se escribió, a menos que se usen lenguaje como Python, que permiten leer el mismo código que se está ejecutando.
La comunidad del software libre debería interesarse seriamente en este tema, antes que se haga moneda común que las máquinas de voto electrónico sean algo cerrado y propietario como las que existen actualmente. Ahí si que estaríamos en problemas. Si el único que puede ver que pasa dentro de la máquina es el que la hizo, estoy totalmente de acuerdo... el voto electrónico no sirve.
Gabriel E. Patiño
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 License.
Suscribirse a:
Entradas (Atom)