• Nokia provée actualizaciones esporádicas las cuales pueden ser automáticamente instaladas en nuestros teléfonos.
• Estas actualizaciones se realizan tomando en cuenta un código interno del teléfono, el cual no puede ser cambiado, de no ser que se haga un "flasheo" del mismo.
• Si estamos por ejemplo, en Uruguay, pero compramos nuestro teléfono en Estados Unidos (como en mi caso), no podremos cambiarle el idioma a no ser que cambiemos el código para que al momento de actualizar Nokia reconozca al teléfono como de Uruguay e instale el software en el idioma adecuado.

Back to blogging after a while, but i dont think it will last.

I am quite pissed of with the new notification system in ubuntu jaunty for several reasons, that i wont state here. One of the later is the fact that you can not change the position of the notification bubble. As i only use one panel and in the bottom, i dont focus my vision on the upper right corner. Because of this i made a patch that moves the notification bubble to bottom right. The patch just does that, for example it wont queue notifications above this bubble…. If you think it could help you, patch is here,

http://dagus.org/files/bottom

Best way to apply is with apt-src

sudo apt-src install notify-osd

cd notify-osd-0.9.11/src/

patch < /path/to/patch

sudo apt-src build notify-osd

sudo dpkg -i notify-osd_0.9.11-0ubuntu3_i386.deb

Nos complace poder anunciar que recientemente hemos publicado una nueva versión de Ceibal-Chess para la XO. Esta versión incluye varias mejoras visuales que harán la experiencia de juego más amena, así como se corrigen algunos errores del juego.

La nueva versión puede descargarse desde http://drupal.ceibaljam.org. Los pasos necesarios para realizar la instalación en la XO son los siguientes:

1. Iniciar la actividad terminal.
2. Obtener la nueva versión mediante el comando: “wget http://drupal.ceibaljam.org/sites/default/files/ajedrez.xo”, sin comillas.
3. Si ya dispone de una versión anterior instalada, ejecutar el siguiente comando para eliminarla: “rm -rdf Activities/Ajedrez.activity”; Reiniciar Sugar presionando: Ctrl + Alt + Erase.
4. Instalar la Actividad mediante el comando: “sugar-install-bundle ajedrez.xo”
5. Reiniciar Sugar presionando: Ctrl + Alt + Erase.
6. El ícono del Ajedrez aparecerá junto con las demás actividades.

Como siempre, pueden mantenerse al tanto de la información más reciente aquí, así como en nuestro grupo Facebook aquí.

El pasado Sábado 26 de Abril se llevó acabo el Festival Latinoamericano de Instalación de Software Libre (FLISoL) donde realizamos la presentación titulada “Herramientas y Técnicas para el Desarrollo de Aplicaciones Libres” en el Auditorio de la Torre de las Telecomuncaciones de Antel. Esta tuvo por objetivo presentar conceptos y herramientas que un desarrollador puede aprovechar para el desarrollo de un proyecto de Software Libre.

La presentación comenzó con una introducción al por qué iniciar un nuevo proyecto, las ventajas desde el punto de vista del desarrollador de hacer que este sea Software Libre u Open Source, y luego continuamos presentando distintas herramientas para el desarrollo. Dentro de este marco se habló de wikis, Software de gestión de la configuración (svn, hg), Issue Trackers y lenguajes de programación, en particular se realizó una pequeña introducción a Python (aunque nada cerca de la gran presentación de Marcelo Ramos en el Anfiteatro).

Durante la parte interactiva de la presentación se desarrollaron varios scripts que pueden resultar de utilidad a alguien que recién esté comenzando en python y le interese la parte de gráficos 2D con PyGame y 3D con OpenGL.

Los ejemplos, junto con las trasparencias de la presentación pueden descargarse del siguiente enlace:

http://www.algorithmia.net/software/download.py?dl=flisol09.zip

Dentro del archivo se incluyen los siguientes ejemplos:

• penguin.py - ejemplo sencillo que muestra como crear una ventana con PyGame y dibujar un png sobre ella.
• demo.py - ejemplo sencillo 2D de animación basada en el tiempo (gracias a Gabriel Eirea).
• holamundo.py - ejemplo intermedio que muestra como dibujar texto con PyGame.
• gl.py - ejemplo avanzado que muestra como integrar OpenGL con PyGame para dibujar una priámide 3D y animarla.

Israel/TPO: Nuevo envío de armas a Israel; el presidente Obama debe detener estas exportaciones

1 abril 2009

La llegada a Israel de un nuevo envío masivo de municiones estadounidenses, revelado por Amnistía Internacional hoy, 1 de abril, pone en duda si el presidente Obama actuará para impedir que Estados Unidos alimente nuevos ataques israelíes contra la población civil que puedan constituir crímenes de guerra, como los perpetrados en Gaza.

Según la nueva información recibida por Amnistía Internacional, el Wehr Elbe, carguero alemán fletado y controlado por el Mando Naviero Militar estadounidense, atracó en el puerto israelí de Ashdod, a apenas 40 km al norte de Gaza por carretera, y descargó, según los informes, más de 300 contenedores. El barco alemán partió de Estados Unidos rumbo a Israel el 20 de diciembre, una semana antes de que comenzaran los ataques israelíes contra Gaza. Transportaba 989 contenedores de municiones, cada uno de ellos de 6 metros de largo con un peso neto total estimado de 14.000 toneladas.

“Legal y moralmente, el gobierno del presidente Obama debería haber detenido este envío de armas estadounidenses, habida cuenta de la amplitud de pruebas que demuestran que las fuerzas israelíes han utilizado recientemente material y municiones militares de este tipo para cometer crímenes de guerra”, ha manifestado Brian Wood, responsable de la campaña de Amnistía Internacional Armas Bajo Control. “Los suministros de armas en estas circunstancias son contrarios a lo establecido por la ley estadounidense.”

Al preguntársele por el Wehr Elbe, un portavoz del Pentágono confirmó a Amnistía Internacional que “la descarga del envío completo de municiones estadounidenses se completó con éxito en Ashdod [Israel] el 22 de marzo”. El portavoz manifestó que el envío iba destinado a un arsenal estadounidense ubicado previamente en Israel. Según un acuerdo establecido entre Estados Unidos e Israel, este último puede hacer uso de las municiones de este arsenal en caso de necesidad. Otro funcionario estadounidense dijo a Amnistía Internacional que se está examinando el uso que hizo Israel de las armas estadounidenses durante el conflicto para determinar si fue acorde con la legislación estadounidense, pero que aún no se ha alcanzado ninguna conclusión.

“Existe un elevado riesgo de que el ejército israelí utilice las nuevas municiones para cometer nuevas violaciones del derecho internacional, como las cometidas durante la guerra de Gaza”, ha manifestado Brian Wood. “Estamos instando a todos los gobiernos a que dicten una suspensión general e inmediata de los suministros de armas tanto a Israel como a todos los grupos armados palestinos hasta que ya no exista un peligro sustancial de que se cometan violaciones graves de derechos humanos.”

Estados Unidos fue, con mucho, el mayor suministrador de armas a Israel entre 2004 y 2008. Además, está previsto que el gobierno estadounidense destine ayuda militar por valor de 30.000 millones de dólares a Israel, pese al uso flagrantemente indebido de las armas y las municiones que las Fuerzas de Defensa de Israel hicieron en Gaza y Líbano. Según una autoridad estadounidense, el presidente Obama no tiene planes de recortar los miles de millones de ayuda militar prometidos a Israel en virtud de un nuevo contrato de 10 años establecido en 2007 por el gobierno Bush, y que supone un aumento del 25 por ciento frente al último contrato acordado por el gobierno estadounidense anterior.

Amnistía Internacional ha informado detalladamente sobre los presuntos crímenes de guerra cometidos por las Fuerzas de Defensa de Israel y por los grupos armados palestinos en Gaza. El 15 de enero, la organización pidió a todos los gobiernos que suspendieran de inmediato las transferencias de armas a todas las partes del conflicto de Gaza para impedir que se cometieran nuevas violaciones utilizando las municiones y otros materiales militares transferidos.

Información complementaria:

El Wehr Elbe zarpó del estado estadounidense de Carolina del Norte el 20 de diciembre, tras recoger su enorme carga de municiones estadounidenses, inicialmente con destino al puerto de Navipe-Astakos, en la costa oeste de Grecia. La señal de su transpondedor desapareció el 12 de enero, cuando el buque navegaba cerca de Astakos, donde no pudo atracar a causa de una protesta de la rama griega de la Coalición Paremos la Guerra. El barco fue luego detectado cuando pasaba por el puerto de Augusta, en la isla italiana de Sicilia, y más tarde cerca de Gibraltar a mediados de febrero, antes de reaparecer el 23 de marzo en ruta desde Ashdod hacia el puerto de Odessa, en el Mar Negro, donde atracó el 26 de marzo, en el atracadero núm. 7. Amnistía Internacional ha sabido ahora que el buque atracó en Ashdod el 22 de marzo y, según los informes, descargó más de 300 contenedores.

