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!

To directly quote from Felipec’s post in his blog:

After a bit more than two years of development we are proud to announce the first stable release of msn-pecan. The project started as a “fork” of libpurple’s msn protocol (read below why it’s not really a fork), but it has grown and soon will become a standalone library with support for Telepathy too.

Even though I have only 3 of the 1009 patches and although I don’t understand any of the code itself, I gotta admit I really feel like I’m part of the project.

7 years ago I started a project to write a text mode, ncurses-based MSN client for Linux. The project is still registered on Sourceforge as msnclient. It was my first attempt at writing free software. However, the challenge was too much for me and the project quickly died. I never got further than logging in and sending a single-worded message to another contact.

I eventually started to learn how to use Pidgin and got my self good hardware and my need of a personalized MSN client was no more. I still think, however, that msnclient is a good concept to try to bring to life. Maybe some day it will be an interface based on the msn-pecan functions.

That said, in mid 2009, when I started learning Git, felipec provided me a branch from his repository to test the direct connection feature (better known as “fast file transfers” or “p2p file transfers”). It didn’t work that time.

6 months went by and lot of commits over his master branch were too. 0.1.0-rc1 came out and directconn was still not working but the dc-test branch was relly old now. I had learned enough about Git and I though that I was better enough to try fixing the DC code. However I really knew nothing about the MSN functionality and I really didn’t understand the code. Well, at least I knew what the first step was: I had to rebase it anyway. So I tried to bring that old branch to the new code base so it could be (at least) useful to the developers. So war was lost for me, but perhaps felipec would get encouraged enough to restart working over this part of msn-pecan (but you’re not supposed to say that, right?). That’s how I saw it and how I got my motivation to do it; also, I would be my first actual real-world git rebase.

The main problem was that felipec had done a lot of relevant code reorganization, renaming and splitting in July (some done good, some done badly). Using some C experience I managed to rebase it and sent it in as a couple of patches.

Suddenly, felipec continued work on directconn. I don’t know if it was because of the patches or not; that doesn’t matter. The important thing is that in msn-pecan 0.1.0, direct connections now work and are stable. Even if not in all cases, it is a great step.

Now I think it went beyond learning how to rebase: I actually learned how to contribute using Git, just like the big boys do in the Linux Kernel project. I still don’t understand the code and the inner workings of the project but those two patches allowed me to learn a lot about software collaboration and review. This was particularly helpful for Superkb which is also written in C and its source code managed in Git.

So, thanks again felipec, congratulations and we all should have a drink for the project, even if on different parts of the world! Let’s party and spread the word.

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)

:-)

Es un video con los experimentos realizados por el Dr. Donald Pettit, astronauta, Ingeniero de Vuelo y Oficial de Ciencias de la expedición 6 a bordo de la Estación Espacial Internacional.

Según la página de Saturday Morning Science, “hasta en su tiempo libre, los astronautas a bordo de la ISS están descubriendo cosas nuevas y sorprendentes sobre la naturaleza”. Según Don Pettit, estos experimentos no se tenían programados como parte de la misión; no eran ciencia “programada” sino ciencia “de oportunidad”.

Este video es un video crudo y directo al grano; tal vez sea una versión compilada; pero hay otras versiones en YouTube y la galería de videos de la expedición donde están editadas a modo de entrevista con un poco más de explicación.

Espero que los disfruten tanto como yo y se sorprendan tanto como los astronautas.

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.

For now, it is only in English. I’m really looking forward to adding a full Spanish equivalent.

I think this will make it a lot easier to keep the documentation up to date.

The SourceForge Wiki doesn’t allow anonymous contributions, so an SF account is needed to include the people in the editors group.

Suggestions and contributions are welcome.

En este video interpretan dos piezas. Abren con el Segundo Movimiento de la Sinfonía No. 10 de Shostakóvich, después unas palabras del director Gustavo Dudamel y cierran con el Danzón No. 2 de Arturo Márquez.

A mí me ha impactado la energía que proyectan estos jóvenes, así como del director, y lo disfrutan.

Lo demás que yo pudiera decir sobre la interpretación no tiene importancia. Escojan sus mejores bocinas y escuchen la música.

