Mas rapido, pero mas lento

En estas vacaciones de diciembre, fui a visitar a mi familia en Medellín. Mi tía Patricia tenía un viejo computador portátil Toshiba Satellite Pro 440 CDT que ya no usaba y decidió regalárselo a mi Papá. Es un portátil que ya tiene sus 11 años, pero, dado que mi papá escasamente usa el PC para leer y escribir correos electrónicos, navegar por Internet y de vez en cuando escribir una carta, le sirve perfectamente. Por supuesto, como buen entusiasta de software libre, pensé que si se le instalara Linux se podría explotar más su potencial. Sin embargo, rápidamente descubrí algo que me dejó atónito y me motivó a escribir esta entrada en mi blog.

El Toshiba Satellite Pro 440 CDT tiene las siguientes características:

Procesador
Intel Pentium MMX de 166 Mhz
Memoria
32 MB
Disco Duro
2 GB.
Software
Microsoft Windows 98 y Microsoft Office 97.

Después de ver las características tan bajas del equipo, hay algo que me da muchísima tristeza. Office arranca mucho, muchísimo más rápido que el OpenOffice de mi PC. Casi cuatro veces más rápido. Aún cuando mi PC tiene 32 veces más memoria que el portátil y un procesador con 20 veces más Mhz. No estoy muy seguro de esto pero, en mi opinión, Office 97 y OpenOffice 2.0 tienen prácticamente la misma funcionalidad.

Después de jugar un rato con el portátil me di cuenta que la velocidad general de sistema, arranque del sistema operativo, apertura de archivos, etc es bastante buena, muy comparable a la de mi PC. Es cierto que hay varias cosas que no pueden ser iguales, por ejemplo, creo que el portátil explotaría antes de poder usar algo como F-Spot o editar imágenes de 8MP con GIMP. La interfaz de mi PC también es más bonita, con más resolución y efectos interesantes. En fin, creo que hay un millón de cosas que no podría ser iguales, pero en el caso de programas como OpenOffice y Office, que son prácticamente iguales, el hecho de que haya un rendimiento similar, o incluso superioridad en el computador de 11 años de edad, me parece algo desgarrador.

¿Qué es lo que pasa? Culpo a los programadores. Somos especialistas en derrochar toda cantidad de recursos que tengamos disponibles. Anteriormente los computadores venían con 32 MB de memoria y los programas tenían que funcionar con eso, y funcionaban. Eso hacía que los programadores se interesaran por mejorar el uso de los recursos. Ahora hay abundancia y se puede derrochar.

Aunque hoy en día tenemos hardware decenas de veces más rápido que hace diez años, parece ser que la calidad y rendimiento de los programas no ha crecido en la misma proporción (si es que ha crecido en algo).

Hay casos mucho más extremos aún. En el mundo del desarrollo de juegos siempre se ha mantenido una tradición de explotar al máximo las capacidades del PC. Es quizás por esto que los juegos son los únicos que parecen mostrar un verdadero avance proporcional a los adelantos en hardware. Recuerdo cuando alguna vez escribí un sencillo juego para PlayStation. El sistema contaba con la miserable cantidad de 1MB de memoria de vídeo y 2MB de memoria de sistema. A mi me parecía demasiado difícil hacer algo con tan pocos recursos, sin embargo los expertos hacían juegos espectaculares con eso. Sabían usar muy bien los recursos.

El tema no necesariamente da para comparar programas viejos con nuevos. Hoy en día también hay buenos programadores que saben utilizar adecuadamente sus recursos. Hay un perfecto ejemplo de dos programas contemporáneos que tienen funcionalidad muy similar pero difieren enormemente en el uso de recursos: uTorrentAzureus.