Amnistía Internacional llamó por primera vez la atención hacia el viaje de este carguero el 15 de enero. Según el contrato de fletamento, autorizado por el gobierno de Bush una semana antes de que las Fuerzas de Defensa de Israel lanzaran su ataque contra Gaza, transportaría 989 contenedores de “munición en contenedor y otros suministros de munición en contenedor” desde la Terminal Oceánica Militar de Sunny Point, en Carolina del Norte, hasta Ashdod. El 31 de diciembre, durante el conflicto de Gaza, se anunció el fletamento, por parte del Mando Naviero Militar estadounidense, de otros dos envíos de munición desde Navipe-Astakos (Grecia) hasta Ashdod, en los que se incluía explícitamente munición de fósforo blanco. Estos envíos se cancelaron el 9 de enero, pero un portavoz militar estadounidense confirmó posteriormente que el Pentágono seguía buscando la manera de hacerlos llegar a su destino.

La sección 502B de la Ley de Ayuda Exterior estadounidense establece que “no podrá prestarse ayuda para seguridad a ningún país cuyo gobierno lleve a cabo una práctica constante de violaciones de los derechos humanos reconocidos internacionalmente”. La Sección 4 de la Ley sobre Control de las Exportaciones de Armas autoriza el suministro de material y formación militar estadounidense únicamente para fines legítimos de seguridad interna, “defensa propia legítima” o participación en operaciones de mantenimiento de la paz de la ONU u otras operaciones conformes con la Carta de la ONU. No obstante, según la Ley sobre Administración de Exportaciones, puede prestarse ayuda para seguridad si el presidente certifica que existen “circunstancias extraordinarias”, con lo que se elude la sección 502B. La Enmienda Leahy prohíbe que Estados Unidos proporcione la mayor parte de las formas de ayuda para la seguridad a cualquier unidad militar o policial cuando existan “indicios creíbles” de que sus miembros están cometiendo violaciones graves de derechos humanos.

OK, tenemos 8GB de RAM instalados, ¿¿por qué mi sistema operativo vé tan solo 3.2GB?? Los sistemas operativos de 32 bits sobre x86 pueden direccionar únicamente 2^32 direcciones de memoria. 2^32 / (1024 * 1024) = 4096 M, por lo cual no podemos esperar que un sistema operativo de 32 bits pueda trabajar con más de 4GB de RAM… Simplemente no puede “hablarle” a más memoria que eso.

Por otro lado, sabemos que los procesadores x86 no disponen de instrucciones específicas de Entrada/Salida, sino que la forma en la cual se comunican con los periféricos es mediante lo que se llama “Mapeo de Memoria”. Bajo este esquema lo que el procesador hace es asignar direcciones de memoria especiales que al ser escritas, los datos no son almacenados en memoria, sino que se “habla” con un dispositivo determinado, como la pantalla, la placa de red, etc. Estas direcciones de memoria no pueden ser utilizadas para almacenar datos, por lo cual la cantidad de memoria efectiva que nuestro sistema de 32 bits que ya estaba limitado a 4GB, quedará alrededor de 3.2GB, como podemos observar en la siguiente captura del System Monitor de un Ubuntu de 32 bits.

La solución a este predicamento y que nos permitirá deshacernos de estas restricciones consiste en utilizar un sistema operativo de 64  bits, para lo cual necesitamos un procesador de 64 bits. La buena noticia es que la mayoría del hardware que compramos hoy en día ya es de 64 bits, como los procesadores Core 2 Duo de Intel o Turion X2 de AMD.

Utilizando un sistema operativo de 64 bits podemos direccionar 2^64 direcciones de memoria, o 17592186044416 M, mucho más que nuestros 8GB. Esto no es un problema para sistemas operativos como Linux o Solaris, que son de 64 bits desde hace más de una década, pero sí para sistemas más inmaduros como Windows, que recien ha comenzado a incursionar seriamente en el mundo 64 bits.

Como puede verse en la siguiente figura, en la práctica mi Fedora 10 de 64 bits reporta que puede hacer uso de un total de 7.8GB, un número muy superior a los 3.2GB de un sistema de 32 bits.

Conclusiones

Una actualización de Hardware sencilla y accesible tanto económicamente como desde el punto de dificultad, donde el verdadero reto está en hacer el cambio a 64 bits para poder sacar el mayor provecho al equipo.

Dependiendo del sistema operativo y las aplicaciones utilizadas sobre este, esta tarea puede resultar algo tan sencillo como reinstalar el sistema o bien volverse una verdadera pesadilla de compatiblidad. La forma más segura de saberlo de antemano es realizando un catálogo de todo el software y hardware del cual hacemos uso y del cual no podemos precindir y determinar si el desarrollador/proveedor provee soporte para 64 bits.

Hasta la próxima.-

Posts anteriores:

• Decidir qué comprar (parte 1/3).
• Instalación (parte 2/3).

Una vez que disponemos de la memoria simplemente debemos instalarla. Para esto debemos remover los dimms actuales y reemplazarlos por los nuevos.

En mi caso, remover la memoria implicó remover la placa de video, la cual no permitía abrir la trabita del socket 0 del canal A, como puede verse en la siguiente figura.

Actualizar el hardware es algo que generalmente me recuerda de la ley de Moore. Si se fijan la siguiente figura, pueden ver el dimm removido (izquierda) y el nuevo (derecha). El dimm nuevo no solo es del doble de capacidad (2GB en vez de 1GB), sino que además su alto es la mitad que el de su antecesor.

Hay que tener cuidado al instalar componentes como la memoria ya que es muy sencillo quemar los sticks con electricidad estática. Utilizar una cinta antiestática ayuda a trabajar tranquilo al costo de que la cinta molesta.

Eso es todo en cuanto a la instalación se refiere. Si lo prefieren, puede resultar una buena idea ir poniendo los dimms de a uno, viendo si el sistema los va reconociendo. Para esto basta con entrar al BIOS, no es necesario bootear el sistema operativo.

En el siguiente post estaremos viendo el lado “Software” de todo este asunto y por qué no podemos ver los 8GB desde el sistema operativo.

Continúa leyendo:

• Decidir qué comprar (parte 1/3).
• Consideraciones de Software (parte 3/3).

Con la llegada de las nuevas memorias DDR3, decidí que finalmente era momento de actualizar la memoria de mi PC de escritorio antes de que en Uruguay se complicara el asunto de conseguir de las “viejas” memorias DDR2.

Cuando compré las partes de mi PC por Setiembre de 2007 me decidí por un motheboard Intel DG965ry, principalmente por el hecho de soportar hasta 8GB de RAM en 4 sockets dual channel. En aquellos tiempos 2GB de RAM era suficiente por lo cual no me molesté en adquirir más, sin embargo llegado el momento de actualizar decidí ir por 8GB directamente.

Saber qué comprar

Antes de comprar memoria, siempre es importante determinar cuales son los modelos compatibles con nuestro sistema, no queremos comprar una memoria que luego no podremos utilizar en nuestro equipo. El sitio web de Intel es una excelente referencia para esto si es que tenemos motherboards de este fabricante. El DG965ry soporta únicamente memorias de 240 pines a 1.8V.

Lo segundo a tener en cuenta es cuánto queremos comprar y saber si el sistema será capaz de soportarlo. Resulta que este motherboard en particular soporta un máximo de 8GB de RAM a 667MHz o (únicamente) 4GB a 800MHz, por lo cual si realmente queríamos subir a 8GB habría que ir por memorias de 667MHz. Si es mejor tener menos memoria pero más rápida o viceversa es un tema de discusión abierta y la respuesta dependerá exclusivamente del uso que se quiera dar al sistema.

Sabiendo ahora qué necesitamos, opté por adquirir memoria Kingston. Tenemos 4 sockets, por lo cual lo más razonable parecía comprar 4 dimms de 2GB, los cuales son bastante fáciles de conseguir a un precio razonable en sitios como Tranza o similares (U$S 26+IVA c/u). Unos 8GB nos quedaría alrededor de 104 dólares + shiping + IVA, algo común dado el hecho de que el mercado de la memoria está deshecho (¡gracias Vista!).

En el próximo post estaremos viendo el proceso de instalación, el cual implicará abrir el PC y remover los dimms para reemplazarlos por los nuevos.

Continúa leyendo:

• Instalación (parte 2/3).
• Consideraciones de Software (parte 3/3).

Hacía un tiempo comentábamos sobre los planes de AMD de discontinuar la línea de procesadores Geode, los cuales son utilizados en algunos dispositivos como las computadoras XO, entregadas en el parco del Plan Ceibal.

Aparentemente OLPC, la empresa detrás de la XO, estaría planeando cambiar a procesadores ARM para la siguiente versión de los equipos: la llamada “XO-2″. Los procesadores ARM son generalmente utilizados en dispositivos móviles (como celulares, iPods, calculadoras, etc) y permitirán obtener mayor provecho de las baterías de las XO, al consumir menos poder.

