Para citar (traducido) del post de felipec en su blog:

Después de un poco más de dos años de desarrollo, realmente nos orgullece anunciar la primera versión estable de msn-pecan. El proyecto comenzó como un “bifurcación” del protocolo msn de libpurple (lea más abajo por qué no es realmente un bifurcación) pero ha crecido y pronto será una librería por sí misma, también con soporte para Telepathy.

Aunque puse sólo 3 de los 1009 parches y que no entiendo nada del código en sí, debo admitir que me siento parte del projecto.

Hace 7 años inicié un proyecto para escribir un cliente de MSN Messenger para Linux, en modo texto, basado en ncurses. El proyecto aún está registrado en Sourceforge como msnclient. Fue mi primer intento de escribir software libre. Sin embargo, el reto fue demasiado grande y el proyecto rápidamente se murió. Nunca llegué más allá de simplemente iniciar sesión y enviar mensajes de una sola palabra a otro contacto.

Eventualmente aprendí a usar Pidgin y conseguí buen hardware y la necesidad de un cliente personalizado de MSN ya no existía. Aún así creo que msnclient es un buen concepto para ser realizado. Tal vez algún día sea una interfaz basada en las funciones de msn-pecan.

Dicho eso, a mediados de 2009, cuando comencé a aprender Git, felipec me proveyó una rama de su repositorio para probar las conexiones directas (mejor conocidas como “transferencias rápidas” o “transferencias p2p”). No funcionaron en ese entonces.

6 meses y muchos commits sobre su master después: 0.1.0-rc1 salió y directconn aún no funcionaba pero la rama dc-test era ya muy vieja. Había aprendido más sobre Git y creí que era lo suficientemente mejor como para intentar corregir el problema de las conexiones directas. Sin embargo no sabía nada de la funcionalidad de MSN ni del código. Al menos sabía cuál era el primer paso: fuera lo que fuere había que hacer un rebase del código. Así que intenté rebasarlo para que las correcciones de la rama dc-test funcionaran bajo la nueva base de código; al menos sería útil para los desarrolladores. Así que la guerra estaba perdida para mí, pero tal vez felipec se podría motivar lo suficiente para continuar trabajando sobre esta parte de msn-pecan (pero se supone que uno no dice eso, cierto?). Así fue como ví las cosas y obtuve la motivación de hacerlo. Además, sería mi primer git rebase en el mundo real.

El principal problema fue que felipec había hecho muchos cambios de reorganización, renombrado y división de código en julio (algunos bien otros mal). Con un poco de experiencia en C, logré hacer el rebase y lo envié como un par de parches.

De repente felipec continuó trabajando arduamente sobre directconn. No sé si fueron los parches o no; eso es lo de menos. Lo importante es que en msn-pecan 0.1.0, las conexiones directas ya funcionan y de manera estable. Aunque no en todos los casos, es un gran avance.

Ahora creo que fue más allá de aprender a hacer un rebase: Realmente aprendí a contribuir usando Git, tal cual lo hacen los niños grandes en el proyecto del Kernel Linux. Aún no entiendo el código ni el funcionamiento interno del proyecto, pero esos dos parches me permitieron aprender mucho sobre colaboración y revisión de software. Esto fue particularmente útil para Superkb que también está hecho en C y su código fuente está manejado en Git.

Así que, gracias nuevamente, felipec, felicidades y todos deberíamos tomarnos un trago por el proyecto, aunque estemos en diferentes partes del mundo. ¡A tirar fiesta y correr la voz!

Por azares del destino encontré que Google ya tiene una pizca de Tijuana lista en el Street View de Google Maps.

Al parecer alguien vio el carro en junio de 2009, se la pasó a algún amigo y éste lo blogueó! :-O

Actualización 1: La mejor foto que publicaron los de tijuanayo.com es la del vehículo de Google siendo cuestionado por la policía.

Actualización 2: También en tijuanayo.com observaron que ya está en línea e hicieron un post al respecto.

Grandioso ¿no? Ojalá pronto podamos tener el resto de los servicios. Particularmente, saber cómo llegar de A a B con optimizaciones, como en San Diego, pero específicas a la localidad. Estas son las optimizaciones que me imagino en Google Maps para Tijuana:

• Usar sólo transporte público
• Usar sólo automóvil
• Evitar boulevares y aprovechar vías rápidas
• Evitar tráfico (en tiempo real)
• Evitar baches y charcos (en tiempo real)
• Evitar balaceras (en tiempo real)
• Parar por una gasolinera non-rata (en tiempo real?)
• Evitar el tren (en tiempo real)

:-)

Por el momento está sólo en inglés. Realmente tengo en la mira poner el equivalente en español.

Con esto será mucho más fácil mantener la documentación al día.

El Wiki de SourceForge no admite ediciones anónimas, así que es necesario contar con una cuenta de SourceForge para poder incluir a las personas en el grupo de edición.

Las sugerencias y contribuciones son bienvenidas.

auto br0
iface br0 net dhcp
   bridge_ports eth0 eth1
   bridge_stp off
   bridge_fd 3

Lo que me impedía hacerlo era que uso algunas extensiones de GNU, BSD o POSIX que no se encuentran en el estándar C.