Enlace al video: http://www.youtube.com/watch?v=amSqQ5XNaGE

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… ;-)

I have always felt the EIGRP metric as being really overwhelming. I see values like “2820096″ and instead of understanding it, I always end up asking what the hell does that number mean.

For example, in RIP:

R    192.168.0.0/24 [120/3] via 172.16.1.1, 00:00:15, FastEthernet0/0

Just by looking at the metric of “3″ I immediately know what is means: there are three steps between the announced network and the router receiving the advertisement. Easy, right? “Understanding the number” makes it easy for me to manage and diagnose it.

In OSPF, the metric (cost) is still not as cumbersome as EIGRP’s. However, in the following example, can you identify what does “66″ mean? For you, is it “just a number” that won over another because of its numerical value being lower? How do you know if the number is right or not?

O   192.168.0.0/24 [110/66] via 172.16.1.1, 00:00:82, FastEthernet0/0

The EIGRP metric formula is better, functionally speaking. It is calculated from various components. As a result, it is more complex. Furthermore, the resulting value is bigger. When you try to read the number in the route table, it is no longer obvious.

D   192.168.0.0/24 [90/2820096] via 172.16.1.1, 00:00:12, FastEthernet0/0

So, what does “2820096″ mean? Well, it’s pretty simple. Take 2820096 and divide it by / 25600 and you get the estimated travel time in milliseconds: .

The EIGRP metric is an approach to calculating the total travel time. By default, EIGRP calculates the packet travel time like is: take the transmission delay in all hops in the path (the famous “delay” part) and —instead of adding all of the serialization delays— add only that of the bottleneck bandwidth for a 100 Kilobit sample.

The goal of this article is to show you how to mathematically get to that conclusion in the particular case of the default K values. This will allow the article to be much shorter and understandable, because the rest of the terms that compose the complete EIGRP metric are more complex and there is less on-line documentation reference for those. Also, Cisco doesn’t recommend changing the K values by default unless you REALLY know what you are doing.

Besides, we can get our engines started and warmed up for a later article with an analysis for the whole formula, don’t we?

Step 0: Starting to think

To put a “meaning” to this number, I will first ask you: if you designed your own “perfect” routing protocol, what would you use as a metric? What formula do you think would provide the routers with the best and closest to reality information in order to always take the most optimal routing decisions, at all times, and whatever the network circumstance is? It is not an easy question, though it is one that any protocol designer will never be able to escape. Think about this for a moment.

When I asked myself this question, my answer was: I think everybody wants the packets to get to its destination (unmodified, of course) as quickly as possible. I would like all participating routers to know the exact time it will take a packet to get to router B. Travel time should be used as *the* metric. In my “perfect” routing protocol, the metric would be measured in some submultiple of seconds. Even the Internet would be better if this were true, except that it’s way too expensive, complex, and difficult to manually control if done this way (that’s were BGP jumps in).

The EIGRP protocol gives it a shot at this approach.

Quoting complete the EIGRP metric formula, by Cisco

To analyze the default metric behavior I will start by quoting the complete EIGRP metric formula specified by Cisco¹:

where:

• 
  • where is the least bandwidth of all outgoing interfaces on the route to the destination network represented in kilobits.
• 
  • where is the sum of the delays configured on the interfaces, on the route to the destination network, in tens of microseconds. The delay as shown in the show ip eigrp topology or show interface commands is in microseconds, so you must divide by 10 before you use it in this formula. Throughout this paper, we use delay as it is configured and shown on the interface.
• If , the formula reduces to .
• Cisco routers do not perform floating point math, so at each stage in the calculation, you need to round down to the nearest integer to properly calculate the metrics.
• The default values for K are:
  • 
  • 
  • 
  • 
  • 

For default behavior, you can simplify the formula as follows:

I found out that sentence to be a source of confusion for myself. Even the simplified, default-behavior metric formula is expressed in a way that assumes we can add apples and oranges, though this is impossible. Cisco wants us to add “bandwidth” with “delay”. So, how do they actually do it? How much is “10 bps + 10 s”?

Step 1: Arranging the mathematical expression in its default K values