Asimismo, los procesadores ARM no son basados en la arquitectura x86, por lo cual no son capaces de ejecutar las versiones más comunes de Windows -en particular XP-. Quedará pendiente ver cómo afectará esto las relaciones entre Microsoft y OLPC.

Linux, por su parte, está portado a ARM, arquitectura sobre la cual es bastante utilizado. A nivel de Ceibal-Chess nos encontramos bastante aislados de este cambio al estar trabajando siempre sobre Python. Restará recompilar gnuchess para ARM

Puedes leer más sobre la arquitectura ARM aqui >>.

Al parecer hay un bug en la forma en que Fedora 10 permite configurar una dirección IP estática a la máquina en la cual se encuentra corriendo. Tras haber dado con este hilo en el foro de linuxquestions.org, me encuentro con que se llegó a la conclusión de que la aplicación para configurar la dirección IP introujo un bug entre las versiones 8 y 10 de Fedora, el cual no permite registrar la máscara de red asignada a la placa de red.

Por suerte en Linux siempre podemos hacer todo desde consola, salteandonos la aplicación que presenta este bug. A grandes razgos, los pasos a seguir son los siguientes:

1. Abrir una terminal y volverse root.
2. Matar definitivamente el NetworkManager: chkconfig NetworkManager off; service NetworkManager stop
3. Editar el archivo de configuración de la interfaz, para eth0 sería /etc/sysconfig/networking/devices/ifcfg-eth0

Finalmente, configurar las opciones para la placa. Una configuración de ejemplo sería la siguiente. Pueden encontrar las opciones necesarias para activar IPv6 en el foro.

DEVICE=eth0

HWADDR=xxxxxxxxxxxx

BOOTPROTO=none

BROADCAST=10.10.10.255

IPADDR=10.10.10.2

IPV6INIT=no

NETMASK=255.255.255.0

NETWORK=10.10.10.0

ONBOOT=yes

DNS1=200.40.30.245

DNS2=200.40.220.254

GATEWAY=10.10.10.1

TYPE=Ethernet

NM_CONTROLLED=no

USERCTL=no

PEERDNS=yes

Otros post relacionados:

• Configura Fedora 10 de 64 bits.
• Configura Fedora 8.

Me complace poder anunciar que con las últimas adiciones al código, estamos listos para comenzar a hacer un testeo más difundido del programa. Estamos buscando voluntarios!! Quienes quieran darnos una mano, pueden descargarse un zip conteniendo todo lo necesario para correrlo en Windows, Linux y Mac de: http://www.algorithmia.net/ceibal-chess-beta.zip.

Ceibal-Chess está desarrollado en Python y utiliza Pygame, por lo cual ambos son necesarios para poder ejecutarlo. Quienes utilizan Windows van a tener que instalarse ambos programas: python 2.6 y pygame 1.8.1-py2.6. Una vez instalados simplemente se extraen los contenidos del zip, y dentro de la carpeta ceibal-chess, doble click en el achivo “main” (main.py).

Quienes usan Linux seguramente ya disponen de una versión de Python 2.x, por lo cual únicamente deberán instalar pygame. Este se encuentra en los repositorios de las distribuciones más polulares bajo el nombre “pygame” o “python-pygame”. Para ejecutarlo simplemente se debe descomprimir el archivo, cd al directorio ceibal-chess y ejecutarlo como python main.py

Otras plataformas pueden consultarse en el FAQ oficial.

Los requerimientos oficiales mínimos para esta versión son: CPU 500MHz, 32 MB RAM (64 recomendado) y 4 MB de disco libre (no incluye espacio requerido por los logs).

Los invitamos a descargarse el programa, probarlo y enviarnos su feedback, este es muy importante para nosotros! Como siempre, pueden encontrar mucha más info en el sitio: http://code.google.com/p/ceibal-chess, en particular les recomendamos leer el FAQ, o bien pueden preguntar por aquí

Leo en Slashdot que AMD, fabricante de los procesadores Geode utilizados en varios dispositivos de bajo consumo -entre ellos la XO- al parecer no tiene planeado ningún remplazo para el mismo para el mediano, corto o largo plazo.

Los procesadores Geode son los utilizados por las computadoras entregadas en el marco del Plan Ceibal en nuestro país, lo cual da a pensar qué sucederá con los futuros equipos que se compren a OLPC. Puede ser que los procesadores Geode sigan siendo utilizados en la XO y no se realice ninguna actualización: Negroponte -jefe de OLPC- nunca fue fanático de aumentar las especificaciones de Hardware de los laptops, o bien puede que sea un punto más a tratar en la agenda para el diseño de la sucesora de la XO, la XO-2.

Según los analistas, en los duros tiempos de la crisis internacional, el procesador Geode no se encuentra en la lista de prioridades de los ejecutivos de AMD.

Leo en LifeHacker acerca de la nueva versión de Virtual Box (2.1), que acaba se ser liberada recientemente.

Según describen en el artículo, se trata de una “actualización importante”, la cual incluye un montón de features experimentales. Entre ellas, las que más llaman la atención son:

• Soporte para virtualización por Hardware sobre Mac OS X.
• Soporte para virtualizar sistemas de 64 bits sobre sistemas de 32.
• Aceleración 3D experimental sobre OpenGL.
• Nuevo motor de NAT más performante y confiable y soporte para ping (al fin!).
• Otras…

Vritual Box se puede descargar como un producto comercial gratuito o en su versión Open Source, con algunas features menos. Pueden descargar la versión más reciente desde virtualbox.org.

Recientemente he abordado un nuevo proyecto dentro del ámbito laboral, lo cual me ha llevado a la necesidad de configurar un sistema basado en Linux de 64 bits. Dentro del espectro de opciones manejadas por el cliente se encontraba Centos 5.0 y Fedora 10, ambas distribuciones basadas en RPM con soporte para 64 bits (aparentemente otras versiones de GNU/Linux no eran una opción).

Debo admitir que en principio tenía mis reservas con respecto a instalar un Linux de 64 bits, no por que pensara que el sistema sería inestable (Linux es de 64 bits desde 1996), sino porque me encontraba bajo la impresión que el soporte para actividades diarias (multimedia, Flash, etc.) no sería muy bueno. Me alegro al poder decir que estaba equivocado. El sistema tiene un gran desempeño y para un usuario es virtualmente es imposible darse cuenta que se está trabajando sobre 64 bits.

Para quienes esten interesados les dejo aquí un paso a paso sobre como configuré Fedora 10 para sacarle el mayor provecho.

Herramientas de Desarrollo

Fedora es una distribución que siempre apeló a los desarrolladores de Software. Configurar un ambiente de desarrollo basado en el Toolchain de GNU es realmente sencillo, simplemente abrimos una terminal y como root ejecutamos:

yum groupinstall “Development Tools” “Development Libraries”

El tamaño de descarga es de aproximadamente 120MB.

Drivers de Video de NVIDIA

NVIDIA provee drivers para Linux de 32 y 64 bits en su sitio sin embargo es conveniente instalarlos mediante el sistema de paquetes, de forma de poder tener un mejor control sobre ellos y poder actualizarlos. Fedora no incluye los drivers de NVIDIA en sus repositorios debido a que estos son privativos, por lo cual agregaremos el repositorio RPM Fusion, donde se encuentran muchos paquetes que el proyecto Fedora no quiere distribuir.

Para agregar los repositorios Free y Non-Free de RPM Fusion utilizamos el siguiente comando, siempre como root:

rpm -Uvh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

Ahora debemos borrar el cache de yum:

yum clean all

Y ahora podemos instalar los drivers para nuestra GeForce 6 o superior (otros modelos):

yum install kmod-nvidia

Codecs de Audio, Video

Finalmente llegamos a los codecs de audio y video. Por suerte su configuración es sencilla habiendo agregado los repositorios de RPM Fusion:

yum install gstreamer-plugins-ugly gstreamer-plugins-bad gstreamer-ffmpeg

y:

yum install xine-lib-extras-freeworld

Flash Player

Tradicionalmente no dispondríamos de un reproductor de Flash para Linux de 64 bits. Afortunadamente, Adobe lanzó hace poco menos de una semana una versión beta de su Flash Player 10 para Linux de 64 bits. En el momento en que escribo esto, el reproductor beta puede descargarse de aquí: http://labs.adobe.com/downloads/flashplayer10.html

Una vez descargado el archivo tar.gz debemos instalarlo manualmente. Para ello lo primero es descomprimirlo y luego moverlo al directorio /usr/lib64/mozilla/plugins/ como root:

mv libflashplayer.so /usr/lib64/mozilla/plugins/

Es importante recordar hacer este archivo ejecutable:

chmod a+x /usr/lib64/mozilla/plugins/libflashplayer.so

Es mejor tener Firefox cerrado cuando hacemos esto. De cualquier forma debemos reiniciarlo para que los cambios tengan efecto.

