Hace 1 año | Por Larpeirán a didyouknowfacts.com
Publicado hace 1 año por Larpeirán a didyouknowfacts.com

La verdad sobre qué tipo de insecto podría haber sido se ha perdido en el folclore, aunque las leyendas dicen que era una polilla aplastada, y como todas las leyendas, parece haber algo de verdad en alguna parte. Según el erudito Fred R. Shapiro , el 9 de septiembre de 1945 (o tal vez 1947), los ingenieros de Harvard estaban trabajando en el Mark II, o Aiken Relay Calculator, que estaba siendo probado por la Marina de los EE.UU. Después de mirar el hardware, encontraron que una polilla caducada había quedado atrapada entre el relé 70 y el pane

Comentarios

mecha

#3 La traducción horrible, el artículo está en wikipedia ES:
https://es.wikipedia.org/wiki/Error_de_software

Trigonometrico

#3 Y si hubiera puesto bug entre paréntesis en el titular, nos enteraríamos de qué va la noticia de un vistazo.

cenutrios_unidos

#4 Es que estaba apolillada, por lo tanto caducada.

Idomeneo

Una buena ocasión para recordar las palabras del gran Dijkstra:

We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation. The nice thing of this simple change of vocabulary is that it has such a profound effect: while, before, a program with only one bug used to be "almost correct", afterwards a program with an error is just "wrong" (because in error).

Fuente: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

Robus

#7 Mmmm... supone que todos los bugs son errores y eso no es siempre así.

Tu puedes montar una librería que funciona perfectamente y viene alguien y la usa para algo para lo que no estaba pensado, en esas circunstancias se puede producir un problema pero no es un error de la librería y tampoco tiene porque serlo del programa que la usa sino de la interacción de ambas.

Ejemplo muy famoso: Un servidor se colgaba siempre las noches de luna llena.

Nadie sabía porque, el servidor funcionaba perfectamente todos los días pero las noches de luna llena (exactamente la noche de luna llena, no aproximadamente) se colgaba.

Debugaron el código y encontraron que la fecha la obtenían de un programa externo al que llamaban y este colocaba en cierta posición de memoria el día, el mes, el año y la hora... pero quien había hecho el programa, que no tenía nada que ver (ni conocía) a los que lo habían tomado de la red y lo habían utilizado en el servidor, había querido añadir que, las noches de luna llena, mostrase un "full moon tonight" al lado de la fecha... al llamarlo desde otro programa y dirigir su salida a una posición de memoria funcionaba hasta que las noches de luna llena, al ser la cadena más larga, machacaba código adyacente en memoria y causaba un fallo del sistema.

¿Es un error del primer programa? No... ¿lo es del segundo? tampoco, es un problema de integración de dos programas sin errores, y eso es un bug.

Idomeneo

#9 Pues no estoy de acuerdo. Para eso existen las especificaciones.

Y una biblioteca cuando la usas acaba formando parte de un programa, ya que se considera como un todo. De hecho la GPL no distingue entre enlace estático o enlace dinámico, si usas una biblioteca, pasa a formar parte de tu programa.

sorrillo

#9 Si el primer programa no estaba diseñado ni pensado para ser usado por terceros el error es de esos terceros por pretender usarlo para tal fin sin ser exhaustivos en sus pruebas, y si no es realista ser exhaustivos, por ejemplo simulando fechas futuras, entonces el error es presuponer que va a seguir funcionando bien en el futuro. El error es no resolver el problema de otra forma que no suponga esas incertidumbres.

Si el primer programa sí se diseñó para ser usado por terceros ese caso debió estar documentado, error del primero si no fue así, error del segundo si fue así y no atendieron a esa documentación.

Es posible que se pueda encontrar algún ejemplo en el que no sea error de nadie pero este no lo parece.

JackNorte

bug= error Polilla =bug

cenutrios_unidos

#1 Aunque poca gente conoce que de esa misma historia viene lo de bugs bunny.

ailian

#1 Bug significa "insecto", no polilla.

JackNorte

#12 y aun asi una polilla sigue siendo un insecto. Pero sin duda una polilla no es un error

M

borrado

M

borrado