Let’s try to state the formula in its default behavior. I will use the following symbols:

• : metric.
• : resulting scaled bandwidth.[/pmath]
• : bandwidth(i), the least bandwidth of all outgoing interfaces on the route to the destination network represented in kilobits.
• : resulting scaled delay.[/pmath]
• : delay(i), the sum of the delays configured on the interfaces, on the route to the destination network, in tens of microseconds.
• : 1000000 (as in 10 Mega-something).

Let’s arrange the formula in a way it really looks like a mathematical equation:

where:

Step 2: moving the “256″ out of the way and getting to the original IGRP metric formula

EIGRP metric is 256 times that of IGRP². This is easily provable: as both, B and D are a multiple of 256, we can divide by it. The result is the exact original IGRP formula3. (Though this is also true in the complete formula, please remember we are only working with the particular case of the default metric behavior.)

This means that the EIGRP metric will be always inflated and will be a multiple of 256.

Let’s do the procedure. First, lets get all into one big formula. Let’s replace B and D for their corresponding formulas:

There we can see how the 256 factor is present in the two terms. We could factor it out but for convenience I will divide everything by 256.

The right side is the default metric for IGRP.

Step 3: Unit analysis and T₃

Or put another way: what is the resulting value measured in, is it Kilobits, seconds, hops, packets…?

The last formula from step 2 has the following form:

where:

• (metric)
• 
• 

The terms and must have the same units. Otherwise, addition couldn’t be possible.

The easiest term to analyze is . According to Cisco must be in tens of microsegundos. Therefore:

And thus, units (and therefore the whole M units) must be tens of microseconds, also.

So:

• (time)
• (time)
• (time)

So, given is a delay, the other term and the total metric must be a delay too in the same scale. Remember what I said at the beginning about using travel time as my “perfect” metric for a routing protocol? EIGRP is actually giving it a shot.

Step 4: Analyzing T₁

In step 3 we let be defined as:

And also that must be in tens of microseconds.

We know the units for and , but what are the units for ?

: tens of millibit

How many bits are ?

So finally, is like this:

Just like , also , so means “serialization delay for 100 Kbits under that bandwidth B_min“.

Conclusion and interpretation

D   192.168.0.0/24 [90/2820096] via 172.16.1.1, 00:00:12, FastEthernet1/1

We know that 2820096 is given in and multiplied by 256.

So we take 2820096 / 256 = 11016.

To convert it to instead, divide the metric / 25.6:

Or to milliseconds, divide it by / 25600:

As I said, the EIGRP default metric is an approach to calculating the total travel time. By default, EIGRP calculates the packet travel time like is: take the transmission delay in all hops in the path (the famous “delay” part) and —instead of adding all of the serialization delays— add only that of the bottleneck bandwidth for a 100 Kilobit sample.

References

¹ Cisco Document ID 16406, actualizado: Sep 09, 2005. Enhanced Interior Gateway Routing Protocol: http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094cb7.shtml

² IP Routing, by Ravi Malhotra, January 2002. Chapter 4: Enhanced Interior Gateway Routing Protocol (EIGRP) http://oreilly.com/catalog/iprouting/chapter/ch04.html#45434

³ Cisco Document ID 13678, actualizado: Aug 10, 2005. IGRP Metric [IP Routing], http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009405c.shtml

Introduction

The most ignored Internet Etiquette rule is that of the posting style when replying to an e-mail message.

By “quoting” I mean the inclusion of a previous message in a new one (for example, a reply) with the intent of stating the relevance of the answer itself in the original context. I would say “Dan, I don’t know what are you talking about. Please quote the original e-mail in your reply next time in order to know what were you replying to.”

Almost every e-mail client do quote the original message in the reply, at least by default. That is good, and it contributes to the “netiquette”, but its abuse has made it completely useless.

By saying that the rule is “ignored”, I mean that the common user doesn’t edit the text put by the e-mail client as the quote. It leaves the quoted message as is, simply ignoring the resulting text. After three iterations of the answer, the “original message” carries more garbage than relevant content.

Common e-mail clients —like Outlook y Thunderbird— don’t help either; those are pretty stupid. They quote whatever they find. Even when the original goal is to place the original message in the editor ready for its editing while replying, it is also true that signatures and those hideous legal disclaimers are stupidly included also.

