« Septiembre 2006 | Bitácora principal | Noviembre 2006 »

Cuernos del Paine

| Comentarios (0)

Hoy, dándome unos minutos de descanso, he revisado algunas fotografías de las muchas que aún tengo sin clasificar adecuadamente. Me encontré con una que me encanta. Es una fotografía tomada el 20 de septiembre de 2002, cuando fuimos con Tatiana al «Parque Nacional Torres del Paine». El invierno comenzaba a desperdirse, no habían muchos visitantes y fuimos de los primeros en la temporada en acampar en lugares que no fueran los refugios. Bastante tranquilidad por cierto, sobre todo en lugares conocidos por atocharse la gente (Valle del francés y en el lago Pehoé).

El paso Gardner —también conocido como el paso «perros»— estaba cerrado aún (fines de invierno), así que hicimos el circuito conocido como la «W», en dirección hacia «Las Torres», bordeando el lago Nordenskjöld para pasar al «Valle del Francés», refugio Peohé, glaciar Grey y regresar por las «Carretas» hasta llegar a la administración.

Cuernos del Paine

Esta foto me encanta porque Tatiana se ve muy contenta, después de varios días donde ya habíamos caminado decenas de kilómetros.

Con Ubuntu Edgy dejarán de existir núcleos específicos para cada procesador, sea 386, 686, k7, 686-smp, etc. Tal vez sea un duro golpe para aquellos que les excita compilar el núcleo para ganar un 1% más de rendimiento y que logran «sentir» la diferencia entre núcleo compilado y uno de paquete.

La razón es simple: midieron y determinaron que la diferencia en el tiempo de respuesta no es significativo para justificar tener núcleos separado. Cuando mucho, 1% de diferencia. Siendo así, la percepción del usuario no cambia, pero permite focalizar mejor el trabajo de los mantenedores de estos paquetes, reducir el espacio requeridos por los espejos y mejorar el uso de ancho de banda. También debiera mejorar el proceso de instalación y reconocimiento de hardware, porque será el mismo independiente de la arquitectura.

Había notado la diferencia, pero fue a través de un mensaje de David Megginson que me enteré del hilo de la discusión en donde se tomó la decisión.

Invitaciones

| Comentarios (2)

Al parecer octubre y noviembre son meses donde se celebran congresos y muestras. He recibido varias invitaciones para ir a exponer sobre desarrollo, GNOME, Software Libre y experiencias personales en todas las anteriores. Me alegra que la mayoría de ellas sean en nuestra región, porque eso muestra vida :-)

No puedo asistir a todas, así que debo decidir de acuerdo a las actividades que tengo pendientes más los permisos que consiga para ausentarme de mi trabajo. A una de ellas, definitivamente no puedo, me queda revisar el resto.

Hay dos de ellas que me han invitado para «equilibrar» los temas y no sea cargado al sistema operativo de la competencia. Me halaga que me hayan considerado, pero no sé si será muy atractivo, por cuanto no sé la asistencia estará realmente interesado en lo que uno pueda decir o mostrar, sino en otras cosas.

Uno de ellos coincide con el «Encuentro Linux, pero como no iré este año, no afecta.

Chiches nuevos

| Comentarios (3)

Hoy llegó Mónica desde Canadá convertida en Dra. Caniupán. Me trajo unos algunos chiches para la cámara fotográfica, y que de a poco iré probando.

  • Un disparador remoto (RS60-E3)
  • Una empuñadura vertical que permite disponer de 2 baterías (BG-E3)
  • Un lente EF 75-300mm 4-5.6 III USM
  • Un lente EF 50mm 1.8 II

El disparador remoto es muy útil, sobre todo cuando se ha utilizado antes. Mi idea es poder utilizarlo en fotografías de larga exposición sin correr el riesgo de mover la cámara. Con mi cámara SLR antigua (Canon EOS 5 / A2E) usaba una, pero lamentablemente no es compatible con la Canon 350D y el adaptador vale más caro que el un disparador nuevo.

Nunca antes he tenido una empuñadura vertical y cuesta acostumbrarse en un inicio. Pero de a poco se va sintiendo más cómodo, además que le da mayor estabilidad a la cámara. Lamentablemente no tenían uno de marca «Opteka» (más barato e igual de bueno que el Canon).

El lente 75-300mm a pesar de ser USM, se siente lento para enfocar. Pero puede ser porque lo he probado de noche y hay poca luz. Así que en la mañana, con luz natural, poder probarlo de mejor forma. Con la Canon EOS 5 usaba un lente Sigma 100-300mm, pero que tenía un modo de macro que funcionaba muy bien a distancias cortas. Lamentablemente, ese lente no es compatible con la Canon 350D.

En el último instante estuve a punto de arrepentirme de pedir el lente EF 50m. De hecho, originalmente nunca lo tuve contemplado. Pero cuando busqué por lentes, siempre se hacía mención a este lente como un «must have» (lo debes tener). Buen lente, buena apertura a un buen precio. Y la verdad es que estoy muy contento con el lente, a pesar que sólo lo tengo por un par de horas.

Como tiene una apertura de 1.8, es posible obtener buenas velocidades con poca luz (no me gusta usar flash). Además, con poca profundidad de campo permite concentrarse en el sujeto de la imagen, dejando el resto borroso. A continuación algunas fotos que tome esta noche:

Tatiana Gutiérrez
Tatiana, al fondo Alfredo Muñoz.

Mónica Caniupán
La Dra. Mónica Canipuán

Almendra
Almendra, cachorra de 6 meses. En esta foto había mucho menos luz, sólo un par de lámparas con pantalla

Aún así, mi problema sigue siendo que no dispongo de mucho disco duro, y en cierta forma, provoca que sea más recatado a la hora de tomar fotografías.