La descarga de uTorrent es de 170KB, la de Azureus es de 9.4 MB, eso es 57 veces más, todo esto sin contar detalles como que Azureus requiere un runtime de Java (~50MB) y que viene en un instalador comprimido (bz2) mientras que uTorrent viene en un ejecutable standalone listo para ser ejecutado. El consumo promedio de Memoria de uTorrent es de 4.6MB, mientras que el de Azureus es de 40MB. El consumo de CPU es difícil de medir, pero los desarrolladores de uTorrent dice puede correr hasta en un CPU 486, eso ni siquiera cumple los requisitos mínimos del runtime de Java, en el caso de Azureus.

Ambos programas tienen casi las mismas funcionalidades, Azureus era el más popular, sin embargo, gracias a la superioridad en rendimiento de uTorrent, este le ha ganado el puesto y su popularidad crece en forma exponencial.

Hay otra razón por la cual hay tanta diferencia en estos programas: El lenguaje de programación. Aceptémolo, por más que varios estudios aseguren que la velocidad de los programas escritos en lenguajes como Java, C#, Python, Lisp, etc. sea igual o, algunos se atreven a decir, superior que C o C++, la verdad es que en la práctica todos los programas realmente eficientes están escritos en C o C++. uTorrent está escrito en C++, Microsoft Office está escrito en C++. Azureus está escrito en Java, OpenOffice está en gran parte escrito en Java. Pero ojo, esto no quiere decir que todos los programas de C++ sean necesariamente eficientes.

Es cierto que otros lenguajes hace al programador más productivo y en general más feliz, pero creo que es difícil negar que con C y C++ se puedan obtener programas más rápidos. ¿O tal vez sea mejor decir que con un poco más de esfuerzo a la hora de programar, esfuerzo al que casi siempre nos obliga C++, se obtengan mejores programas?

C++ siempre me encantó y lo usé mucho para muchos proyectos. Hace un tiempo me enamoré de Python y ha pasado bastante tiempo desde la última vez que usé C++ ¿Será que es tiempo de abrir el baúl y volver a sacar esos conocimientos de C++? ¿O será mejor seguir con los lenguajes de alto nivel y más bien tratar de hacer esfuerzos para lograr un balance entre felicidad del programador y eficiencia del programa?

MonoHotDraw

Por estos dias estoy programando MonoHotDraw, que es el séptimo intento por hacer una librería de diagramación para MonoUML. Se llama MonoHotDraw porque está basado en el diseño de HotDraw y JHotDraw. MonoHotDraw está escrito en C# con Mono y usa varias herramientas de GnomeGtkCairoPango, etc.

Aquí hay un video de una aplicación que estoy escribiendo para una tarea de universidad que usa MonoHotDraw. Es un sencillo editor de mapas mentales. Se supone que debo entregarlo el 18 de diciembre. Tengo que apurarme y convertirlo en algo decente.

Por cierto, YouTube no me reconoció el video correctamente. Termina instantaneamente. Google Video si lo reconoció, aunque la resolución está fea. ¿Alguien sabe como convertir videos ogg theora en avi xvid o algo compatible con YouTube?

Actualización.

Olvidé decir que MonoHotDraw se encuentra disponible en el repositorio Subversion de MonoUML. La licencia de MonoHotDraw es LGPL, aunque tal vez la cambie a MIT X11. ¿Qué opinan ustedes?

El tercer puesto

Este artículo me encantó. Algunas citas:

And while it’s true that in many industries there is a correlation between market share and profitability, one doesn’t necessarily lead to the other.

A recent survey of the evidence on market share by J. Scott Armstrong and Kesten C. Green found that companies that adopt what they call “competitor-oriented objectives” actually end up hurting their own profitability.

…of the six companies that defined their goal exclusively as market share, four eventually went out of business.

Nintendo siempre me ha gustado mucho. El Wii es mi consola favorita de esta nueva generación. Me parece muy sano este enfoque de negocios, es bueno para ellos y bueno para los demás. Lástima que todavía existan empresarios poderoso con un pensamiento como el de Larry Ellison, quien es famoso por citar a Genghis Khan a la hora de expresar su forma de actuar: “Winning is not enough. All others must lose.”

