Portada
mis comunidades
otras secciones
#1:
Me quedo como comenta el usuario klazerver :
#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
Lo siento por la familia, aunque hayan pasado más de 20 años, estas desgracias siempre se llevan a la espalda
#22:
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).
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).
#3:
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:
#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.
Comentarios
Me quedo como comenta el usuario klazerver :
Vaya una patata de artículo!
Desde luego la wikipedia como comenta #1 tiene mucha más información sobre el tema.
#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.
#25 Te sorprendería la cantidad de errores de primero de carrera que se llevan a produccion
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
#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
#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.
#5 No de dominio público, sino accesible al público. Igual que una novela, por ejemplo. Entiendo que quería decir eso.
#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.
#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.
#8 Tenéis un vídeo bastante ilustrativo que viene acorde con el comentario #2 en
#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).
#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: https://www.redhat.com/es/open-source
#32 existen los emuladores
#7 Y por eso salieron las licencias de software libre. La GPL por ejemplo obliga a que los softwares derivados sean libres también
#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.
#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)
#2 ¿Qué arreglarías con eso?
#2 Estaba programado en ensamblador, así que el código fuente exacto se puede extraer de la máquina.
#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.
#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.
#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
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.
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).
#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.
#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.
#50 joder. No debería ser posible pero me lo creo, lamentablemente, me lo creo.
Bueno, de algo hay que morir.
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.
Hoy es el día de publicar dupes? Errores de software. Cosas que nunca debieron haber ocurrido
Errores de software. Cosas que nunca debieron habe...
mtholyoke.edu#18 Ese enlace está roto.
#21 ah, es que si el enlace no se mantiene, se puede repetir? No sabía eso...
#35 Hombre, si solo hay un enlace y no es accesible.....
#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?
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
"Todavía muchos programadores de software alegan frases como “nadie murió por un error en el código“" ¿Los programadores web?
#29 Y los programadores de gestión.
#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í.
#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
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.
#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
#13 que te informen a toro pasado no es lo mismo que tú dices.
#23 Con el corporativismo médico hemos topado. Está casi a la altura del que existe en el ejército.
#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
#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.
#55 Si quieres un bombero que le pise la manguera a otro habla con un perito medico
#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
#43 El papelito que tu dices se llama consentimiento informado y obviamente no cubre las negligencias. Faltaria mas
#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.
#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
#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.
#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
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
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.
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.
"Bug" no está en el diccionario de la RAE
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.
Software asesino, 9 muertos, 14 heridos graves
Software asesino, 9 muertos, 14 heridos graves
itweb.co.zael 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
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...
#62 En círculos de programadores amateur.
¿Y ahora se culpa a los programadores del poco respeto que tiene la sociedad hacia nuestro trabajo?
#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".
#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.