Como les adelantábamos el otro día, la tan esperada Tablet de Apple fue anunciada en su último evento del 27 de Enero. La “iPad”, como ha sido bautizada, ha causado un revuelo bastante importante en la blogósfera, con comentarios, críticas y festejos por toda la Web. Desde Gizmodo hasta la Free Software Foundation, pasando por OSNews, Slashdot, Hacker News y varios otros.
Mi idea no es proveer aquí mi opinión personal sobre el dispositivo (planeo hacerlo más tarde), sino más bien hacer un eco de las opiniones tan variadas que he visto en la Web.
No hubieron sorpresas, nada fuera de las expectativas, nada especial, ninguna “One More Thing” [frase célebre de Steve Jobs, CEO de Apple]. Esto proveyó los fundamentos para las primeras críticas al dispositivo desde un punto de vista de los consumidores.
No mucho se hicieron esperar otras partes “interesadas”, como la Free Software Foundation, quienes pronto manifestaron su oposición al dispositivo, el cual se encuentra “plagado de DRM” y atenta contra la libertad de utilizarlo libremente y con cualquier propósito. Supongo que todo lo que argumentan es cierto, no obstante, ya hemos comentado sobre nuestra visión sobre la naturaleza cerrada de Apple en varias ocasiones anteriores, principalmente en referencia al iPhone.
En algún punto en “tierra media” entre la posición de los consumidores y la FSF, he leído la opinión de algunos desarrolladores y hackers. Por lo que he visto, los desarrolladores tienden a estar contentos con el dispositivo. Piensan que es una plataforma realmente interesante de programar y que ofrece posibilidades más allá de las computadoras “tradicionales” a las que estamos acostumbrados.
Otro motivo por el cual están contentos es porque la iPad ofrece una configuración de Hardware/Software uniforme que hará mucho más sencillo asegurarse que las aplicaciones desarrolladas funcionan correctamente en los dispositivos de los consumidores (después de todo, existe una única configuración disponible).
Otros han calificado al dispositivo como “la computadora perfecta para gente mayor”. Gente que solo quiere una computadora para leer el correo y navegar por Internet y no quiere estar manejando las complicaciones de Software Antivirus, Firewall, Antispam, Automatic Updates, DLL Hell y otros dolores de cabeza comunes en el mundo de algunos Sistemas Operativos se encontrará muy a gusto con el dispositivo.
Como pueden ver, hasta el momento las opiniones son muy variadas y hay mucho para digerir antes de poder saber si el dispositivo llegará a colmar las expectativas que habría levantado durante los últimos meses. Dependerá de los desarrolladores de aplicaciones…
Dentro de unos pocos momentos estará comenzando el evento de Apple en San Francisco, CA, donde se espera que anuncien la tan anticipada Tablet.
Desde el boom de la idea del Netbook y la introducción de un modelo propio por básicamente todo fabricante de Hardware salvo uno, siempre se estuvo a la expectativa de si Apple introduciría un modelo de Laptop pequeño y barato. Al tiempo, sin embargo, los se comenzó a anticipar más bien un Tablet de pantalla táctil, en vez de un Netbook con teclado.
Aún no se sabe nada oficialmente del producto, no obstante, los rumores parecerían indicar que el producto contaría con una pantalla táctil de 10 pulgadas con un Modem 3G y corriendo alguna versión del iPhone OS. En sí todo parecería indicar que se tratará de un “iPhone Grande” que -además de poder realizar todas las funciones de un iPhone- permitiría adquirir contenido digital como libros electrónicos y suscripciones a diarios y revistas. En ese aspecto tiendo daría para pensar en la Tablet como una mezcla entre un iPhone y un “Nook” de Barnes & Noble.
Otros productos que se espera que Apple introduzca, aunque quizás no en este evento, incluyen la próxima iteración del iPhone: el iPhone 4 y la nueva generación de Macbooks con procesadores Core i7.
Veremos dentro de unas pocas horas qué es lo que se anunciará hoy…
El día de ayer la Unión Europea aprobó la compra de SUN Microsystems por parte de Oracle. La compra ya había sido aprobada desde hacía algunos meses por las autoridades necesarias en Estados Unidos y únicamente estaba faltando la aprobación de la Unión Europea, quienes estaban preocupados por el futuro de la base de datos abierta MySQL.
SUN habría comprado MySQL un tiempo antes de que Oracle anunciara su interés de compra de SUN, y lo que preocupaba a la UE era que Oracle, siendo una empresa con un fuerte producto de base de datos privativa, fuera a terminar MySQL, la base de datos abierta más popular.
Habiendo aclarado las dudas, se dio la luz verde para la adquisición. Adiós, SUN.
Hace unos momentos acabé de actualizar a la más reciente versión de Firefox: Firefox 3.6.
El navegador dispone de varias mejoras en términos de desempeño y se “siente” bastante más liviano que su antecesor, Firefox 3.5. Otra cosa que me llamó la atención fue el nuevo sistema de Temas para el navegador (denominado “Firefox Personas”). Actualmente hay más de 1000 Temas distintos que pueden descargarse del sitio oficial de Mozilla.
Esta mañana leía un artículo en un blog llamado “Insight VR” muy interesante. El artículo cuenta la historia de una aplicación estilo “Asteroids” desarrollada hace 12 años por un -en aquel momento- estudiante de Computer Science.
Según cuenta, la aplicación se desarrolló utilizando Mesa, una implementación libre de OpenGL, como un trabajo obligatorio.
En un principio, la aplicación se desarrolló sobre un Mac, al poco tiempo se portó a una Workstation SGI (debiendo reescribir únicamente las rutinas de entrada del usuario). A los años, ésta se portó a Windows y, más recientemente, al iPhone.
La historia es muy interesante y termina con una conclusión bastante importante. El autor destaca como el hecho de haber trabajado con un estándar abierto (OpenGL) permitió que su programa pudiera mantenerse vigente y sobreviviera la prueba del tiempo.
“Imagina si en vez de OpenGL (ok, Mesa3D) hubiesemos usado alguna versión temprana de Direct3D para mi clase de gráficos. No solo todo lo que escribí se hubiese vuelto obsoleto cinco veces a esta altura, sino que ¿en qué plataformas funcionaría? “
El autor concluye,
“Realmente hay algo para decir a favor de los estándares abiertos y las bibliotecas construídas sobre dichos estándares. [...] Si estás escribiendo algo que va a tener una vida útil más allá de un par de años, deberías considerar cuidadosamente las tecnologías de base que utilizarás para construirlo. No te distraigas con los términos marketineros o lo que esté de moda. Incluso si lo que estás escribiendo es código para descartar, escribirlo portable puede brindar oportunidades que de otra forma no existirían.”
Realmente algo para considerar.
Les dejo el link al artículo (en inglés).
Realizando algunas pruebas básicas de profiling de Ceibal-Chess, noté que por algún extraño motivo el subproceso creado para ejecutar el motor de ajedrez (gnuchess) consumía una cantidad impresionante de CPU.
Inmediatamente esto me llamó la atención, debido a que el proceso estaba siendo configurado en modo “easy”, que deshabilita que se planifiquen jugadas durante el turno del usuario. Para peor, invocando gnuchess manualmente desde la terminal no provocaba este efecto.
Definitivamente se trataba de un tema a investigar en detalle.
Tras probar distintas invocaciones y parámetros, pude determinar que el problema resultó ser en la forma en que se creaba el subproceso.
Nuestra invocación era realizada aproximadamente de la siguiente forma:
from subprocess import Popen, PIPE ... #Mal!!: proc = Popen(args=["-e", "-x"], executable="/ruta/absoluta/a/gnuchess-linux", stdin=PIPE, stdout=PIPE, close_fds=True)
Resulta ser una sutileza, pero no se está brindando la ruta al ejecutable como primer argumento y si bien la llamada funciona de todos modos y el proceso es creado, tras comenzar a escribirle en su entrada estándar (stdin), éste comienza a utilizar el 100% del procesador.
Cambiar la llamada a Popen de forma tal que incluya el ejecutable como primer elemento de la lista args misteriosamente resuelve este problema.
Al probar el cambio sobre la XO, no solo se nota que el desempeño de la aplicación es mucho mejor (la interfaz de usuario tiene ahora más tiempo de CPU disponible), sino que además se solucionó un problema con un molesto icono que quedaba trancado en la vista home de Sugar.
Los cambios ya se encuentran commitieados al repositorio y próximamente estaremos actualizando las versiones disponibles en Algorithmia y el sitio oficial del CeibalJam.
En estos últimos días he estado trabajando sobre un renderer para un artículo que estoy produciendo para una importante revista de Linux. El renderer debía dibujar un campo de vectores discretizado, con dimensiones variables de 16×16, 32×32, 64×64 y hasta 96×96 (o más, dependiendo de la cantidad de memoria de video disponible).
Cada elemento en el campo de vectores es representado visualmente por un cuadrado (piensa en una baldoza) y una flecha (que representa la dirección). Cada cuadrado se forma con dos triángulos y cada flecha con tres, por lo cual para un campo de vectores de tan solo 16×16 estaríamos dibujando 1.280 triángulos, mientras que para un campo más grande de 64×64 estaríamos trabajando con un total de 20.480 triángulos.
La diferencia en desempeño fue increible. Con un mediano trabajo de refactoring logré obtener una aceleración que permitía redibujar la escena mucho más rápido, tanto más que no me alcanza el refresh rate del monitor para dibujar todos los cuadros que son generados por segundo.
Convertir el código de rendering de Modo Inmediato de OpenGL a VBO’s no fue tarea sencilla sin embargo. El problema fundamental consistió en que para trabajar con VBO’s se deben realizar transferencias de porciones de memoria RAM a buffers en memoria de video, por lo cual es necesario realizar un manejo bastante importante de punteros. Manejar punteros no es problema desde un lenguaje como C o C++, pero se puede llegar a complicar cuando se está trabajando en Python.
El primer problema consistía en convertir las listas de vertices y colores de listas Python a arrays contínuos en memoria. Para esto (y mucho a mi pesar) debí utilizar NumPy.array, lo cual solucionó el problema, pero al costo de agregar una nueva dependencia al código: numpy. Lo bueno es que teniendo un NumPy array, resulta sencillo generar los tipos adecuados para que los datos lleguen correctamente a la memoria de video. El siguiente snippet muestra la llamada a la función de copia de memoria:
from OpenGL.GL import * from OpenGL.arrays import ArrayDatatype as ADT import numpy ... array = numpy.array(vertices_and_colors, dtype=numpy.float32) glBufferData(GL_ARRAY_BUFFER, ADT.arrayByteCount(array), ADT.voidDataPointer(array), GL_STATIC_DRAW)
El segundo problema que tuve consitió en cómo indicarle a PyOpenGL los offsets dentro del buffer. El buffer de memoria que estoy utilizando está cargado tanto con datos de vértices como de colores, por lo cual debía poder especificar dónde empiezan los vértices y dónde empiezan los colores (en offset de bytes) a la API. Si bien esto parecía sencillo utilizando ctypes, se complicó bastante debido a un bug en PyOpenGL 3.0. La solución fué descargar el código de la Beta de PyOpenGL 3.0.1, compilarlo y hacer uso de ésta biblioteca en vez de la versión disponible en los repositorios de Ubuntu y Macports (actualmente ambas presentan este bug).
Una vez actualizada la biblioteca, crear un puntero genérico (void *) resultó trivial, como se muestra a continuación.
from ctypes import c_void_p ... glColorPointer(3, GL_FLOAT, 0, c_void_p(colors_offset))
Quiero mencionar que cuando escribí en la lista de usuarios de PyOpenGL preguntando por este último problema, quien me respondió que en realidad se trataba de un bug en la biblioteca no fué ni más ni menos que el autor de la misma.
En Algorithmia estamos trabajando mucho en las áreas de Visualización, Aceleración y desarrollo multiplataforma mediante el uso de OpenGL y CUDA desde varios lenguajes, incluyendo tanto C como C++ y Python.
En Varrojo@Linux queremos darle a todos nuestros lectores un cálido saludo de despedida del 2009, desearles que pasen unas muy felices fiestas y que los reciba un excelente 2010 lleno de oportunidades!
Queremos aprovechar este espacio para nombrar algunos de los hitos de este 2009 que se nos va. Saludos a todos y gracias por acompañarnos durante todo el año!!
Hitos del 2009 en Varrojo@Linux:
Algunas estadísticas para este 2009 (a partir del mes de Junio):
Gracias por acompañarnos y hacer de este el gran año que fue para nuestro sitio! Saludos y esperamos seguir en contacto durante este 2010.
Desde que desempaqueté la versión para XO de Super Vampire Ninja Zero, lo he estado utilizando sobre Linux de vez en cuando. Si bien de momento aún es un prototipo, el juego es divertido y me recuerda a varios juegos del estilo que jugaba cuando era “jóven” como Final Fight Guy, Final Fight Guy 2 y TMNT: Turtles in Time (muy recomendado).
En el juego utilizamos un personaje denominado “Mina”, que pelea contra zombies, ninjas, vampiros y hombres lobo. Mina tiene dos golpes básicos: uno rápido (Q) y uno fuerte (W), además de uno súper (A). La gracia consiste en que unos puede combinar estos golpes para formar Combos que hacen más daño y además alejan a los enemigos, lo cual resulta muy útil cuando se pelea contra 3 o más a la vez (algo común).
Les dejo algunas combinaciones que he descubierto, también a modo de recordatorio.
Los Combos también se pueden mezclar, por ejemplo comenzando el de 7 golpes pero con un par de W, la Q final hará una patada con giro.
Esto es todo lo que he encontrado hasta el momento. Si tienen más combinaciones, dejenlas en los comentarios!
Si no han probado el juego, se los recomiendo ampliamente. Se puede descargar de aquí y tiene una versión para Windows y una para XO, a partir de la cual, como mencionabamos antes, se puede extraer un binario que debería funcionar sobre cualquier Linux.