Error en Mono

Hoy, mientras trabajaba en MonoCanvas, estaba husmeando en el código de Mono, cuando por casualidad me di cuenta de un error que, al parecer, nadie había notado. El operador de inequidad (!=) entre dos objetos del tipo System.Drawing.RectangleF estaba implementado de esta forma:

public static bool operator != (RectangleF r1, RectangleF r2)
{
	return (r1.X != r2.X) && (r1.Y != r2.Y) &&
        (r1.Width != r2.Width) && (r1.Height != r2.Height);
}

Obviamente, la implementación correcta debería ser:

public static bool operator != (RectangleF r1, RectangleF r2)
{
	return (r1.X != r2.X) || (r1.Y != r2.Y) ||
        (r1.Width != r2.Width) || (r1.Height != r2.Height);
}

Aproveché que estaba trabajando con la versión SVN e inmediatamente hice un parche y lo mandé.

Es increible como, pese a la gran cantidad de pruebas unitarias que tiene Mono, se haya colado un bug de este tipo. Me he dado cuenta de que en el código trivial, como el de este ejemplo, es más fácil dejar pasar bugs. Esto caso me recuerda mucho al caso del error en la búsqueda binaria en Programming Pearls.

Curiosamente el error lo encontré mientras miraba el código, pero ¿qué hubiera pasado si estuviera escribiendo una aplicación que usara ese operador? Creo que hubiera pasado un largo rato partiendome la cabeza antes de siquiera sospechar que es el operador el que tiene un bug. La moraleja de la historia es no subestimar las tareas triviales a la hora de programar.

DebConf8 en Colombia

No soy adepto de ninguna distribución de Linux. Generalmente me gusta saltar de una en una buscando las cosas buenas y las cosas malas de cada una. Por supuesto que también he probado Debian. Muchas veces me gusta quejarme de los innumerables defectos de Debian, aunque más que todo es sólo para molestar a Santago,Alerios y otros debianitas.

En las pasadas Jornadas de Software Libre, durante el viaje de regreso de la finca en dónde realizamos las mesas de trabajo, ocurrió algo bastante interesante con respecto al tema: Luciano estaba comentando con otros debianitas lo interesante que fue la DebConf 6 en Oaxtepec. Por alguna razón, alguien dijo que deberíamos hacer una DebConf en Colombia. Claro que fue en el mismo tono que se dice que deberíamos hacer el mundial en Colombia. Entonces yo dije “¡¡¡Si!!! hagamos una DebConf en Colombia”. Inmediatamente, Luciano, quién ya había escuchado varias de mis quejas de Debian, me dijo algo como “¿y es que te vas a pasar a Debian? ¿o qué?”. Yo lo pensé un momento y le dije: “Si, si hacen una DebConf en Colombia me paso a Debian”. Él se encargó de repetirlo en voz alta para que todos los del bus lo pudieran escuchar. Después de eso, la idea quedo rondando en el ambiente.

Por estos días, parece que cada vez suena más posible la idea de hacer la DebConf en Colombia. De hecho, ya hay una página donde se está discutiendo el asunto y varios voluntarios, incluyéndome. Por mi parte, con ganas de motivar a la comunidad de Debian, he aumentado mi oferta, ya no sólo pienso pasarme a Debian, sino que también prometí tatuarme una espiral en caso de que se realice el evento. Lo dejo consignado aquí para que quede prueba de mi promesa. Burbuja también decidió sumarse a la iniciativa y prometió tatuarse la espiral en un cachete (uno de los de abajo :P). El tema del tatuaje ya se está comentando en #debian-co y en la lista de debian-colombia.

La verdad es que, independientemente de si me agrada Debian o no, me gustaría muchísimo que un evento de este estilo se realice en Colombia. Creo que es algo bastante posible y pienso apoyarlo completamente.

¡Nos vemos en la DebConf!

De vuelta a la vida

