Una de las grandes decepciones que he tenido en los últimos tiempos, es ver cómo Amarok: el mejor software de gestión de música de todos los tiempos, ha pasado a la mediocridad cuando llegó la versión 2.x.

Si bien hoy en día uso como notebook personal una Macbook con su sistema operativo y gestor de música de fábrica, el Amarok 1.4 sigue siendo el mejor gestor que he usado y la segunda decepción que tuve fue cuando vi que Ubuntu 9.04 Jaunty trae la versión de Amarok 2.x, nombre clave: bonito, barato…pero malo.

Me ha tocado hacer un orgulloso downgrade a la versión 1.4, y lo pude hacer gracias a la inteligencia colectiva que promueve la blogósfera, así que paso a describir las simples instrucciones para que todo aquel que esté sufriendo el Amarok 2.x, pare de sufrir!

Primero agregamos una fuente de paquetes al apt, ejecutar estos comandos desde un Terminal en el entorno gráfico:

gksu gedit /etc/apt/sources.list.d/amarok.list

…agregando la siguiente línea:

deb http://ppa.launchpad.net/bogdanb/ppa/ubuntu jaunty main

Luego, agregamos la clave del paquete a nuestro anillo:

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com \
0x1d7e9dd033e89ba781e32a24b9f1c432ae74ae63

Y por último, desinstalamos amarok 2.x para darle la bienvenida al 1.4:

sudo apt-get update
sudo apt-get remove amarok
sudo apt-get install amarok14

Eso es todo. Más simple, imposible.

Realmente, el amarok 2.x parece un insulto a los usuarios de Amarok, quizás deberían dejarlo para comenzar la release 3.x, nombre clave: la anterior era una joda!

Recordé que varios de mis amigos geeks usan esas terminales que se deslizan desde arriba como si fuera la consola del Quake, y con eso en mente empecé a buscar el software libre disponible para mi flamante Ubuntu 8.10 Intrepid Ibex. Había varias opciones, y obviamente yo buscaba las que estaban basadas en el framework GNOME para mantener la consistencia del escritorio. Es más, si estaba basado en la libvte mucho mejor, ya que me llevo de 10 con la terminal de GNOME.

Opciones hay varias, pero como me pasó con Amarok, ninguna de las opciones reunía todas las características que uso en una terminal (que no son muchas!!!):

1. Múltiples pestañas
2. Colores de fuentes y fondo personalizables
3. Apertura/cierre y cambio de pestañas con combinaciones de teclas
4. Seteo de título de pestaña (con tecla caliente, alias hotkey)
5. Y ahora el gran agregado: una tecla rápida global para mostrar/esconder la terminal

De más está decir que Yakuake cumplió todos estos requisitos y algunos otros más. La gran contra es que tengo otra vez cargado el sistema KDE para una sola aplicación, pero bueno… en este caso es la aplicación principal que me permite ganarme la vida, así que podemos dejarlo pasar por esta vez

Ya que estamos, les recomiendo que lean un post anterior que habla sobre los colores para emular una terminal Hércules, después de varios años de usar ese esquema de color les puedo decir que me sigue pareciendo uno de los más descansados.

El único inconveniente (al menos para mi) es que utiliza las bibliotecas del entorno KDE, y yo como usuario del entorno GNOME, no veo la necesidad de cargar semejante framework en la RAM de mi computadora, tan sólo por un programa… es por eso que cada tanto daba una revisada a los varios programas de gestión de música que hay para GNOME.

Finalmente me convenció Exaile, que cubre mis expectativas con respecto al tipo de uso que le doy a Amarok. Mayormente mis necesidades son que se pueda conectar con Last.fm, pudiendo sugerir música relacionada a la que estoy escuchando y además poder ser controlado por teclas rápidas globales, de modo que estando minimizado yo pueda pausar, adelantar, cambiar el volumen, puntuar, etc.

Exaile tiene la posibilidad de agregarle extensiones, las que me permiten hacer justamente lo que quiero, por fin pude desinstalar las libqt de mi sistema!

Para aquellos que quieran hacer funcionar las teclas rápidas globales con compiz, acá les va un dato: Hay que instalar el compiz-manager y armarlas ahi ya que el plugin solo es para metacity. Ejecutando ‘exaile –help’ van a poder ver la cantidad de acciones que puede realizar una tecla rápida.

Espero les sirva la recomendación!

Bien, luego de varios meses de no escribir, me siento en la obligación de al menos informar que este blog corre en la última versión disponible de wordpress: la 2.7

¿Mejoras con respecto a la anterior? Seguro debe haberlas, pero como no he sido usuario asiduo de la rama 2.5.x, a mi no me pregunten

Lo que si, la interfaz está mejor organizada, da una sensación de tener todo a mano sin tener que scrollear mucho hacia abajo.

De paso, ya que andaba con ganas, cambié el tema por uno que soporte widgets, y le agregué el plugin que la gente de Sociable ha escrito para darle capacidades de FacebookConnect, lo que permite a los usuarios loguearse a mi blog con su cuenta de Facebook, y compartir contenidos del blog en esa red social.