Así mismo cabe destacar que Sun ha liberado una versión de 64 bits de su plugin de Java para navegadores de 64 bits. No lo he probado, pero pueden encontrar información aquí: http://www.phoronix.com/scan.php?page=news_item&px=NjkyOQ

Espero les resulte útil, y como siempre, los invitamos a dejar sus comentarios. Pueden descargar el DVD o Live CD de Fedora 10 para 64 bits desde aquí: http://fedoraproject.org/en/get-fedora-all.

Las personas que fumaron durante mucho tiempo y luego dejaron, tienen sueños múcho más vívidos que cuando tenían el vicio. También, la tercera parte de los que dejan dicen haber soñado con estar fumando. En esas situaciones sienten pánico o culpa por estar hacienda lo que en la vida real habían decidido dejar de hacer.

Esto es llamado Incorporación del Sueño y es la experiencia en la que por ejemplo un sonido que ocurre en el momento en el que estamos soñando, es incorporado como parte del sueño. Otro ejemplo ocurre cuando tenemos sed y en el sueño sentimos que estamos sedientos. A mi me pasó muchas veces sentir que estoy meando y bueno … ya se imaginarán los resultados. Por cierto, esto me pasó hasta los 16 años (no le digan a nadie). Este que sigue es una pintura de Dalí que representa el concepto de la incorporación.

Cuando uno sueña está paralizado, y lo más probable es que, esto sucede para prevenir que el cuerpo actué en función de lo que estamos soñando. Gracias a Dios, sinó haríamos muchas cagadas. Según la mejor encyclopedia del mundo, mientras soñamos se genera una hormona que apaga el movimiento evitando que reaccionemos de manera no deseada mientras dormimos.

Como otro dato anecdótico, las personas que roncan, cuando roncan no sueñan. Esta es una lista bastante pelotuda pero en mi caso me he preguntado algunas de estas cosas muchas veces, y por ahí alguno de ustedes también. A parte, decidí al menos por una vez no darle palo a nadie ni a ninguna institución para ver que es lo que comentan.

No hace tanto escribíamos sobre los (desastrosos) resultados de probar Ceibal-Chess sobre el Hardware real de la XO. Resultados debidos principalmente al bajo poder de cómputo de estas maquinitas en comparación con los equipos utilizados para desarrollar y probar el programa.

Equipo donde se desarrolló la mayoría del código: Core2Duo 2.1GHz vs. XO: AMD Geode a 500Mhz.

Finalmente hoy me dediqué a realizar algunas pruebas de profiling sobre el código, para intentar identificar los posibles cuellos de botella. Por profiling no me refiero a ninguna herramienta profesional más allá del clásico enfoque de combinar print’s con la función time() para ver por dónde va el código y medir el tiempo de ejecución de distintas llamadas.

Si bien se logró rastrear el principal cuello de botella al cálculo de movimientos, resultó que realizar estas mediciones arrojó unos resultados interesantes sobre posibles puntas para optimizar el programa. Principalmente llamó la atención la gran cantidad de veces que era llamada la función encargada de determinar si el rey se encontraba Jaque Mate. Detectar el Jaque Mate es la condición para determinar el fin de juego, una condición que debe testearse bastante seguido (en cada Frame) para presentar un mensaje, evitar que los jugadores puedan seguir moviendo piezas, etc.

Determinar si estamos en Jaque Mate involucra evaluar todos los posibles movimientos de las piezas del oponente (llamando a nuestra pesada get_moves()) para ver si el rey se encuentra contenido en alguno de ellos y si no tiene escape.

El abuso de esta función causaría que se dispararan un gran número de llamadas al cálculo de movimientos, lo cual consumía muchos ciclos. Este era un problema de Ceibal-Chess. De hecho, mediante las pruebas realizadas se logró detectar que la condición de Jaque Mate se revisaba incluso cuando el juego se encontraba desplegando el menú de opciones, algo completamente innecesario.

Mediante la eliminación de algunas llamadas superfluas, junto con la implementación de un sencillo cache de movimientos para la función que calcula todos los movimientos del oponente (get_all_oponent_moves()) fue suficiente para traer el desempeño del programa a un nivel aceptable sobre la XO.

Ciertamente el código requerido para solucionar el problema fué mucho más sencillo de implementar que si se hubiese tomado el enfoque de realizar la implementación del cálculo de movimientos en C++, lo cual si bien hubiese mejorado el desempeño, no hubiese la solución “natural”, y quizás no hubiese valido la pena por el nivel de complejidad que agrega al proyecto el tenerlo implementado de a partes en 2 lenguajes.

Moraleja de la historia: antes de salir a programar como locos, a veces es mejor sentarse a hacer algunas mediciones, por más que sientas que en ello “pierdes” el tiempo. Al final de cuentas, “si no puedes medirlo, no puedes mejorarlo”.

>> Sitio de Ceibal-Chess en Google Code: http://code.google.com/p/ceibal-chess

Aprovechando el haber conseguido una XO para traerme a casa el lunes pasado, y tras una o dos horas peleando para lograr conectarla al wifi de casa (tuve que cambiar la encriptación a WPA Personal con TKIP, nada más anda), decidí probar la versión más reciente de Ceibal-Chess sobre el Hardware real.

El proceso de empaquetado, por suerte, seguía funcionando apropiadamente, y bastó con ejecutar nuestro generador de bundles para obtener el archivo distribuible (el “instalador”) para la XO.

Probar el juego sobre el Hardware real es significativamente distinto que hacerlo sobre otros sistemas, principalmente por cuestiones del Hardware mismo: la pantalla es más pequeña, el procesador más lento y la memoria más chica.

Si bien el juego comienza siendo jugable de forma apropiada, tras unas pocas jugadas, el manejo de eventos (capturar el click para seleccionar y luego mover una pieza) se vuelve demasiado lento, ciertamente por debajo de lo aceptable.

Recuerdo que Pablo Flores habría probado una versión anterior de Ceibal-Chess sobre su XO y me comentó que la maquinita podía manejarlo bien, entonces allí me surguió la duda de qué podría haber cambiado del juego desde que él lo probara de forma que, a medida que jugamos, se vuelve más y más pesado.

Haciendo memoria, resulta que el cambio principal realizado consistió en agregar la evaluación de jugadas hipotéticas para filtrar los movimientos inválidos del juego. Las reglas del ajedrez prohíben mover una pieza que está protegiendo al Rey de ser atacado. El programa debía implementar esta funcionalidad, sin embargo, para hacerlo debemos determinar si al mover una pieza a una determinada posición, el Rey entraría en Jaque.

La forma en que esto se hace consiste primero en determinar todos los movimientos válidos de la pieza seleccionada (el peón en nuestro ejemplo), luego generar un nuevo tablero “hipotético” para cada uno de los movimientos posibles y finalmente determinar si el Rey se encuentra en Jaque en ese tablero. En caso de estarlo, el movimiento se descarta.

Para determinar si el Rey está en Jaque, se evalúan todos los posibles movimientos del adversario, determinando si el Rey se encuentra comprendido dentro de alguno de ellos. Para calcular los movimientos debemos volver a invocar nuevamente nuestra función. Veamos esto gráficamente:

Seleccionar Pieza -> Calcular Movimientos -> Generar Tableros Hipotéticos -> Determinar Jaque para cada tablero -> Calcular Movimientos.

Resulta que calcular los movimientos de una pieza es una función recursiva! Una función que además aumenta la cantidad de tableros hipotéticos generados dependiendo de la cantidad de movimientos que la pieza seleccionada puede hacer.

Cuando el juego inicia, solo los peones se pueden mover y hacia adelante 1 o 2 pasos, por lo cual el número de tableros hipotéticos generados se mantiene bajo. Pero a medida que se comienza a entablar la batalla, las piezas podrán estar en cualquier orden y seguramente generarán una cantidad mayor de tableros hipotéticos, haciendo que Calcular Movimientos ejecute muchas veces y recursivamente, consumiendo casi todo el procesador de la XO.

Claramente este problema debe ser solucionado. De momento se me han ocurrido dos alternativas: manejar un caché de movimientos, intentando realizar el cálculo de los movimientos de la pieza que seleccionamos una sola vez (igual será lento la primera), o bien, reimplementar el cálculo de movimientos en C o C++, brindando la velocidad asociada a la ejecución nativa  a esta función, pero al costo de deber volver a implementara, testearla y de deber tener mucho cuidado de no romper la portabilidad del código (actualmente Ceibal-Chess puede ejecutar en cualquier plataforma que disponga Python y Pygame). Una tercer alternativa implicaría una implementación en C o C++ con caché.

Aún me encuentro duda de cuál será el mejor enfoque, pero lo que es seguro es que debemos proveer una solución a esto antes de poder liberar la versión 1.0.