Después de mucho tiempo, vuelvo a la vida. Hace más de tres semanas mi PC se quemó. Un transformador de energía cerca de mi casa explotó y causo una gran descarga de energía que fue lo que causó el daño. El análisis post-mortem me dice que las cosas pasaron así:

Una fuerte corriente eléctrica entró por las líneas de la energía, sin embargo, mi regulador de voltaje hizo su trabajo correctamente, impidiendo que esa corriente dañara la fuente de mi pc, ni el monitor, ni los parlantes. El fusible del regulador quedó cristalizado, vuelto nada. Sin embargo, otra corriente de energía, igual de fuerte, entró por otro lugar, la línea de la televisión por cable. En el techo, los cables de la televisión estaban completamente chamuscados. La corriente entró al cablemodem y, por supuesto, chamuscó el cablemodem, luego, salió por el cable de red hasta mi pc. La tarjeta de red explotó y el quemonazo hizo que se dañaran: La tarjeta madre, el procesador, la memoria, la tarjeta de vídeo y la tarjeta de red. La fuente, el disco duro, el DVD y el quemador se salvaron.

Al final terminé como 20 días sin PC y fueron realmente horribles. Por esta razón es que he vivido bastante incomunicado ultimamente. Pero bueno, al final logré conseguir partes nuevas y estoy de nuevo en línea. También parece que la empresa de energía va a responder por los daños, lo cual es una excelente noticia.

El Efecto Evento de Software Libre

El otro día, discutiendo en el canal #gluc de freenode, decíamos que la comunidad del software libre tiene un comportamiento bastante peculiar y que los eventos de software libre generan un impacto más allá de lo que normalmente se podría pensar. El canal del gluc originalmente fué un canal sólo para el GLUC, pero últimamente se ha convertido en uno de los canales más populares de la comunidad del software libre en Colombia. Con las JSL, el canal se la pasa bastante activo. Últimamente es posible encotrar a casi toda la comunidad del software libre en el canal. Si usted es entusiasta del software libre, le recomiendo que entre al canal.

Claro que también hay otra cosa que hay que tener en cuenta, y es el “efecto evento de software libre” en el canal. Antes de las JSL yo decía que existen tres fases del canal: La fase “pre-evento”, bastante activa, pero no a su tope, se genera unas cuantas semanas antes del evento. La fase “post-evento”, es la más activa de todas y es en la que casi todo el mundo entra al canal, se habla mucho de las fotos, de los videos, de los proyectos, de las borracheras, etc. Por último queda la fase “no se ve ningún evento a la vista” en donde el canal decae y quedan los mismos 5 pelagatos de siempre. ¿y qué pasa durante los 4 días que dura el evento? bien, esta fase es como el ojo del huracán, todo muy tranquilo, calmado, quieto, pero muy pronto todo se va a mover mucho, muchísimo.

Aqui hay un screenshot del canal, si tiene curiosidad entre, ya sabe, #gluc en freenode

Screenshot de Gaim

Jornadas de Software Libre

Qué montón de tiempo sin escribir. Después de llegar de Medellín, en dónde la pasé de maravilla, llegué a comenzar clases y terminar de ayudar en la organización de las Jornadas de Software Libre aquí en Popayán. Las JSL terminaron ayer y debo decir que todo salió muy bien. El evento estuvo bacanísimo. Vino gente de muchas partes del País: Bogotá, Medellín, Cali, Pereira, Pasto, Bucaramanga, entre otras.

Como le mencioné a varias de las personas que asistieron al evento, creo que las JSL están en un proceso de evolución, de crecimiento. Su objetivo es convertirse en el evento de software libre en Colombia. Creo que las JSL 2006 de Popayán cumplieron en su objetivo de marcar un punto en esa evolución. Estoy seguro que la próxima versión en Medellín va a ser mejor, continuando el proceso de consolidación del evento.

Este es el sitio para encontrar fotos del evento:

Fotos JSL

Tres meses, tres eventos