Ok. Beyond the rant, the main purpose of this article is to show the current quoting and reply techniques, but more important, to yearn for a style / technique used more than 15 years ago, even before Internet started to be popular in the city where I live.

A correctly applied etiquette to an e-mail reply allows a well-organized message. This etiquette is mainly formed by two elements: (a) the correct placement of the answer in relation to the quoted message and (b) the correct editing of the quoted message.

Reply text placement against the quoted text

The best way to explain this is to mention the three different styles and the difference between them: top-posting, bottom-posting and interposting (or in-line posting). It refers to the placement of the answer before, after or inserted into the original text.

Example A: top-posting

Yes, and I'm going to do it.

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> Octavio:
>
> Is the maintenance window on next Thursday?
>
> Who's going to execute the changes?
>
> Regards.
>
> ---
> Hitsuo Tikashi.
> Infrastructure Services Manager.
> Integrated Systems, Inc.
> T. +1 (619) 555-1234
> E. hitsuo.tikashi@sistint.com.mx

Example B: bottom-posting

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> Octavio:
>
> Is the maintenance window on next Thursday?
>
> Who's going to execute the changes?
>
> Regards.
>
> ---
> Hitsuo Tikashi.
> Infrastructure Services Manager.
> Integrated Systems, Inc.
> T. +1 (619) 555-1234
> E. hitsuo.tikashi@sistint.com.mx

Yes, and I'm going to do it.

Example C: interposting (or inline-posting)

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> Octavio:
>
> Is the maintenance window on next Thursday?

Yes.

>
> Who's going to execute the changes?

I am.

> Regards.
>
> ---
> Hitsuo Tikashi.
> Infrastructure Services Manager.
> Integrated Systems, Inc.
> T. +1 (619) 555-1234
> E. hitsuo.tikashi@sistint.com.mx

Which one do you think is the best? All of them has pros and cons, so the answer may be different in each environment. What do you think are the pros and cons of each?

For instance, In some mailing lists, top-posting is more than prohibited. Either you do bottom-posting or, better yet, interposting. This has been used since before the existence of e-mail as is known today.

However, in businesses and common use, the most popular style is top-posting, due to the easiness of just “writing and sending” without worrying for anything else; this has moved the MUAs (e-mail clients) to be configured for top-posting out of the box. This, in turn, makes it even more popular.

Proper editing of the quoted text

The last example of interposting made it easy to show how a great part of the reply text is just useless. It is considered that the quoted text is part of the reply, as it occupies disk space as part of the reply.

I’ll use that interposting example as the case to analyze, but the following applies to either of the three quoting styles.

From the word “regards” on, the text is irrelevant, and thus, useless. Maybe we could say that the line “Octavio:” is also irrelevant, but let us not be so picky at the moment. In numbers, 8 out of 21 lines (38%) are useless; so are 25 of the 59 words (42%); and so are 161 of the 373 characters (43%). We still have to take into account that mi reply signature is not there, so that will slightly lower those ratios.

Example D: Proper quoting in top-posting

Yes, and I'm going to do it.

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> Octavio:
>
> Is the maintenance window on next Thursday?
>
> Who's going to execute the changes?
>

Example E: Proper quoting in bottom-posting

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> Octavio:
>
> Is the maintenance window on next Thursday?
>
> Who's going to execute the changes?
>

Yes, and I'm going to do it.

Example F: Proper quoting in interposting (or in-line posting)

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> Octavio:
>
> Is the maintenance window on next Thursday?

Yes.

> Who's going to execute the changes?

I am.

The main argument for not editing the quoted text would be that it takes a long time to do it and it is done inefficiently. At home, this is called “lazyness”.

This will be the argument for those that don’t know the keyboard shortcuts for text editing, in particular the use of the Shift key as a non-written standard to select text. Using Shift and the arrow keys, followed by “Delete”, is extremely easy to select and erase useless text.

Yearning for Blue Wave and FidoNet

Before going into user interfaces and mobile devices, I’d like to take a momento to show my yearning feeling for the times where I wrote in FidoNet, even before the Internet started to be popular in Tijuana (1994 to 1996).

