Cuando los fetichistas del libro se olvidan de la lectura

No soy un fanático de los ebooks, fundamentalmente por mi miedo al DRM. Es muy difícil que una editora no caiga en la tentación (en realidad ya han caído), es muy fácil convencer a los políticos –teniendo el dinero y lobby adecuado– de que la “piratería matará el libro”.

Últimamente soy aún menos fan, nos han bombardeado con publicidad y noticias desde todos los medios.

Pero entiendo que el ebook es un avance inevitable y beneficioso (además de los ecológicos). Por usar un mantra, la nueva  Biblioteca de Alejandría es sin duda Internet. Allí es posible acceder casi a cualquier conocimiento con unos cuantos clics.

Pero el “medio” tal como lo conocemos ahora tiene unas limitaciones: la pantalla y la posición de lectura no favorece la lectura sosegada, pausada, asimilando y recreando en tu mente lo que estás leyendo.

La lectura en un ordenador tiene que ser de textos muy breves, si son largos se leen en diagonal (scanning), o se abandona la lectura a los pocos párrafos. Además de la brevedad obligatoria, el estilo con que se escribe en Internet difiere mucho a lo de los libros, se invierte la pirámide. En un libro el desenlace va al final. Se dedican cientos de párrafos a construir el mundo de fantasía, o a introducir los conceptos paso a paso en caso de libros técnicos, preparando todo para el gran final. En Internet hay que comenzar contando la idea o desenlace desde las primeras líneas.

Es decir, el “formato” del libro es, o era, imposible de mantener en una Internet de píxeles “grandes” y contender físico pesado. La única forma de poder disfrutar de la misma forma que disfrutamos la literatura en “formato libro” es encontrar un dispositivo que ofrezca la misma comodidad de su “contenedor canónico” (por comodidad).

Pero debe ser por eso bombardeo de noticias que comentaba que algunos “intelectuales” se dedican recién ahora a analizar el ebook (pero no se preocupan por temas del DRM, acceso universal, o el derecho a “prestar” nuestro libros).

Un ejemplo de hoy es el artículo El Héroe de Manuel Rivas, que critica el futuro de ebooks y la presunta desaparición del libro de papel:

El libro alimenta un ecosistema ahora en peligro. Una ciudad existe cuando hay media docena de buenas librerías y todavía se oye el zumbido de una minerva imprimiendo poemas sonámbulos.

Tampoco habla allí de la “lectura”, sólo de una especie de fetichismo social: la librería tradicional en las ciudades (y supongo que también lo que hoy es tan común y solemos llamar “quedadas”).

Luego dice una frase aclaradora:

No, no acabarán con los libros mientras existan héroes como Benigno.

Obviamente confunde “libro” con “libro de papel”. No se preocupan del fondo: la lectura. Sólo se preocupan del “depositario” de papel, para nada del estilo ni del formato (quizás también de que no podrán presumir de bibliotecas enormes con cientos de libros porque cualquier chaval podrá tener diez veces más en un chip del tamaño de una uña).

Puro fetichismo egoista y simplón elevado a categoría de reflexión intelectual. Quizás el único lugar donde se esté discutiendo seriamente sobre la lectura sea en las pantallas y teclados de los ordenadores.

PS: Una pequeña evidencia más que El País debería renovar a sus columnistas, o al menos mandarles a cursos de reciclaje. Como los contemporáneos de Colón, sólo ven monstruos más allá de su horizonte tan personal y obsoleto.

Viaje al pasado, o como decir tonterías del software libre

Como un viaje al pasado, me encontré con el apunte 8 cosas (y mitos) que Linux y el Software Libre deben mejorar. Escribiré y contestaré rápido porque en unos minutos salgo hacia al aeropuerto.

Antes de iniciar, unas aclaraciones (o como dicen en inglés, un “disclaimer“): (1) Unas 2/3 partes del software que utilizo a diario es Software Libre, (2) mi máquina de trabajo principal es una MacBook con OS X, Windows XP y Ubuntu Linux. Hago estas aclaraciones porque cada vez que alguien escribe un artículo como este lo acusan de “winfanboy” o “macfanboy” y se olvidan que quizás quien escribe simplemente trata de ser objetivo, o incluso (como en este caso) simplemente querer ayudar.

Esta es una falacia de autoridad cansina y basado en una autoridad ridículo: soy más objetivo creíble porque instalé o uso un GNU/Linux. Es como ese que empieza su diatriba racista o xenófoba diciendo: “no soy racista, tengo un amigo gitano/negro…” Pero lo siento, se puede tener instalado una Ubuntu y ser un completo ignorante de cómo ha podido crearse esa empresa y y distribución, o de la historia y conceptos básicos.

Habiendo dicho eso, hoy quiero hablar de varios problemas que creo la comunidad deOpen Source (Software Libre)

La comunidad del software libre no es la misma que la del open source. Aunque se compartan licencias y proyectos, las motivaciones son muy distintas. En la primera es ética-filosófica, en la segunda puramente técnica (y desde mi punto de vista egocéntrica desde el punto de vista del programador).

1. El mito de que el Software Libre es gratis.
[...] En este caso creo que la comunidad del Software Libre debe tener un mensaje mas realista que el de “te va a salir todo gratis”

Jamás desde el software libre se afirma eso, fundamentalmente porque el precio no es una motivación ética. En todo caso cuando oye esas afirmaciones debería dudar de que el que lo dice sepa realmente de qué está hablando. Aunque también hay que decirlo, si no tienes costes de licencias iniciales, ya estás bajando el precio sin gastar una hora de trabajo. Empresas como Google o Facebook explicaron hasta el cansancio de que no hubiese sido posible para ellas comanzar si tenían que pagar las licencias de software privativo para todos sus servidores.

1. El mito de que puedes hacer lo que quieras con el Software Libre

En este punto lanza la mayor cantidad de afirmaciones falsas y sin tener idea. Por partes.

Una vez mas, esto es algo que termina disparando el tiro por la culata a muchos consultores, que sin saber las particularidades de las distintas licencias Open Source, implementan sistemas de Software Libre a clientes empresariales.

Critica a los consultores que has hablado, o menciona la empresa. En todo caso la culpa es de ellos, no del software libre, el open source o las licencias.

Sucede que irónicamente (dado el nombre de Software “Libre”), que el Software Libre en realidad no es libre bajo muchas licencias, ya que (como ejemplo) te quita una de las libertades mas básicas de la sociedad humana: La libertad de tu beneficiarte económicamente con el fruto de tu labor.

Ridículo. La primera libertad y más fundamental es la libertad del usuario para hacer lo que quiera con el software de su ordenador. Además ninguna licencia libre impide al autor de un código hacer lo que quiera con sus programas, puede publicarse sólo con licencia libre, o con varias, venderlo, o regalarlo.  O puede trabajar modificando y desarrollando software libre cobrando por ello, o puede incluso vender software libre –como hacía Richard Stallman o la misma FSF– siempre y cuando respete la licencia de los trabajos de terceros.

Se bastante bien (y he escrito al respecto en eliax anteriormente) que “la manera” de hacer dinero con el movimiento Software Libre es cobrando por servicios, y no por el software, pero aquí olvidamos un componente bastante importante: Los que escriben ese software en primer lugar.

Puedes cobrar por el software, ninguna de las licencias de la FSF y compatibles impide la comercialización. Lo que quieres que respetar es la intención y autorización de los otros autores. ¿O pretender hacer negocio con el trabajo de otros sin respetar sus intenciones ni devolver nada a cambio?

Es fácil decirle a alguien “escribe 10,000 lineas de código que haga esto y aquello”, y después tomar el código de esa persona para tu propio beneficio sin darle un centavo, y decirle (mientras le das unas palmaditas en la espalda) “y ahora no te preocupes que harás dinero haciendo consultoría o dando algún tipo de servicio con esto que haz escrito”.

Contradictorio. Si puedes coger código de otra persona es porque el otro así lo ha querido. Y puedes venderlo si tienes mercado. Con el software privativo no puedes hacer nada de esto, ni siquiera usarlo como te apetece.

Uno de los grandes secretos ocultos del movimiento Open Source es que la mayoría de los que donan su tiempo al movimiento rara vez obtienen un beneficio económico de su esfuerzo. Noten que no estoy diciendo que eso sea algo malo, en el sentido de que quien quiera donar su tiempo que lo haga (yo mismo lo he hecho), pero sí me preocupa que una movimiento que haga tanto incapié en la palabra “libre” en realidad le quite una de las libertades mas importantes del ser humano, la de beneficiarse (y sí, de manera egoísta si lo quieren ver de esa manera) de los frutos de su talento.