Yo no sabía, pero basta con añadir la línea

#define _GNU_SOURCE

o, según el caso,

#define _POSIX_C_SOURCE 2

al principio del código fuente y glibc reconoce y habilita las funciones que hagan falta.

Esto es un paso hacia adelante, pues ahora ya puedo usar un simple “grep” para ver en qué archivos están “solicitando extensiones”.

Desafortunadamente aún falta bastante para llegar al ideal, pues sigo atado a las herramientas de GNU. Por ejemplo ¿qué pasa si trato de compilar sobre OpenSolaris? La última vez que lo intenté, resultó que el Makefile usa extensiones que dependen de gmake (una de ellas es el include no fatal). Pero si hubiera gmake, ¿compilaría?

Sólo hay una manera de saberlo… ;-)

[Sun Dec 20 14:37:42 -0800 -- alvarezp@octavio:~/patch-test]
$ ls -l
total 24
-rw-r--r-- 1 alvarezp alvarezp 7127 Dec 20 14:37 slpcall.bak
-rw-r--r-- 1 alvarezp alvarezp 7127 Dec 20 14:37 slpcall.c
-rw-r--r-- 1 alvarezp alvarezp 7232 Dec 20 14:37 slpcall.c.2

[Sun Dec 20 14:37:43 -0800 -- alvarezp@octavio:~/patch-test]
$ diff -u slpcall.c slpcall.c.2 > p

[Sun Dec 20 14:37:57 -0800 -- alvarezp@octavio:~/patch-test]
$ cat p
--- slpcall.c	2009-12-20 14:37:36.000000000 -0800
+++ slpcall.c.2	2009-12-20 14:37:36.000000000 -0800
@@ -66,6 +66,11 @@

 	slpcall->slplink = slplink;

+	slpcall->wait_for_socket = FALSE;
+	slpcall->xfer = NULL;
+	slpcall->dc = NULL;
+	slpcall->branch = NULL;
+
 	msn_slplink_add_slpcall(slplink, slpcall);

 	slpcall->timer = purple_timeout_add_seconds(MSN_SLPCALL_TIMEOUT, msn_slpcall_timeout, slpcall);

[Sun Dec 20 14:38:00 -0800 -- alvarezp@octavio:~/patch-test]
$ diff -u slpcall.bak slpcall.c # .bak is a backup of original

[Sun Dec 20 14:38:19 -0800 -- alvarezp@octavio:~/patch-test]
$ patch < p
patching file slpcall.c

Hasta aquí, todo bien.

[Sun Dec 20 14:38:53 -0800 -- alvarezp@octavio:~/patch-test]
$ cp slpcall.bak slpcall.c

[Sun Dec 20 14:39:02 -0800 -- alvarezp@octavio:~/patch-test]
$ mkdir x

[Sun Dec 20 14:39:04 -0800 -- alvarezp@octavio:~/patch-test]
$ mv slpcall* x/

[Sun Dec 20 14:39:06 -0800 -- alvarezp@octavio:~/patch-test]
$ ls -l
total 8
-rw-r--r-- 1 alvarezp alvarezp  410 Dec 20 14:37 p
drwxr-xr-x 2 alvarezp alvarezp 4096 Dec 20 14:39 x

[Sun Dec 20 14:39:08 -0800 -- alvarezp@octavio:~/patch-test]
$ diff -u x/slpcall.c x/slpcall.c.2 > px

[Sun Dec 20 14:39:20 -0800 -- alvarezp@octavio:~/patch-test]
$ cat px
--- x/slpcall.c	2009-12-20 14:39:02.000000000 -0800
+++ x/slpcall.c.2	2009-12-20 14:37:36.000000000 -0800
@@ -66,6 +66,11 @@

 	slpcall->slplink = slplink;

+	slpcall->wait_for_socket = FALSE;
+	slpcall->xfer = NULL;
+	slpcall->dc = NULL;
+	slpcall->branch = NULL;
+
 	msn_slplink_add_slpcall(slplink, slpcall);

 	slpcall->timer = purple_timeout_add_seconds(MSN_SLPCALL_TIMEOUT, msn_slpcall_timeout, slpcall);

[Sun Dec 20 14:39:22 -0800 -- alvarezp@octavio:~/patch-test]
$ patch < px
patching file slpcall.c.2
Hunk #1 FAILED at 66.
1 out of 1 hunk FAILED -- saving rejects to file slpcall.c.2.rej

¿La solución?

patch -p0 < px

Una regla de etiqueta en Internet muy ignorada es la del citado de mensajes al contestar un correo electrónico.

Al hablar de “citado” me refiero a la inclusión de un mensaje anterior dentro de uno nuevo (una respuesta, por ejemplo) con el objetivo de mantener la relevancia de la respuesta dentro del contexto original. Es decir, le diría a alguien: “Javier, no sé de qué hablas. La próxima vez cita en tu respuesta el mensaje original para saber a qué estás contestando.”

Prácticamente todos los clientes de correo electrónico citan el mensaje que es objeto de respuesta, al menos por defecto. Eso es bueno y contribuye con la etiqueta, pero ha desencadenado un abuso de esta regla que la vuelve totalmente inútil.