Uno de los elementos en los que intenté hacer más énfasis durante la presentación de Ceibal-Chess fue como prácticamente todos los elementos del programa se fueron desarrollando en forma incremental e iterativa, donde partíamos realizando una implementación simple de una idea que nos parecía buena, y luego la íbamos refinando de a poco en varias iteraciones, hasta llegar a una versión que nos dejara satisfechos.

Este fue el caso para el diseño del menú del programa, el cual permite al usuario (niño) seleccionar el modo en el cual jugar, ver quién realizó la aplicación o bien, salir de ella.

Durante las primeras 3 semanas del proyecto, el desarrollo se enfocó principalmente en el ajedrez mismo: dibujado del tablero y de las piezas, implementación de las reglas del juego, interacción con el usuario e integración con la Inteligencia Artificial. En aquellos tiempos, el juego debía configurarse mediante línea de comandos o bien editando el código.

A medida que las diversas áreas del “core” comenzaron a alcanzar un determinado nivel, se comenzó a implementar una versión inicial del menú, la cual pueden ver en la siguiente figura:

From Ceibal-Chess

Tras contactar a Jurema -nuestra diseñadora (¡que importante es siempre tener un diseñador!)- comenzamos a disponer de imágenes y arte que pudiéramos utilizar para mejorar el aspecto visual. En esta segunda fase simplemente se intentó mapear el arte sobre el menú, realizando las adaptaciones al código necesarias.

El resultado fue menos que óptimo, si bien mejoraba la apariencia.

From Ceibal-Chess

Para la siguiente versión, del menú fue importante basarnos en las omisiones de la fase anterior para corregir los desvíos. Algo tan simple como especificar el tamaño que el menú ocupa en pixels ya permite coordinar esfuerzos entre las distintas disciplinas (programación y diseño) para generar un mejor producto.

From Ceibal-Chess

En este punto ya sabíamos que el menú nos gustaba así, y habiendo establecido su apariencia general, una cuarta iteración nos llevó a la versión actual del menú donde principalmente se agregaron detalles que “endulzan el ojo” (eyecandy). Probamos varias ideas, pero siempre respetando la evolución realizada en las fases anteriores. En este caso decidimos experimentar haciendo trasparente el fondo violeta del menú, el cual le da un mayor sentido de integración con el resto de la aplicación.

From Ceibal-Chess

Probablemente se disponga de una fase más de experimentación, buscando agregar detalles visuales al menú, pero conservando el resultado logrado a través de las distintas iteraciones.

Cabe destacar que el menú ya era funcional desde su primera versión, pero el proceso iterativo permitió producir algo que además de ser útil, fuera lindo a la vista. Este es un ejemplo de como partiendo de una versión sencilla algo que aparece para subsanar una necesidad puntual (”necesitamos un menú”), se puede ir iterando haciendo leves mejoras hasta llegar a una versión funcional y además agradable. Este siempre ha sido el espíritu detrás de este proyecto.

Recuerden que pueden bajar el último snapshot de Ceibal-Chess desde:

• http://code.google.com/p/ceibal-chess

Finalmente, tras actualizar mi versión de VirtualBox en Fedora y descargar la iso de OpenSolaris, pude iniciar este sistema en una nueva máquina virtual para ver en qué andaba su comunidad y realizar algunas pruebas.

Como se menciona en varios blogs de personas que han hecho esto antes que yo,  levantar el LiveCD del sistema fue un proceso directo, sin muchas vueltas, y todo anduvo “out of the box”… bueno, todo menos la conexión a Internet.

Realmente probar el sistema y no tener conexión es bastante aburrido, ya que no hay mucho para vermás allá del entorno GNOME y BASH, por lo cual me puse en campaña de poder arreglar la conexión.

Revisando por ahí, en este blog de SUN alguien publicaba sus experiencias de correr OpenSolaris sobre Mac OS X, y comentaba que notó que lo que estaba roto no era el driver de la placa de red, sino que simplemente OpenSolaris no puede resolver los nombres de servidor a sus direcciones IP. Para esto debemos configurar los servidores de DNS.

Configurar los servidores de DNS es igual que en Linux (ambos tienen su herencia UNIX después de todo). Simplemente creamos el archivo resolv.conf en /etc:

nameserver 200.30.40.245

nameserver 208.67.220.220

nameserver 208.67.222.222

Este archivo hay que crearlo como root. En el LiveCD la contraseña es “opensolaris”.

Una vez creado este archivo  podremos resolver los servidores con nslookup, pero las aplicaciones como Firefox y wget cancelarán con un error. Para repararlo es necesario copiar el archivo /etc/nsswitch.dns a /etc/nsswitch.conf:

# cp /etc/nsswitch.dns /etc/nsswitch.conf

Con eso debería quedar pronto. Un último detalle importante a tener en cuenta es que en VirtualBox deberá utilizarse como tarjeta de red emulada el modelo: “Intel PRO/1000 MT Desktop”, para la cual OpenSolaris ya trae driver. Si bien esta es la opción por defecto, vale la pena revisar que este sea el valor seleccionado antes de iniciar la máquina virtual.

Hoy actualicé VirtualBox a la última versión en Fedora. Estaba utilizando la 1.5 (previa a que Sun comprara Innotek), por lo cual no tenía buen soporte para Solaris. El proceso de actualización fue bastante sencillo, pero tuve que realizar algunos ajustes para que la nueva versión funcionara en mi sistema.

Descargué del sitio de VirtualBox  la última versión en formato RPM para mi versión de Fedora (8), pero ésta se reusaba a ser instalada mientras estuviera la versión 1.5 presente, por lo cual debí eliminarla primero:

$ sudo yum remove VirtualBox

Luego procedimos con la instalación, utilizando rpm:

$ sudo rpm -ivh \

VirtualBox-2.0.2_36488_fedora8-1.i386.rpm

El paquete instaló correctamente y pude iniciar el administrador con el comando VirtualBox. Por suerte las máquinas virtuales creadas con la versión 1.5 fueron detectadas y actualizadas a la versión actual, sin embargo cuando quise iniciar alguna para probar la conversión, recibí un mensaje de error que decía algo en las líneas de: “VirtualBox can’t operate in VMX root mode”, y me pedía que eliminara el módulo KVM de mi Kernel.

Este es un problema común y al parecer se debe a que VirtualBox no puede ejecutar si hay otro visor de máquinas virtuales ejecutando que haya activado las instrucciones del procesador de virtualización por hardware. En mi caso, eliminar el módulo no era una opción, ya que lo utilizo para acelerar por hardware la emulación de Sugar sobre qemu, por lo cual la solución fue simplemente remover el módulo del Kernel esta vez (y cada vez antes de iniciar VirtualBox).

lsmod nos muestra los módulos cargados. Buscamos kvm:

$ /sbin/lsmod | grep kvm
kvm_intel              23169  0
kvm                    89201  1 kvm_intel

Ahora removemos el módulo kvm_intel y luego kvm. Si lo hacemos al revés obtendremos un mensaje de error, ya que kvm_intel hace uso de kvm.

$ sudo /sbin/modprobe -r kvm_intel
$ sudo /sbin/modprobe -r kvm

Listo, reiniciamos VirtualBox y esta vez la máquina virtual levantó bien, sin errores. Siguiendo los pasos de Fernando Briano, estaremos probando Solaris virtualizado dentro de poco.

Descarga VirtualBox para tu sistema operativo:

•  http://virtualbox.org/wiki/Downloads

Slashdot tiene un articulo interesante hoy donde invita a los lectores a compartir sugerencias con respecto a qué tamaño de partición es mejor utilizar como partición de Swap en Linux.

Tradicionalmente, la regla era que la partición de Swap debería ser del doble de tamaño que la cantidad de memoria RAM disponible, sin embargo, con la cantidad de memoria disponible hoy en día, duele sacrificar 4 u 8 GB de disco para establecer una partición que podría no utilizarse.

El consenso general en Slashdot parace ser “depende de tus aplicaciones y de tu Hardware”. Si solo utilizas el navegador, y tienes 2 GB de RAM, probablemente no necesites Swap, pero si quieres correr esa aplicación de análisis de datos o de computación gráfica monstruosa, entonces te convendría tener un buen número, no demasiado ajustado pero tampoco demasiado grande.

Como guía general, un lector posteó las sugerencias para ejectuar el motor de base de datos Oracle:

• RAM entre 1GB y 2GB, entonces Swap = 1.5 veces el tamaño de la RAM
• RAM entre 2GB y 8GB, entonces Swap = 1 vez el tamaño de la RAM (mismo tamaño).
• Más de 8GB, entonces Swap = 0.75 veces el tamaño de la RAM.

Claro que hay que tener en cuenta, también, que si estamos hablando de un Laptop y queremos poder utilizar la funcionalidad de suspender a disco (hibernar), la partición de Swap tendrá que tener por lo menos el mismo tamaño que la cantidad de memoria RAM disponible, de forma de poder escribir todo su contenido a disco antes de apagar el equipo.

Los invito a leer los comentarios en Slashdot:

• How Big Should My Swap Partition Be, vía Slashdot, en inglés.

Hace 5 días el proyecto detrás de mi Sistema Operativo cumplió 5 años. ¡Feliz cumpleaños, proyecto Fedora!

Fedora is all about freedom and rapid innovation.

Fedora is a Linux based operating system that provides users with access to the latest free and open source software, in a stable, secure and easy to manage form. We strongly believe in the bedrock principles that created all the components of our operating system, and because of this we guarantee that Fedora will always be free for anybody, anywhere, to use, modify and distribute.

(Fuente: http://fedoraproject.org/wiki/Overview)

Adobe liberó recientemente la nueva versión de la llamada “Creative Suite”: un conjunto de herramientas que incluyen Photoshop y DreamWeaver, entre otros. La gran novedad de esta versión de las herramientas, al compararla con sus predecesoras, es que en esta versión algunos de los productos de la Suite sacan provecho del Hardware de video (la GPU), en vez de depender únicamente en la CPU para realizar la manipulación de imágenes y video.

Esta es una gran noticia para usuarios de esos productos, ya que las GPU’s suelen ser mucho más eficientes para hacer operaciones en paralelo sobre grandes volúmenes de datos. Las herramientas en cuestión son Photoshop, After Effects  y Premiere pro.

Según el artículo en Slashdot:

Tanto Premiere Pro como After Effects sólo soportan características de GPU en la línea profesional de GPU’s Nvidia Quadro, pero Photoshop CS4 permite aceleración por GPU en cualquier GPU que soporte Shader Model 3.0 (como la serie Nvidia GeForce 6200).

Asimismo, también leo en Gizmodo que Adobe ha agregado  soporte para “multitouch” en sus productos. Orgullosos dueños de MacBook Air’s y MacBook Pro’s pueden ahora utilizar gestos similares a los del iPhone o iPod Touch en sus Mac’s para interactuar con las herramientas de la suite.

Parte de la presentación de Ceibal-Chess en el Software Freedom Day. El video quedó un poco cortado, pero los conceptos principales se encuentran presentes.

Como mencionamos con anterioridad, el pasado Sábado 20 se presentó, en el marco del Software Freedom Day, el proyecto en el cual hemos estado trabajando desde el último Ceibal Jam, el Ceibal-Chess.

Ceibal-Chess es un proyecto que apunta a desarrollar un Ajedrez para los laptops del Plan Ceibal, que pueda ser utilizado por los niños para aprender las reglas de este juego.

Personalmente quedé satisfecho con la presentación realizada, si bien hubo que apurarla un poco sobre el final debido a restricciones de tiempos. Durante la presentación Pablo Flores realizó una muy completa introduccion al Plan Ceibal, así como al Ceibal JAM, mientras que yo tuve la opotunidad de presentar la metodología de desarrollo que aplicamos durante la corta vida del proyecto.

Me hubiese gustado poder hacer una demo un poco más extendida, de forma de mostrar el potencial de la aplicación a la audiencia, sin embargo creo que la presentación logró sus objetivos.

Quiero agradecer a todos quienes asistieron a la presentación y, sin más, invitarlos a participar del proyecto, ya sea jugando y buscando bugs, revisando el código (el cual se encuentra completamente disponible bajo la licencia GPLv2), mandando parches, etc.

Varrojo.-

• Página del proyecto en googlecode: http://code.google.com/p/ceibal-chess
• FAQ en español: http://code.google.com/p/ceibal-chess/wiki/FAQSp

Fedaro publica en su blog la entrevista realizada a Jon “Maddog” Hall durante su breve visita a nuestro país. La entrevista se publicó en “La Diaria”. Les dejo un extracto de la entrevista y el link a la versión completa, en el blog de Fedaro.

Del artículo en Fedaro.info:

Hay varios motivos por los cuales el Estado debería usar Software Libre. En primer lugar por un tema de independencia tecnológica, cuando el Estado utiliza software del cual no posee el código fuente, deja en manos de quien posee el código fuente gran parte de su poder de decisión. La decisión de cuando cambiar a una nueva versión, la decisión de qué correcciones realizar y cuanto tiempo invertir en solucionar los problemas que puedan surgir.

Una repartición estatal puede continuar utilizando Windows 95 o Windows 98, pero ya no contará con soporte para esos sistemas operativos y nadie se lo podrá brindar dado que solo una empresa tiene el código fuente.

Pero lo que es aún más importante, es un tema de soberanía y seguridad, dado que cuando uno usa software del cual no posee el código fuente no puede saber realmente que es lo que hace ese software.

En cambio utilizando Software Libre, se mantiene la libertad de contratar a quien uno desee para modificar ese código, mejorarlo y adaptarlo a las necesidades locales.

Continúa leyendo:

• Entrevista completa en Fedaro.info.

El próximo sábado se llevará a cabo el Software Freedom Day en la Fundación de Cultura Informática (FCI). En esta oportunidad estaremos presentando el proyecto “Ceibal-Chess”: una actividad para Sugar cuyo objetivo es enseñar a los niños a aprender a jugar ajedrez.

El evento comienza a las 17:00 horas, les dejo el afiche debajo. Nos estamos viendo

Una de las cosas que pienso que se podría haber hecho mejor en Leopard es la terminal. Para alguien que está acostumbrado a hacer uso de Gnome Terminal o Konsole, la configuración por defecto de la terminal en Mac OS X le parecerá bastante rudimentaria, por más que esta utilice BASH y se dispongan de todos los comandos tradicionales de UNIX.

El problema principal es la dificultad para moverse entre palabras y al principio y final de la línea que uno escribe para poder editarla. Tras buscar bastante, por suerte encontré en este blog como configurar esto para simular un comportamiento como el de las terminales en los escritorios de Linux

Al iniciar la Terminal, dirigirse a las Preferecias desde el menú y luego al tab “Settings”. Aparecerá frente a nosotros la lista de secuencias enviadas a BASH según las distintas teclas presionadas. Nos interesa cambiar “control cursor left” y “control cursor right” y configurarlos de forma que al presionar Control + Flecha Izq. o Control + Flecha Der., el cursor se mueva una palabra hacia atrás o hacia adelante.

Para esto hacemos doble click en la línea a editar y editamos la secuencia enviada a BASH a \033b para “cursor left” y \033f para “cursor right”. Los cambios se aplican instantáneamente, no hay necesidad de reiniciar la Terminal.

Otra cosa que nos puede resultar útil es tildar la casilla de verificación “map Meta to Option”. Por defecto la Terminal utiliza como botón “Meta” la tecla Escape. En Linux suele utilizarse Alt. Al tildar esta casilla, la tecla “Option” (Alt. en Mac) se tomará como “Meta”, pudiendo hacer uso de esta como hacemos en Linux.

Para seguir leyendo:

• Configurar la Terminal en Mac OS X. [en Inglés]

El próximo Jueves (11 Set.) John “Maddog” Hall estará haciendo una presentación en la Universidad Católica sobre el uso de Software Libre en la educación. Maddog es un histórico promotor del software libre. Es presidente y director ejecutivo de Linux International y desde hace años recorre el mundo con la finalidad de dar a conocer las ventajas del empleo de Linux como sistema operativo [Wikipedia].

Jueves 11
20:00   Universidad Católica,

Software Libre en la Educación: Cómo le enseñan dos (o tres) veces

Como estudiante de software durante cuarenta años, y un ex-profesor universitario, el orador demostrará por qué el Software Libre debe utilizarse siempre que sea posible para alcanzar los objetivos educativos y de investigación de la Universidad. Se presentarán ejemplos prácticos de los puntos abordados.

Dados los ejemplos de varias facultades de la Universidad de la República adoptando el uso de estándares abiertos para el manejo de documentos dentro de la universidad y como formato de intercambio de información con estudiantes, espero que esta presentación sea un impulso para que nuestra universidad tome una ruta similar en este sentido; cuando menos para el desarrollo de trabajos de investigación - a quién le sirve un trabajo de investigación de más de un año de duración, el cual se encuentra completamente confinado dentro de un formato de archivo que no sabremos si podremos abrir de aquí a 10 años.

¿Cuántas horas de investigación y trabajos de grado se encuentran hoy bajo riesgo de perderse para siempre por no solicitar a los investigadores que hagan entrega de al menos una copia de la versión final en un formato abierto?

Para seguir leyendo

• Facultad de Ciencias migrará a Formatos Abiertos.
• Vocero de Microsoft dice que ODF ganó la “guerra de estándares”.
• Universidad de la República migrará a formatos abiertos.

Nos llega a través de Mark3l:

Comunicamos a Usted la resolución Nº 53 adoptada por el Consejo de la Facultad de Ciencias en sesión extraordinaria de fecha 01/09/08:

 

“Exp. Nº 241160-001001-08

Atento a la resolución Nº 10 adoptada por el Consejo Directivo Central en sesión del 27 de mayo de 2008, disponer que a partir del 1º de enero de 2009, todo intercambio y publicación de documentos digitales en la interna de la Facultad de Ciencias y en sus comunicaciones públicas, se realizarán de acuerdo a la política establecida en el documento Estándares de Formato de Archivos de Ofimática EFAO.“ (10 en 10)

Leo en Slashdot sobre una empresa China que ha conseguido diseñar un Laptop que podría producirse a unos 98 dólares, finalmente permitiendo alcanzar la meta de OLPC de producir Laptops de 100 dólares para todos los niños de los países en desarrollo a un precio accesible.

El diseño plantea cambios significativos al concepto de Laptop, y según el artículo, se basa en lecciones aprendidas tanto del XO como del EeePC de Asus.

Según el artículo:

Por sobre todas las cosas, [el Laptop] se ve bastante bien. Procesador basado en MIPS, WiFi, 1GB de almacenamiento flash, corre Linux, 3 puertos USB, Ethernet, lector de tarjetas SDHC, entrada y salida de audio, soporte para múltiples tabs en Firefox y procesamiento de texto con Abiword.

Lo que más me llamó la atención fue la elección de un procesador MIPS, en vez de uno basado en x86. De acuerdo al artículo, esto permitió reducir aún más los costos. Dado que Windows XP nunca correrá sobre un procesador MIPS, es casi seguro que este aparatito no proveerá la opción Windows/Linux, como OLPC ofrece. Teniendo esto en cuenta, veremos si OLPC acepta que este dispositivo provea los fundamentos para el (ya anunciado) XO-2.

El dispositivo, llamado Mini Note, se espera para Octubre de 2008.

Update: parece que el dispositivo puede correr Windows CE. Probablemente Negroponte pueda seguir con su idea de enseñarle Windows a los niños del tercer mundo.

Desde el sábado pasado tengo una XO en casa, que gentilmente me fue prestada por los organizadores del Ceibal Jam 2. Si bien ya había utilizado Sugar sobre las máquinas virtuales para Qemu que uno puede descargarse prearmadas desde sugarlabs.org, debo admitir que utilizar el sistema sobre el Hardware real es una experiencia significativamente distinta.

Sin dar más vueltas, vamos directamente a lo que nos interesa en esta primera parte: el Hardware de la XO. El Sugar que incluye esta máquina ya dispone de la Actividad Terminal (un emulador de consola), por lo cual podemos utilizarlo para acceder directamente al sistema GNU/Linux en el cual éste se basa para averiguar las características de Hardware.

Procesador

El procesador es un AMD Geode de 430.952 MHz con un caché de 128KB. Desde el comienzo ya podemos notar que estos aparatos no disponen de poder de cómputo en abundancia, un punto a tener en cuenta cuando desarrollamos aplicaciones en otros computadores, que luego esperamos poder ejecutar sobre estos.

Memoria

Otro importante factor a tener en cuenta durante el desarrollo de aplicaciones para las XO es la cantidad de memoria disponible.  El comando free -m nos reporta que el sistema dispone en total de 232 MB de RAM, de los cuales 215 están en uso, con 117 MB como caché. Esto significa que en realidad nos quedan 134 MB libres de memoria física para nosotros, un factor importante a tener en cuenta, ya no creo que estas maquinitas dispongan de la posibilidad de paginar a almacenamiento secundario. Este número limita el tamaño de nuestras aplicaciones si es que queremos cargar muchas imágenes y sonidos.

Almacenamiento

Como almacenamiento secundario se dispone de una tarjeta de únicamente 1GB. Suficiente para albergar Linux, Sugar y varias Actividades, pero no para cargar el aparato con mucho contenido multimedia.

La Pantalla

Otro dato que resulta importante al desarrollador de Actividades es que la pantalla tiene una resolución de 1280×900.

Por algún motivo a las aplicaciones desarrolladas con pygame (o con SDL) en modo ventana siempre se dibujan en la esquina superior izquierda y se les agrega un recuadro negro. Si nuestra aplicación pygame ejecuta en modo ventana, deberíamos solicitar un tamaño de ventana de 1280×900 para asegurarnos que no nos quedará esta área negra inaccesible en la esquina inferior derecha.

La pantalla tampoco parece ser capaz de desplegar muchos colores, las Actividades por lo general utilizan colores grises y no se ven muchos colores a la vez. Unas pruebas básicas demostraron que el blanco, negro, rojo y verde encendidos al máximo se visualizan bien, pero habría que ver qué sucede al bajar la intensidad de los mismos.

Teclado

El teclado es pequeño. Punto. Está hecho para las manos de un niño, dificilmente resulte cómo para un adulto. Más allá de eso, lo único fuera de lo ordinario es que la XO no tiene teclas de función (F1..F12), por lo cual no deberíamos asignar eventos a ellas en nuestras aplicaciones

Dell anunció hoy su esperado “Netbook” o Mini Inspiron que desde que originalmente se vió a Michael Dell con uno, comenzaron los rumores de Dell entrando en el mercado de los laptops barátos y ultra portables.

El aparato, llamado Inspiron Mini 9 entró a la venta hoy en Estados Unidos por 399 dólares en su versión con Windows XP. Una versión con Ubuntu se encuentra anunciada para los próximos meses, cuyo costo será de 349 dólares.

Debajo de su brillante carcaza se encuentra un procesador Intel Atom de 1.6 GHz, 512 MB de RAM, una pantalla de 8.9 pulgadas 1024×600 “led-backlit” (consume menos batería) y un dispositivo de almacenamiento de estado sólido de 4, 8 o 16 GB. La placa de wifi es una 802.11g.

La placa de video es una Intel GMA 950, que si bien no provee una performance disparatada, tiene buenos drivers para Linux y puede manejar los efectos básicos de Compiz Fusion (es decir los efectos de Vista y el famoso Cubo 3D).

La batería es de 4 celdas y debería durar unas 3 horas, dependiendo del uso que se le dé al aparato.

Vía Gizmodo y dell.com.

Head Tracking for Desktop VR Displays using the WiiRemote

El próximo sábado será la primer jornada del Ceibal Jam! 2, en la Universidad Católica. Adjuntamos la convocatoria. Esperamos verlos : )