Nadie está obligado a programar software libre, ni a usarlo, no entiendo que se preocupe por las intenciones de los demás.  Y como dije antes, ninguna licencia prohíbe que el autor de programas haga lo que quiera con ellos, además no se puede, es imposible legalmente –por las leyes de copyright/derechos de autor–

Pero todo esto surge de una confusión más grande. Las cláusulas de entregar el código fuente de software libre sólo se aplican en caso de distribución a terceros (salvo licencias como la Affero GPL que también se “dispara” en ejecución remota) porque aquí entra en juego la libertad de los otros usuarios. Mientras no haya distribución tienes las libertades fundamentales que aseguran todas las licencias libres:

• Hacer con el software lo que quieras: ninguna licencia de software privativo lo permite.
• Modificarlo como quieras: ninguna licencia de software privativo lo permite.
• Libertad para distribuirlo: es una libertad, no una obligación. No tienes por qué publicar ni distribuir nada, pero si lo haces y es de software de terceros debes respetar la licencia que le han puesto.

3. El pensamiento radical de muchos en el movimiento Open Source

Otro punto que creo no favorece al movimiento Open Source en general, es la existencia de muchos radicalistas, que se comportan mas como sacerdotes fanatizados que como ingenieros o consultores.

Un ejemplo, el mismo Richard Stallman (fundador de GNU), a quien admiro por un lado (por sus destrezas técnicas), pero con quien tengo serias diferencias filosóficas sobre el Sofware Libre.

[...]

Richard Stallman no es del open source, está cansado de repetirlo y se conocen sus diferencias filosóficas profundas. Volver a repetir esto es no tener la mínima idea de lo que se está criticando.

Además sí, Richard Stallman es un radical, como toda persona que da prioridad a los valores éticos. Estos valores éticas son fruto de la reflexión lógica, no de religiones, que son todo lo contrario. Pero Richard Stallman es personalmente consecuente con lo que dice, no obliga –ni puede– a nadie a que sea igual que él, no demanda a nadie e incluso se toma a humor su propio radicalismo, por eso se disfraza de San Ignucio (es que todavía hay muchos que no captan la ironía).

O sea, el “radical Richard Stallman” vive acorde a su filosofía, renunció a todo poder como está claro en las licencias. Todo lo contrario que por ejemplo Steve Jobs, cuya empresa hasta demanda a otros porque arrancan Mac OS X en un hardware diferente al de Apple y así violan la licencia, o a escuelas por el logo de una fruta… pero resulta que el perjudicial para el software por su radicalismo es Stallman. Absurdo.

Esta vista radical en muchos casos se enfrenta directamente con varias empresas las cuales piensan (obviamente) en hacer dinero, y si una librería de código bajo cierta licencia implica que estos deban liberar todo su software propietario, o si en el mejor de los casos tengan que molestar a sus clientes diciéndoles que deben instalar esto o aquello ya que no lo pueden incluir en el binario para no arriesgarse a un proceso legal, ese tipo de cosas simplemente cierran muchas puertas.

¿Está defendiendo el “derecho” de una empresa de coger el trabajo de otros y venderlo sin respetar la licencia ni el trabajo de sus programadores que les han autorizado a usarlo de una manera? Seguramente Apple o Microsoft sí que lo permiten para sus programas y no demandarían a nadie si usan sus códigos fuentes sin autorización.

4. La confusión con las múltiples distribuciones del mismo software
Este tema lo vemos claramente en Linux, en donde la cantidad de distribuciones se acerca a 180 (no contando las distribuciones fuera de mantenimiento, que son un sinnúmero mas) [...]

Hablando tanto de libertad y ahora se queja de que haya libertad. ¿Qué pretende? ¿Que Richard Stallman u otro “radical” obligue a las empresas a que se fusionen? ¿a que creen más distros? ¿o que la licencia lo prohíba expresamente?

Quiero eso que fuma.

5. El tema de “El Programador Mas Macho”
Otro problema relacionado al punto anterior es que debido a que todo el mundo cree tener la “mejor” solución a un problema, que muchas veces esto conduce a anarquía, y división del software en cuestión. Linux es un excelente ejemplo, en donde podemos citar el eterno debate entre los gestores gráficos KDE y GNOME. Al final los usuarios finales tienen que decidir cual de los dos elegir, pero una vez mas, un usuario común no sabe cobre cuál base elegir, por lo que aunque esto sea bueno para usuarios técnicos que pueden elegir su favorito, para un usuario común y corriente es mejor decidir por ellos y darles un entorno estándar que puedan utilizar en cualquier versión de Linux.

De nuevo, ¿qué pretende? ¿que las licencias prohíban la diversidad? ¿que les impida a lso programadores iniciar nuevos proyectos? No entiendo absolutamente nada.

Además KDE y Gnome no tienen nada que ver con Linux (que es sólo un kernel) y se ejecutan en otros sistemas operativos que no son GNU/Linux.

6. La gran confusión entre todos los tipos de licencias
¿Cuántas personas técnicas conocen que pueden discernir entre los distintos tipos de licencias de Open Source? Muy pocas. Yo mismo acabo de contar 65 licencias diferentes en esta página.

Otra vez. Se queja de la diversidad ¿pretende prohibir que programadores o proyectos pueden elaborar sus propias licencias? ¿acaso se ha leído todas las licencias de software privativo? Cada programa tiene la suya, así que si las empieza a contar debe haber decenas de miles, que es mucho más que “65″.

Pero sí, es un problema, por eso la FSF pide que no se hagan tantas licencias que luego generan problemas legales. Pero el problema de fondo no es la licencia, sino las leyes de propiedad intelectual que obligan a elaborar textos muy complejos para la “autorización”, i.e. licencia.

¿Qué significa eso? Que antes de uno escribir una sola linea de código y reutilizar código Open Source, debe primero hacer una maestría en ciencias legales, o contratar un abogado experto en la materia (ahí van los ahorros del software “gratis”), para saber cuál licencia utilizar. Y eso es un grave problema.

Falso, para usar y modificar un programa internamente ni hace falta leer la licencia si es libre: puede estar seguro que tiene asegurada su libertad. Sólo debe estudiarlas si piensa distribuir un paquete con programas que usan licencias diferentes. ¿Pero acaso no se dió cuenta que con software privativo no lo hace porque ni siquiera tiene la opción? ¿O está defendiendo una especie de “no podemos permitir que la otra gente lo pueda hacer, no podemos permitir que sólo tengan que estudiar las licencias”?

Por cierto, ¿se ha leído y comparado una licencia de Mac OS X o la de Windows? ¿le permite combinar el código fuente con otros sin problemas ni necesidad de estudiar licencias o contratar abogados?

Para finalizar, la FSF y otras organizaciones hacen esfuerzos para compatibilizar licencias, se modifican para ello (como la GPL3 para que sea compatible con Apache) y hay guías. Además, no debe ser tan complicado, yo dedico una hora de una asignatura de un máster para enseñar lo fundamental de las licencias, ni tampoco se ven demandas por el uso indebido. De hecho hay más demandas de Apple o Microsoft por razones de las más variopintas que por problemas de licencias libres…

8. El mito de que Software Libre es utilizado en la mayoría de las empresas

De nuevo confunde la propaganda que pueda hacer una empresa con el uso real de software libre. Pero sí, cualquier empresa que esté en Internet, o tenga una conexión hacia Internet, seguro que usa mucho software libre:

• Navegador
• Buscadores como Google
• Routers
• Servidores webs
• DNS
• Todas las grandes “redes sociales” usan software libre: Facebook, Tuenti, Twitter, Digg, Reddit… Menéame mmm, no estoy tan seguro de esta última
• El blog de Eliax

No pensé que a estas alturas hubiese alguien mínimamente inteligente que pudise escribir tantas falsedades con argumentos con la falta de la mínima lógica para criticar al software libre, tema sobre el cuál manifiestamente desconoce. No es un problema ignorar un tema, todos ignoramos cientos de miles, pero escribir sobre lo que se ignora y además para criticarlo de esta manera es, como mínimo, un despropósito.

Por cierto, este señor hablando tanto de libertad y no veo que tenga ninguna licencia en su blog, lo que significa que no autoriza a nadie a re-usarlo. Cosas de la coherencia.

Salgo corriendo al aeropuerto…

Pequeño acertijo físico… o informático

Releyendo mi apunte Seducciones de la informática… me acordé de una pregunta de examen de un instituto de física:

Una habitación perfectamente aislada térmicamente. Adentro hay un enchufe (que funciona) y una nevera con el motor y compresor de gas “perfectos” (es decir, sin pérdidas de energía en forma de calor). La nevera tiene la puerta abierta y se pone en marcha en un momento dado.

¿Qué pasa con la temperatura de la habitación desde el momento que se pone en marcha la nevera? ¿Por qué?

1. Sube.
2. Se mantiene.
3. Baja.

La respuesta se puede encontrar –o mejor dicho deducir– leyendo el apunte mencionado y/o alguno de los enlaces.

Anotaciones científicas de “Seducciones de la informática”

El viernes 9 de octubre di una conferencia en VivaAmerica titulada “Seducciones de la informática“. Salvo quizás la hipótesis de que estamos prácticamente obligados a crear nuevas formas de comunicación, todo lo que menciono no es nada nuevo, más bien son teorías científicas bien fundadas o que están generando un debate interesante en la comunidad científica.

Hace unos meses de Casa de América me propusieron que de una charla “tipo TED” –es decir, para hacer un vídeo de no más de 20 minutos de duración– sobre redes sociales. Les dije que buscaría una forma de hablar de ellas pero desde un punto de vista menos superficial y de hype tradicional que se suele ver en las charlas sobre el tema.

Se me ocurrió que además de ello podría explicar lo afortunados que somos los informáticos al ser testigos de revoluciones importantes en el campo. Fundamentalmente el surgimiento de la bioinformática y los ordenadores cuánticos que son más importantes y radicales que las “redes sociales” aunque se hable poco de ellos. (Aunque no lo mencioné explícitamente, también intento transmitir un mensaje profundamente ateista y contra los defensores del creacionismo, que en sus argumentos falaces deducen que la complejidad requiere que haya un diseñador: en la charla queda claro que es el azar el generador último de esas complejidad).

Fue así que plagié el nombre “Seducciones…” de la asignatura de libre configuración que estoy dando en la UIB donde tratamos estos temas y que fue originalmente creada por Llorenç Valverde (actualmente Vicerector de Tecnología de la UOC).

El eje de la charla son las ideas que usé para la presentación de Carlos Almedia hace unos meses en Palma que a su vez estaba basada en preguntas que me hacía y sobre las que escribí hace dos años: ¿La mejor defensa “científica” de eso llamado redes sociales o 2.0?

Tiene cuatro partes bien diferenciadas (las transparencias en PDF, 3.2 MB):