Al decir que la regla es “ignorada”, me refiero a que el usuario común no edita el texto citado por el cliente de correo. Deja que su programa cite el mensaje original ignorando el texto resultante. Después de 3 iteraciones de respuesta, el “mensaje original” contiene más basura que contenido relevante.

Y los clientes de correo electrónico —como Outlook y Thunderbird— tampoco ayudan; son demasiado tontos. Citan lo que se encuentran. Si bien, el propósito es dejarte el mensaje original listo para su *edición* durante la respuesta, lo cierto es que incluyen hasta las firmas y los legales odiosos.

Bien, más allá de la queja, el propósito de este artículo es mostrar las técnicas de citado y respuesta existentes, pero sobre todo, expresar mi añoranza por un estilo que usaba hace 15 años, incluso antes de la proliferación de Internet en esta ciudad.

La etiqueta bien aplicada a una respuesta o forward de correo electrónico permite un mensaje relativamente organizado y se compone de dos elementos: (a) la correcta colocación de la respuesta en relación al mensaje citado y (b) la correcta edición del mensaje citado.

Colocación de la respuesta en relación al mensaje citado

La mejor manera de explicar lo que es, es mencionando los tres diferentes estilos y la diferencia entre ellos: publicación superior (top-posting), inferior (bottom-posting) e intercalado (interposting or inline-posting). Corresponde a colocar la respuesta arriba del mensaje original, abajo, o intercalando las respuestas a los diferentes temas del texto.

Ejemplo A: publicación superior (top-posting)

Sí y la voy a realizar yo.

El Vie, 26 Jun 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> dijo:
> Octavio:
>
> El mantenimiento es la madrugada del próximo jueves?
>
> Quién la va a realizar?
>
> Saludos.
>
> ---
> Hitsuo Tikashi.
> Coord. de Servicios de Infraestructura.
> Sistemas Integrados.
> T. +52 (664) 555-1234
> E. hitsuo.tikashi@sistint.com.mx

Ejemplo B: publicación inferior (bottom-posting)

El Vie, 26 Jun 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> dijo:
> Octavio:
>
> El mantenimiento es la madrugada del próximo jueves?
>
> Quién la va a realizar?
>
> Saludos.
>
> ---
> Hitsuo Tikashi.
> Coord. de Servicios de Infraestructura.
> Sistemas Integrados.
> T. +52 (664) 555-1234
> E. hitsuo.tikashi@sistint.com.mx

Sí y la voy a realizar yo.

Ejemplo C: respuestas intercaladas (inline-posting)

El Vie, 26 Jun 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> dijo:
> Octavio:
>
> El mantenimiento es la madrugada del próximo jueves?

Sí.

>
> Quién la va a realizar?

Yo.

> Saludos.
>
> ---
> Hitsuo Tikashi.
> Coord. de Servicios de Infraestructura.
> Sistemas Integrados.
> T. +52 (664) 555-1234
> E. hitsuo.tikashi@sistint.com.mx

¿Cuál consideran que es mejor? La respuesta puede variar según el entorno, pues tienen pros y contras. ¿Cuáles consideras que son los pros y contras de cada uno?

En las listas de correo, por ejemplo, el escrito superior está más que prohibido, a favor del escrito inferior (o mejor aún, el intercalado). Este se ha venido manejando incluso desde antes de la existencia del “correo electrónico” como se conoce hoy en día.

Sin embargo, en los negocios y el uso común, lo más popular es el estilo “superior”, debido a que es más fácil “escribir y mandar” sin preocuparse por más; esto ha llevado a que los clientes de correo electrónico más populares vengan preconfigurados de esa manera, lo que a su vez lo populariza aún más.

Correcta edición del mensaje citado

El ejemplo anterior de mensaje intercalado deja al descubierto la inutilidad de una gran parte del texto de respuesta. Se considera que el texto citado forma parte de la respuesta, pues pertenece al mismo mensaje y ocupa espacio en disco como parte de la misma.

Tomaré el ejemplo de intercalado expuesto arriba como caso de análisis, pero esto aplica a cualquiera de los tres estilos de colocación de respuesta.

A partir de la palabra “saludos” es texto irrelevante (y por ende, inútil). Tal vez podríamos argumentar que la línea “Octavio:” también es texto irrelevante, pero no seamos tan quisquillosos en este momento. En números, son inútiles 8 de 21 líneas (38%); 25 de 59 palabras (42%); 161 de 373 caracteres (43%). Hay que considerar que falta mi propia firma, lo cual disminuirá ligeramente estos porcentajes.

Ejemplo D: Correcto citado en publicación superior

Sí y lo voy a realizar yo.

El Vie, 26 Jun 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> dijo:
> Octavio:
>
> El mantenimiento es la madrugada del próximo jueves?
>
> Quién la va a realizar?
>

Ejemplo E: Correcto citado en publicación inferior

El Vie, 26 Jun 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> dijo:
> Octavio:
>
> El mantenimiento es la madrugada del próximo jueves?
>
> Quién la va a realizar?
>

Sí y lo voy a realizar yo.

Ejemplo F: Correcto citado en publicación intercalada.