Estos meses que vienen van a estar llenos de eventos en la comunidad del Software Libre en Colombia. Entre el 18 y 21 de Agosto son las Jornadas de Software Libre aquí en Popayán. Creo que el evento va a estar bien bacano, varias personas van a asistir y van a haber actividades diferentes a las conferencias que lo van a hacer muy interesante. Algunos piensan hacer una mini-debconf, otros han pensando en hacer talleres de Python yotros más han pensado en hacer un bof sobre Gnome. Por supuesto la debeta no faltará. Sobra decir que siendo este evento en mi ciudad no faltaré por nada del mundo. Acme y Alerios también hablan sobre el evento.

El 14 y 15 de septiembre se realizará la celebración del Día Internacional de Software Libre en Pasto, organizado por UdeNar y Parquesoft. Este evento se ve bastante interesante. Tengo muchas ganas de asistir a este evento, no conozco Pasto y tengo varios amigos pastusos que me han hablado muy bien de la ciudad.

Por último, Del 2 al 6 de Octubre será la Semana Linux de la Universidad Distrital en Bogotá. El año pasado tuve la oportunidad de asistir a este evento y la pasé muy bien. Espero no perdérmelo este año.

Así que si todo sale bien y no ocurre ningún contratiempo, asistiré a estos tres eventos en lo próximos tres meses. De seguro van a estar todos muy bacanos.

Una Imagen de Flickr

Elephants Dream

En estos días me bajé Elephants Dream, también conocido como el Proyecto Orange. Elephants Dream es un cortometraje de animación 3D realizado exclusivamente con software libre. Blender es la principal herramienta utilizada, pero también se necesitaron otras utilidades como GIMPInkscape y CinePaint.

 

Escena de Proog y Emo hablandoEscena de Proog y Emo hablando

Elephants Dream ha sido financiado por la Fundación Blender y el Netherlands Media Art Institute. La creación de esta película ha servido para realizar muchas mejoras en Blender. Creo que es un excelente ejemplo de cómo un gran proyecto puede impulsar el desarrollo de un programa libre.

 

 

Escena de Proog bailando en el vacíoEscena de Proog bailando en el vacío

Sin ser un experto, puedo decir que la película se ve muy bien visualmente. Me gustan mucho los detalles de los personajes, especialmente el cabello. A veces la animación no luce muy real, pero creo que en general se ve muy bien. Cumple muy bien su propósito de mostrar las capacidades que tienen las herramientas libres.

 

 

Escena del Robot Máquina de EscribirEscena del Robot Máquina de Escribir

Me parece que la película falla en la forma en que lleva la historia. Justo cuando uno empieza a medio imaginarse de qué se trata la película, esta termina intempestivamente. Es de esas películas que lo dejan a uno con esa pregunta: ¿…Ya se acabó? Al final la película resulta ser puros cabos sueltos y uno no entiende casi nada.

 

Me gusta la escena en que Proog corre y baila en el vacío y la máquina lleva a sus pies pequeñas plataformas de acuerdo a como se va moviendo. También me gusta ese curioso robot máquina de escribir que se escribe a sí mismo.

Por supuesto, la película esta disponible bajo la licencia Creative Commons Attribution. Y se puede descargarlibremente desde la web. Algo curioso es que me bajé la versión de máxima resolución en formato MPEG-4, pero es tan pesada que le quedó grande a mi viejo PC. VLCMedia Player Classic y Windows Media Player fallaron en reproducirla. Hacían el intento, pero se veía todo muy lento, no podían seguirle el ritmo a la película. Mplayer fue el único que pudo reproducirla, sólo con el backend de vídeo X11 basado en XImage, con direct rendering y sindouble buffering. El problema era que ese backend no permite redimencionar el vídeo y pues, como tenía tanta resolución, no cabía completamente en mis 1280×1024 que es lo que más da mi monitor. Así que no me quedó otra que volver a bajar la película en un formato más pequeño.