Crecimiento y declive de la comunidad

En el grupo de Facebook Gultij – Grupo de Usuarios de GNU/Linux de Tijuana, Gustavo pregunta lo siguiente. He traducido las citas que originalmente estaban en inglés.

Momentum de las comunidades del software libre:

Veo un post en los grupos de OpenSuSE que dice algo así como:

«Googleé grupos de usuarios de Linux en mi región y encontré que la mayoría de los sitios no han sido actualizados en años. ¿Comenzó a morir Linux mientras estuve ausente?»

Y una de las respuestas, que me pareció acertada:

«Sí, la comunidad es una sombra de lo que alguna vez fue. El Código Abierto y la tecnología ya no es tan padre y la nube es un enorme parásito adjuntado a la comunidad Open Source.»

Me parece acertada la última línea. ¿Se ha vuelto la comunidad FLOSS simplemente un producto / mercancía para los intereses de otras compañías o proyectos, mas allá de la temática filosófica? ¿Qué opinan?

Primero hay que detectar las falacias, y en la pregunta original hay una grave. No es lógico implicar “sitios de los GUL sin actualizar →  Linux comienza a morir”, esa es una conclusión un tanto melodramática.

Lo que sí es cierto es que la comunidad se ha transformado. No es que la comunidad venga a menos sino que se ha transformado gracias al surgimiento de otras fuentes de información centralizadas en la nube. Al tener un alcance mayor, es más fácil encontrar respuestas de mayor calidad en estos foros; es natural. En otras palabras, la comunidad global se ha fortalecido y algunas comunidades locales presentan declives.

El beneficio de los GUL locales es menor en apariencia pero sólo lo es en cuanto al GUL como fuente de información. Hay otros beneficios más difíciles de apreciar y Mario H. Cornejo los describe muy bien en la publicación Presentar en un grupo de usuarios de su blog Developeando.

Sin embargo, a pesar de este surgimiento de información centralizada, modificar nuestro consumo hacia la nube nos hace dependientes de la misma (y en consecuencia de E. U. A. y el dólar), en lugar de ejercer la libertad de nuestro propio cómputo. No estoy lanzando culpas: los costos y el mercado dirigen parte de este movimiento, pero la disculpa no elimina la realidad.

Hay que diferenciar audiencia de comunidad. Hay que diferenciar a quienes buscan en el grupo de usuarios como mera fuente de información (la audiencia, que consume el valor del grupo) de quienes aportan con trabajo, participación, código y contenido original (la comunidad, que genera el valor del grupo).

El perfil de la gente que genera valor es diferente del perfil de la gente que lo consume. No resulta sorpresivo que —salvo algunas excepciones— la mayoría de la gente que genera valor también está presente en el canal de IRC #gultij en la red Freenode.

He visto —en otros lugares— que la gente dice “¿cuándo es la siguiente presentación?” pero nadie dice “yo ofrezco este tema”. Eso no es comunidad, eso es audiencia. Con esto me refiero a que los sitios Web de los LUG no se actualizan solos; algún humano debe generar el contenido (de preferencia original, no sólo enlaces a blogs).

Al final del día, el éxito de los GUL depende únicamente de la gente. Si la gente no aporta con trabajo a un GUL, éste automáticamente se desvanece. Es muy fácil:

  • Si pocos trabajan para el GUL, la densidad de trabajo es muy alta y los frutos de la comunidad son bajos; los voluntarios se desmotivan y se van.
  • Aunque haya actividad, si no se da la apariencia de dicha actividad, los externos no la perciben (como ocurre en la pregunta original) y no participan; entonces el trabajo se mantiene concentrado en unos cuantos… y ver punto anterior.

En resumen, a la pregunta original —la que fue citada por Gustavo— yo contestaría: los grupos de usuarios de tu área comenzaron a morir debido a que estuviste ausente.

Software Freedom Day, Tijuana 2015

La fecha para el Software Freedom Day Tijuana 2015 está establecida. Será el sábado 19 de septiembre de 2015.

¡Bienvenidos presentadores! Envía tu propuesta antes del 31 de julio a http://sfd.gultij.org/

Regístrate en http://sfd.gultij.org/

¡Comparte tus conocimientos! Regístrate en http://sfd.gultij.org/ y presenta en el Software Freedom Day, Tijuana 2015

A veces un “if” es más barato

En una interesante discusión en el grupo de Facebook de la Comunidad .NET Tijuana surgió el tema de las microoptimizaciones, en particular el uso de evaluación en corto circuito y el ahorro de ifs “que son muy costosos al CPU”.

Mi último argumento:

A lo que iba es que el short-circuit, si bien te puede ahorrar ifs, también puede darte sorpresas como brincarse validaciones de seguridad. Ha ocurrido en otros lenguajes. Yo prefiero un if explicito, que en realidad no es nada caro al CPU, a menos que no diseñes bien tus condiciones.

Entonces el autor original hace un planteamiento: ¿Cuál de los dos siguientes programas es más rápido?

Sigue leyendo

Monitor

Monitor state diagram

Monitor state diagram

Monitor is a purely-Bash script that lets us leave the PC monitoring the result of an instruction. Unlike watch, Monitor is not about observing the output of the instruction, but to detect the moment when the instruction fails and stops failing and execute instructions whenever this happens.

Monitor was written to keep an eye on randomly failing services. The problem will sometimes last for a short while and it is not easy to take a sample of the system just right when the problem is occurring.