El Vie, 26 Jun 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> dijo:
> Octavio:
>
> El mantenimiento es la madrugada del próximo jueves?

Sí.

> Quién la va a realizar?

Yo.

El argumento principal para no editar el texto podría ser que es muy ineficiente y tardado hacerlo. Lo que en mi barrio le llamamos “hueva”.

Este será el argumento que den aquellas personas que no conozcan los atajos de teclado para edición, en particular el uso de la tecla Shift como un estándar no escrito para marcar texto. Usando Shift y las flechas seguido de la tecla “Delete”, es sumamente fácil marcar y eliminar texto inútil.

Añorando Blue Wave y FidoNet

Antes de tocar el tema de las interfaces de usuario y los dispositivos móviles, me tomaré un momento para externar mi más sincera añoranza por los tiempos en los que escribía en FidoNet, antes de la presencia popular de Internet en Tijuana (1994 a 1996).

En FidoNet, la costumbre era un tanto distinta. En ese entonces usaba un shareware popular llamado Blue Wave Offline Reader. Muchos usábamos Blue Wave, que tenía un estilo especial de preparar el citado antes de enviarlo a edición:

El Vie, 26 Jun 2009 17:42:34 -0700, Hitsuo Tikashi dijo:
 HT> Octavio:
 HT>
 HT> El mantenimiento es la madrugada del próximo jueves?
 HT>
 HT> Quién la va a realizar?
 HT>
 HT> Saludos.
 HT>
 HT> ---
 HT> Hitsuo Tikashi.
 HT> Coord. de Servicios de Infraestructura.
 HT> Sistemas Integrados.
 HT> T. +52 (664) 555-1234
 HT> E. hitsuo.tikashi@sistint.com.mx

Lo interesante no está en el intercalado, pues entonces como hoy, con un par de Enters tenía una respuesta intercalada.

Y para borrar a partir de “Saludos”, tal como hoy: me coloco en la letra “S” de “Saludos” y en dos pasos: Shift+Ctrl+End, Delete, y listo: mensaje limpio.

Y entonces yo contestaba:

El Vie, 26 Jun 2009 17:42:34 -0700, Hitsuo Tikashi dijo:
 HT> Octavio:
 HT>
 HT> El mantenimiento es la madrugada del próximo jueves?

 Así es. Aunque el mantenimiento no está considerado de carácter crítico,
 en caso de posible falla afectaremos los acuerdos de nivel de servicio,
 pues hace menos de 30 días hubo otra falla por parte de nuestros
 proveedores.

 HT> Quién la va a realizar?

 Yo.

Lo realmente interesante es que cuando el susodicho remitente intentara contracontestar mi respuesta, el texto era automáticamente ajustado a la longitud de la línea y citado de la siguiente manera:

El Vie, 26 Jun 2009 17:42:34 -0700, Octavio Alvarez dijo:
 HT> Octavio:
 HT>
 HT> El mantenimiento es la madrugada del próximo jueves?
 OA>
 OA> Así es. Aunque el mantenimiento no está considerado de carácter
 OA> crítico, en caso de posible falla afectaremos los acuerdos de
 OA> nivel de servicio, pues hace menos de 30 días hubo otra falla por
 OA> parte de nuestros proveedores.

 Enterado. Te encargo el changarro y mantenme informado.

 HT> Quién la va a realizar?
 OA>
 OA> Yo.

 ¿Quién estará monitoreando los servicio al siguiente día?

En el ejemplo, el usuario ya intercaló su respuesta hacia mí.

Puede apreciarse cómo las líneas del texto no corresponden a las líneas originales: fueron modificadas inteligentemente, siendo consideradas como un párrafo y ajustadas para mantener un bloque sólido y consistente de texto.

Puede verse cómo el texto es sumamente claro y fácil de seguir; aún más, si el lector y el editor se encargaban de poner en diferentes colores a los diferentes autores.

Este estilo, además de ordenado es escalable. Después de múltiples iteraciones, el texto y el formato se mantienen en orden.

El Vie, 26 Jun 2009 17:42:34 -0700, Octavio Alvarez dijo:
 HT> Octavio:
 HT>
 HT> El mantenimiento es la madrugada del próximo jueves?
 OA>
 OA> Así es. Aunque el mantenimiento no está considerado de carácter
 OA> crítico, en caso de posible falla afectaremos los acuerdos de
 OA> nivel de servicio, pues hace menos de 30 días hubo otra falla por
 OA> parte de nuestros proveedores.
 HT>
 HT> Enterado. Te encargo el changarro y mantenme informado.
 OA>
 OA> Ok. Le enviaré un mensaje a su celular, según el procedimiento.

 Y además mándamelo por correo, por favor.

 HT> Quién la va a realizar?
 OA>
 OA> Yo.
 HT>
 HT> ¿Quién estará monitoreando los servicio al siguiente día?
 OA>
 OA> Estará el compañero nuevo, pero ya hablé con los demás para que
 OA> estén al pendiente de caulqueir eventualidad.

 ¿Ya intercambiaron números de teléfono?

Desde mi punto de vista esto es mucho más inteligente que su popularizada contraparte:

El Lun, 29 Jun 2009 17:42:34 -0700, Octavio Alvarez <alvarezp@alvarezp.ods.org> dijo:
> El Dom, 28 Jun 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> dijo:
> > El Sab, 27 Jun 2009 17:42:34 -0700, Octavio Alvarez <alvarezp@alvarezp.ods.org> dijo:
> > > El Vie, 26 Jun 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> dijo:
> > > > Octavio:
> > > >
> > > > El mantenimiento es la madrugada del próximo jueves?
> > >
> > > Así es. Aunque el mantenimiento no está considerado de carácter
> > > crítico, en caso de posible falla afectaremos los acuerdos de
> > > nivel de servicio, pues hace menos de 30 días hubo otra falla por
> > > parte de nuestros proveedores.
> >
> > Enterado. Te encargo el changarro y mantenme informado.
>
> Ok. Le enviaré un mensaje a su celular, según el procedimiento.

Y además mándamelo por correo, por favor.

> > > > Quién la va a realizar?
> > >
> > > Yo.
> >
> > ¿Quién estará monitoreando los servicio al siguiente día?
>
> Estará el compañero nuevo, pero ya hablé con los demás para que estén
> al pendiente de caulqueir eventualidad.

¿Ya intercambiaron números de teléfono?

Esto es lo mejor que un mensaje de correo electrónico puede dar. No está tan mal, asumiendo que el autor haya seguido la etiqueta.

De no ser así, nos encontramos con:

• Prefijos de cita como el siguiente: > >> > >>> >
• Líneas partidas por exceder una cierta longitud.
• Mensajes citados en su totalidad, incluyendo párrafos irrelevantes.
• Mensajes llenos de firmas y bloques de textos de información legal (a veces en dos idiomas por mensaje).

Aunque mejor que lo que se ve día a día, dista mucho de la comodidad de trabajar con el estilo de Blue Wave / FidoNet.

De interfaces de usuario

Los clientes de correo electrónico son realmente deficientes en promover la cultura de la etiqueta en el correo electrónico.

Considero que podría existir un mecanismo en los clientes de correo electrónico para detectar la firma del remitente y excluirla del mensaje citado. Esto ahorraría que después de tres respuestas, la respuesta contuviera tres copias del mismo rollo:

> ---
> Hitsuo Tikashi.
> Coord. de Servicios de Infraestructura.
> Sistemas Integrados.
> T. +52 (664) 555-1234
> E. hitsuo.tikashi@sistint.com.mx
>
> El contenido de este mensaje de correo, así como sus anexos pueden ser
> confidenciales y estar protegidos por derechos de autor. Están dirigidos
> única y exclusivamente para uso de el (los) destinatario(s). Si Usted
> lo ha recibido por error debe destruirlo de su sistema. No se permite
> copiar, ni imprimir, ni distribuir este correo o sus anexos, ni usarlos
> para propósito alguno ni dar a conocer su contenido a persona alguna.
> La información aquí contenida no necesariamente refleja la opinión
> o postura de [NOMBRE DE LA EMPRESA] ni sus subsidiarias, afiliadas
> o alianzas.
>
> Por favor piense en el planeta antes de imprimir este mensaje.

(Nota: la última línea la he visto en algunos mensajes de correo y la he incluído sólo porque al imaginarme ese llamado a la ecología al lado de ese derroche de energía eléctrica y espacio en disco que suele estar en HTML, no puedo evitar contener mi deficiente sentido del sarcasmo.)

Los dispositivos móviles

En una pantalla de 160×320 y un teclado miniatura uno podría argumentar que es difícil realizar toda esta edición de mensaje de forma práctica. Sin embargo, del mismo modo en el que los dispositivos móviles presentan al usuario interfaces apropiadas para realizar otras tareas, es en la interfaz donde radica la facilidad o dificulad de realizar estas ediciones.

De ser popular el intercalado, un dispositivo móvil contaría con una función para “contestar el siguiente bloque o párrafo” o tal vez para “navegar por párrafo” y escoger “contestar”, “dejar” o “eliminar” cada uno de ellos hasta una opción para “borrar el resto del texto”.

Si la interfaz no lo contiene, es porque el intercalado no fue lo suficientemente popular y hoy en día no se demanda lo suficiente.

Conclusiones

He tratado de mostrar cómo el estilo del ejemplo F es el más ordenado, organizado y escalable de todos, basado en la experiencia previa de Blue Wave y FidoNet.

Personalmente, trato de respetar el estilo que la mayoría de la población utilice en un contexto dado. Es lo mejor. Una persona que contesta con intercalado en una lista donde todos contestan arriba del mensaje original (por ejemplo, en el trabajo) sólo provocaría confusión para todos.

No me queda más que hacer el llamado a quienes participan en grupos de discusión, listas de correo (en especial a los de áreas más técnicas) que al menos entre nosotros mismos sigamos estas reglas de etiqueta:

• Intercalar nuestras respuestas en el mensaje original.
• Eliminar las partes irrelevantes del mensaje citado, en especial firmas y párrafos legales.
• Reacomodar los párrafos que se vuelvan ilegibles.
• Evitar vicios de escritura.
• Apoyar nuestro texto con los emoticones en caso de que pudiera prestarse a confusión.

