Los primeros sistemas de mensajería instantánea que existieron datan de finales de los años '60, principios de los '70.
Los viejos Unixes tenían una herramienta (que posteriormente sería implementada por un estudiante de la universidad de Washington, reconocida y popularizada con el nombre "talk" y que de hecho, todavía existe y funciona igual que en aquellas épocas) que permitía establecer conversaciones en tiempo real entre usuarios del mismo sistema, o de diferentes sistemas en forma remota.
Hoy día, medio siglo después, la mensajería instantánea sigue estando vigente, aunque los sistemas y el software que se utilizan para transmitir los mensajes han cambiado bastante. Del simple hecho de poder enviar texto plano de aquellos días, hasta los "guiños" y las animaciones en 3D transmisibles a través del MSN Messenger, han pasado muchas cosas...
Lo más sorprendente es el tamaño de los programas de mensajería.
Hoy a la tarde tuve que actualizar un MSN Messenger y me dí cuenta de una forma algo bizarra que ese programa, que originalmente solo transmitía texto, ahora pesa 66.5 megabytes, y que opcionalmente viene acompañado de otros programas accesorios (que ocuparán otros tantos megabytes extra) de dudosa utilidad, y que vienen a formar parte de un paquete más grande denominado "Windows Live Essentials", que es la respuesta de Microsoft a la falta de software de Windows, que hace que algunos usuarios se sigan volcando hacia las Apple, que traen de base más utilidades y software que las que trae de base el conocido sistema operativo...
Entiendo que el programa hace muchas más cosas ahora, pero no olvidemos que hablamos de un programa de mensajería instantánea... algo que debería ser simple y que debería ocupar una fracción de lo que ocupa este monstruo multifacético.
A modo de comparación, diremos que si usamos un cliente de Jabber para Windows, descargable también en forma libre y gratuíta desde internet, como lo es Pandion (1.7 megabytes), podremos hacer teóricamente lo mismo, o por lo menos lo más importante que MSN Messenger hace, que es transmitir texto, por una fracción del espacio que este último ocupa, y con mayor seguridad.
En esencia, los programas de mensajería instantánea son eso... programas que envían texto desde una computadora a otra en tiempo real.
¿Alquien sabe porqué se complicó tanto y creció exponencialmente algo que originalmente era tán simple?...
jueves, 18 de febrero de 2010
La "evolución" de la mensajería instantánea...
martes, 9 de febrero de 2010
Ojo con lo que compilás, nabo.
A veces uno hace tonterías y se le complican las cosas más simples... Esta es la historia de cómo se complicó algo que debió haber funcionado bien desde el principio, simplemente por equivocarse de versión de un software accesorio (y de cómo encontré el error finalmente).
En uno de nuestros productos (el servidor de correo electrónico), utilizo un sistema de control de contenidos basado en una versión modificada de simscan.
El viernes pasado estuve tratando de compilar la última versión (1.4.0), con algunas modificaciones para resolver detalles de ejecución cuando se hace referencia al antivirus ClamAV (básicamente, el problema surge del umask activo en el momento en que simscan crea el directorio de trabajo donde va a almacenar los adjuntos para procesarlos), así que apliqué los cambios e intenté compilar. El producto final pareció quedar perféctamente bien, así que se instaló y quedó "funcionando".
En las pruebas consecuentes, observé que el servicio SMTP fallaba miserablemente. Cuando intentaba enviar cualquier tipo de mensaje a través del nuevo servidor, aparecía un error en el programa de correo, aunque el error no aparecía como debía ser, sino que solo aparecía un error de transmisión (fucking cliente de correo apestoso...).
Puse una captura de tráfico en el servidor, y cuando intenté enviar un mensaje pude ver el mensaje de error que el servidor enviaba al cliente (y que el cliente no me mostraba...):
Traté de buscar el error en el código fuente del QMail (usando grep), para poder determinar qué era que lo causaba, y así llegué al archivo qmail.c, donde encontré que la línea se correspondía con el código de error número 71:
[...]
case 71: return "Zmail server temporarily rejected message (#4.3.0)";
En linux, los códigos de error están definidos en el archivo /usr/include/sysexits.h de los headers del kernel, así que como no me acordaba de a qué correspondía exactamente, me puse a buscar el código en los fuentes, llegando a la línea que contiene la explicación del error:
Aparentemente, el QMail no podía iniciar una instancia de "algo" que invocaba en el momento que el mensaje se iba a pasar a la cola para posterior procesamiento, así que evidentemente el problema tenía que estar en el programa de manejo de la cola. Solo hay dos opciones para este caso, o se usa el programa original de QMail para el manejo de la cola qmail-queue, o se invoca el programa que se encarga de los chequeos de contenidos, y ese es el simscan.
Como de todas maneras no sabía porqué fallaba, activé un recordio sobre el servicio (básicamente captura la salida y los mensajes de error de todos los programas implicados en la transacción y los almacena en el log para posterior análisis), y así podría ver qué pasaba exactamente en los registros del mismo. Y entonces el error se hizo visible:
@400000004b6c75a6291a7bdc simscan: exit error code: 71
@400000004b6c75a6291ca2a4 10303 > 451 mail server temporarily rejected message (#4.3.0)
Aparentemente, el que fallaba era el ripmime... cosa rara, ya que nunca me había dado problema. Simscan utiliza ripmime para extraer los adjuntos de los mensajes, para luego pasarle el antivirus y el antispam a cada uno por separado. Decidí revisar el ripmime y todo parecía correcto. El ripmime podía ser invocado sin problemas desde la línea de comandos. Hice pruebas para verificar que hacía su trabajo y todo funcionó correctamente, desorientándome más a cada momento. Revisé el código que instanciaba el ripmime en el fuente del simscan, y finalmente dí con esta línea:
switch(pid = vfork()) {
case -1:
return(-1);
case 0:
close(1);
close(2);
execl(RIPMIME, "ripmime", "--disable-qmail-bounce",
"-i", message_name, "-d", NULL );
_exit(-1);
}
Me llamó la atención el argumento pasado al ripmime durante el fork, --disable-qmail-bounce, ya que no recordaba haberlo visto en la ayuda del mismo, así que revisé bien el fuente del ripmime y me dí cuenta de que dicho argumento no existía en la versión que estaba usando(!)...
Comenté el argumento en la invocación del ripmime, recompilé el simscan, lo instalé y cuando intenté enviar el mensaje de correo, ¡funcionó todo a la perfección!
Ahí el problema se hizo obvio finalmente.
Revisé bien y me dí cuenta de que la versión de ripmime que estaba utilizando era la 1.3.0.9, así que busqué nuevamente con más tranquilidad y encontré la última versión disponible, la 1.4.0.9. Esta versión SI tiene el argumento anterior, y la invocación del ripmime con dicho parámetro funciona. Le había errado de versión al descargarlo, por un dígito.
Simplemente, el error fué bajar una versión de ripmime vieja, que no tenía el argumento que simscan le pasaba cuando lo invocaba.
Final feliz, pero luego de un buen rato de "entretenido" debugging...
¿Moraleja?: Revisá bien lo que bajás para compilar. Seguro ya te lo habían dicho, pero no viene mal que lo recuerdes de vez en cuando...
Happy hacking!
miércoles, 3 de febrero de 2010
Armatix: Seguridad biométrica para armas(??)
Armatix es el nombre de una empresa que produce elementos mecano-electrónicos para seguridad de armas. Básicamente, esta gente diseñó un sistema que consta de un receptor de radio instalado en un arma y un emisor de ondas de radio incorporado en un reloj.
La idea detrás de esto es que para que el arma dispare, el reloj debe estar a una distancia de aproximadamente 20 centímetros de la misma, sino, el arma permanece bloqueada.
El método parece interesante, pero cabe preguntarse muchas cosas al respecto del mismo...
Por ejemplo, ¿qué pasa si en medio de la noche entra un asaltante a la casa del dueño de una de estas armas, y por esas casualidades de la vida el reloj se cayó de la mesa de luz...?
¿Tendrás que usar el reloj las 24 horas para que el sistema sea efectivo? ¿Si se te rompe el reloj qué hacés?
Siendo de plástico (aparentemente bastante ordinario) ¿qué pasa si un asaltante viene y te arranca el reloj de la mano o le dá un buen golpe con algún objeto contundente para romperlo?
En medio de la noche, al intentar apuntarle a un atacante ¿no te molestará en la vista la luz de un led verde (o rojo) enorme en la parte posterior del arma, haciendote además vulnerable por dejarte plenamente iluminado en un momento donde probablemente quieras permanecer oculto en la oscuridad, y probablemente dándole al atacante una ventaja al saber que si la iluminación es roja, evidentemente no tenés el reloj y el arma no va a disparar?
Si el reloj se te rompe, ¿lo llevarías a un relojero o a un armero?
La señal que emite el reloj, ¿estará encriptada o simplemente será una señal ordinaria, fácilmente reproducible mediante equipo de transmisión de ondas de radio standard?
¿Qué pasa si alguien diseña un aparato capaz de emitir una señal en la misma frecuencia del radio del reloj, ya sea para desactivar tu arma, o para activarla en manos de alguien que no tiene el reloj?
La verdad, no creo que este sistema tenga demasiado andamiento... salvo para los coleccionistas que quieren tener "algo raro y super moderno" en su colección. Para los demás, creo que esto no es realmente práctico, al igual que otros métodos que promociona Armatrix ("Señor asaltante, espere que voy a tratar de recordar el PIN del dispositivo de seguridad que bloquea mi arma...").
Gaston Glock patentó un sistema similar ("System for activating a weapon with an identification mechanism" USPA 20030070343) en el año 2003, pero hasta ahora no se ha visto ninguna Glock con ese sistema... ¿Será que se hizo las mismas preguntas y se dió cuenta de que el sistema no era realmente práctico?... La verdad, no sé, pero a mi déjenme con una pistola standard nomás, no sea que me pase como al pobre Wikus Van De Merwe (District 9) si es que la ciencia avanza lo suficiente como para asociar las armas al ADN de los portadores...
Salutti!
martes, 2 de febrero de 2010
GExperts: Si Google lo sabe, ellos también
Talvéz registre el término, antes de que alguien me lo robe...
Un "GExpert" es un usuario cuyo conocimiento viene en forma casi exclusíva de lo que puede obtener en una búsqueda en Google.
Hasta hace relativamente poco tiempo, tuve un empleado así. El tipo era muy hábil en el uso del buscador, así que solía encontrar rápidamente una respuesta a prácticamente todo. Una vez, estaba chateando con él sobre la posibilidad de cambiar un software de VPN que yo usaba (que trabajaba con IPSEC/ISAKMP) por otro no standard, le pregunté si ese otro software no daba problemas al asignar el MTU de los paquetes al encapsularlos (por el tema de la fragmentación), a lo cual, luego de una pausa prudencial, me contestó que no creía que hubiera problema. Lo que él no sabía es que yo estaba corriendo una captura de tráfico en la red donde estaba trabajando y que ví que esa pausa prudencial fué aprovechada para (o debería decir, "causada por") hacer una consulta en Google sobre el término "MTU", algo que me dió la pauta de que evidentemente él no solo abusaba hábilmente de Google para cualquier caso que escapara a su sabiduría, sino que sus "sólidos conocimientos de TCP/IP y redes" no eran tán sólidos como se podía leer en su curriculum...
En fin, lo importante de esto es que cada vez más se dá que los usuarios (técnicos y no técnicos) dependan de Google para prácticamente cualquier cosa que hagan en Internet. Con el advenimiento de servicios como Google Docs, Google Chrome, Google Maps, Google Earth y las adquisiciones de Blogger, Youtube y Picasa, parece que la cosa solo empeoró. De alguna manera, la "gran G" acostumbra a los consultantes a obtener respuestas y soluciones a todo sin tener que pensar ni sudar demasiado, y eso a la larga seguramente resulte negativo para quienes abusen de su uso. No hay que olvidar que todo vive en una "nube"... Una nube que puede desaparecer de repente, y con ella, todo lo que le hayamos confiado.
A Internet se le han atribuído varios males de nuestros tiempos, (supongo que la proliferación de material pornográfico es uno de ellos, aunque no entiendo muy bien cual es el problema en realidad...), pero uno que creo que no se le atribuyó todavía es el de hacer perezosos a los usuarios. Así como la "caja tonta" de los '60 nos trajo el autismo forzado de los televidentes, la internet trajo consigo la pereza de los que no quieren aprender nada nuevo, ya que simplemente todo está al otro lado de una simple búsqueda en Google...
Multivac existe y ya casi piensa por nosotros. Talvéz no encuentre la respuesta a la última pregunta... pero casi siempre tiene algo que ofrecer a los usuarios que la visitan, al igual que los antíguos oráculos griegos.
Que no se les haga costumbre obtener respuestas a todo en Google. No siempre se encuentran respuestas correctas (de hecho, la relación entre las respuestas correctas y las incorrectas parece ser de 1:3), y la naturaleza siempre cambiante de Internet hace cada vez más dificil encontrar cosas útiles, verídicas y confiables.
Practiquen la memoria y no dependan tanto de Google. Imaginen que están usando BING, y con eso seguramente se les vaya las ganas de buscar cosas en Internet...
:wq