Nokia Research Center ha desarrollado una implementación de Map/Reduce, una de las herramientas que Google utiliza para el procesado de inmensas cantidades de información.

El funcionamiento de Map/Reduce a grandes rasgos consiste en partir el conjunto de datos en pequeños segmentos y distribuir datos y código de ejecución en diferentes computadoras (Map) para que trabajen en paralelo. El resultado de este procesamiento luego es recuperado e integrado en un solo lugar para su procesamiento final y uso (Reduce). Se puede leer más acerca del tema en el paper publicado por Google.

Nokia Research Center comenzó un proyecto denominado Disco Project, que consiste en un servidor implementado en Erlang que nos permite como usuarios ejecutar scripts en Python (si, leyeron bien!) en forma distribuida y masiva.

En el sitio del proyecto tenemos un lindo tutorial que podemos probar desde nuestra propia PC, si tenemos un CPU multicore y GNU/Linux, claro está

Lo que no es tan bárbaro, a mi modo de verlo, es escuchar música o ver películas en la notebook, ¿por qué? bueno…a menos que tu notebook tenga un buen par de parlantes internos o uses auriculares, la calidad del sonido no será la óptima.

Lo lindo de una PC desktop es que normalmente la tenemos enchufada a algún equipo de audio, o bien a unos parlantes buenos y potentes. Lo no tan lindo es que ver películas sentado en el escritorio no es cómodo, y tener que ir a la PC para cambiar la música cada vez que quieras tampoco.

Con estas experiencias en mente, estaba pensando que una buena alternativa sería poner en mi desktop un servidor de reproducción de audio, en donde yo desde la notebook, quizás vía una interfaz web pudiera manejar la música que suena en el equipo de audio, ya sea que esté en el balcón, en la cama o mi escritorio…pero esto no me resolvía el problema del audio en los videos que suelo ver, y fue por eso que nunca lo implementé.

Hace poco me puse a leer un poquito sobre Zeroconf, por recomendación de un amigo que me dijo que está interesante, y me encuentro con que existen servidores de audio que usan esta tecnología. Zeroconf es un conjunto de protocolos que permiten la configuración automática de varios aspectos de una red, sin la intervención de un administrador o equipo central. Con agrado veo que PulseAudio, un servidor de audio con capacidades de red, tiene un módulo de Zeroconf, y una enorme cantidad de clientes entre los que se incluyen Amarok, Mplayer, Xine, gstreamer, GNOME, etc.

Combinando PulseAudio con Zeroconf en una red WiFi, he logrado que al iniciar mi sesión GNOME, mi notebook descubra automáticamente el servidor PulseAudio en mi PC Desktop (que siempre tengo funcionando) , y de ahí en más tengo la opción de elegir que la música y el audio de los videos salgan por el equipo de audio.

Esto que puede parecer una pavada, en la práctica es una comodidad increíble, recomiendo que lo prueben porque vale la pena. No voy a escribir un tutorial porque al menos en Debian es realmente trivial hacerlo funcionar, pero les dejo un enlace que lo explica muy bien:

http://www.pulseaudio.org/wiki/PerfectSetup

¡Que lo disfruten! Si alguno tiene experiencias similares, sería interesante que las comenten.

Lo curioso de este sitio es que nos permite subir nuestros proyectos para luego hacer un análisis del código fuente, detectando los lenguajes utilizados, y sacando estadísticas. Como primera medida subí el proyecto GNOME War Pad a partir de mi repositorio git público, y en un par de horas el sistema había importado el código fuente y había analizado su contenido, detectando los contribuidores y su nivel de actividad en el proyecto.

Pueden ver además que a partir del código fuente, el sitio arma una especie de perfil de cada desarrollador, con información sobre el nivel de experiencia en cada lenguaje, cantidad de commits, etc. En fin, me pareció una idea original armar una red de desarrolladores cuya información sea extraída directamente de su trabajo, puede ser una buena fuente de contactos a la hora de buscar gente para un nuevo proyecto.

Durante mucho tiempo estuve usando ese esquema hasta que me mudé de computadora, y no recordaba el esquema de colores ni tampoco quien me lo comentó pero después de escarbar un rato finalmente lo encontré:

• Color de letra: #FF5C42
• Color de fondo: #010037

Bueno, ahi está! que quede para la posteridad. Que lo disfruten

La administración de servidores involucra variadas tareas, desde la elección de hardware para un nuevo servidor, la instalación del sistema operativo, aplicaciones, su configuración, pruebas y puesta en producción, para luego terminar con el mantenimiento de dicho servidor, que puede incluir más tareas como por ejemplo: actualización periódica del software instalado, la corrección de mínimos errores que podamos haber tenido en la configuración inicial, el agregado de pequeñas herramientas que nos ayudan a mantener los servicios funcionando, copias de respaldo de datos, y quizás también del sistema base… la lista continúa pero creo que la idea está planteada: Administrar servidores no es una tarea simple.

A medida que sumamos servidores a nuestra carga administrativa, cada uno con sus peculiaridades, servicios diferentes, configuraciones personalizadas, etc. nos vemos más y más inmersos en un problema latente:

• Nuestra carga horaria necesaria para tener todo funcionando es cada vez mayor, ya que por cada servicio en cada servidor, los problemas que aparecen son únicos y muy pocas veces se repiten en otros casos. Esto significa que con casi cualquier problema que surge, el tiempo que tenemos que dedicarle a la investigación y resolución del mismo es tanto como el tiempo que le vamos a tener que dedicarle al siguiente, y así.
• Por más minuciosos que seamos, las soluciones que aplicamos en un servidor hace 1 año serán distintas a las que utilicemos en la implementación de servidores hoy en día, por más que la funcionalidad de ellos sea similar. Día a día pulimos métodos, mejoramos algoritmos, aprendemos nuevas formas de hacer lo mismo que nos ahorran tiempo, y todo eso lo aplicamos a los servicios que tenemos a cargo, pero actualizar esos métodos en servidores donde los tenemos funcionando en alguna manera hoy antigua, es o bien muy costoso o simplemente imposible. En consecuencia: los métodos que utilizamos a través de los años quedan dispersos en la línea temporal que forman los equipos generados por nosotros.
• ¿Y que me cuentan de la gestión de software? Habíamos visto que parte de nuestras tareas era la de mantener actualizado el software instalado en los equipos. Si bien hay administradores que tienen como política la frase “Si funciona, no lo toques”, yo creo que si la distribución te ofrece la estabilidad y confianza suficientes como para saber que las actualizaciones de seguridad no te van a romper nada, el actualizar es una necesidad, no sólo en los servidores expuestos a redes públicas como Internet. ¿Qué pasa cuando tenemos que actualizar 10 servidores? ¿Y cuando son 100? ¿Qué pasa cuando tenemos que instalar un nuevo software en 10, 50, o 100 servidores? Nos arremangamos, respiramos hondo, y o bien planeamos los siguientes 2 meses implementando el mismo software una y otra vez, o descartamos nuestros preciados fines de semana para acelerar el paso. De más está decir que si en vez de servidores hablamos de estaciones de trabajo…se complica un poquito más la cosa.
• A medida que la infraestructura aumenta de tamaño, vamos necesitando gente que nos ayude. Si las políticas administrativas no están estandarizadas de alguna manera, lo único que haremos es sumar un ancla más sobre nuestro pescuezo, ya que las nuevas personas tendrán sus propios criterios y formas de hacer las cosas, multiplicando la variedad en la que los problemas son solucionados y por lo tanto, haciendo cada vez más necesaria gente altamente capacitada para el mantenimiento. De más está decir que es difícil conseguir gente con mucha experiencia que esté interesada en mantener un verdadero caos, ¡ellos tienen mejores cosas que hacer de su vida, y vos también deberías!

En mi haber tengo casi 10 años de experiencia en la administración de servidores, y esto sólo lo digo para recalcar el hecho que las problemáticas arriba expresadas sólo se hicieron evidentes cuando ya era tarde, cuando tenía encima casi 40 servidores, todos configurados artesanalmente y cada uno con sus peculiaridades. Ni yo me acuerdo de todos los detalles que hay ocultos en cada servicio que todas esas máquinas dieron. Si alguien me hubiera advertido, es probable que haya empezado a planear una estandarización temprana que me hubieran permitido administrar 400 servidores sin mayores problemas.

Aquí es cuando entra Puppet al rescate, ésta es una herramienta que nos ayuda solucionar los problemas antes mencionados. Puppet tiene varios componentes, entre ellos se encuentra el servidor, que distribuye las recetas que los clientes deben aplicar en cada servidor. Y ya que hablamos de recetas, éstas están escritas en un lenguaje declarativo, es decir, un lenguaje que expresa el estado de cómo debería estar el servidor, sin caer en una receta paso a paso para llegar a ese estado. Una receta en Puppet se refiere entonces a recursos, y su estado en el equpo, como por ejemplo: el paquete vim debe estar instalado y debe ser el editor por defecto, entonces Puppet se encarga que esto sea aplicado, ya sea en un Debian, un Redhat, Ubuntu o SuSE, nosotros nos olvidamos de los detalles menores.

Este alto nivel de expresión nos permite escribir recetas que luego podemos compartir con otros colegas, tal cual el software libre! esto es algo que muy pocas veces se ha hecho ya que las herramientas que los administradores de sistemas realizamos son normalmente muy ad hoc, poco portables a otros entornos.

Entre los recursos que Puppet nos permite administrar, están los paquetes de software, archivos y directorios, usuarios, tareas de cron, etc. y además como la herramienta está escrita en el lenguaje Ruby, es fácilmente extensible para agregar nuevos recursos.

El caso ideal luego de haber aprendido esta herramienta, sería que con cada servidor nuevo, lo único que haya que instalar sea el sistema base, el cliente Puppet, y luego éste se encarga del resto, manteniendo el estado que se expresa en las recetas a rajatabla, chequeando que se cumplan cada tanto, y nosotros mientras tanto pudiendo regresar a casa temprano, olvidandonos que estamos de guardia y que de un momento a otro, el celular podría sonar por algún incendio.

Les dejo disponible los slides de mi charla por si les sirve de algo.