Gracias por la paciencia de leer hasta aquí.

Para remplazar texto en vim, confirmando cada remplazo, basta con agregar la opción “c” al comando “s”.

Si nuestro comando original era %s/viejo/nuevo/g entonces se usa %s/viejo/nuevo/gc.

Cada posible remplazo se sombrea y vim solicita confirmación con las siguientes opciones:

y = yes, remplazar el texto sombreado.
n = no, ignorar el texto sombreado.
a = all, siempre sí remplazar todo.
l = last, cambiar el actual y terminar.
q = quit, ignorar el actual y terminar.
^E = desplazar el texto hacia adelante (para ver más texto).
^Y = desplazar el texto hacia atrás.

Fuente:
Vim tips: The basics of search and replace

Teclado Microsoft Natural, pintado por Superkb (Cairo, flat_key)

Ha habido mucho trabajo en esta versión y lo más notable es el soporte para pintar el teclado usando Cairo.

Cualquier falla que encuentren, por favor levanten un bug en el sistema de seguimiento de bugs, o bug tracking system. Al levantar un caso de bug, todo queda escrito y no se nos van a olvidar las cosas. Lo más importante es que el caso o bug quedará documentado para evitar que usuarios y desarrollador(es) trabajemos doble.

Por supuesto, lo anterior no quita que podamos platicar y discutir en #superkb en irc.freenode.net.

Quiero agradecer al Grupo de Usuarios de Linux de Tijuana por la retroalimentación sobre Superkb, sobre todo estos últimos días, en particular a:

• IsReal, por el post en su blog y usar Superkb para aprender a hacer paquetes RPM. Si tendremos uno para la 0.20 será gracias a él. Update: Ya tenemos paquete para Fedora Core 12! Gracias, IsReal.
• aduarte, por las eternas recomendaciones.
• biker, por intentar incansablemente de instalarlo por más que le falle. Al ver los errores he podido corregirlos.
• y me faltó juan_arandaalva, por la ayuda con Cairo (que al final resultó ser una tontería).

Bien, los recursos y descargas están donde siempre: en la página de Superkb en este blog y en el sitio oficial.

De cualquier manera, cito todo eso aquí:

• Versión más reciente: 0.20.
• Licencia: GPL v2.
• Página del proyecto: http://superkb.sourceforge.net/
• Proyecto en Sourceforge: http://sourceforge.net/projects/superkb
• Descarga en gz: superkb-0.20.tar.gz
• Descarga en bz2: superkb-0.20.tar.bz2
• Descarga para Fedora Core 12: superkb-0.20-1.fc12.i686.rpm
• Seguimiento de bugs: https://bugs.launchpad.net/superkb
• Descarga desde Git: git clone git://superkb.git.sourceforge.net/gitroot/superkb/superkb superkb-git
• Navegación del historial en Gitweb: http://superkb.git.sourceforge.net/
• Suscripción RSS a liberaciones de archivos: http://sourceforge.net/export/rss2_projfiles.php?group_id=154661

Además de estar presente para escuchar otras pláticas, yo me apunté a una para presentar sobre Git.

El objetivo de la plática era dar a conocer a Git como un sistema distribuído de control de versiones, y tratar de demostrar su funcionamiento con un ejemplo.

Si bien la parte de la plática salió bien y las primeras muestras en proyección funcionaron, la demostración en la maqueta no salió como esperaba.

Fuera de que lo que llevaba como servidor se puso a hacer un fsck a la hora de levantar el lab y que hubo que levantar una red alterna porque los peers no se veían entre ellos, lo que realmente mató la demostración fue que olvidé el asunto de los permisos. Al no tener los usuarios permisos para leer los repositorios unos de otros, la demostración se convirtió en un ejemplo de VCS centralizado.

Realicé varios clones, uno de otro y con otro usuario para cuidar los accesos a la laptop. Para cuando todos clonaron del repositorio compartido, estúpidamente perdí rastro del árbol de repositorios generados. Pero en fin, estaba logrando recuperar camino, cuando…

Debido a que todos clonaron de mi repositorio –que tenía una working copy, es decir, que no era un repositorio bare– cuando quisieron darle git push sólo Alex pudo enviar sus cambios y ocurrió lo que tenía que pasar:

1. Que a los demás les apareció un mensaje sobre las “refs” que rápidamente se resolvió con git pull
2. Una vez realizado el pull, git les comenzó a rechazar el push, debido a que mi copia local estaba “sucia”, es decir, que no correspondía con la última versión del HEAD.

Esto lo he resuelto múltiples veces con git reset --hard pero por algún motivo que desconozco, nunca pensé en forzar mi copia local a la versión actual de HEAD. Y aún si lo hubiera hecho, era demasiado tema para una sola sesión explicar git reset.

Algunos tuvieron conflictos y no pudieron realizar el git pull necesario para preparar el git push. Yo me preguntaba por qué tenían conflictos, y entre las tantas cosas que estaba tratando de resolver simultáneamente, el laboratorio me rebasó.

Afortunadamente, la parte conceptual quedó cubierta, algunos lograron instalar Git y ejecutar algunos de sus comandos.