Convocatoria al Ceibal Jam 2

Bajo la consigna Vení a programar, se realizará los días 30/8 y 6/9 el 2do encuentro Ceibal Jam!.

Ceibal Jam es un movimiento social independiente de afiliación abierta y voluntaria, que busca nuclear a todos quienes tengan interés en contribuir al desarrollo de software con utilidad potencial para el Plan Ceibal; es un esfuerzo por desarrollar la capacidad local de crear nuevas aplicaciones y modificar las existentes para que atiendan a las necesidades específicas de la realidad uruguaya.

En esta ocasión se realizarán talleres introductorios a la programación para las computadoras XO del Plan Ceibal, dirigidos a públicos con distintos niveles de conocimiento, al tiempo que se presentarán proyectos de desarrollo en curso y se formarán grupos para trabajar durante las jornadas en distintas propuestas de programación.

Con el fin de recibir propuestas y sugerencias de desarrollo, se ha habilitado un foro en Internet, de acceso público: http://www.mediagala.com/rap/foro/viewforum.php?f=15

El encuentro cuenta con el auspicio de la Universidad Católica del Uruguay, de Larrobla & Asociados y Artech.

Fecha: El encuentro se realizará en dos jornadas, los sábados 30/8 y 6/9, de 9 a 18 hs.
Lugar: Universidad Católica del Uruguay, Avda. 8 de Octubre 2738, Montevideo.
Más información e inscripciones: http://wiki.laptop.org/go/Ceibal_Jam

Se agradece difundir esta información.

Utilicen https://login.facebook.com/login.php, envía el nombre de usuario y contraseña cifrados por SSL.

Uruguay es el primer país del mundo en poner en marcha el proyecto OLPC (un laptop por niño) mediante el llamado Plan Ceibal. El objetivo del Plan consiste en dar a cada niño de la escuela pública un laptop que pueda utilizar para estudiar, jugar, conectarse a Internet y compartir con su familia. Todo esto con el fin de disminuir la brecha tecnológica.

A nivel de nuestro país existen dos redes o grupos de apoyo al Plan Ceibal: Ceibal RAP y el Ceibal Jam. Ceibal RAP se enfoca en temas que tienen que ver principalmente con la logística de estos aparatitos (llevarlos a las escuelas, traerlos cuando se rompen), así como generar contenidos y documentación que las maestras y niños puedan utilizar para sacar mayor provecho al Plan.

Ceibal Jam, por su parte, consiste en actividades de programación, donde la idea es desarrollar programas (llamados “actividades”) que puedan utilizarse en estos Laptops. Esta segunda entrega se está organizando en la Universidad Católica del Uruguay y se realizará los sábados 30 de agosto y 6 de setiembre.

Hasta ahora han habido tres reuniones organizativas, pero ya hay un cronograma tentativo sobre las actividades que habrán durante las jornadas (tomado de Ceibal Jam):