In FidoNet, it was common to do this a little different. I used a popular shareware named Blue Wave Offline Reader. Many of us used Blue Wave, which had a particular way of preparing the quoted text before putting it into the editor:

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi said:
 HT> Octavio:
 HT>
 HT> Is the maintenance window on next Thursday?
 HT>
 HT> Who's going to execute the changes?
 HT>
 HT> Regards.
 HT>
 HT> ---
 HT> Hitsuo Tikashi.
 HT> Infrastructure Services Manager.
 HT> Integrated Systems, Inc.
 HT> T. +1 (619) 555-1234
 HT> E. hitsuo.tikashi@sistint.com.mx

The interesting thing is not in the inline replying. Same as today, a couple of Enters in the right place allowed me to reply in-line.

To erase from “Regards” on, still same as today: I place the cursor in the “R” from “Regards” and Shift+Ctrl+End, Delete and voilà: message is clean.

And so was my answer:

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi said:
 HT> Octavio:
 HT>
 HT> Is the maintenance window on next Thursday?

 Yes. Even thought the changes are not considered to be critical, in case
 of a possible failure we will affect our service level agreements,
 because less than 30 days ago our carriers suffered an outage.

 HT> Who's going to execute the changes?

 I am.

What is really interesting is that when the original sender tried to reply me back, the text would be automatically adjusted to the line length (properly word wrapped) and quoted in the following way:

On Fri, Jun 26 2009 17:42:34 -0700, Octavio Alvarez said:
 HT> Octavio:
 HT>
 HT> Is the maintenance window on next Thursday?
 OA>
 OA> Yes. Even thought the changes are not considered to be critial, in
 OA> case of a possible failure we will affect our service level
 OA> agreements, because less than 30 days ago our carriers suffered an
 OA> outage.

 Acknowledged. I leave it in your hands and keep me informed.

 HT> Who's going to execute the changes?
 OA>
 OA> I am.

 BTW, who will monitor and operate the services the next day?

In the example, the user interleaved its answers to me.

Notice how the quoted lines don’t exactly match the original lines. those were modified intelligently, being considered as a paragraph and adjusted to keep a solid and consistent text block.

Also, notice how the text is clear enough and easy to follow; even more if the reader and editor software puts the different authors in different colors.

This style, beyond organized is scalable. After multiple iterations, the format and the text are kept organized.

On Fri, Jun 26 2009 17:42:34 -0700, Octavio Alvarez said:
 HT> Octavio:
 HT>
 HT> Is the maintenance window on next Thursday?
 OA>
 OA> Yes. Even thought the changes are not considered to be critial, in
 OA> case of a possible failure we will affect our service level
 OA> agreements, because less than 30 days ago our carriers suffered an
 OA> outage.
 HT>
 HT> Acknowledged. I leave it in your hands and keep me informed.
 OA>
 OA> Ok, I'll send you an SMS, according to the procedure.

 And please send it to me via e-mail, also.

 HT> Who's going to execute the changes?
 OA>
 OA> I am.
 HT>
 HT> BTW, who will monitor and operate the services the next day?
 OA>
 OA> It would be the new team member, but we have already asked everyone
 OA> else to be alert and ready in case of any eventuality.

 Have you exchanged phone numbers yet?

From my point of view, this is much more intelligent than its popular counterpart:

On Mon, Jun 29 2009 17:42:34 -0700, Octavio Alvarez <alvarezp@alvarezp.ods.org> said:
> On Sun, Jun 28 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> > On Sat, Jun 27 2009 17:42:34 -0700, Octavio Alvarez <alvarezp@alvarezp.ods.org> said:
> > > On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> > > > Octavio:
> > > >
> > > > Is the maintenance window on next Thursday?
> > >
> > > Yes. Even thought the changes are not considered to be critial, in
> > > case of a possible failure we will affect our service level
> > > agreements, because less than 30 days ago our carriers suffered an
> > > outage.
> >
> > Acknowledged. I leave it in your hands and keep me informed.
>
> Ok, I'll send you an SMS, according to the procedure.