Yo siento que quedé debiendo, así que he preparado un ejemplo que podrán leer y seguir con toda calma.

Se trata de una serie de acciones realizadas con Git afectando cuatro repositorios para demostrar la naturaleza distribuída de este gran manejador de versiones.

Hagan clic en la imagen para entrar a una tabla con cuatro columnas. Cada columna pertenece a los comandos ejecutados en un repositorio. Verticalmente es una línea de tiempo.

Si ustedes siguen todo el laboratorio en orden, los repositorios les quedarán de la siguiente manera:

Por medio de cambiar el prompt PS1 de Bash he resuelto el problema de saber a qué hora ejecuté un comando.

Mi prompt anterior era el default de Ubuntu:

PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '

Para efectos de simplificar, eliminaré la parte ${debian_chroot:+($debian_chroot)}. Bastará indicar que muestra la variable de entorno debian_chroot entre paréntesis cuando ésta tenga un valor asignado. Desconozco más.

Digamos entonces que mi prompt anterior era:

PS1='\u@\h:\w\$ '

Versión por default.

Y planteé como objetivos:

• Que me permitiera encontrar fácilmente la separación entre comandos ejecutados.
• Que me permitiera separar visual y fácilmente los componentes del prompt.
• Que me permitiera determinar cuándo exactamente ejecuté un comando (útil durante mantenimientos de emergencia).
• Que a pesar de tanta información, no se me acabe el renglón para escribir mi comando.

Así que:

• Incluí un \n al principio del prompt para dejar una línea en blanco.
• Incluí la fecha y hora con huso horario \d \t \D{%z}. El huso horario es particularmente útil cuando hay que compartir un resultado con un tercero que pudiera estar en otro lugar.
• Puse en verde el identificador de usuario y en azul el directorio actual
• Inicié el comando en una línea nueva. Una ventaja de esto fue que para documentar, puedo simplemente copiar toda la línea y no se incluye toda la información irrelevante.

Quedó como sigue:

SET_GREEN=`echo -e '\033[01;32m'`
SET_BLUE=`echo -e '\033[01;34m'`
UNSET_COLOR=`echo -e '\033[0m'`
PS1='\n[\d \t \D{%z} -- \[$SET_GREEN\]\u@\h\[$UNSET_COLOR\]:\[$SET_BLUE\]\w\[$UNSET_COLOR\]]\n\$ '

En líneas posteriores en mi .bashrc, Debian y Ubuntu anteponen \[\e]0;\u@\h: \w\a\] para que el título cambie al establecer el prompt. Esto se habilita si la terminal es compatible con los cambios de título.

El resultado final es:

Resultado final.

gawk '{print "\007" $0 }'

This will effectively “prepend” a bell to each line.

You can convert this into an alias or a command (say /usr/local/bin/line-beep.gawk):

#!/usr/bin/gawk -f

{ print "\007" $0; }

So it can be used in a code like the following:

tail -f /var/log/messages | grep --line-buffered dhcpd | line-beep.bash

That’s why Opera can be set to ignore core X fonts, by unchecking the Enable Core X fonts configuration option. You can use this as a workaround.

So, the result of having this option enabled can be compared in the following images. The first image shows the rendering when the font-family: "Deja Vu Sans", sans-serif directive is used. The second image shows the same page when the “Deja Vu Sans” option is removed from the directive. In this second case, Opera renders the text using the “sans-serif” font, whatever it matches.

Seen from a different perpective, it appears to be that when Opera asks X for a font, X returns an antialised core font. Does this happen on other distributions too?

Continuing with the stream of web browser interoperability issues I recently found how to make Opera 10 work with a Cisco Secure Access Control Server 4.1.

The problem I experienced is briefly described as, clicking any option in the menu (in the left frame) will open the menu again in the right frame, instead of actually showing the selected option.

The answer is simple: set Opera to identify as Firefox for that domain or IP. This is located under Tools » Preferences » Advanced » Content » Manage Site Preferences. Add the site and under Network, change “Browser identification” to “Identify as Firefox”.

Here are the screenshots. Click on them.

Opera identified as such.

Opera identified as Firefox.

The analysis narrows down to this code in the menu:

// unfortunately the Object model in IE doesn't match the Netscape one so we have to check the browser...
if( "Netscape" == navigator.appName )
{
	obj.href=sequence_url;
}
else
{
	ua=navigator.userAgent;
	v=navigator.appVersion.substring(0,1);
	if ((ua.lastIndexOf("MSIE")!=-1) && (v!='1') && (v!='2') && (v!='3'))
	{
		// MSIE 4.0 and later.
		obj.href=sequence_url;
	}
	else
	{
		parent.parent.R.location=sequence_url;
	}
}

(some code snipped)

<A HREF="" TARGET=R onClick="getURL( this , 'setup.exe?action=make_r_fs&option=users' )" >
<IMG SRC="images/cisco_buttons/user-up.gif" BORDER=1 ALT="User Setup"></A>

So Cisco is actually trying to detect the UA, but instead of assuming a standards-complaint browser and applying special fixes for IE, it assumes IE and applies a special fix for Mozilla (Netscape).