Besides, this kind of situations share some characteristics:

  • It is desired to know when did the failure occur and when did it raise back to know what section of the logs to browse for useful information.
  • It is desired to take action when a new failure occurs. These actions can be alert sending or snapshot taking.
  • It is desidred to be tolerant to temporary situations. For example, a simple lost ping doesn’t imply an actual lose of service.

Although this type of monitoring can be easily solved by using while under Bash, it could easily become complex and it is not fun to debug it each time the need comes up. Besides, it is also possible to make mistakes in the while logic and not notice until the next instance of the failure happens and we didn’t get the expected system snapshot.

With Monitor, the logic is already established and tested. It’s just a matter of indicate the commands that we want to monitor and the actions to execute on state change.

The code is available in Github: https://github.com/alvarezp/monitor

Example

In a hypothetical problem we lose communication with our own host and we don’t know why. We suspect that a running process is inserting rules in iptables that result in communication blockage.

Let’s user monitor.bash to keep an eye on the result of a ping to localhost and to take an iptables configuration snapshot on failure.

# monitor.bash --rest-time 1 --on-down 'iptables-save' 'ping localhost -c 1 -w 1 >/dev/null 2>&1'
       INIT 2015-11-05 15:21:58 PDT lun
         UP 2015-11-05 15:21:58 PDT lun
     ---- the weird process applies iptables -A INPUT -i lo -p icmp -j DROP ----
FALLINGDOWN 2015-11-05 15:22:13 PDT lun
# Generated by iptables-save v1.4.21 on Mon May 11 15:22:17 2015
*filter
:INPUT ACCEPT [74:70608]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [67:5781]
-A INPUT -i lo -p icmp -j DROP
COMMIT
# Completed on Mon May 11 15:22:17 2015
       DOWN 2015-11-05 15:22:17 PDT lun
     ---- the weird process applies iptables -F INPUT ----
RAISINGBACK 2015-11-05 15:22:32 PDT lun
         UP 2015-11-05 15:22:36 PDT lun

It gives the impression that iptables-save is run after getting to FALLINGDOWN, but in fact it executes just before entering DOWN.

Now we have timestamps to look for more information in our logs and some evidence to delve into the problem and its diagnostic.

Monitor

Diagrama de estados de Monitor

Diagrama de estados de Monitor

Monitor es un script escrito en puro Bash que permite dejar a la PC monitoreando el resultado de una instrucción. A diferencia de watch, no se trata de estar vigilando la salida de la instrucción, sino de detectar el momento en que ocurre la falla y ejecutar instrucciones cuando el servicio vigilado se cae o se levanta.

Monitor fue escrito para vigilar servicios con fallas de naturaleza aleatoria. En ocasiones el problema dura poco y no es fácil tomar una muestra del sistema justo cuando el problema ocurre.

Además, este tipo de situaciones tiene algunas características:

  • Se quiere saber cuándo se cayó y cuándo se volvió a levantar el servicio para saber en qué sección de las bitácoras buscar.
  • Se quiere tomar acción cuando se detecta otra caída. Estas acciones pueden ser toma de diagnósticos o envío de alertas.
  • Suele necesitarse ser tolerante a oscilaciones pasajeras; por ejemplo, un ping perdido no implica una caída de un equipo.

Si bien este tipo de vigilancia se resuelve fácilmente con un while de Bash, éste puede volverse rápidamente complejo y no es divertido estar depurándolo cada que uno se ve en la necesidad. Además, es posible cometer errores al programar la lógica del while y no darnos cuenta hasta cuando el problema original ya volvió a ocurrir y no obtuvimos la monitorización esperada.

Con Monitor, la lógica está establecida y comprobada. Sólo basta indicar qué instrucción queremos monitorizar.

El código está disponible en Github: https://github.com/alvarezp/monitor

Ejemplo

En un hipotético problema perdemos comunicación con nuestro propio host y no sabemos por qué. Sospechamos que un proceso corriendo en nuestra máquina está insertando reglas de iptables que resultan en el bloqueo de esta comunicación.

Utilicemos monitor.bash para vigilar el resultado de un ping a localhost y que en caso de caída confirmada se tome una muestra de iptables.

# monitor.bash --rest-time 1 --on-down 'iptables-save' 'ping localhost -c 1 -w 1 >/dev/null 2>&1'
       INIT 2015-11-05 15:21:58 PDT lun
         UP 2015-11-05 15:21:58 PDT lun
     ---- el proceso misterioso aplica iptables -A INPUT -i lo -p icmp -j DROP ----
FALLINGDOWN 2015-11-05 15:22:13 PDT lun
# Generated by iptables-save v1.4.21 on Mon May 11 15:22:17 2015
*filter
:INPUT ACCEPT [74:70608]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [67:5781]
-A INPUT -i lo -p icmp -j DROP
COMMIT
# Completed on Mon May 11 15:22:17 2015
       DOWN 2015-11-05 15:22:17 PDT lun
     ---- el proceso misterioso aplica iptables -F INPUT ----
RAISINGBACK 2015-11-05 15:22:32 PDT lun
         UP 2015-11-05 15:22:36 PDT lun

Da la impresión que iptables-save se ejecuta después de quedar en FALLINGDOWN, pero en realidad se ejecuta justo al entrar en DOWN.

Ya tenemos fechas y horas para buscar en bitácoras y algo de evidencia para profundizar en el diagnóstico.