And please send it to me via e-mail, also.

> > > > Who's going to execute the changes?
> > >
> > > I am.
> >
> > BTW, who will monitor and operate the services the next day?
>
> It would be the new team member, but we have already asked everyone else
> to be alert and ready in case of any eventuality.

Have you exchanged phone numbers yet?

This is the best the current e-mail practices can get us. It is not bad, but only if the authors and client software follow the etiquette.

If not, we get:

• Badly nested quoting prefixes like: > >> > >>> >
• Badly split lines for exceeding a line length.
• Fully quoted messages, including irrelevant paragraphs.
• HTML garbage from improper tag handling.
• Messages full of signatures and legal texts (sometimes in more than one language per message).

Even though a message from an author that followed the etiquette is a lot better than what we see in a day-to-day basis, i feel it far from the comfort of working in the Blue Wave / FidoNet style.

About user interfaces

E-mail clients fail in promoting the etiquette culture in e-mail messaging.

I think there could be a signature detection mechanism and automatically exclude it from the quoted text. This would save us from getting three copies of the same bulk after three replies:

> ---
> Hitsuo Tikashi.
> Infrastructure Services Manager.
> Integrated Systems, Inc.
> T. +1 (619) 555-1234
> E. hitsuo.tikashi@sistint.com.mx
>
> The content of this e-mail message and its attachments is confidential
> and may be protected by Copyright law. It is intended exclusively to the
> addressees and them only. If you have received it by mistake, you must
> eliminate it from your system. In this case you are not allowed to copy,
> print or distribute this e-mail or its attachments nor use them for any
> purpose of allowing its contents to be known by any person. The here
> included information is not necesarily backed up by [CORPORATION NAME]
> or any of its subsidiaries or strategic alliances.
>
> Please consider the environment before printing this message.

Note: I’ve seen that last line in some messages. I included it because I just couldn’t help myself from using my poor sarcasm after seeing that call for the ecology right after that waste of electricity and disk space (that is usually in HTML format).

Mobile devices

In a 160×320 screen and an itsy bitsy teenie weenie keyboard one could argue that is difficult to do all of this editing in a practical way. However, in the same way new mobile devices present the user an appropriate interface to do other common tasks in a different way, it is the UI that holds how easy or impossible the editing would be.

If in-line posting were popular, a mobile device would have a function or command to “answer below this paragraph” or “navigate by paragraph” and choose “reply, leave or snip” each of them and maybe even an option to “erase the rest of the text”.

If the UI doesn’t have it, it is because in-line posting has not been that popular and not requested enough. It is still a deficiency, though.

Conclusions

I’ve tried to show show the style in example F is the most organized and scalable among all possible, based on previous experience from Blue Wave and FidoNet.

Personally, I try to go with the same style that most of the people use in the same context. It’s the best. A people replying with interposting in a mailing list where everybody top-post (for example, at work) will only confuse for everybody.

I have nothing else to say than to throw a call to those that participate in discussion groups, mailing lists (and, in particular those in technical areas) that at least we observe this etiquette guides among ourselves:

• Reply in line to the topics in the original answer.
• Eliminate irrelevant parts of the quoted message. Signatures and legal texts in particular.
• Rearrange illegible paragraphs (word wrapping, for example).
• Use correct spelling and grammar.
• Back our text up with emoticons if confusion might arise.

Thank for the patience to read all the way to here.

[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

El texto dice:

Uno o más de los mensajes seleccionados no tienen el cuerpo descargado localmente, ¿Desea que Opera descargue los cuerpos faltantes antes de la exportación (sumamente recomendado)?

:-D

He realizado un cambio en el método antispam para el blog. Notarán que ya no se ven las sumas; esto es porque automáticamente se contestan y esconden por medio de JavaScript.

Si acostumbran navegar sin JavaScript, verán el cuadro de las sumas como siempre y bastará con contestar la suma, o bien, habiliten JavaScript para mi blog.

Mis pruebas fueron satisfactorias (probado con Opera y Links), pero si notan que algún comentario se pierde en el olvido, por favor notifíquenmelo a alvarezp@alvarezp.ods.org.

Veremos qué tal funciona.

Gracias.

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