El viejo truco informático, sobre todo en sistemas domésticos o poco comprometidos, es apagar y volver a encender el sistema en cuestión antes de dar ningún otro paso. Eso no siempre es posible, y uno esperaría que en sistemas más profesionales esto no fuera necesario. Sin embargo, y en el apartado de cosas que uno no esperaría que puedan suceder en este curioso artículo Boeing 787s must be turned off and on every 51 days to prevent ‘misleading data’ being shown to pilots nos cuentan que los sistemas informáticos de estos aviones necesitan apagarse y volverse a encender para estar seguros de que mostrarán la información correcta a los pilotos.

Como anécdota personal, en cierta ocasión no funcionaba el sistema de entretenimiento (la pantallita) y la azafata la arregló apagando y volviendo a encender mi ordenadorcito, no sin insistir un poco porque no parecía darle importancia.

Esta necesidad viene en forma de orden de la Administración Federal de Aviación de EEUU:

The US Federal Aviation Administration has ordered Boeing 787 operators to switch their aircraft off and on every 51 days to prevent what it called “several potentially catastrophic failure scenarios” – including the crashing of onboard network switches.

El problema sería que los pilots podrían ver información incorrecta:

According to the directive itself, if the aircraft is powered on for more than 51 days this can lead to “display of misleading data” to the pilots, with that data including airspeed, attitude, altitude and engine operating indications. On top of all that, the stall warning horn and overspeed horn also stop working.

Por devolver la fe sobre estas cosas siempre le podemos echar la culpa en el caso del Boeing a que se trata de sistemas antiguos. El otro día podíamos leer U.S. Air Force Performs First Ever Code Change On A Flying U-2 Spyplane Running Kubernetes. Allí nos explican un caso de un avión espía U-2 actualizando código mediante este sistema de contenedores, en vuelo. Eso sí, no está claro el alcance de la actualización.

We don’t have the whole details here, so the extent of the “update” is not clear (actually, the deployment of a new container in Kubernetes can be seen more like a configuration update than a code change). Anyway, the achievement of the latest milestone proves that the U.S. Air Force is continuing to advance in its program to give its weapons system the ability to leverage the power of containerization.

Interesante.

Actualización (2020-11-03): En otros modelos de la casa, nos enteramos de que Boeing 747s still get critical updates via floppy disks.

Pen Test Partners discovered a 3.5-inch floppy disk drive in the cockpit, which is used to load important navigation databases. It’s a database that has to be updated every 28 days, and an engineer visits each month with the latest updates.

Los sistemas de control de versiones se basan en poder calcular de manera eficiente la diferencia entre dos ficheros. En How different are different diff algorithms in Git? hablan justamente de eso.

Identifican tres casos de uso de estas diferencias y comparan sus prestanciones.

From our systematic mapping, we identified three popular applications of diff in recent studies.

Fundamentalmente: recolección de métricas, identificar la introducción de fallos (bugs) y obtener parches (patches). Con dos algoritmos, Myers e Histogram.

In our empirical analyses, we conduct three comparisons based on the most popular usages of git diff found in our mapping study: collecting metrics, identifying bug introduction, and getting patches. We investigate the disagreement between two diff algorithms: Myers and Histogram, and take a manual measurement of their quality in generating the diff lists.

Lectura interesante.

Un ejercicio curioso en Getting a program right, in nine episodes donde Bertrand Meyer nos acompaña donde desarrolla un programa sencillo y lo va mejorando mediante técnicas de verificación formal.

Aunque el testing ha ganado muchos adeptos hay que recordar lo que decía Dijkstra: las pruebas pueden demostrar la presencia de errores, no su ausencia.

in fact, I have always thought that the inevitable Dijkstra quote about testing — that it can only show the presence of errors, not their absence

Esto no es hablar mal de las pruebas, es sensacional poder encontrar partes de nuestros programas que están mal.

La verificación aporta otro tipo de valores, y de eso va lo que se puede leer allí. El programa es una búsqueda binaria, que es un concepto fácil de entender, pero no tan sencillo de hacer complemtamente bien.

Interesante.

De la mano de blockchain han venido los smart contracts: se trata de ‘programas’ o ‘codificaciones’ de intenciones, condiciones y consecuencias que gracias a esta tecnología permitirían que determinados contratos puedan ejecutarse sin necesidad de que los humanos intervengan (en la realización de los hechos del contrato en sí, se entiende).

Desde la ignorancia informada, uno siempre ha pensado que si se ha de codificar determinadas condiciones de la vida en un contrato la cosa ya es suficientemente compleja. Si a eso le añadimos la ejecución automatizada, es probable que haya que hilar más fino. Y, claro, aparecen los bugs y las vulnerabilidades.

De esto hablaban en Las 5 vulnerabilidades más habituales de los Smart Contracts y lo más gracioso es que los fallos se parecen mucho a los de los programas ‘normales’.

• Errores aritméticos con números enteros

Desbordamientos, falta de precisión, …

• Vulnerabilidades del límite de block gas

El límite de block gas es la forma que tiene Ethereum de asegurarse de que los bloques no crezcan demasiado. Simplemente significa que los bloques están limitados en la cantidad de gas que las transacciones contenidas en dichos bloques pueden consumir. En pocas palabras, si una transacción consume demasiado gas nunca cabrá en un bloque y, por lo tanto, nunca se ejecutará.

En determinadas circunstancias esto provoca que haya instrucciones de los contratos que nunca llegan a ejecutarse.

• Falta de parámetros o controles de precondición

Si hace falta que algo se cumpla a la hora de ejecutar un contrato, debemos estar seguros de que los datos que se reciben son adecuados.

• Frontrunning

El frontrunning potencial es probablemente el tema más difícil de prevenir en nuestra lista de vulnerabilidades comunes. Este puede definirse como la apropiación de una transacción no confirmada, y es consecuencia de la propiedad de transparencia del blockchain.

• Bugs de lógica simples.

No hace falta buscar, de todas formas, fallos muy sofisticados. Parece que es frecuente encontrar:

… el problema más común que detectamos es la presencia de errores simples en la lógica del smart contract. Estos errores pueden ser el resultado de una simple errata, una mala comprensión de la especificación o un error de programación mayor …

Interesante.

Esta entrada habla de Python, pero a veces por desconocimiento (o comodidad) no utilizamos todas las características de nuestros lenguajes favoritos y me pareció de interés.

En Reduce Memory Usage and Make Your Python Code Faster Using Generators hablan de los generadores, como un mecanismo para gastar menos memoria y generar un código más eficiente en Python.

Técnicamente, un generador es una función que utiliza yield en lugar de return nos dice el autor.

A generator looks a lot like a function, but uses the keyword yieldinstead of return. Let us take an example for better understanding.

Cuando hacemos una llamada tenemos un valor, pero con algunas característias interesantes. Por ejemplo, la función next(), que nos devolverá el siguiente valor generado por la función original (esto es, es una función que nos puede ir proporcionando valores sucesivos).

The important thing to note is how state is encapsulated within the body of the generator function. You can also step through one by one, using the built-in next() function:

En Python podemos utilizar la función range() para generar una sucesión de valores, que genera(ba) un coste importante (según el tamaño, claro) en espacio y tiempo al ejecutarse. Aunque allí no se dice, que hace mucho tiempo que teníamos xrange() y que en Python 3 range() también es un generador, con lo que el problema no sería tal.

En todo caso, parece que casi siempre merece la pena evaluar las consecuencias de las estructuras que utilizamos.