Páginas
26 abr 2010
Linux hasta en la cocina
Gracias a esta alfombrilla que encontré en una tienda de bricolaje, con una forma casualmente muy parecida (por no decir idéntica) a Tux, la mascota de Linux, podemos tener Linux en nuestro baño o cocina sin necesidad de ordenador.
15 abr 2010
Probabilidad remota
Como últimamente me estoy aficionando ligeramente a la estadística (quién me lo iba a decir...), quería destacar unos párrafos que me han encantado del libro Pro Git.
Para aquellos que no conozcáis Git, este es un sistema de control de versiones distribuído, lo que ofrece algunas ventajas sobre otros sistemas centralizados como Subversion ó SourceSafe (del que ya hablé tiempo atrás).
Una peculiaridad de Git es que no designa cada versión (cada snapshot o foto del código) con un número incremental, sino que utiliza una firma generada con función hash de 160 bits, en concreto SHA-1. Una función hash toma una determinada entrada y genera una salida de una longitud determinada (en este caso 160 bits, es decir, un número entre 0 y 2^160 - 1). Idealmente, una buena función hash tiene varias propiedades, entre las que se incluyen:
- Una mínima varianza en la entrada de la función genera cambios grandes en la salida de la función.
- Es muy complicado (por no decir prácticamente imposible) encontrar dos entradas que generen la misma salida (lo que se denomina una colisión).
Y de esta cuestión, la probabilidad de colisión, viene el párrafo que me ha gustado. Ante la preocupación de qué ocurriría si en Git dos versiones distintas generaran la misma firma. El texto original es este:
A lot of people become concerned at some point that they will, by random happenstance, have two objects in their repository that hash to the same SHA-1 value. What then?
(...)
However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is p = (n(n-1)/2) * (1/2^160))
. 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth.
Here’s an example to give you an idea of what it would take to get a SHA-1 collision. If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (1 million Git objects) and pushing it into one enormous Git repository, it would take 5 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision. A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night.y la traducción vendría a ser algo como:
A mucha gente le preocupa que en algún momento tengan, por casualidad, dos objetos en su repositorio cuya firma (hash) sea el mismo valor SHA-1. ¿Qué ocurre entonces?
(...)
Sin embargo, deberías tener constancia de lo ridículamente improbable es este escenario. La firma SHA-1 es de 20 bytes de longitud, ó 160 bits. El número de firmas de objetos generadas aleatoriamente que son necesarias para asegurar una probabilidad del 50% de una única colisión es aldededor de 2^80 (la fórmula para determinar la probabilidad de colisión es p = (n(n-1)/2) * (1/2^160)). 2^80 es 1,2 x 10^24 o 1 million de billones de billones (en formato americano, donde 1 billón es 1.000.000.000). Eso es 1.200 veces el número de granos de arena en La Tierra.
Aquí va un ejemplo para darte una idea de qué tomaría conseguir una colisión SHA-1. Si los 6,5 billones de humanos (billones americanos, serían 6.500 millones) estuvieran programando y, cada segundo, cada uno produjera el código equivalente a la historia completa del kernel Linux (1 millón de objetos Git) y enviándolos a un enorme repositorio Git, pasarían 5 años hasta que ese repositorio contuviera suficientes objetos como para tener un 50% de probabilidad de una única colisión de un objeto SHA-1. Existe una mayor probabilidad de que cada miembro de tu equipo de programación sea atacado y asesinado por lobos en incidentes sin relación durante la misma noche.
Conozco gente tan gafe que estoy casi convencido que cuando comencemos a utilizar Git en nuestro trabajo generará una colisión, pero en general me parece una probabilidad razonable.
Etiquetas:
Git,
probabilidad,
software libre
12 abr 2010
Cuidado con vuestros proyectos software libre, o "El golpe de estado AMSN"
Nota del autor (actualización a 13/04/2010):
Visto el increíble revuelo causado por este post, quería pedir a los lectores un poco de calma:
- Por muy injusta (o justa) que os pueda parecer la postura de cualquiera de los implicados, no es motivo suficiente para insultar a ninguna persona que ha perdido cientos o miles de valiosas horas de su vida desarrollando un software de forma altruista para sus usuarios.
- Lo aquí expuesto no es más que mi opinión, por supuesto totalmente subjetiva, expresando mi malestar por las formas en las que se me ha eliminado del proyecto, el tratamiento posterior, y en general la gestión actual del proyecto AMSN.
- En el post está el enlace a la conversación original, y Youness ha publicado en su blog también una entrada. Libres sois todos de leer ambos post, leer la conversación, y opinar, como ya habéis hecho. Sólo espero que lo hagáis educadamente.
- Esto no es ninguna cruzada, ya que aquí no se está luchando por nada, ni hay un posible ganador. No tiene sentido inundar de Spam ningún blog o foro, ni desinstalarse masivamente ningún software. Mi objetivo era simplemente dar a conocer mi versión de la historia, y creo que ya se ha cumplido subradamente.
- Por desgracia no tengo tiempo de seguir todos los comentarios surgidos alrededor del post y Meneame, aunque lo intentaré dentro de lo posible. Gracias a los que me habéis apoyado. Y a los que no, respeto vuestras opiniones.
Hace ya unos pocos años, como un fork del proyecto ccmsn (tras la imposibilidad de contactar con su autor), comencé el desarrollo de AMSN
Por cosas de la vida, las circunstancias van cambiando, y llegó un momento en el que no me era posible dedicar el tiempo que me gustaría a continuar el desarrollo del proyecto, y pasé a un discreto segundo plano. Otras personas continuaron, y continúan, con mayor o menor efectividad, en el proyecto.
A pesar de todo, he intentado no perder el contacto con el proyecto, e intentar seguir su desarrollo en las listas de correo, en las que cada vez se desarrollaba menos actividad.
Cuál fue mi sorpresa cuándo el otro día, accediendo a las páginas de Sourceforge, la forja dónde se aloja el proyecto AMSN, me encuentro con que ya no formo parte de los miembros del proyecto. ¿Qué habrá sucedido?, me pregunto. ¿Cómo es posible que de repente, sin ningún conocimiento por mi parte, se me haya eliminado del proyecto que fundé, y al que tanto tiempo y esfuerzo he dedicado?
Así que me decido a escribir un mensaje a la lista de correo de desarrolladores, a la que por suerte todavía pertenecía, preguntando sobre este hecho. La conversación completa se puede seguir aquí:
http://www.opensource-archive.org/showthread.php?s=efebe43e81eb30437944b5f147c82914&t=173160
El resumen de la conversación mantenida es el siguiente: inicialmente sorprendido, pregunto cuándo y por qué se me eliminó del proyecto, ya que no había tenido ninguna noticia, ni aviso al respecto. Youness, el nuevo jefe de facto (a quién yo hice administrador del proyecto hace un tiempo) me responde que él mismo eliminó a los miembros inactivos hace algún tiempo. Respondo (creo que siempre educadamente) exponiendo las razones por las que creo que debería permanecer en el proyecto, o por las que, como mínimo, se me debería haber avisado en lugar de expulsarme miserablemente por la espalda y sin avisar, y a partir de ese momento lo único que recibo es una serie de insultos y gritos (cosa que, la verdad, no me sorprende viniendo de esa persona).
A mi modo de ver, el desarrollo de AMSN se ha cerrado bastante, y se convertido en un grupito de amigos que se pasan el día en el IRC contandose sus batallitas. Si no estás en el IRC con ellos y no te llevas bien con el jefe, entonces no puedes pertenecer al equipo, da igual que seas el fundador o tus méritos pasados.
He visto a desarrolladores descontentos hacer forks de un proyecto para continuarlo a su manera, pero es la primera vez que veo dar un golpe de estado en toda regla, y expulsar al creador del proyecto sin dignarse a enviarle ni un email o aviso. ¿Qué opinión os merece esta forma de actuar?
Actualización: vista la polémica generada, que conste que mi objección no es el hecho de que me hayan echado del proyecto (esto podría comprenderlo, aunque yo no lo hubiera hecho). Lo que me parece lamentable es la forma de hacerlo, es decir, eliminarme sin ni siquiera un triste aviso, por la espalda, y luego tratarme como si jamás hubiera hecho ningún mérito por el proyecto, y que si quiero volver a participar, que haga como cualquier otro desarrollador, y comience enviando parches, y ya verán si se me admite.
Creo que nunca les he dado motivos para desconfiar de mi, y por tanto creo que estoy en mi derecho (como fundador y creador de gran parte del código) de poder volver a participar en el proyecto si sacara tiempo, y ganas (que cada vez me quedan menos con actitudes y personas así) para retomarlo. A día de hoy veo más probable volver a hacer un fork por mi cuenta, que volver a trabajar en el proyecto actual.
Actualización: Respuesta de Youness en su blog, en la que podéis encontrar algunos comentarios míos.
10 abr 2010
Piloto por un día
Cuatro imágenes valen más que 4000 palabras:
A los mandos del avión (con ayuda, claro)
El Pilar a la vista
¡Mi barrio!
Posando en la Cessna con la que hemos volado.
Actualizado: y ahora, ¡¡un video!!
A los mandos del avión (con ayuda, claro)
El Pilar a la vista
¡Mi barrio!
Posando en la Cessna con la que hemos volado.
Actualizado: y ahora, ¡¡un video!!
Suscribirse a:
Entradas (Atom)