EDICIóN GENERAL
102 meneos
3364 clics
Este envío tiene varios votos negativos. Asegúrate antes de menear

Morir por culpa de un bug

Katty murió a las pocas semanas y fue uno de los tantas víctimas del “bug de la Therac-25“ y según dicen luego de este caso fue necesaria la elevación de los estándares de testeo y revisión de código en sistemas médicos. Esto sucedió hace más de 20 años y si bien a la fecha los sistemas de radiación fueron perfeccionados y un error de estos ronda lo imposible todavía muchos programadores de software alegan frases como “nadie murió por un error en el código“. Seguramente ellos no conozcan la historia de la Therac 25.

etiquetas: morir , culpa , bug , therac-25 , katty
  1. Me quedo como comenta el usuario klazerver :

    <<Muy interesante el post, pero también muy corto, se acaba justo cuando le hace a uno agua la boca y no especifica nada sobre el error.

    En la Wikipedia encontré información muy interesante que sirve de complemento perfecto: es.wikipedia.org/wiki/Therac-25
    >>
  2. Y por estas cosas, absolutamente todo el código fuente debería ser público.

    Lo siento por la familia, aunque hayan pasado más de 20 años, estas desgracias siempre se llevan a la espalda :'(
  3. #2 Que sea público no alcanza. Si no hay programador que se interese en revisarlo puedes imprimirlo y mandarlo casa por casa. Debería haber auditoria obligatoria
  4. Creo recordar que un cúmulo de errores en el código de la centralita electrónica de algún modelo de vehículo provocaba el bloqueo del acelerador en modo "a fondo" y que fue la causa directa de un buen número de accidentes mortales y no mortales hace bastantes años, fue un escandalazo en su momento que dio lugar a indemnizaciones multimillonarias. Así que no sé por qué ese mito de que los errores de software no han matado a nadie.
  5. No me he leído el artículo, pero conozco el suceso. Nos lo pusieron de ejemplo de los peligros de un sistema concurrente.

    Fue un cumulo de despropositos, para empezar los tíos se habían montado su propio sistema operativo. Amigo, no reinventes la rueda.

    Por un error, era posible lanzar radiaccion sin montar el escudo protector. El bug es gordo, pero esque no entiendo porque no hicieron una protección por hardware (si no está el escudo instalado, no puede disparar).
  6. #2 No veo por qué todo el código fuente debería ser público. Si una empresa invierte dinero, tiempo y esfuerzo en desarrollar una herramienta útil para ella o para terceros, tiene derecho a protegerla y obtener beneficios en la manera que prefiera: venta de licencias, servicio en la nube, copyleft, etc.
  7. #22 En algo tan crítico como es la radiación deberían existir varios failsafes y no confiarlo todo a uno sólo ya sea soft o hard.
    Como dices, es incomprensible.
  8. #1 El programa cambiaba una variable bandera incrementándola, en vez de asignarle un valor fijo. Ocasionalmente ocurría un desbordamiento de variable, haciendo que se ignoraran chequeos de seguridad.

    Increíble que un error de este calibre se lleve a producción. Esto es de primero de carrera. o_o
  9. #6 Tampoco estaría de acuerdo con eso. El código fuente de un programa puede contener una solución costosa y valiosa, que suponga una ventaja competitiva para una empresa. Cualquiera que pudiera verlo tendría medio trabajo hecho para desarrollar un programa similar.
  10. #2 Eso no te asegura que el código sea revisado. De hecho para eso existen las auditorías de código que es lo que se debe hacer para algo así. (Y por entidades independientes).

    Por ponerte un ejemplo yo he trabajado para un banco y mi código se auditaba por 2 empresas independientes tras entregarlo. (Aparte de hacerle pentesting y demás). Eso tras haberlo testeado y revisado mi empresa y el propio banco.
    El código obviamente no era público (ni veo por qué tendría que serlo)
  11. Bueno, de algo hay que morir.
  12. Vaya una patata de artículo!
    Desde luego la wikipedia como comenta #1 tiene mucha más información sobre el tema.
  13. Cualquier muerte evitable es una desgracia. Aún así, viviendo en un mundo controlado cada vez más por algoritmos me parecen pocas las que hay.
  14. #7 #6 Lo que quería decir es que debería ser accesible al público para que pueda ser analizado por cualquiera, con la licencia adecuada.
    #7 Hombre, si eres capaz de montarte una máquina como estas en casa... El problema es que necesitas el hardware para usar el software, así que por muchas ventajas competitivas que tengas, si no es con ese hardware no va a funcionar.
  15. A ver, la historia es curiosa como tal pero la redacción pésima y mínima la información sobre el caso... mucho mejor la info de la wikipedia
  16. #5 No de dominio público, sino accesible al público. Igual que una novela, por ejemplo. Entiendo que quería decir eso.
  17. #29 Precisamente entraba a preguntar si a nadie le había chocado lo de que todavía muchos programadores de software alegan frases como “nadie murió por un error en el código“. No es que tenga muchos amigos, pero no conozco a nadie que diga una cosa así.
  18. "Todavía muchos programadores de software alegan frases como “nadie murió por un error en el código“" ¿Los programadores web?
  19. #13 Los papelitos que te hacen firmar antes de una intervención o tratamiento, por más que digan y quieran, no eximen en absoluto de responsabilidad en caso de negligencia. Para lo único que sirven es para que no puedas alegar desconocimiento de la naturaleza de la intervención o tratamiento si se producen efectos secundarios previsibes o cosas similares. Pero, por lo demás, si el médico la caga, paga. CC #9
  20. Ahora no mueren por errores médicos, si la cagan te intentan colar el justificante de que estabas informado de posibles efectos adversos del tratamiento.
    Y lo digo por experiencia propia.
  21. Articulo pobre, corto y que no entra a fondo.
    Si es el caso que creo, el error tenia que ver con el modo de entrar los datos
  22. #2 Claro hombre, claaaaaro. SUponiendo que el error este en la parte de validación o la del sistema del desarrollo en V de un proyecto de SW, y se produzca el error cuando, por ejemplo, se introducen los datos en un orden determinado, se avance en el programa, y luego se vuelva atrás cambiando un dato, como por ejemplo reajustar los KeV de la emisión. Claro, ese error se solucionaría con código abierto.

    Para ello, cada persona que quisiese emular el código, debería comprarse la máquina, introducir el código, e ir testeando y validando toooooodos y cada uno de los casos, por lo que también deberá comprar detectores, phantoms....

    No es SW de ordenador para reproducir una peli, o retocar cuatro fotos. Es una máquina de rayos!! Para ello, ya están los grandes equipos de testeo de estas compañías, los controles médicos y regulatorios que han de pasar, y las múltiples pruebas y ensayos clínicos que realizan antes de llegar al mercado de forma masiva.

    Errores y fallos siempre los va a haber, SIEMPRE, y lo que hay que exigir es una gran calidad e inversión por parte de estas empresas en equipos de test y validación, y que pasen los máximos controles posibles (aunque esto conlleve otros problemas como barreras de entrada al mercado de salud, demora en años en la finalización de estos proyectos, etc.. ). Pero con SW abierto no se conseguiría un carajote.
  23. #29 Y los programadores de gestión.
  24. #18 Ese enlace está roto.
  25. #35 Hombre, si solo hay un enlace y no es accesible.....
  26. #7 Y por eso salieron las licencias de software libre. La GPL por ejemplo obliga a que los softwares derivados sean libres también
  27. #8 Tenéis un vídeo bastante ilustrativo que viene acorde con el comentario #2 en www.youtube.com/watch?v=a8fHgx9mE5U
  28. #25 Te sorprendería la cantidad de errores de primero de carrera que se llevan a produccion
  29. #2 no tiene nada que ver una cosa con la otra, hay millones de códigos fuente abiertos, y siguen conteniendo fallos.

    El problema está básicamente en dos puntos, la poca revisión del código (creo que por aquel entonces no existían los QA team) y los malos testings, donde se centran en probar el 99% de las veces las cosas como tienen que funcionar, y no se dedican a encontrar fallos.

    Por ultimo, a la hora de la verdad, en producción siempre ocurre la casuistica mas extraña y ocurren cosas inesperadas.
  30. #55 Si quieres un bombero que le pise la manguera a otro habla con un perito medico
  31. #9 Si no quieres asumir riesgos de un medicamento o de una operación eres libre de rechazarlo; salvo en los poquísimos casos de riesgo para la salud pública
  32. Para algo están las auditorías internas y externas. Así como los testeos y pruebas. Además de las mejoras en los standards que el propio artículo refleja, como pasa en otros campos.

    De todas maneras este es un caso de lo más extremo. Y el artículo bastante flojete.
  33. #13 que te informen a toro pasado no es lo mismo que tú dices.
  34. #45 No, es un dogma, como que magisterio se aprueba son estudiar y sin currárselo, que el software nunca ha matado a nadie y que nunca han despedido a nadie por comprar productos IBM.

    Obviamente las tres afirmaciones son falsas, y por otra parte la gente odia y admira a partes iguales lo que no comprende.

    Si un niño de doce años hace una aplicación de Android con AppInventor cargada de bugs es un gurú. Si hacemos tú o yo una aplicación de 3 en raya picándote todo el código desdecero y haces un análisis del funcionamiento de la aplicación tal y como te piden en tu asignatura de calidad de software y eres un fracasado porque una de las imágenes que aparece en la aplicación es fea o "has hecho un simple tres en raya".
  35. Un artículo poco interesante sobre un tema muy interesante, casi que los comentarios son mucho mejores y luego nos quejamos de que la gente no lea la noticia. Es casi categoría gente de bart.
  36. #21 ah, es que si el enlace no se mantiene, se puede repetir? No sabía eso...
  37. #37 Entonces? tendría que haber más repetidas? A partir de cuantas empezamos a considerar que son realmente repetidas?

    Hummm, entonces se puede hacer un script para comprobar la vigencia de todos los meneos y, en caso de fallar el enlace, buscarlo en google y subir uno nuevo, no?
  38. #42 los malos testings, donde se centran en probar el 99% de las veces las cosas como tienen que funcionar, y no se dedican a encontrar fallos.

    Cierto, no importa las perrerías que me aguante el código sin problemas durante las pruebas, me basta con enviarlo a los técnicos para que lo usen y rápidamente me encuentran los fallos :-P
  39. "Bug" no está en el diccionario de la RAE
  40. #2 esa afirmación es un especie de dogma de fe en la bondad humana. Hacer todo el código público sirve tanto para mejorarlo como para meter cualquier bug difícil de detectar. Y estoy pensando en código muy concreto en el que he trabajado que por razones de seguridad no podría hacerse público.
  41. #38 ha muerto muchísima gente por errores de software/implementacion, el problema es que muchas veces es difícil identificarlos como único responsable de la tragedia
  42. #13 Que te informen a toro pasado no es legal. Primero han de explicarte la intervencion con sus riesgos mas frecuentes y los mas graves y luego firmas el consentimiento informado. Te llevas una copia a casa y si cambias de opinion simepre puedes cambiar de opinion
  43. #43 El papelito que tu dices se llama consentimiento informado y obviamente no cubre las negligencias. Faltaria mas
  44. #26 A veces, el corporativismo medico se confunde con que otro medico, con mas conocimiento y perspectiva que el propio paciente sabe que a veces las cosas no van bien. Que aun asi existe? Por desgracia si
  45. #56 El consentimiento informado no es válido si no se firma con 24 horas de antelación. Salvo urgencia. Si hay riesgo vital no hace falta siquiera
  46. #50 joder. No debería ser posible pero me lo creo, lamentablemente, me lo creo.
  47. #2 Estaba programado en ensamblador, así que el código fuente exacto se puede extraer de la máquina.
  48. Ha muerto muchísima gente por culpa de un "bug" y cualquier programador "responsable" que escriba software para cuestiones críticas lo asume. Si programas un robot ensamblador de coches sabes que si el brazo de 1500 kilos se descontrola puede arrancarle la cabeza a alguien. Si programas un ascensor inteligente sabes que puede volverse loco y caer descontroladamente o chocar contra el techo si se va todo el soft a la mierda. O un puente levadizo computerizado que atrape coches, o una factoría o central nucelar, o un robot cirujano, o un vulgar marcapasos que de repente enloquezca por un bug y deje frito a su pobre usuario.

    Todo software que controle procesos físicos puede causar daños físicos, hasta una, en apariencia, inocua lectora de CDs puede, y ha causado, heridas graves si se descontrola, acelera el disco hasta su casi desintegración y se abre de repente lanzando el disco a toda velocidad como si fuese una sierra radial voladora.

    Precisamente una de las primeras noticias que envié a este portal (con otro avatar, que me gusta cambiar) versaba sobre un cañón anti-aereo computerizado con un bug que provoco 9 muertos y decenas de heridos al disparar contra los humanos en vez de contra los blancos.

    www.meneame.net/story/software-asesino-9-muertos-14-heridos-graves
  49. #32 existen los emuladores
  50. #23 Con el corporativismo médico hemos topado. Está casi a la altura del que existe en el ejército.
  51. el factor humano y de la maquina son fundamentales en el desarrollo de cualquier actividad, imaginaros que el programador con un contrato precario que halla programado de mala fe cientos de equipos medicos u ordenadores de cualquier sistema vital, menudo estropicio de sociedad

    lo mejor para que una sociedad prospere en bienestar e igual son empleos dignos y un sistema educativo de calidad sino pueden ocurrir muchos sabotajes por explotacion desmesurada
  52. #54 Si un médico no tiene más conocimiento y perspectiva que el paciente, acabáramos. A veces las cosas no van bien porque hay mala praxis y no hay conocimiento, ni doctorado que valga. Si hay mala praxis y se tapa, hay corporativismo. Yo no tenía ni idea de que esto era así hasta que me ha tocado sufrirlo personalmente y es desesperante. Entre bomberos no nos pisamos la manguera.
  53. #53 El papelito que sigo diciendo, se llamará consentimiento informado o la carabina de Ambrosio, pero el hecho cierto es que nunca te lo dan con antelación, sino escasos minutos antes de practicarte la intervención o la prueba (yo siempre los he firmado con el camisón puesto). Igual que con las escrituras notariales (sobre todo las de hipoteca). Que se lo quiere leer con detenimiento: ¡oh, por supuesto! Siéntese allí y lea tranquilamente, que nosotros ya llamamos a otro y, si eso, ya le avisaremos a usted cuando podamos atenderle.
  54. #57 Pues apunta, porque yo, ya te digo, en el propio vestuario (mejor dicho, tabuco al efecto) y con médico, enfermera y anestesista allí, junto a la mesa, casi en presenten armas. Me hace gracia, porque no hace ni 24 hora que hablábamos de esto mismo con mi hermano (DUE) y unos amigos suyos, uno de ellos médico. Y no me ha ocurrido una vez ¿eh? sino cada 18 meses, cuando toca colono.
  55. #2 ¿Qué arreglarías con eso?
  56. #28 El código puede ser abiert, vale. ¿Pero cómo realizas la verificación? Necesitas de un hardware. No habría que confundir el código abierto con el desarrollo de código de un producto comercial (que puede basarse en código abierto).
  57. #32 en el caso que dices, las empresas que hacen el hardware ya se ocuparán de proporcionar material suficiente a la comunidad para que ésta haga un buen desarrollo y el hardware se pueda vender bien.

    Si no te ha convencido el vídeo, puedo ponerte más ejemplos: www.redhat.com/es/open-source :-)
  58. ¿Y ahora se culpa a los programadores del poco respeto que tiene la sociedad hacia nuestro trabajo? :palm:
  59. De la wikipedia:

    El fallo sólo ocurría cuando se introducía una secuencia particular de teclas en la terminal VT100, que controlaba la computadora PDP-11 de la Therac-25. En un plazo de ocho segundos, se debía de pulsar la tecla «X», (que erróneamente seleccionaba el modo de fotones de 25 MeV), seguido de «cursor arriba», seguido de «E» (que seleccionaba el modo de electrones de 25 MeV) y «Enter». Esto ocurría muy raramente y se desconocía que existiera tal error.

    Aparte que ese terminal y ese ordenador fueron mi introduccion a la informatica (Dios, que viejo me siento...), el tema tenía su coña.. dudo que ningun sistema de chequeo o de calidad del software fuera a pillar esto (el origen del error) , aunque esta claro que el fallo gordo era permitir que , fuera como fuera, se pudiera configurar el sistema de forma que achicharrara al paciente...
  60. #24 Ni te imaginas la cantidad de máquinas de grabado y corte por láser que pueden disparar estando la tapa levantada. No es una marca ni dos, son muchísimas. Y se soluciona con un interruptor de pontencia puesto en serie con el conmutador de disparo del tubo.
  61. #51 Me refería a la frase : 'todavía muchos programadores de software alegan frases como “nadie murió por un error en el código“'

    No sé en qué ambientes de programación se debe mover uno para escuchar esto pero de la boca de los programadores que conozcono no sale, más bien de sus cuñados y sus sobrinos.
  62. #62 En círculos de programadores amateur.
comentarios cerrados

menéame