Posts filed under 'Software Libre'
Tener una notebook tiene muchos beneficios, aún cuando la usemos en casa. Poder chequear correo desde la cama es algo impagable. También lo es programar tirado en el sofá, o visitar nuestros sitios web favoritos en la mesa de la cocina.
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.
January 31st, 2008
En Internet, hoy la moda son las redes sociales, y las hay de todos los gustos y colores. Hace unos días llegué a Ohloh, una red social que centra su foco en developers y proyectos de Software Libre y la verdad es que me pareció muy interesante!
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.
November 23rd, 2007
Hace unas semanas estuve en la edición 2007 de CaFeCONF, donde asistí a una muy buena presentación sobre desarrollo de juegos usando Python y Pygame. Afortunadamente los expositores la filmaron y publicaron en Google Video, así que hago mi parte en publicitarla, se las recomiendo!
October 29th, 2007
Hace 2 o 3 años uno de mis amigos me comentó o publicó de alguna manera que no recuerdo, un esquema de colores para configurar el emulador de terminales de texto de tal manera que se asemeje a los viejos monitores Hércules monocromo ámbar. El argumento era que estos monitores tenían un contraste mucho mejor que los actuales para trabajar en pantallas de caracteres y por lo tanto aquellas personas que trabajan muchas horas en un emulador de terminal (por ejemplo, administradores de sistemas UN*X) disfrutarían del descanso visual y del recuerdo de aquellas viejas buenas épocas usando colores similares.
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 
October 16th, 2007
El viernes pasado tuve la oportunidad de participar como orador en las 6tas Conferencias Abiertas de Software Libre de Capital Federal, organizadas por CaFeLUG, y lo que me permitieron exponer en esta ocasión es una herramienta que vengo mirando de hace relativamente poco tiempo, pero que me interesa muchísimo: Puppet.
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.
October 11th, 2007
Previous Posts