Ya que he mencionado la cámara EOS 5 (A2E en EEUU), aprovecho señalar una característica que me gustaba mucho, y que a pesar de ser un modelo antiguo a estas alturas de la vida, es muy confortable. La cámara permitía elegir el punto de enfoque con la vista. Bastaba mirar el punto a enfocar, presionar levemente el botón de disparo y enfocaba. Esa experiencia hace que elegir el punto de enfoque manualmente se sienta aún más lento.

Por otro lado, espero el día 11 de noviembre, para poder conversar con Alvaro Herrera, con quien no he podido coincidir en congresos y/o charlas este año. Hace poco se compró una cámara, lo que abre un nuevo tema de conversación.

Existen diversos programas para control de versiones, algunos centralizados (como CVS, SVN, etc.), otros descentralizados (git, bazaar, darcs, arch, etc.)

El esquema tradicionalmente usado es el modelo centralizado, en donde hay un repositorio en un servidor central contra el cual todos trabajan. Es el modelo que sigue GNOME. Cuando se ha usado por años, da la impresión que es la forma de trabajar.

No me referiré, sin embargo, al uso en proyectos grandes. Sino más bien al uso personal, ya sea para mantener bajo control los cambios realizados a distintos documentos, programas, páginas web, etc. En esta situación, es incómodo pensar en un servidor central. ¿Qué sucede si estoy desconectado y quiero realizar cambios? ¿O quiero volver hacia atrás? O simplemente, si quiero comenzar un nuevo repositorio.

En estos casos es muy útil contar con sistema de control de versiones distribuidos, no por el hecho de ser distribuida, sino porque no depende de un servidor central. Cualquiera podría llegar a serlo. De las alternativas, la que me gusta más es Mercurial. Es rápido, ocupa relativamente poco espacio y es fácil de usar. Bueno, hay más pero no quiero extenderme. Al final de este mensaje menciono varias lugares donde obtener más información.

En Debian o Ubuntu la instalación es fácil, y está disponible la última versión estable.

$ sudo apt-get install mercurial

Pero instalarlo en forma local es muy sencillo. Es 95% Python y 5% C (para las partes que se requiere eficiencia).

Un uso común: dispongo de un proyecto pequeño y deseo comenzar a controlar los cambios sin necesidad de inundarme de directorios proyeco-1, proyecto-2, proyecto-3, proyect-4-este-si-que-si, proyecto-final, proyecto-final-2, etc.

$ cd proyecto
$ hg init
$ hg add archivo1 archivo2 archivo3 archivo4 ...
$ hg commit

Todo el historial quedará almacenado en un subdirectorio llamado .hg. Luego, se puede trabajar y añadir los cambios que se deseen y aplicarlos con commit.

Para partir una nueva rama de trabajo, entonces basta obtener una copia y trabajar en ella.

$ hg clone proyecto proyecto-bar

Si además, converso con un amigo que quiere ayudar. Bueno, es posible habilitar un servidor web y que tome los cambios desde allí:

$ hg serve

La otra persona podrá obtener una copia de mi repositorio fácilmente con:

$ hg clone http://ip.de.mi.equipo:8000/

Con eso obtendrá una copia completa del proyecto, incluyendo el historial de cambios. Incluso, en el futuro podrá «traer» los cambios desde el repositorio y examinar la evolución del proyecto en el otro equipo, para ello basta ejecutar:

$ hg pull

Además, posee un visor de cambios similar al que cuenta con git. Basta invocarlo con:

$ hg view

Para cambiar de versiones de trabajo, basta ejecutar:

$ hg update 

Donde id corresponde al identificador de cambios (en estricto rigor de un conjunto de cambios). Así es posible ir hacia adelante, hacia atrás de forma muy rápida. id se obtiene con el mismo visor o bien a través de:

$ hg log

Lo mejor de todos, es que si uno desea realizar pruebas de comandos sin dañar un proyecto en curso, se crea un repositorio nuevo o se puede sacar una copia de alguno existente. Es rápido y fácil. Por otro lado, la interfaz web permite muchas más cosas, como exportar un los cambios en formato RSS, o entregar una copia al vuelo en tar.gz, zip o tar.bz2.

Rafael Villar Burke (pachi) ha escrito artículos sobre mercurial, que explica muy bien, desde los conceptos básicos hasta el trabajo diario. En el sitio de Mercurial también hay suficiente documentación, como la guía guía rápida es muy buena para los impacientes. También hay tutoriales traducido a varios idiomas.

Para mí es útil, porque puedo trabajar en varios equipos (computadores). Antiguamente usaba rsync para todas esas operaciones, pero requería acordarme en cual fue el último donde trabaje. Si cometía un error, perdía los cambios. Ahora no.

Canes en el agua

| Comentarios (0)

Una de las caraterísticas que me gusta de los Golden Retriever, es la facilidad con que se meten al agua. Ayer en Flickr, Tatiana encontró una fotos y videos que muestran lo fácil que les resulta.

La primera foto captura bien el momento, cuando el can salta en busca de la presa.

Piscinazo

Lo que resulta impresionante, al menos yo no lo había visto antes, es un perro buceando en busca de su juguete. Aunque la calidad de la foto no es la mejor, lo importante es el motivo. De hecho, la imagen corresponde a un cuadro del video.

Un golden retriever buceando

Para ver los videos del cuceo canino desde Linux es necesario descargar los videos originales, que se encuentran en Quicktime. También es posible verlo utilizando la versión beta de Flash 9, para quien quiera aventurarse a instalarlo.

Grandes pensadores

| Comentarios (1)

Almendra ¿pensando?

La foto fue tomada por Tatiana en la semana que nos inundamos. Yo la encuadré y le dejé en blanco y negro. La imagen original se encuentra en Flickr.