1. ADN, conocimiento, información e informática (transparencias #6 – #11)
2. La evolución y la influencia del lenguaje (#12 – #14)
3. La teoría de la información (#15 – #16)
4. El universo como un gran ordenador cuántico (#17 – #25)

ADN, conocimiento, información e informática

Se introduce con una visión “clásica” de la información, el conocimiento, la informática, y las relaciones con el ADN. Sobre este tema escribí hace cuatro años en Las cinco formas de almacenar el conocimiento…

1. ADN: Es el primer método de almacenamiento del conocimiento. EL ADN existe para almacenar el conocimiento de cómo crear vida, como una máquina de Turing. El conocimiento está profundamente empotrado, pasar de grado es obligatorio para la supervivencia de las especies. El conocimiento es persistente, pero se actualiza muy lentamente. No tenemos la capacidad de cambiar el conocimiento –todavía, o sí…– de forma intencionada. El ADNpuede hacer crecer un objeto físico que interactúa y modifica el entorno.
2. Cerebro: Es un “experimento” casi exclusivo de la raza humano: almacenar más conocimiento en el cerebro que lo que se hereda en el ADN. Usamos nuestro cerebro para almacenar el conocimiento que adquirimos, fue el segundo método de almacenar el conocimiento que conocimos. El conocimiento es muy volátil, pero podemos cambiarlo rápida e intencionalmente. Podemos aplicar ese conocimiento para afectar y modificar el mundo.
3. Máquinas y herramientas: El valor más importante de una herramienta no es ella en sí misma, sino como ha sido creada y modificada. El conocimiento del creador de esas herramientas es lo que marca las diferencias. Se las suele llamar también “conocimiento sólido” y fue la tercera forma de almacenar el conocimiento. El conocimiento es bastante persistente, pero no es fácil de actualizar. Es intencional y existe para afectar el mundo exterior.
4. Libros: Ha permitido nuevas formas de depositar y acceder al conocimiento que hasta ese momento estaban confinados al cerebro. Hizo al conocimiento portable en el tiempo y en el espacio. El conocimiento es muy persistente, pero de actualización lenta. Aunque los libros son intencionales no tienen capacidad para cambiar al mundo.
5. Software: Es la última forma conocida –de hace sólo unos 50 años– para almacenar el conocimiento. Después de unos inicios dubitativos, está creciendo a una velocidad vertiginosa. Multitud de personas están trabajando para obtener información de las fuentes más diversas, comprenderla, clasificarla y trasladarla a este medio, y entonces intentan validar todo ese conocimiento. Hay una razón para que se invierta tanto esfuerzo, este medio tiene las características que deseamos y que no tienen los otros medios: es intencional, persistente, de actualización sencilla y rápida, y sobre todo es activo.

Al final de esta parte menciono a la bioinformática, una nueva “ciencia” que une los conocimientos de una ciencia natural, la biología, con otra ciencia formal, la informática.

La evolución y la influencia del lenguaje

Con “El origen de las especies” de Charles Darwins aprendimos que la evolución fue –y es– una lucha cruenta y sangrienta por la supervivencia. Aquellos individuos que sobrevivían más tiempo eran los que más se reproducían, transmitiendo así sus pequeñas ventajas genéticas a sus descendientes. Cien años después, también aprendimos que esos genes no son más que pequeñas unidades básicas –bits– de información.

Investigaciones posteriores descubrieron que, a diferencia del resto de las especies, los humanos no respetamos la Teoría de la Evolución, ni al “egoísmo de los genes”, como lo describió Richard Dawkins. Nuestra organización social es diferente, y quizás única en el universo.

Los científicos que estudian estos “extraños” comportamientos humanos nos explican las razones, hemos sido capaces de comunicarnos, de compartir información sobre nuestros deseos e intereses, de cultivar la empatía. Así pudimos establecer objetivos colectivos a corto plazo, en beneficio de otros a más largo plazo.

Como bien lo resume Dawkins en su documental “The big question: Why are we here?”:

Y entonces, ocurrió algo sin precedentes: surgió un cerebro que fue capaz de mirar al mundo y preguntarse, (tal vez por primera vez) la pregunta “¿por qué?”

¿Por qué estamos aquí?

Ya no teníamos que limitarnos a lo que la naturaleza nos diga. Pudimos pensar en metas de acuerdo a nosotros, y desarrollamos una herramienta para expresar estas metas: el lenguaje.

El hablar nos permite compartir metas. Y la criatura capaz de comunicar sus metas empieza a pensar intencionalmente, a actuar intencionalmente, a crear intencionalmente.

E incluso más asombrosamente, a través del lenguaje nuestras metas pueden tomar una vida más allá de cualquier individuo. Un inventor puede producir la rueda. Usando el lenguaje, generaciones de inventores, compartiendo la meta del transporte rápido, pueden producir el automóvil moderno.

La tecnología permite al ser humano realizar sus objetivos con gran eficacia. Y cuando los seres humanos persiguen una meta, ellos mismos fuerzan el paso de la evolución.

Ésta es una forma completamente nueva de evolución, no evolución genética.

La teoría de la información

En 1948, Claude Shannon, un científico contratado por la AT&T para investigar cómo aumentar el número de comunicaciones por los cables telefónicos, publicó el artículo “Una teoría matemática de la información”, que dio origen a lo que hoy conocemos como “Teoría de la Información”. Ese modelo –de origen y objetivos aparentemente modestos– permitió avances radicales en la transmisión y codificación de datos. Es la base de todas las comunicaciones modernas: la radio, televisión, satélites, teléfonos, Internet.

Una de las grandes victorias de la teoría de Shannon es que define matemáticamente la redundancia y que defiune cuánta información puede transportarse por un canal de comunicación, éste es el famoso teorema de la capacidad de canal.

La idea central de la Teoría de la Información es la entropía. Entropía e información están relacionadas íntimamente, de hecho entropía es una medida de la información. De hecho Shannon estaba por llamarle “información”, pero fue Von Neumann el que le propuso usar entropía:

Deberías llamarle entropía, por dos razones. En primer lugar tu función de incertidumbre se ha usado en mecánica estadística con ese nombre, así que ya tiene un nombre. En segundo lugar, y más importante, nadie sabe lo que es realmente la entropía, así que siempre tendrás una ventaja en el debate.

Lo más sorprendente y contraituitivo de la función de incertidumbre de la teoría de Shannon es que un mensaje que es predecible lleva menos información que un mensaje que parece estar formado por caractates aleatorios.

Parece que Shannon no dió demasiada importancia a las similitudes de su entropía de la información con la entropía termodinámica, pero otros científicos sí lo hicieron.

Antes de la teoría de Shannon, en 1929, el científico húngaro Leó Szilárd resolvió la paradoja del demonio de Maxwell(el año está mal en la Wikipedia): el acto de obtener información de la posición de un átomo incrementa la entropía del universo, contrarestando los esfuerzos del “demonio” de decrementar la entropía de la caja.

En 1951, inspirado por la teoría de la información, Léon Brillouin trató de explicar qué es lo que hacía el “demonio” para incrementar la entropía en la caja. Sus conclusiones fueron que la entropía de Shannon y la entropía termodinámica estaban ínitimamente relacionadas, aunque la teoría de la información provee una perspectiva diferente.

Con las leyes de la termodinámica se puede aplicar energía para separar las moléculas frías de un gas encerrado en una caja reduciendo así su entropía. Si se deja de aplicar esa energía a la caja la entropía vuelve a aumentar volviendo así al equilibrio. En cambio con las leyes de la información se aplica energía para obtener y procesar información de las moléculas en el gas, este procesamiento cambia la información almacenada en la caja. Una vez que se deja de aplicar energía esa información almacenada se disipa en el ambiente. La naturaleza intenta disipar la información tanto como intenta aumentar la entropía: las dos ideas son los mismo.

Aunque parce obvio, muchos científicos no estaban de acuerdo. La respuesta final provino de las ciencias de la computación.

En la década de 1930 Alan Turing demostró que una máquina que pudiese grabar símbolos en una cinta, borrarlos y mover esa cinta puede hacer lo mismo que cualquier ordenador concebible. Un ordenador, o el cerebro, no es más que una máquina de procesamiento de información y por lo tanto sujeta a la Teoría de la Información: manipular esos bits de información está ligado al consumo de energía y entropía. Así, los científicos se dedicaron a investigar cuánta energía y entropía se consume o produce cuando se manipulan bits, era el primer paso para entender cómo trabajan los ordenadores y el cerebro.

El físico Rolf Landauer dio en 1961 con una respuesta sorprendente, conocido como el principio de Landauer. Este principio dice que cualquier operación lógica que implique el borrado o la sobreescritura de información implica un aumento de entropía. O dicho de otra forma, cualquier operación reversible como la negación, suma o multiplicación no consume energía ni modifica la entropía. Pero si la operación es irreversible, como el “borrado de bits” entonces sí consume energía que se disipa (es el calor que disipan nuestras CPU) y aumenta la entropía del universo.

La respuesta definitiva lo dió en 1982 el “padre” del cifrado cuántico Charles Bennet en su artículo The Thermodynamics of Computation– a Review, Bennet “mata” definitivamente la paradoja del demonio de Maxwell. El demonio es en el fondo una máquina de procesamiento de información, una Máquina de Turing. Esta máquina debe medir la velocidad de los átomos de alguna manera, guardar ese bit de información en la cinta y ejecutar un programa que tome la decisión de abrir o no la puerta. Pero escribir ese bit implica que en algún momento hay que borrar un bit previo. Aunque se tenga muchísima memoria, ésta no puede ser infinita ya que el número de partículas en el universo es finito por lo que el “demonio” se quedará sin memoria y tendrá que borrar bits al coste de liberar entropía. Así el demonio de Maxwell fue asesinado después de más de 100 años. Pero lo sorprendente es que además quedaba claro que no podría haber máquinas de movimiento perpetuo… demostrado con las ciencias y la teoría de la información.

Y todo esto ocurría con una “modesta” teoría, cuyo autor –Shannon– nunca tuvo la intención de resolver la paradoja de Maxwell ni estudiar las relaciones entre información, partículas y termodinámica.

El universo como un gran ordenador cuántico

La posición y velocidad de un átomo en un gas registra información, es decir, los átomos registran bits ¿Cómo se procesa esa información? Las colisiones atómicas.

En el modelo de Edward Fredkin y Tommaso Toffoli del artículo Conservative Logic (1982) cada colisión realiza las operaciones lógicas AND, OR, NOT y COPY. Fijando las posiciones y velocidades iniciales adecuadas es posible “programar” circuitos lógicos. O sea, los átomos moviéndose en un gas son en principio capaces de realizar procesamiento digital universal. Es muy complejo fijar esas posiciones y velocidades adecuadas para cada átomo, además las colisiones en un gas son caóticas y por el efecto “mariposa” la mínima variación contaminaría el proceso completo. Pero estos problemas pueden (y son) resueltos por la mecánica cuántica.

Como lo demuestra el experimento de la rendija, uno de los “misterios” de la física cuántica es la dualidad partícula-onda. Este experimento demuestra que debido a su naturaleza de ona, una partícula no necesita estar en un sitio determinado. Esta propiedad de estar en varios sitios al mismo tiempo es la responsable de la potencia de la computación cuántica.

Si se coloca uin detector en una de las rendijas la interferencia desaparece, se dice que la interacción ha localizado a la partícula, o sea destruyó su cartacter de onda. Este proceso se denomina decoherencia y se produce ante la mínima interacción con su entorno –por esa es la razón los “objetos grandes” están en un sitio u otro–.

La unidad de información cuántica son es el bit, sino el qubit. Este puede ser un espín nuclear, la posición de un electrón en u interferómetro, no es importante el medio, sino la información cuántica que representa. A diferencia de un bit tradicional puede tener ambos valores, 0 y 1 simultáneamente, hasta que ocurra la decoherencia.

Desde 1980 se discutía la posibilidad de construir un ordenador cuántico que pudiese procesar como un ordenador normal, a principios de los 90 se empezaron a construir los primeros ordenadores cuánticos basados en la resonancia nuclear magnética [*]. En 1994 se publica el primer algoritmo de factorización ejecutable en ordenadores cuánticos, al algortimo de Shor. (Más información: vídeo Seth Lloyd’s Quantum Computer, Quantum Computation Roadmap, Timeline of quantum computing).

[*] Según Decoding the Universe y la Enciclopedia Británica, el primer ordenador cuántico fue fabricado por Isaac Chuang de Los Alamos National Laboratory y Neil Gershenfeld del MIT y tenía 2 qubits.

La idea que el universo sea un ordenador no es nueva, Konrad Suze –la primera persona en construir un ordenador moderno– ya lo propuso en 1967 en su Rechnender Raum que se cita como el inicio de la Física Digital. El mencionado Edward Fredkin es del grupo del científicos de este grupo, como así también Stephen Wolfram (el creador de Mathematica y el más reciente WolframAlpha) extendió la idea de Fredkin y Suze para su autómata celular en su controvertido pero muy vendido libro A New Kind of Science.

Norm Margolus, alumno y colaborador de Tommaso Toffoli, demostró que un sistema físico simple con colisiones de átomos puede realizar computaciones digitales universales. Junto con Lev Levitin publicaron en 1998 el artículo The maximum speed of dynamical evolution donde fijan los límites de las operaciones (flips) sobre los bits (o dicho de otra forma, la velocidad máxima de evolución, que es proporciona a la energía del sistema): el Teorema de Margolus-Levitin.

A partir del teorema anterior y trabajos de Planck, Seth LLoyd en Computational capacity of the universe calculó la capacidad de procesamiento del universo: 10¹⁰⁵ operaciones por segundo, sobre 10⁹⁰ bits. La cantidad de operaciones en total en los 14.000 millones de años calculados del universo son 10¹²⁰ operaciones. Más tarde, en 2004, Lawrence Kraus (autor de La física de Star Strek) y Glenn D. Starkman publicaron Universal Limits on Computation donde analizan la cantidad de información que puede almacenar y procesar el universo, así calculan que al universo le quedan “sólo” 10¹²⁰ operaciones.

Complejidad y azar

Explicar el tema de la complejidad algorítmica o las relaciones entre complejidad y entropía haría incabable este apunte. Pero desde el punto de vista físico, de la información o biológico (recomiendo la conferencia Complexity vs Chance para conocer las ideas fundamentales desde el punto de vista biológico) la complejidad de nuestro universo se explica desde el punto de vista del azar.

Como explicar Seth Lloyd en Programming the Universe (Capítulo 8), esta complejidad es fácilmente explicable desde el punto de vista de la teoría de la información si se considera al universo como un gran ordenador cuántico. Ludwig Boltzmann ya había propuesto que el origen del universo es resultado del azar de fluctuaciones estadísticas. Boltzmann se dio cuenta que su demostración era errónea y no continuó con el tema.

Sin embargo usando la información algorítmica sobre trabajos iniciados por Gregory Chaitin y Bennet (From Complexity to Life: On The Emergence of Life and Meaning) sí se puede explicar el origen de la complejidad a partir de eventos aleatorios. Si a los monos del Teorema de los infinitos monos se cambia la máquina de escribir por un intérprete de lenguaje de ordenador, las probabilidades que generen un código que a su vez genere resultados es mucho menor. Así, aunque 10⁹⁰ monos no hayan sido capaces de reproducir Hamlet desde la creación del universo, sí podrían haber dado origen a estructuras tan complejas como las de universo. La pregunta es, ¿quién genera esas entradas aleatorias? El principio de incertidumbre de Heisenberg: las fluctuaciones cuánticas.

La ciencia en España no necesita tijeras

Aunque me vaya a quedar con las ganas de muchas más, una razón a la iniciativa:

Desde la revolución agraria las sociedades más desarrolladas no fueron las que podían comprar las herramientas, sino las que tenían los conocimientos y recursos para construirlas. Por ello en los países más desarrollados aproximadamente el 80% de la financiación de I+D proviene de fondos públicos. EEUU invierte en I+D  casi el triple del PIB que España, la media europea es el doble, y algunos paises europeos casi cuatro veces más. Las tijeras no generan atajos.

Cinco días bastan

Te trajimos hace cinco días y pocas horas, luego de años de “negociación” para convencer a la madre de las niñas de tener una mascota en casa.

Tenías dos mes, olías mal, estabas engripado, con conjuntivitis, casi no comías ni bebías. Luego te has infectado por culpa de tus defensas bajas.

Cada día te llevamos al veterinario, has aguantado colirio en los ojos, antiparasitarios, inyecciones diarias de antibióticos, limpiezas forzadas, a las niñas que no te dejaban ni dormir.

Hoy martes ya estabas mucho mejor, comías, corrías por toda la casa, has empezado a usar todos los juguetes que te habíamos comprado. Has empezado a subir al muro del balcón. Hemos tenido que cerrar el toldo para que no te caigas.

Poco después de las diez de la noche, después de que las chicas se despidieron, se te ocurrió subir otra vez, te has colado en el espacio entre las rejas. Cuando yo daba la vuelta por la casa corrriendo para cogerte, te has resbalado. Fui a buscarte tembloroso, te llevamos al veterinario pero ya no pudo ser.

Cinco días cuidándote ha sido suficiente para que toda esta familia esté desconsolada.

Recuerdo que la última vez que lloré fue hace 14 años, cuando tuvimos un aborto inesperado del que iba a ser nuestro primer hijo. Pensé que nunca volvería a sentir ese dolor. Aunque pasé momentos muy duros, jamás había vuelto a soltar una sola lágrima.

Hasta esta noche, que puse a cero el contador. Varias veces, y sin poder hacer nada. Tuve que encerrarme para no empeorar el desconsuelo de las niñas.

Lo que puede llegar a hacer sentir un bichito feo, peludo y mil leches, en sólo en cinco días. ¿O es empatía con los hijos? Anyway… será una larga noche, menos mal que al menos ya tengo los nuevos capítulos de House y The Big Bang Theory  gracias a lo último de Casciari.

PS: Lo siento, si no escribía reventaba, ya me siento mucho mejor llegar a la postdata.

La larga cadena de errores del accidente del avión de Spanair

Devoré entero Informe interino A-032/2008 (vía) sobre el accidente del avión de Spanair. El informe es apasionante a los que nos gusta el tema de la aviación. Pero además muestra claramente como los accidentes son una larguísima cadena de errores. En este caso la cadena comienza desde el propio diseño de sistema de la MD80, de los manuales, de las listas de comprobación, inconsistencias de las normativas y finalmente de los pilotos.

Intentaré resumir de forma sencilla lo que dice el informe. Perdón por los posibles errores o imprecisiones, lo escribo de memoria de las 96 páginas –bien densas– y [desfortunadamente] no soy piloto

Básicamente el accidente se produjo porque los pilotos no habían desplegado los flaps (los alerones posteriores de las alas) y los slats (los delanteros) necesarios para el despegue. A eso se sumó un fallo del TOWS (Take-off Warning System), el sistema de aviso de configuración de despegue, que no indicó con alarmas que el avión no estaba preparado para despegar.

Por las conclusiones preliminares del informe, los pilotos han interrumpido la verificación de la lista After Start (después del arranque de los motores y de verificar que la zona está “limpia”). Justo antes de llegar a la verificación de los flaps la verificación se interrumpe para pedir autorización para rodaje. Luego no se vuelve a oir la palabra flaps. Éste fue básicamente uno de los problemas, pero no es totalmente achacable a los pilotos. Las listas de verificación no estaban bien diseñadas ya que items críticos están muy atrás en la lista y se produce en momentos que hay mucha actividad e interrupciones. Además hay que tener en cuenta que era la segunda salida después de la avería de sobrecalentamiento de la sonda de temperatura de aire exterior.

Como decía el TOWS que debía haber hecho sonar la alarma al acelerar los motores no funcionó. La razón era bien sencilla: estaba en “configuración de aire”. Hubo un fallo de un relé, el R2-5, que es parte del sensor de tierra del tren de aterrizaje delantero: cuando se detecta presión en el amortiguador se pone en estado de “sensación de tierra”, el TOWS sólo se activa en esta situación.

Pero aquí hay varios problemas. Según los manuales y normativas, el TOWS sólo debía verificarse al inicio del primer vuelo del día (ya lo han cambiado después del accidente para que se haga antes de cada vuelo) y los TOWS de los MD80, 727 y 737-200 no tienen un sistema para alertar a los pilotos que no funciona correctamente. Aunque hagan la comprobación el sistema podría fallar hasta el momento del despegue y los pilotos no se darían cuenta.

¿Por qué no tiene indicadores? Porque estaba considerado como un equipo de barrera adicional (backup), no como esencial, por lo que no tenía redundancia ni indicadores especiales (pero la otra contradicción es que está en la normativa como “Lista de Equipamiento Mínimo Maestra” –MMEL– por lo que es indispensable para poder despegar).

Y el problema de la falta de redundancia es que por el fallo de un simple relé –el R2-5– hizo que fallase el TOWS y no había forma que los pilotos se enterasen. Pero hay otra triste paradoja relacionada con este fallo que podría haber dado pistas pero que no estaba explicado en ningún manual.

Ese avión tuvo que abortar el despegue porque la sonda de medición de temperatura exterior –RAT (Ram Air Temperature probe)–  estaba dando mediciones muy altas –hasta 105 grados–. Eso ocurría porque se puso en marcha la calefacción estando en tierra cuando sólo debe funcionar en el aire, para evitar el congelamiento.

¿Por qué se encendió en tierra? Porque también depende de la misma configuración de vuelo o tierra que depende el TOWS. Este mismo avión había tenido ya varias averías de ese tipo –son difíciles de debuggear, más aún con el fallo intermitente del R2-5–. Tendría que haber dado una pista que el sistema se sensación de tierra estaba fallando, pero no estaba indicado en ningún manual.

Es sorprendente como un accidente tiene siempre una cadena de errores, incluso tan larga como éste (y abrevié bastante) que comienza con el propio diseño de algunos sistemas del avión y las imprecisiones y errores de normas y procedimientos. Son los problemas de ingeniería  de sistemas tan complejos, con interacciones humanas –las que hacen que funcione todo el sistema de navegación aérea– aún más complejas.

La buena noticia de este desastre es que a partir del accidente de Spanair se han lanzado varias recomendaciones para evitar que vuelva a suceder. La otra buena noticia es que los aviones más modernos tienen ordenadores que hacen varios de los controles que antes se hacía manualmente. Esos ordenadores llegan a simular el movimiento hacia adelante de los mandos aceleradores para verificar que el TOWS funciona correctamente.

Por último, me ha soprendido gratamente el informe. Me da la impresión que la investigación fue (y es, todavía continua) muy profesional y meticulosa. Además está escrita en un lenguaje tan simple que hasta un juez o fiscal podría entenderlo… bueno, perdón por la exageración

Informe interino

A-032/2008

El bug marciano

El día 4 de julio de 1997 el Mars Pathfinder  aterriza en Marte y a las pocas horas empieza a enviar las fotos de Marte en alta calidad que todos conocemos. La misión hasta ese momento de calificó de éxito. Se despliega la nave que sirvió para el viaje y para el aterrizaje –el SpaceCraft/Lander (diagrama inferior)– para dejar salir al Sojounder Rover (la conocida imagen de la derecha).

A los pocos días se detectan continuos reinicios del ordenador del Lander cuando intentaba enviar datos metereológicos y científicos a la Tierra. Los reinicios del ordenador estaban ocasionados por una tarea (bc_sched) que verifica si otras han acabado, de no ser así reinicia todo el software (sin pérdidas de los datos obtenidos, que se mantienen en la RAM).

El hardware

El ordenador de la nave era un Power1/RS6000 de IBM, conectada a un bus VME con interfaces para la cámara, la radio y un bus 1553. El bus 1553 tenía dos partes, una usada para navegación espacial (aceleradores, válvulas, sensor solar y scanner de estrellas) y otra para el aterrizaje  con interfaz para el acelerómetro, radar de altitud y lo sinstrumentos meteorológicos-científicos: el ASI/MET. El hardware del 1553 fue heredado de la sonda Cassini y tenía un modo de funcionamiento simple y obligatorio, el software controlador y toma de datos debía planificarse exactamente cada 0.125 segundos (u 8 Hz).

El software

El sistema operativo usado era el VxWorks, adaptado específicamente al procesador RS600. VxWorks es un Unix de tiempo real desarrollado por Wind River y comprada completamente por Intel hace pocos días (el 17 de julio). La arquitectura del software era la siguiente:

1. bc_sched: Era la tarea con máxima prioridad y se encargaba de preparar las “transacciones” para el siguiente ciclo de 0.125 segs sobre el bus 1553.
2. entry+landing: La tarea con la segunda prioridad, ya inactiva.
3. bc_dist: La tarea de tercera prioridad, toma datos del 1553 y las coloca en un doble buffer circular desde donde extraen información las otras tareas, salvo las ASI/MET.
4. Otras tareas de baja prioridad de la nave.
5. ASI/MET: es la tarea de menor prioridad junto con las otras tareas científicas (generación y compresión de imágenes, etc.). A diferencia de las otras tareas, la ASI/MET toma datos al 1553 a través de un mecanismo de comunicación entre procesos usando el pipe() de vxWorks (es estándard de Unix).

El problema

Luego de detectado el problema se obtuvieron datos de debug del Mars Pathfinder y se simularon condiciones similares con un sistema gemelo en la Tierra trabajando junto con desarrolladores de VxWorks.  Luego de 18 horas de simulaciones descubrieron lo que estaba pasando: por sobrecarga de tomas de datos –era mejor de lo que se esperaban– el sistema estaba más cargado que el peor caso probado en Tierra y ocasionaba la inversión de prioridades que impedía que la tarea bc_dist pudiese acabar… por culpa de la ASI/MET, aunque esta era de menor prioridad.

Inversión de prioridades

Este es un tema que ya se conocía en la “culturilla” informática, aunque no había nada forma ni soluciones hasta 1980 que se presentó una solución en el artículo Experience with processes and monitors in Mesa. Actualmente es un tema muy estudiado en las asignaturas de sistemas operativo o concurrencia, pero sobre la cuál no hay un consenso unánime sobre la mejor solución, aunque la más usada y simple es conocida como herencia de prioridades.

La inversión de prioridades es un problema que se pueden presentar en todos los sistema de multiprogramación cuando se usan mecanismos para controlar la exclusión mutua al acceso de recursos compartidos –como los semáforos mutex–. Antes que un proceso pueda acceder a esa sección crítica debe hacer una operación de wait sobre el semáforo, esta operación puede generar que el sistema operativo bloquee a ese proceso hasta que el proceso que está en la sección crítica en ese momento salga de ella.

Pero puede ocurrir lo siguiente.

Supongamos que A sea el proceso de mayor prioridad, B una de prioridad intermedia y C la de menor prioridad. C entra a una sección crítica, mientras está en ella es “quitada” –preempted– de la CPU para ejecutar el proceso B que tiene mayor prioridad. En ese momento A se ejecuta e intenta entrar en la misma sección crítica que C, como C está en ella A es bloqueado y el planificador del –el scheduler– sistema operativo vuelve a ejecutar el proceso B.

Es decir, C nunca sale de la sección crítica porque hay un proceso B con mayor prioridad, A que tiene mayor prioridad que los demás tampoco se ejecuta porque está esperando que C salga de la sección crítica… pero ésta no sale porque B tiene preferencia.

Este efecto es el conocido como inversión de prioridades y es lo que pasó en el Mars Pathfinder, bc_dist es equivalente a A, las otras tareas de baja prioridad de la nave son B y ASI/MET es C. ASI/MET fue preempted durante  la llamada a la función select() (también estándar de Unix) que daba “acceso” al descriptor del pipe. Esta llama entra a una sección crítica mediante un semáforo mutex que es el que ocasionó la espera infinita de bc_dist.

El diagrama siguiente (obtenido de este PDF) muestra gráficamente lo que acabo de describir:

Cuando se ejecutaba bc_sched, la de mayor prioridad de todas las tareas, ésta detectaba que bc_dist no había acabado su ciclo y reiniciaba el sistema.

Nota: la terminología más apropiada quizás sea “proceso” en vez de “tarea” (no conozco más detalles de cómo están implementados), pero preferí respetar la terminología de los informes oficiales.

La solución

VxWorks sí tenía la opción de habilitar la herencia de prioridades, pero el JPL de la NASA había decido no habilitarla ya que era una variable global que afectaba a todos los semáforos. Una vez confirmado que se trataba de un problema de inversión de prioridades pidieron a VxWorks que analice el efecto global, estos respondieron que afectaría muy poco al rendimiento y que el sistema se comportaría de la misma forma siempre que hubiese un sólo proceso en las colas de espera de los semáforos. Como éste era el caso decidieron que habilitarían la herencia de prioridades de forma global.

Pero no tenían forma de cambiar esa variable directamente en el Mars Pathfinder, el procedimiento era que se debía enviar un parche binario con las diferencias entre el software de Marte con el que tenían en Tierra. Así que tuvieron que seguir este procedimiento, generar el parche y enviarlo por radio a Marte donde un programa preparado lo valida estrictamente y luego lo aplica (es similar  por ejemplo al sistema de parches que se usa para actualizar los teléfonos con Android).

Este “parchado” quizás debería figurar como la actualización remota más lejana realizada a un sistema operativo.

Más información:

• ¿Qué pasó realmente en Marte? [*]
• Página web del Mars Pathfinder

[*] Este es el “resumen oficial” de Glenn Reeves, director del equipo de software de Mars Pathfinder en el JPL de la NASA. Fue una respuesta con correcciones a un resumen de Mike Jones (de Microsoft Research) sobre una keynote de Dave Wilner (CTO de Wind River).

Curiosidad: Como le han “colado” la herencia de prioridades a Linus Torvalds

Linus Torvalds fue siempre reacio a implementar herencia de prioridades en Linux. Lo dejó bastante claro en un email del 2005:

“Los amigos no dejan que los amigos usen herencia de prioridades”
No lo hagas. Si realmente lo necesitas de todas formas tu sistema ya está roto.

Pero resulta que Linux sí soporta la herencia de prioridades desde la versión 2.6.18. ¿Quién lo logró? El fantástico Ingo Molnar. Éste había desarrollado la nueva interfaz de semáforos futex, era una optimización importante ya que casi todo el código se ejecutaba en modo usuario sin necesidad de hacer “costosas” llamadas de sistema en cada operación de semáforos. Estas últimas sólo se hacen en caso de contención entre varios procesos.

Este nuevo método era mucho más eficiente y fue aceptado para el kernel. Años después Ingo introdujo sin demasiada fanfarria –pero muy bien explicado y argumentado– el PI-futex, o lightweight userspace priority inheritance. Así tenemos en Linux un sistema de semáforos con rendimiento similar a los sistemas de tiempo real, además con herencia de prioridades… a pesar que Linus lo había prohibido expresamente tres meses antes. Ingo, genial como siempre

¿”Ingeniería” del software? Ahora vienen los mea culpa

Los que leen habitualmente mi blog conocen mi opinión sobre la “ingeniería del software tradicional”, muchas veces hablé de ello y del “mal” que hacen en general a la profesión, y hasta como limitan la innovación.

Nunca me gustó que se llame “ingeniería” a un proceso que tiene poco que ver con los de las ingenierías tradicionales, entre ellas que las tradicionales poseen una serie de herramientas analíticas y cuantitativas para evaluar y estimar riesgos y tolerancias. En el desarrollo de software no tenemos esas herramientas, quizás nunca las tengamos: no es lo mismo trabajar en la construcción de elementos físicos, limitados por leyes fundamentales de la física, con pocas combinaciones posibles, con la construcción de programas informáticos que no tienen esas limitaciones físicas, ni en las combinaciones posibles.

Este tipo de visión propuesta desde el mismo nombre “ingeniería” nos lleva a errores muy importantes, por ejemplo el de suponer que las construcciones físicas y las matemáticas [los programas] son equivalentes. No sólo hace “daño” a los proyectos que nunca pueden cumplir plazos y presupuestos, sino también a la propia “ciencia” y profesión informática. Es un engaño, fundamentalmente a los propios profesionales. Así se cometen errores derivados como reclamar colegios, regulaciones y normas y procedimientos similares a otras ingenierías: las soluciones equivocadas son más perjudiciales que los problemas abiertos. Además es ponernos una venda en los ojos para no observar el verdadero potencial de la informática, ni para darnos cuenta de dónde está la innovación (que no es precisamente seguir haciendo el mismo software de siempre).

Escribí bastante sobre estos temas, fundamentalmente en apuntes críticos con la creación de los colegios oficiales informáticos. El núcleo de la argumentación es la que comentaba antes, incluso de crear una “pseudociencia” (p.e. en Recursividad, punteros, estadísticas y pseudociencia del software, Diseño, ingeniería, ágiles… y frameworks, Redescubriendo al Dijkstra provocador 18 años después), además enseñado en la universidad como si de leyes científicas se tratasen –quizás lo que más daño hace–.

También critiqué al establishment de la “ingenieria del software”, dominado por tecnológos pocos “científicos” –en su mayoría empleados de grandes corporaciones de desarrollo de software para empresa de Fortune 500– que en ninguna de sus publicaciones científicas presentan los datos para que puedan ser contrastados (algo inherente del software privativo) y sometidos al peer review (que no es aceptable en ninguna otra rama científica). Este mismo establishment ha ignorado durante muchos años al software libre con sus métodos de diseño y desarrollo completamente contradictorios con los propuestos por la “ingeniería tradicional” (muy bien expuesto en al “Catedral y el Bazar” de Eric Raymond).

Muchas de las respuestas que tuve –incluso entre supuestos reputados profesionales– es que “hago daño a la profesión” [sic].

Pero ahora está surgiendo el mea culpa de los gurús incondicionales de la “ingeniería del software”. El reconocido gurú Tom DeMarco (gracias Paco) que escribió el artículo de opinión Software Engineering: An Idea Whose Time Has Come and Gone? (algo así como “Ingeniería del software: ¿una idea de tiempos pasados?”) que es en gran parte una autocrítica a sus ideas y libro de referencia Controlling Software Projects: Management, Measurement, and Estimation.

Resumo sus ideas fundamentales con algunas de sus frases traducidas literalmente:

• Hoy en día todos comprendemos que las métricas de software cuestan dinero y tiempo, y que deben ser usadas con moderación.
• El desarrollo de software es inherentemente diferente de las ciencias naturales tales como las física, por lo que sus métricas son muchas menos precisas para capturar lo que deben describir.
• La frase más citada del libre es «No puedes controlar lo que no puedes medir». Esta frase contiene una verdad real, pero cada vez me sentía más incómodo con el uso que hice de ella. Está implícita en la frase (y en título del libro) que el control es un aspecto importante, quizás el más importante, de cualquier proyecto de software. Pero no lo es.
• Muchos proyectos se han realizado sin demasiado control pero han generado productos maravillosos tales como Google Earth o la Wikipedia.
• Esto nos lleva a la desagradable conclusión que el control estricto es algo que importa mucho en proyectos relativamente inútiles y mucho menos en proyectos útiles. Sugiere que mientras más te enfoques en el control aumenta la probabilidad de que estás trabajando en un proyecto que se esfuerza por generar algo de valor relativamente menor.
• ¿Estoy diciendo que está bien ejecutar proyecto sin control o con un control relativamente menor? Casi. Estoy sugiriendo que deberíamos seleccionar primero a los proyectos cuyo control preciso no importe demasiado.
• Estoy llegando gradualmente a la conclusión que el momento de la ingeniería del software vino y se marchó.
• En los últimos 40 años nos hemos torturado por nuestra ineptitud en acabar proyectos a tiempo y con el presupuesto previsto. Pero como sugerí antes, no debería haber sido el objetivo supremo.
• El objetivo más importante es la transformación, crear software que cambie el mundo, o que transforme una empresa, o la forma en que hace negocios.
• El desarrollo de software es y será siempre algo experimental. Lo construcción real de software no es necesariamente experimental, pero sí lo es su concepción. Allí deberíamos enfocar nuestros esfuerzos. Allí es donde deberíamos haberlo hecho siempre.

Está muy bien que por fin los gurús de la “ingeniería [tradicional] de software” comiencen a reconocer errores y dejar de ignorar a los métodos y filosofías tan habituales del software libre y de proyectos que han sido realmente innovadores desde el punto de vista de gestión de proyectos de software. Todavía se queda corto y esta opinión me deja la misma sensación de dejè vu que me produjo hace unos diez años la moda de lo métodos ágiles y la programación extrema: era algo que ya se veía hace tiempo en el software libre y de hecho era mucho más radical que las “radicales” nuevas metodologías y métricas. Por ejemplo.

Tom DeMarco cita a dos proyectos que le parecen notables para mostrar la contradicción con las ideas tradicionales: Wikipedia y Google Earth. Pero resulta que ambos tienen muy poco que ver y no han sido “seminales” en sus aŕeas.

El software de la Wikipedia [un wiki colaborativo] es muy sencillo y no fue el primero en hacer un programa de este estilo. el éxito e importancia social de al Wikipedia es el proyecto global, y cómo ha conseguido formar una enorme comunidad de gente que comparte valores de fomentar la divulgación libre del conocimiento. Poco tiene nada que ver con “desarrollo de software”, sino con valores y conceptos mucho más amplios.

Google Earth es un programa mucho más complejo pero que ya eran comunes desde principios de la década de los ‘90, con el auge de las estaciones 3D (el líder indiscutible era Silicon Graphics, SGI) y la realidad virtual. De hecho Google Earth surge de la compra de una empresa (Keyhole) que a su vez se basó en otras ideas e implementaciones previas de 1994. El logro fundamental de Google Earth poder acceder a esa cantidad de datos y dejarlos a disposición de todo el mundo, algo que antes sólo podían hacer muy pocas empresas. (En todo caso yo hubiese mencionada a Google Maps, porque mostrar esa información usando sólo HTML y Javascript sí fue una innovación importante, junto con Gmail mostraron el camino del desarrollo de aplicaciones Web/Ajax complejas).

Si yo tuviese que elegir proyectos de software realmente indicativo de las contradicciones con las “métricas tradiconales”, por ejemplo:

• Núcleo Linux: Es muy complejo desarrollaro un núcleo de sistema operativo, la variedad de hardware es enorme, los bugs tienen consecuencias graves, se necesitan mucho conocimientos, tiene una enorme cantidad de elementos independientes, las combinaciones de caminos de ejecución de casi infinitas. Aún así se desarrolló uno que funciona desde los superordenadores más grandes del mundo a los teléfonos móviles, con el aporte de miles de programadores sin ningún tipo de reuniones, coordinación, diseño previo o siquiera documentación básica (ahora ya hay bastantes libros y documentos).
• KDE/Gnome: Dos proyectos complejos, independientes pero competidores e incluso “con esfuerzos inaceptablemente duplicados”, pero que cada uno aportó innovaciones en distintas áreas y se integran o usan en entornos diversos como escritorios completos a dispositivos móviles o multimedias (por ejemplo el Sfari/Webkit que se ejcuta en Mac, iPhones, Androids y Nokias es derivado directo del KHTML de KDE).
• Sistema GNU/Linux o BSD (+ X.org, +GNOME/KDE, +multitud de software): Ejemplo radical de cómo se pueden construir sistemas complejos muy completos basados sólo en una coordinación o consenso mínimó para las interfaces entre ellos. Estas interfaces además son muy simples y no han dejado de evolucionar sin necesidad de “cambios drásticos”.

Cualquiera de los tres proyectos es –en código fuente– órdenes de magnitud más grande que la Wikipedia o Google Earth, además ninguno de ellos dependió de una empresa o fundación, y tienen una complejidad y diversad de uso mucho mayor.

Por eso, está muy bien que empiecen a descubrir todo un mundo allí fuera, que creció y se desarrolló sin seguir las métricas y métodos “tradicionales”. Es aún una mejor noticia que los gurús de la ingeniería del software empiecen la autocrítica de las ideas erróneas que han fomentado durante 40 años.

Estaría ahora muy bien que los fanboys de esa “ingeniería” empiecen a aceptarlo. Pero sería mucho mejor que los responsables de planes de estudio y asignaturas de “ingeniería del software” en las carreras informáticas sean conscientes del problema, al menos ya tienen a uno de sus gurús poniendo en dudas los cimientos de su [pseudo] ciencia. Quizás así dejaremos de leer y escuchar falacias tales como “para ser buen director de proyecto no hace falta saber programar”, “un proyecto es malo si no tiene un diseño previo bien especificado y documentado”, o el mantra:

[...] podemos y/o debemos gestionar un proyecto de software de la misma forma que un proyecto de arquitectura.

Futurología: en unos pocos años veremos que el hot topic en las publicaciones de ingeniería del software serán estudios de caso de grandes proyectos de software libre. Nos hablarán de la radicalidad de los métodos ágiles usados, la coordinación debil, el software evolutivo, la complejidad de las relaciones sociales entre programadores y usuarios, la influencia del uso real de los usuarios para el diseño del software, la importancia del release often, del peer review, los casos reales de uso no previstos por los programadores… y volveré a sentir una sensación de dejà vu.

United States of Bloggers

El título es un homenaje a la excelente serie United States of Tara (que me tiene toda la semana en espera para verla los lunes por Fox Paramount). Se trata de una mujer ama de casa –protagonizada muy acertadamente por Toni Collete– que sufre del trastorno de identidad disociativo. Sobre este último está relacionada esta curioso historia que nos pasó ayer, si la hubiese seguido un psiquiatra [*] seguramente habría sospechado del mismo trastorno

El resumen del historia.

En el Menéame somos muy estrictos controlando el envío y votos con usuarios clones, como así también el astroturfing.   Dedicamos mucho esfuerzo desarrollando el software para que lo detecte automáticamente, y también “horas-persona” controlando y verificando. Somos muy estrictos con esto ya que al principio del menéame empezamos a notar era el truco usado por empresas y redes de blogs para promocionar artificialmente sus envíos. Además de ser una “trampa” nada honesta, es injusta ya que perjudica a los pequeños blogs que no tiene los recursos o tiempo para dedicarse a crear muchas cuentas, reiniciar routers, comentar con “personalidad disociada”… o simplemente que sus principios les impide hacer este tipo de trampas [**]

Digamos que hay un blog XYZ y dos usuarios clones A y B. Hace dos días A hace su segundo envío, ambos del blog XYZ. Casi inmediatamente el usuario B comenta en la misma noticia. El sistema nos avisa de posible astroturfing, vamos a verificar y vemos que:

• A y B son usuarios clones, usaban el mismo ordenador, el mismo navegador e incluso el mismo perfil (el software del menéame detecta esto, cualquier programador podría encontrarlo rápidamente).
• B había votado los dos envíos de A a los pocos minutos, para poder hacerlo tuvo que reniciar su router para coger una IP diferente.
• B también había comentado en los dos envíos de A, por supuesto con opiniones favorables.
• Un usuario deja un comentario diciendo que es “spam”, el usuario B afirma que el blog es de él y le pide a A que deje de enviar de su blog para que no crean que B hace spam.
• El email de A es XYZ@gmail.com (el mismo nombre que el blog que B dice ser el autor).

Verificados todos esos datos procedemos a banear el blog temporalmente –un mes– y deshabilitamos al usuario A. Dejamos un comentario en el mismo envío enlazando a las normas y copiando el texto específico:

meneame.net/legal.php#tos
El usuario se abstendrá de crear múltiples cuentas con el fin de promocionar sitios webs, participar en discusiones simulando las opiniones de personas distintas (astroturfing)…

A las pocas horas –ayer– recibimos el siguiente email de queja:

Humillación y baneo injusto a unos usuarios legítimos

Han cometido un error al banear al usuario A por astroturfing, ya que es una persona diferente al usuario que hay detrás de B. Le expongo los hechos, punto por punto:

• Yo soy B y A es mi hermano.
• El blog es mío y no quería aparecer en Menéame ya que, como todos sabemos, las visitas que genera son de muy baja calidad (con esto me refiero a esporádicas y con un índice bajísimo de fidelización). Tampoco quería que mis contenidos enriqueciesen a unos pocos listos, cosa que a mi no me pasa al querer ofrecer un blog libre de publicidad.
• Hace unos días le dije a mi hermano que se registrara en Menéame (craso error, ya que en su lugar debería haberme ido yo) y él quería enviar noticias. Sin embargo, la mayoría de las noticias de sus blogs preferidos ya estaban meneadas y enviaba las de mi blog. En los comentarios de la noticia en cuestión le digo que no menee mis noticias.

Revisen los comentarios y verán que se han equivocado. Sin embargo, sé que no lo reconocerán por vuestro afán de poder y ego desmesurado ¡Qué lástima que no aprendieran nada sobre el abuso de poder en aquella revolución virtual que hubo!

Por último me gustaría hacerle llegar la opinión de mi hermano y que yo comparto: Sois unos auténticos dictadores. Espero que se dignen a responder a estos ex-usuarios que con sus actividades algo habrán contribuido a vuestros cuantiosos ingresos, cosa que dudo de unos tipos de tal catadura moral.

Emails como estos, de clones que niegan ser la misma persona y que contratacan con insultos e incluso amenazas de publicar en blogs, son cosas casi de todos los días. Pero tenía varias cosas que me llamaron la atención y me parecían que tenían chicha para averiguar qué más había:

• Habla de “baja calidad” y “fidelización” para un blog que tiene sólo dos entradas y que habían sido enviadas al Menéame en menos de 24 horas.
• Sabía el truco de reiniciar routers para poder votar la noticia de su otro clon. Hablaba del banday –la típica excusa– así que no podía ser un usuario novato ni con intenciones de “arreglarlo”, sino lo contrario.
  
• Nos acusa e insulta siguiendo el “patrón habitual” del  que escribirá un apunte comentando lo malos-malosos que somos los del Menéame.

Así decido contestar y enterarme qué o quién estaba por detrás. Recibimos la respuesta, la parte interesante:

Perdóname Sr Gallir por estar de vacaciones en mi casa y hacer uso del ordenador familiar. También perdóneme por no empezar todos mis comentarios con un ¿Sabía que el usuario A es mi hermano?

Le voy a ser sincero, lo del cambio de IP fue precisamente porque creí que podían pensar que estábamos haciendo astroturfing y supongo que no hay medios para saber si verdaderamente hay dos personas. Después pensé que era una paranoia mía y no volvía a hacerlo.

Seguían sin cuadrarme las cosas, el email de su hermano era en realidad el del blog, más los votos y comentarios en ambas noticias desde el mismo perfil del navegador y con pocos minutos de diferencia nos hacían estar casi seguro de que no era toda la historía.

Respondí nuevamente.

El siguiente email aclaraba todo el asunto, o no, pero al menos es un poco más creible:

Le voy a contar toda la verdad para terminar de una vez con esto. El autor es A (mi hermano pequeño) que inició el blog a petición mía para que se introdujera en este mundillo. Me dijo que meneará algún post suyo para darse a conocer, pero yo no podía debido a que no tenía el karma suficiente. Se registró y meneo su primer post. Me dijo que le habían acusado de Spam, y para que no lo masacraran a negativos dije que el blog era mío. No hay astroturfing, sólo un caso muy dudoso (sólo dos post) de Spam. Le cuento esto para que sepa la verdad, ya que no me gusta mentir. Créalo o no, sinceramente me da igual.

Una historia muy curiosa (mi respuesta final), de las tantas que tenemos y que la falta de tiempo, obligada discreción y la LOPD nos impide contar con toda su sofisticada belleza disociada que envidiarían hasta los guionistas de United States of Tara

——

[*] Uno de los admins del Menéame es un reconocido psiquiatra madrileño –un puto crack como profesional, mejor aún como persona–. Muchas veces nos asesora en estos temas, y me parece que muchas veces tampoco encuentra explicación

[**] Este control es lo que más problemas y críticas genera. Muchos de esos apuntes de blog criticando tan ferozmente porque somos unos fascistas dictadores censores, o que no permitimos la promoción de blogs son derivados de las medidas que tomamos cuando detectamos estos abusos con clones. Lo que pasa es que esa parte de la historia no la cuentan, ya nos lo tomamos casi en broma, pero antes me afectaba mucho personalmente.