That’s why changing the identifier for that site actually works. Now the JavaScript code correctly detects the UA and performs the correct action of loading the page in the “R” frame.

En Tijuana, el evento se realizará en la sala de audiovisual del edificio de Gobierno del Estado de BC, este sábado 19 de 2009 en punto de las 10:00 a. m.

Por mi parte, estaré presentando una charla sobre paquetería libre para Windows y Linux.

Lo único malo es que ese día me toca trabajar por la mañana, pero nos vemos allá para la conferencia a las 3:00 p. m.

Más información sobre el evento en la página del SFD 2009 en GULTIJ.

Así que abrimos la segunda herramienta: Enlaces directos a las webcams de las garitas entre Tijuana y San Diego.

En breve: Sólo hay que usar los canales 1, 6 y/u 11 para las redes inalámbricas. Hay que ajustar la potencia para usar la red cómodamente pero sin estorbar inútilmente al vecino.

Los punto de acceso inalámbrico (Access Points, AP), ofrecen 11 (tal vez hasta 14) canales a escoger. Lo que no dicen, es que sólo 3 de esos 11 canales se pueden escoger sin estorbar a nadie más.

Sin embargo, las opciones reales son sólo tres: 1, 6 y 11.

Como se puede ver en la gráfica, los canales tienen una separación de 5 MHz entre sí, pero cada canal usa 22 MHz.

Esto significa que si se tiene un vecino en canal 1 y otro vecino en canal 6, poner nuestro AP en canal 3 no sería una buena elección. Habrá interferencia en los canales de los tres vecinos, metiendo ruido, en lugar de compartir el canal.

La clave de esto es que no es lo mismo compartir el canal, que meterle ruido. Al compartirlo, la tarjeta detecta que no puede transmitir al mismo tiempo que otro equipo y se espera a que el otro termine. Sin embargo, meter ruido implica que ambas transmisiones fallan y ambos deben retransmitir. Al final, esto resulta más caro para ambos.

Hay quienes proponen un diseño de cuatro canales (1, 4, 8 y 11), pero esto resulta menos eficiente que un diseño de tres canales con uno compartido. Hay un documento de Cisco que analiza específicamente este caso: Channel Deployment Issues for 2.4-GHz 802.11 WLANs

El otro parámetro a ajustar es la potencia. Supongamos que dos vecinos tienen sus AP en el mismo canal por fuerza mayor. ¿Cómo pueden interferirse lo menos posible?

• Bajando la potencia de sus AP para que las áreas de cobertura se traslapen lo menos posible.
• Subiendo la potencia para que ambos compartan el canal de forma más ordenada. Sin embargo, subir la potencia, por lo general estorbará a otros vecinos, por lo que no siempre es esta la mejor opción.

¿Qué es lo mejor, desde mi punto de vista?

• Sólo usar la red inalámbrica cuando sea necesario. Esto significa que es mejor utilizar la red alámbrica tanto como sea posible.
• Acordar con los vecinos cercanos que sólo se usen los canales 1, 6 y 11 y que cada quien escoja el canal menos saturado.
• Ajustar la potencia de los AP al nivel óptimo: que sirva bien pero sin estorbar a otros.
• Mover de lugar los AP, de modo que queden instalados en el centro del área de cobertura. Esto alejará un AP de otro AP y ayudará un poco. Aún así se compartirá el canal por aquellas laptops que estén físicamente ubicadas entre ambos AP.
• Si alguno de los vecinos tiene demandas más grandes de consumo que el resto (por ejemplo, un vecino transfiere archivos pesados frecuentemente entre sus PC y los demás sólo hacen navegación común y chat), reserven uno de los canales para él, y los demás compartan los otros dos canales. Al final sale mejor para todos, pues la probabilidad neta de colisión es menor.

Algunas empresas tienen demandas más grandes de consumo y usan aparatos que dinámicamente cambian el canal de sus AP hacia la mejor frecuencia disponible. En esos casos, la negociación es un poco más difícil, pero pueden acordar que cierto AP sólo pueda usar —digamos— el 1 y el 11, y dejar a los vecinos que usan navegación simple, el canal 6.

Y el primero en la lista es: Consulta de saldo, Ticket Alimentación Electrónico, Accor Services México.

Mientras Accor Services México no me deje consultar el saldo de mi TAE a través de su sitio, yo voy a publicar un método alterno.

Todo fuera como eso, pero en este momento el daño está hecho: el blog ha sido eliminado de los índices de Google.

Desafortunadamente, ODS se niega a tomar acción contra este problema, así que me he visto en la forzosa necesidad de cambiar la URL para mi blog.

La nueva dirección es: http://blog.alvarezp.org/

Mucho agradeceré a quienes me conceden el honor de enlazarme desde sus sitios, blogs y demás, que actualicen su enlace. Consideren que se eliminó el directorio /blog/ en favor de tener todo bajo el directorio root en el host blog.alvarezp.org. Entre más links se actualicen ya, más pronto encontrará Google el nuevo sitio y, con un poco de suerte, reaparecerá en los índices de Google.

De todos modos, la dirección anterior seguirá funcionando durante un tiempo indeterminado. Ningún sitio padecerá tenebrosos 404 por este movimiento.

Gracias de antemano.