Sábado 30/8

• 9:30 Acreditaciones
• 10:00 Plenario (Aula Magna)
  • Bienvenida
  • ¿Qué es el Ceibal Jam!?
  • Descripción de proyectos iniciados
• 11:30 Talleres de python (2hs)
  • Sala 1: Iniciación a la programación para XO (docente a definir). Entorno de desarrollo, hola mundo, primeros pasos.
  • Sala 2: Python avanzado (Santiago Aguiar). El lenguaje python en profundidad
  • Sala 3: Programación de juegos para XO (Nicolás Castagnet). Programación del entorno gráfico, etc.
• 13:30 Almuerzo
• 15:00 A programar!
• 19:00 Discusión docente: las TICs en la educación (Salón sin máquinas). Modera Fernando Giménez

Sábado 6/9

• 9:00 Seguimos programando
• 18:00 Plenario de cierre

La Universidad ha puesto a disposición de los asistentes 3 laboratorios con PC’s que dispondrán de un ambiente de desarrollo basado en Ubuntu Linux, así que la idea sería juntarse y programar actividades para los niños

Hemos mencionado el comienzo de la producción en masa de los Laptops del Plan Ceibal, así como cómo emularlos y sus fuertes características de seguridad en varias ocasiones.

Ok, quizás no fue una guerra en el mismo sentido que cuando la gente habla de Firefox vs. Internet Explorer, o Windows vs. Linux, pero es sabida la pequeña competencia que hay entre los lenguajes Ruby y Python.

Ruby tuvo su auge alrededor del 2003 o 2004, donde se volvió popular tras la aparición del framework “Rails” (deben haber oido hablar de “Ruby on Rails”), una API que permite crear sitios Web basados en el patrón MVC con acceso a base de datos.

La principal ventaja de Ruby on Rails era justamente su sencillez. Recuerdo haber ido a una charla de Enrique Place en el Día Debian de hace un par de años donde presentaba dos imágenes, cada una con una pila de libros considerados “esenciales” para aprender una determinada plataforma. Por un lado estaba la pila de J2EE, básicamente un conjunto de unos 20 libros que abarcaba desde JSP’s y Servlets hasta Tomcat, Struts y JSF. Por otro lado estaba la pila de Ruby on Rails: 3 libros. Todo apuntaba a que en el futuro, las plataformas principales de desarrollo de aplicaciones y sitios Web serían tres: .NET, J2EE y Ruby on Rails. No obstante, las cosas no fueron tan así.

De pronto la gente comenzó a darse cuenta que las aplicaciones desarrolladas con Ruby on Rails no eran tan convenientes como se decía (a pesar de que no era necesaria mucha experiencia para comenzar a hacer sitios Web). Creo que recuerdo algún artículo en Slashdot que mencionaba los costos secundarios que traía desarrollar aplicaciones sobre esta plataforma (mano de obra, mantenimiento de las aplicaciones, etc.).

Como era de esperarse, eventualmente también aparecieron un par de frameworks para Python de desarrollo de sitios Web: primero TurboGears, aunque no he oido hablar de él desde hace tiempo, y luego Django. Django se ha vuelto muy popular para el desarrollo de sitios Web basados en tecnología Open Source, y de hecho no me sorprende escuchar más de él estos días que de Ruby on Rails.

Creo que mis sospechas terminaron de confirmarse en una charla “a todo Ruby” por parte del UyLUG a la que concurrí hoy. Mi amigo Alejandro Esperón (Ratman) me comentaba lo no-tan-sorprendido que se encontraba al darse cuenta de que eramos tan solo 12 asistentes en la jornada. Yo le pregunté si le parecía poco, a lo que me contestó que en la jornada anterior del ciclo de charlas del UyLUG, las jornadas “a todo Python”, asistieron aproximadamente 40 personas.

¿Dónde está Ruby hoy?

Leo en Slashdot acerca de la “trifecta geek” que el grandulón se mandó la semana pasada. Aparentemente no solo se unieron a la Fundación Apache como miembro Platino (la membresía es de 100.000 dólares al año), sino que tambien liberaron parches para ADO-db bajo la licencia LGPL y extendieron la “promesa de especificación abierta” (OSP) con más de 100 protocolos de interoperabilidad entre las versiones Cliente y Servidor de Windows.

Si bien, según comentan algunos expertos, la OSP está lejos de ser un artefacto legal que permita proteger contra posibles demandas por violación de patentes a quienes implementan interfaces publicadas por Microsoft, esto sumado al hecho de unirse a la fundación Apache y liberar parches bajo una licencia Open Source verdadera, consiste en un movimiento del grandulón hacia la comunidad Open Source.

Por ahí esto sea el resultado de la puja de algún pequeño grupo dentro de MS que entienda las ventajas que tendría tanto para la empresa misma como para la comunidad que ésta comenzara a abrirse al resto del mundo, o quizás tenga que ver con el retiro de Bill Gates, una de las principales figuras detrás de todo el concepto de Software Privativo. A lo mejor el día que Steve Ballmer se retire también, MS se de cuenta de que es tan solo un jugador más en una gran comunidad de empresas y personas.

Si al igual que a mi les sucede de trabajar con la computadora largas jornadas de 8 o más horas, quizás los siguientes tips les puedan ser de utilidad. Desde hacía un tiempo estaba notando que mi Fedora me estaba dejando con un fuerte cansancio en la vista, que por lo general terminaba derivando en dolores de cabeza, contracturas o aire.

Pensando por qué esto no me pasaba al utilizar otras computadoras (incluso si se trataba de monitores CRT) noté que el escritorio de Fedora 8 es por defecto muy brillante. Hay muchos colores claros y blancos fuertes que tras varias horas de trabajo desgastan demasiado la vista. Cuando bajar el brillo del monitor no es una opción, los siguientes ajustes pueden ayudar a disminuir el esfuerzo de la vista sobre un GNOME (en inglés).

Oscurecer los Paneles

Fedora 8 introdujo el tema visual “Nodoka” cuyos paneles son muy brillantes (casi tendiendo a blanco). Para bajar el brillo nos dirigimos a System -> Preferences -> Look and Feel -> Appearance. Ubicamos el tema Nodoka y seleccionamos Customize.

En la solapa “Colors” pinchamos sobre el color de fondo de las ventanas (windows) y lo bajamos a gusto. En mi caso sustraje 30 de cada uno de los componentes RGB, de forma de mantener la proporción entre los canales, pero haciendo el escritorio más oscuro (acercándolo al gris).

Adicionalmente podemos bajar el color de los campos de texto (input boxes), cuyo color es un blanco al máximo (255, 255, 255). Sustraer 20 de cada canal fue suficiente en mi caso, dejando (235, 235, 235).

Los cambios se aplican directamente, no es necesario cerrar la sesión.

Oscurecer Firefox

Firefox es una aplicación que hay que oscurecer casi obligatoriamente. El color de fondo para las páginas que trae por defecto es un blanco al máximo (#FFFFFF en la notación que utiliza Firefox). Para bajar la intensidad debemos ir a las opciones de configuración secretas de Firefox, ingresando en la barra de direcciones “about:config”, sin comillas.

En la página de configuración filtramos por la palabra “background” y buscamos browser.display.background. Aquí podemos editar este valor a algo menor, por ejemplo “#CCCCCC”, que es un blanco mucho más leve, tendiendo al gris.

Quizás tengamos que reiniciar Firefox para que los cambios tomen efecto. Fedora 8 trae Firefox 2, esto quizás sea distinto en Firefox 3.

Oscurecer el Editor de Texto

Finalmente, quienes utilizan GEdit para programar pueden cambiar el esquema de colores a algo más oscuro. En GEdit, nos dirigimos al panel de preferencias: Edit -> Preferences y en la solapa “Fonts & Colors” seleccionamos el tema “Oblivion”, el cual configura un fondo gris oscuro con texto blanco.

Esto son solo un par de ejemplos de cosas que se pueden hacer para hacer más tolerable el estar tantas horas frente a una computadora con Fedora. ¿Tienen otros tips? Nos encantaría conocerlos! Dejen sus comentarios abajo!!

Según leo en Gizmodo, de acuerdo con Gartner, Apple se ha vuelto el fabricante #3 de computadoras en el mundo, siguiendo únicamente a Dell y HP. De acuerdo con Gartner, esto se debe al aumento en las ventas de Mac’s de un 38% el año pasado, elevando su cuota del mercado a 8.5%, y rebasando a Acer en 65.000 unidades. Actualmente Dell y HP tienen un 31.9% y 25.3% del mercado respectivamente.

No puedo dejar de preguntarme si este aumento en las ventas de Mac’s se debe a algún motivo en particular, como digamos, el Sistema Operativo que la competencia está preinstalando o si será por alguna otra cosa. Personalmente, yo finalmente decidí comprarme un Mac el día que OOXML se volvió estándar ISO. De cualquier forma, felicitaciones para Apple.