El Software Que (A Veces) Te Mataba Con Radiación

[@Sergio1096]

Yo recuerdo en mis clases de informática que los profesores nos repetían "cualquier cosa que programen, háganlo a prueba de idiotas, aunque la instrucción sea agregar un número entre 1 y 5, siempre habrá alguien que agregará una letra". Y ver este video me recuerda a eso, parece que las cosas que programas están bien pero no tomas en cuenta muchos factores externos.

[@RubénAldoGarcíaGonzales]

y tambien a prueba de gente habilidosa. Puede que tu programa sea perfecto para un oficinista cualquiera. Pero que lo toque una secretaria con un APM que rivaliza a campeones de RTS van a saltar errores que ni imaginabas que podrian ocurrir.

[@El_Balak]

Exacto, en mi caso en el mundo del diseño gráfico también vale, hay que crear las cosas pensando que todos son idiotas

[@misilagata]

Acordáos del software del Boeing 737 MAX. Mató a los pasajeros de dos Jumbos completitos.

[@nonm956]

me paso recientemente soy tecnico de mantenimiento en una empresa y me llamaron por radio para acudir a una maquina dobladora que no doblada cuando llegue me dice el operador que la maquina no dobla y le aparecen rayas a sus valores revise y me di cuenta que estaba oprimiendo la letra "i" en el campo donde debe de haber solo numeros para el angulo de dobles y esas eran las lineas que decia la letra "i"

[@hola_y_buenDia]

la falla no es del software en si, si no la logica de systema del contexto general. la falla es que eligieron a un ingeneiro de software para hacer eso y esta muy mal. el ingeniero de software es debil en dar se cuenta en la logica general de las circunstancias solo la logica del algoritmo. es un falla de systema debieron de contratar a un ingeniero de systemas que de un esquema de la circuntancia general conun ingeniero de seguridad industrial ambos luego de estudiar el esquema general recien pedir a un igeniero de software que haga dentro de la esquema de probelmaticas de la interaccion fisica etc, y un experto en seguridad de redes y de informatica. la falla es del gerente del invesionista porque no entiende las ciencias generales que se interconectan que implica. muchas veces solo ve reducir gasto.

[@jschellDev]

Impecable video, hace 13 años que soy programador y pase por varias empresas (algunas internacionales muy muy grandes) y te puedo asegurar que no siempre se aplican procesos correctos de testeo, revisión, etc, es la interminable lucha entre intentar bajar el costo y ser bueno al mismo tiempo.

[@hugobracamontesbaltazar]

Lamentablemente eso sucede no solo en empresas que desarrollan software...

[@intron9]

Exacto y lamentablemente no es cosa exclusiva de los 80s , sino de toda la vida. en los 2000s se vendieron Toyota Camry que se aceleran solos, aún siguen funcionando porque le conviene más a la empresa pagar los juicios.

[@heribertoperezteran8316]

Pienso que de manera redundante debió tener un medidor de radiación que detuviera el proceso en caso de sobreexposición, pero seguramente en esos tiempos la cultura de minimización de riesgos era distinta.

[@jeminuz]

El testing es visto como innecesario por la mayoria de las empresas porque cuesta dinero y causa retrasos y a cambio no da "nada". Muy pocas empresas entienden que ese "nada" que aporta el testing bien hecho, es usabilidad y satisfaccion del cliente que puede valer millones de dolares. Eso sin contar los bugs que directamente causan perdidas financieras. Pero de todas las empresas en las que he trabajado, 90% prefieren no tener QAs o si los tienen, tratarlos como si no fuesen necesarios.

[@nicoperez4319]

*la interminable lucha entre bajar costo y vender mas y primero*

[@jovkniemozna]

yo soy Analista QA y cuando me certifiqué, este fue el ejemplo que salió en la clase, yo soy de los que se encargan de encontrar estos tipos de errores... excelente canal, suscrito!

[@zeta9028]

6:13 ODEVOVLE AL CREADOR DEL VIDEO

[@zeta9028]

ODEVOLVE A @Ricardo Vargas jovk a su huevo todo lo del video *HAÁ a su mam4*

[@SHORELESSPRODUCTIONS]

Te hago una petición especial confio te acuerden de mi si algun dia notas este error, Single event upset error de evento unico te pido exijas el uso de ram con ECC (código de corrección de error) para los dispositivos medicos en especial los que operan la retina tengo un panico o la idea de que un rayo cosmico golpee a a la maquina que te opere

[@jovkniemozna]

@@SHORELESSPRODUCTIONS conozco las memorias ECC, de hecho he trabajado con ellas

[@dorantesjoseluis3887]

Perdón la ignorancia que es "QA"?

[@juanibordarojas]

En una de las primeras clases de introducción a la computación nos hablaron de este caso y el del avión que automatizaba los controles con software

[@diegorr1378]

¡¡Espectacular vídeo!! Curiosidades: Soy técnico en radioterapia en España, además de estudiante de medicina xD. La dosis habitual de un tratamiento no son 10 Grays, sino 60. Igualmente, 200 Gray es suficiente para asar a un paciente. Aquí en España, en Zaragoza, creo que en los años 90, hubo un problema parecido, pero no sé si de Hardware o de Software. La máquina en cuestión adminsitraba una dosis mucho más alta de la prescrita, con un resultado fatal para los pacientes. Desde entonces, todos los días por la mañana, se calibran todos los equipos de radioterapia con un dispositivo para garantizar que la dosis programada coincide con la dosis real administrada por la máquina. Por cierto, efectivamente los electrones se usan para tratar tumores superficiales, como los de piel, y algunas enfermedades no tumorales, mientras que los rayos X permiten irradiar tumores en profundidad. Hoy en día los electrones apenas se usan. La novedad es el tratamiento con protones. Me encanta tu contenido !!! Un saludo

[@ROCK0115]

Oye pero las dosis y el plan de radiación se hace en función del paciente, y se dan a dosis bajas. Muchas veces en muchas sesiones.

[@Luis45ccs]

El habla de 2 grays no 10 como tu dices, pero igualmente dices que un tratamiento normal es 60, ya eso no lo se, soy de programación no radiologo pero almenos concuerdan en que 150 a 200 Grays ya es una muy fuerte sobredosis.

[@JorgeMadTor]

@@Luis45ccs La dosis de radiación estandar son 2Gy por sesión. Suelen oscilar de 50 a 70Gy, es decir de 25 a 35 sesiones si es un tratamiento estandar con intención curativa. Esto es lo estandar, aunque cada vez se tiende más a hipofraccionar teniendo más dosis por sesión y menos sesiones. Tratamientos paliativos suelen oscilar de 3 a 8Gy por sesión, dependiendo el número de sesiones. 150Gy o 200Gy no existen en radioterapia externa como tratamiento externo. El problema no es la dosis total, que lo es, si no recibir una dosis de 20Gy en una sola sesión sin ningún control. Actualmente existen tratamientos denominados SBRT donde esas dosis de 20Gy si existen en única sesión muy controlado el blanco, con haz muy colimado y mucha precisión. Esas dosis necrosan el tejido y siendo muy precisas permiten realizar lo que se denomina una radiocirugía compitiendo con un tratamiento quirúrgico convencional.

[@JorgeMadTor]

@@ROCK0115 A cada paciente el físico médico, en España radiofísico hospitalario diseña un plan distinto, la dosis por sesión dependerá del objetivo del tratamiento y el esquema que mejor se ajusta. Este esquema de tramiento lo decide lo decide el oncólogo radioterápico en función del cáncer a tratar.

[@tubeyou8903]

No sé nada de radioterapia, así que, aunque digan cosas interesantes, no les daré like a ninguno hasta informarme 😄

[@Alazarg6k4wF2xJ3g]

Hubo negligencias gravísimas por todas partes. Que una máquina de la que literalmente depende la vida de personas pueda seguir funcionando después de dar códigos de error del tipo que sean es una incompetencia imperdonable. Pero que tanto el hospital como la empresa la pusieran en funcionamiento de nuevo afirmando que habían conseguido multiplicar por 100000 la seguridad sin entender cuál y cómo fue el error que costó la vida y salud a varias es una negligencia que sobrepasa lo criminal.

[@cobayototoro29]

tienes razón

[@jaxonsantamaria738]

la cuestion son las estadisticas, esas maquinas estaban en muchos lugares del mundo y en mas de 99% de los casos habian funcionado bien y sin problemas, nadie piensa nunca en el peligro que pueda representar una probabilidad de menos del 1%, por eso se confiaron.

[@JorgeMadTor]

Muy interesante el video. Soy físico médico en España. Aquí denominado Radiofísico Hospitalario. Es muy curioso conocer todo esto, saber de donde venimos, donde estamos y donde quizás irá el futuro. Hoy en día los tratamientos ya no los introduce el operador, son diseñados previamente a través del físico médico mediante software, este tratamiento con todos los parámetros es volcado a una red y finalmente la red comunica con el acelerador para realizar el tratamiento. Existen estándar básicos para evitar cualquier tipo de confusión en este aspecto con todos los parámetros físicos de hz. La emisión de radiación genera en toda la sala señales luminosas de aviso. No mediante software ni hardware si no mediante detectores independientes del propio acelerador. Me resulta increible que se pueda irradiar y que el operador en dichos años no era consciente de que el acelerador estaba en funcionamiento. Además es necesario pulsar físicamente un botón para iniciar la irradiación, nunca una irradiación se puede iniciar exclusivamente por software. Los enclavamientos (interlogs) de hardware, hoy es impensabe que solo por software se pudiese irradiar sin un control electrónico de hardware en el que se verifica que los parámetros básicos de irradiación son correctos antes de generar el haz. Diariamente se controla que el acelerador acepta de forma correcta los parámetros y que la dosis de haz es correcta. Además mensualmente se realiza una verificación con detectores más finos de que el acelerador irradia de forma correcta. Hoy en día, los tratamientos antes de ser irradiados en pacientes son verificados al irradiarse en un detector, teniendo que ser coincidente la dosis. Al no existin variable humana de introducción de parámetros y ser los parámetros de la red los que configuran el haz permite verificar que el tratamiento es correcto. En España se han tenido incidente importante como fue el incidente de Zaragoza, este incidente fue producido porque un técnico de la empresa responsable del acelerador puenteó las energías irradiando siempre con la energía superior. En dicha época los físicos médicos eran testimoniales en el país y no existía legislación que obligara a prueba ninguna. Hoy en día esto es imposible, tras la intervención de un técnico de la emrpesa, el radiofísico, o físico médico debe verificar que los parámetros de haz se mantiene mediante mediciones independientes. Agradezco enormemente este video, conocer de donde vienen los mecanismos de seguridad actuales y además un toque de atención para estar siempre alerta pues tanto software o hardware no siempre es perfecto debiendo existir varios mecanismos de seguridad que impidan un accidente en radioterapia.

[@intron9]

Son cosas que suceden cuando las empresas tienen demasiado poder, poca responsabilidad, y productos deficientes de los que solo quieren exprimir dinero. No es cosa de los 80s , en los 2000s salieron Toyota Camry que se aceleran solos, aún siguen funcionando porque le conviene más a la empresa pagar los juicios.

[@oscarsalas5017]

Hola. Soy desarrollador de software, me llama la atención que el área de informática haya hecho "copy-paste" del software, evidentemente al haber actualizado el hardware se requiere actualizar el software. Muchas veces se asume que el esquema de un software es entrada-proceso-salida, lo correcto es entrada-validacion-proceso-validacion-salida, esto evita muchos errores, además nunca es bueno asumir que nuestro trabajo está bien, siempre debemos verificar. Saludos.

[@esanchoe]

La "Reutilización de Código" es habitual en el desarrollo de software, permite aprovechar el trabajo ya realizado, reducir tiempos de desarrollo y economizar recursos.

[@HYP3RK1NECT]

@@esanchoe Hacer un uso consiente de los snippets (revisandolo que no tenga errores semánticos).

[@oscarlopeztorres6842]

Este canal vale oro, no le canso de recomendarlo en los foros, ojalá tengas mucho más audiencia

[@Alexis-hj6ci]

Ahora que estás hablando de fallos catastróficos de software me acordé de la vez que una zonda espacial, que costó millones de dólares, se estrelló por el simple hecho de qué en uno de los pasos se les pasó el realizar una conversión del sistema inglés al internacional.

[@juanaguilar829]

También un avión canadiense estuvo a punto de siniestro por lo mismo

[@Luis45ccs]

@@juanaguilar829 Si, se quedo sin gasolina por poner libras en lugar de kg o no recuerdo si eso lo miden en litros y la unidad inglesa no de, cual es pero seria como medio litro asi colocaron solo la mitad, no se bien como fue el calculo

[@Alexis-hj6ci]

@@Luis45ccs Es que era de los primeros aviones en ese aeropuerto en usar medidas en el sistema internacional y los que lo recargaron no revisaron. Además resulta que el sistema de medición de combustible tampoco funcionaba bien y marcó como que estaba lleno aunque no lo estaba.

[@_Tao__]

Otra razon por la wue el sistema internacional es mejor

[@alpha-draconis]

y el problema del MCAS de Boeing, que se lo achacaban a los pilotos pero terminó siendo un funcionamiento anormal del software

[@sanjaques]

Siempre tuve esa sensación de probable falla en el momento de irradiar ya sea por el simple cambio de un switch, o filtros en aparatos menos complejos, pero no por causa del software y menos que lo descubran en el hospitalel problema ; muy buen video, soy de Mantenimiento Elecronico

[@plantonevil5823]

Es increíble cómo una coincidencia puede ser tan letal en tantas ocaciones, esto solo deja en claro que nosotros como humanos no podemos evitar un asistente pero si evitar su causa.

[@RandMV]

Asistente?

[@Luis45ccs]

@@RandMV creo que quiere decir una concordancia

[@sorauten6068]

*Accidente

[@IIISpeeder]

@@sorauten6068 Hablando de errores de software. Especificamente con el autocorrector . ^^ Bueno. Justo este es otro ejemplo del por que no confiar ciegamente en el software. No siempre puede estar listo o adivinar las intenciones del usuario u operador. Este incidente pudo evitarse si el autocorrector estuviese apagado o el usuario hubiere tenido un poquito mas de paciencia para evitar el blunder. (es lo que hay tener dedos mas rapidos que la cabeza o actuar mecanicamente) Por otra parte yendo a terrenos de neurociencia este ejemplo tambien ilustra lo que llamabas problemas de condicion de carrera. usualmente los movimientos programados por habito son de respuesta mas rapida que los meditados dado que nuestro sistema nervioso tiene configurada una jerarquia de ejecucion donde la prioidad maxima se da a la medula espinal (reflejos) de ahi al bulbo, de ahi al cerebelo, de ahi al rombencefalo y finalmente al cerebro propiamente dicho. (por eso mismo las emociones afloran primero antes de pensar en las acciones mismas)

[@srhayami]

Otro tema de error de software y hardware en cierto modo de era moderna, fue el 737 max8, que esta detectaba que el avión estaba entrando en perdida, y le quitaba el control a los pilotos y corregía el trim mientras este estuviera en automático. Ojala lo pudieras investigar y hablaras de ello en un futuro video. Creo recordar que parte del problema era que el procesador se sobrecargaba y el software empezaba a fallar.

[@voidedcracker0771]

No es el del vídeo pasado?

[@FacuA0]

Eso ya lo habló en el vídeo pasado.

[@stardust1985]

No sé porque KZbin me mostró esto, pero increíblemente interesante y sobre todo bien explicado, ya tengo con que pasar el insomnio.

[@kevinhernandez-et1mz]

Dios!!! Necesito más vídeos, son adictivos. Excelente narración y trabajo investigativo amigo.

[@funny_man]

En la lista de lecciones aprendidas yo agregaría, también, que es muy importante tener registros de eventos (log) para poder repasar los pasos que llevaron al error. Pienso que el error se podría haber evitado, si después de configurar el equipo, se pasaba a una pantalla de carga donde se configuraba todo el hardware y una vez configuraba todo, mostraba un reporte de como estaba configurado y preguntaba si quería iniciar o no.

[@sjosephc7pamaster20]

pense exactamente lo mismo,muchas cosas se pudieron haber evitado si hubiesen log

[@jampgold]

Ya se lo estoy compartiendo a mis amigos "las actualizaciones de Software son innecesarias", "No se toca lo que ya funciona". Excelente vídeo 👍🏽

[@andres614]

Pues ese no es el mensaje del vídeo 😂

[@RayRapidoso]

Definitivamente este se está volviendo poco a poco uno de los mejores canales de divulgación sobre software que hay en youtube.

[@senderista7365]

Que video tan increible, me encanta que no solo cuentas una historia, sino que lo haces desde una perspectiva de programador. Con este tipo de material solo me apasiono más por mi carrera. Increíble, nuevo sub!

[@RonBastidas]

Maestro Saitama, siempre es un placer verle por este medio, sobre todo cuando se pone a divulgar... un abrazo!

[@RingaTech]

Abrazo de vuelta, que bueno que te gustó, saludos!

[@horochigundam7648]

Jajajaja c mamo

[@danierun2077]

C mamo XD

[@viruett7659]

una marravilla la calidad de divulgación y investigación, me gustaria seguir viendo videos como este !!!

[@elorozko]

Cómo estudiante de ingeniería biomédica este tipo de videos me encantan, magnífico contenido el que subes, me encanta.

[@panterxs4153]

lo use como podcast mientras hacia un trabajo para la universidad relacionado con el software en las instituciones publicas, muy interesante, y estoy de acuerdo con las reflexiones al final del video, el uso y mantenimiento del software es de vital importancia para su correcto funcionamiento eso es básico, en especial para esta clase de situaciones una lastima que se perdieran vidas por estos errores...

[@SuperBlablabla3]

Me paso parecido hace poco, en 2 computadoras con el controlador de una tarjeta wifi usb inalambrica aunque no estuviera conectada, solo en 1 computadora de cada 50 causa problemas, lo que causaba era congelaba como de 2 o 3 segundos cada 30 minutos y seguia funcionando normalmente no se apagaba o daba pantallaso asi todo el dia, se asocia normalmente a problemas de sectores dañados en el disco duro o el cable en mal estado, pero revisabas sectores dañados todo bien, el cable por si si o no lo cambias por uno nuevo, y seguia dando problemas, hasta llegas a pensar que es la tarjeta madre, formateabas y igual mismo problema, querias grabar un dvd, cd, transferir archivos o cualquier tarea que demore buen tiempo y la maquina con este problema no era confiable por que en cuanto ocurria eso te hechaba a perder la grabaciones y tareas programadas pendientes... POR FIN que di con el error despues de meses, de que era el driver de las tarjetas wifi que instalaba eran unas Netgear WG111v2 tipo G de 54mbps, en ciertas computadoras con chip de video intel G31 y G41 trabajando con sistema windows XP con su version de driver wifi mas reciente, que por cierto son muy pocas ya por eso me costo dar con ese error, el santo remedio fue instalarle un driver mas antiguo a ese sistema y sin la utilidad de netgear dejando que el sistema gestione las redes inalambricas, por cierto se consiguieron esas antiguas tarjetas inalambricas a buen precio y se ve que son de calidad, a pesar de ser antiguas tienen antenas potentes en distancias un poco alejadas son muy estables trabajan mejor en la practica que una usb wifi china tipo N de 150mbps, cumplen bien para el trabajo y hasta ahora ninguna se ha dejado de funcionar, solo por ese pequeño problema muy raro y especifico con el driver, salieron buenas en general esas usb netgear

[@Namnoh]

Ringa, estos videos así son genialeeess, me encantan, por favor no dejes de hacerlos, usualmente no estoy al pendiente de noticias así, pero en el formato en que las cuentas, y las formas que lo haces, lo hacen muy entretenido, me hace interesarme mucho en la historia. Muy buen video, Ringa.

[@DanielFrias6388]

Persona necesita radiación: Doctor: bien. Máquina: *Poner la pata de elefante dice.

[@ErickGonzalez-uw3cg]

Lo prometido es deuda!!! Excelente video Rodrigo, Siempre aprendiendo algo nuevo...

[@canelarurimutti1540]

Cuando veo estos casos de negligencia me tiembla la mandíbula de rabia, pobre de la gente que murió por culpa de eso

[@ricardoestrada7323]

Impresionante video. Y un tema muy muy poco tratado. Por favor necesitamos más videos asi

[@DavCov88]

Excelente e interesante contenido. Deberían mostrar este video en todas las escuelas y universidades donde impartan programación!, saludos

[@JoseMolins]

Impresionante video, enhorabuena por el detalle y por la buena explicación.

[@ElkinMarenco]

De los mejores videos sobre desarrollo de software que he visto, muchas gracias.

[@Lv7-L30N]

Es realmente importante hacer este tipo de revisiones, personalmente nunca digo que tengo algo listo hasta que no estoy seguro que tengo todo tipo de situaciones posibles en el codigo. Muchas gracias

[@bryansanudogarcia1691]

Buenas tardes , muchas gracias, demasiada calidad en el contenido del canal y la forma de difundir estos temas, da un punto de vista muy diferente. simplemente gracias 10/10

[@ajoloteenvaso]

soy ingeniero de software en USA y sinceramente tu video es increible!!!! gracias por tu esfuerzo.

[@ninjamasterretro]

uffffff me encanta este tipo de videos siendo del área de ingeniería de sistemas Ringa seguí con este tipo de casos de software que falla y explicando las fallas, excelente

[@Ikuuu]

Excelente vídeo y clara explicación. Resulta atrapante el tono con el que lo relatas, dan ganas de ver hasta el último segundo. Otra cosa que noté y que me gustó mucho, fue que en la animación de la pantalla del Terac25 al cambiar la X por la E, en la parte inferior derecha aún sigue seleccionado el tratamiento para rayos X. Esos pequeños detalles de producción que ayudan a comprender el relato valen oro.🙌

[@GustavoGil05]

Excelente información, muy buena para reflexionar sobre nuestra labor como programadores. Hoy en día se toman las pruebas y los desarrollos de software muy a la ligera, el marketing también hace estrago en nuestro medio, se venden literalmente o a veces se regalan, librerías y frameworks como la panacea, la solución a todos los problemas, lo mejor de lo mejor... y luego aparecen en los sistemas esos fantasmas, bugs, duendes, que luego el programador no sabe porqué. Hoy en día se abusa de los equipos, allí en lo que cuentas una persona fue la responsable, ya que no se nombra un equipo, pero hoy en día son equipos gigantes con gente que entra y sale, yo creo que aún es peor, tanto el control como los aspectos de seguridad y confiabilidad.

[@Luis45ccs]

Muy cierto, siempre hay que estar rodeando errores de capas inferiores, horrible

[@JuanCarlosRojas]

Excelente análisis de fallas y muy bien documentado, felicitaciones.

[@victormamani9814]

Este video esta muy bien elaborado, aunque no estudie ingeniería en sistemas, incidentes como este pueden pasar en cualquier otro campo laboral, las fallas de seguridad están en todos lados y nunca debemos dejarlos pasar por alto

[@TeeNKa]

Buenísimo el video la verdad, según lo que llego a ver como desarrollador de software y acorde a lo que pude aprender de la vida, puedo ver cómo el desarrollo tiene que ser de lo más orgánico posible. Cosa que en casos como estos no lo es, más que nada porque los individuos que suelen estar a cargo de empresas intentan responder a una demanda rápida de las solicitudes de diferentes individos en instituciones siempre ligadas a contratos burocráticos que se interponen en una relación orgánica entre ambas partes para conseguir productos que sean seguros como se necesitan en estos casos y que además, si llegan a conseguir algo tan importante como la máquina, los individuos pueden conseguir tanto poder en un sistema que salen impunes ante determinados eventos como la muerte de algún paciente porque no se corra la voz. Muchos pensarán seguro que las regulaciones de seguridad establecidas para estos desarrollos son lo que va a evitar que en futuras invenciones sucedan accidentes tan horribles. Sin embargo no puedo evitar ver a estas regulaciones como desinsentivos y dificultades de nuevos competidores para que desarrollen mejores sistemas con menor presupuesto, cosa que los que ya están dentro de los ámbitos tecnológicos, ya tienen por sus propios medios el dinero para, o pagar el desarrollo de diferentes parámetros de seguridad exaustivos, o para pagarle a los burócratas de turno que viven de estas regulaciones. Y que aún así terminan con accidentes como el del Samsung Galaxy S7 si no me equivoco, que estallaba la batería por física básica. Ojo que no estoy proponiendo sistemas ni estar en contra de algo, lo que sí estoy viendo es cómo siempre se desarrollan desinsentivos al crecimiento orgánico por medio de diferentes burocracias, y todo lo que rompa paradígmas cada vez es más dificil de crear y siempre termina siendo por los mismos actores que tienen el dinero para poder realizarlas y hasta normalmente se basan en un conjunto de pequeños cambios ya creados independientemente. Que ojo, no está mal que se hagan este conjunto de cambios, pero las trabas para la proyección orgánica a gran escala se hace cada vez más notoria.

[@loquenderogamesful]

Trabajo en el departamento de validaciones, y me encargo de validaciones de sistemas computarizados/automatizados, realmente mi profesion no es relacionada con software o hardware, pero si con la industria farma, donde se usan equipos automaticos, mi curiosidad por los computadores y ganas de juguetear se pueden usar adecuadamente oara encontrar errores en el software de los equipos, y es parte del trabajo de validacion, este ejemplo sirve mucho para aprender

[@gansito.nice1]

Me encantó tu video, tus explicaciones, el tema etc. Me gustaria ver mas videos como este.

[@AlexanderGarcia-mo1bk]

Gracias por estos videos tan informativos. Ojalá KZbin recomendará más este tipo de canales.

[@kevinhoward3258]

Muy buen video sabes ahora pensando si no tenemos cuidado y usamos nuestro se sentido comun como humanos y dejamos muchas cosas en manos de la inteligencia artificial y pensamos que cada cosa que nos indica es segura y precisa creo que a futuro podremos ver muchos problemas como este por eso nunca debemos fiarnos por completo de nada. Saludos desde Costa Rica y sigue con este tipo de contenido vas muy bien.

[@ReynaldoRamos666]

Este canal es pura calidad ... Si youtube promocionara más este tipo de contenido, ahora seriamos una mejor sociedad. Podrías hablar de Stuxnet ... Me gustaría tu magistral explicación, y como abordarías el tema !!!

[@handbed]

Espectacular historia quiero más, Lo que más me ha gustado, ha sido la explicación, el énfasis en los detalles

[@jorgitoaguero2087]

ME ENCANTA EL AMBIENTE, LA TEMATICA, LO TECNICO; LA NARRATIVA, ME SUSCRIBO CAPOOOO

[@susejzepol]

Muy interesante, ahora miraré la fase de QA con otros ojos.

[@cruzjaviertenoriolira4128]

Exelente contenido. Acabo de descubrir este genial canal, ojalá tengas muchos éxitos en tu canal.🙏🏻

[@joolobo5530]

La importancia de que en todos los departamentos médicos, exista un programador responsable de hacer el mantenimiento y verificaciones correspondientes. Excelentes videos, saludos

[@cesarbernal1864]

Si, se le llaman Ingenieros Biomédicos.

[@joolobo5530]

@@cesarbernal1864 mi ignorancia te lo agradece 😁😊

[@Luis45ccs]

@@joolobo5530 los programadores que indicas estarian en las empresas fabricantes de equipos no en hospitales o clinicas

[@alejandroatencio08]

Muchas gracias por el contenido, es un excelente contenido, se agradece mucho. saludos.

[@guillermopereyra5494]

Super interesante y aparte poco"visto"lo que habla este video,aparte de las demandas legales a las empresas implicadas,es mala prensa y seguramente a nadie le conviene demasiado ventilar estas cosas,por eso no se conocen estos incidentes,saludos desde Argentina.

[@Davidto92]

Tu contenido siempre es de mucha calidad, lo he recomendado a mis colegas, ¡saludos!

[@catroventos6028]

q bien explicado, da gusto seguir tus comentarios, ojalá esto sirva a muchos creadores de software a no pecar de exceso de confianza, murphy siempre se cumple. por otra parte, creo necesario q todas estas tecnologias de alto riesgo, con el tiempo, se vean obligadas a seguir un protocolo de seguridad en capas, como ocurre con los aviones comerciales, y q cada fase del proceso haga su propio testeo de configuacion coherente antes de continuar. Gracias y felicitaciones.

[@ivap4436]

Buenísimo el vídeo, muy informativo sin ser aburrido. Me suscribo..

[@MalcomRomero]

muy buen video ringa! la importancia de testear los programas y máquinas

[@pinguinauta9353]

Pedazo de video para tomar conciencia con la ingeniería de software

[@octaviokriskovich4364]

Me encantan tus videos ringa, me impulsaron a irme por la ingeniería en sistemas

[@carloscarlin9454]

Te escuché desde principio a fin, impresionante. Gracias por tu video.

[@leonelquintero2350]

Excelente.....por supuesto que este tipo de videos son muy útiles como cultura general......eso sí por favor no dejes de hacer videos donde programas, también son geniales.

[@otrociber4506]

Wooww no me había puesto a pensar que un programa puede fallar en algo y tenga consecuencias devastadoras. Buena información en tu video 👍 sigue adelante.

[@FamCendejasRdz]

Gracias, excelente video y un caso terrible de fallas de software.

[@Luniverso]

Que buen video loco, ademas de que el tema es interesante, tu forma de contarlo lo hace aún mas.

[@miguelalarcon]

Muy interesante y bien expuesto como paciente de radio terapia me causo terror saber que podrían pasar este tipo de cosas en tratamiento por suerte actualmente hay más precaución con estos fallos.

[@jonathanbarzola]

¡Muy buen video! Es genial como elaboras tus videos, sigue subiendo contenido por favor!

[@Flashjacks]

Impresionante. No sabía nada de esta historia. Me sonaba de niño en los 80, alguna noticia pero poco más. Lo más fuerte para mí es el error 54. Ún número que me persigue a donde vaya.

[@miguelextreme2012]

Interesante informacion, no me cabe en mi cabeza que un software de los años 80 pudiese tener esos errores graves, normalmente al pasar los años y ser mucho mas complejos los sistemas operativos y el software, tienen tendecia a contener errores. Tambien es muy critico dejar todo en manos del software y no en llaves de seguridad de hardware, es como tener un horno de microondas y que los swhitchs sean solo sensores que informan a la computadora de control!

[@kurapica152]

Es común que aveces pasen errores, yo trabajo programando y diseñando hardware para robots y maquinas de minería y cuando uno programa comete el error aveces de ver todo como que el usuario haría las cosas igual que nosotros y aveces por eso quedan bug, se debe pensar como un usuario común para tratar de ver todas las posibilidades. Una vez me paso en una maquina de minería que el equipo funciono bien varios meses estaba recién entregado y no fallaba nada, pero un día cambiaron al operario e hizo una combinación extraña de comandos, botones que era casi imposible que pasara y paso jaja bueno la maquina fallo y se rompieron un para de cosas pero nada grave ya que era teleoperada , desde ese día después de desarrollar hacemos pruebas con todas las posibles formas de uso que podria dar un operario comun sobre todo en mineria que son brutos y apretan cosas sin ver manuales.

[@readdata]

"[...] brutos y sin ver manuales."? , estas describiendo al 99% de los usuarios de cualquier cosa , sea tecnológica o no. Jajaja

[@kurapica152]

@@readdata jajaj pero los mineros son peores, es como tratar con un cabernicola xd

[@Luis45ccs]

A mi como programador me asombran los usuarios, estos tienen formas inauditas de usar las cosas, yo viendolos alucino, ni sabia que mis sistemas podian hacer esas cosas, al menos sin fallar y otras veces falla y me digo como es que hicieron, lo que hicieron por dios, pero lo hacen. Algunos tocan todo, otros no te indican las fallas y buscan rodearlas y los ves un dia trabajando y sufriendo porque pensaron que eso era asi y ya, me gusta verlos trabajar porque aprendo mucho de posibles agujeros de guion y huecos de programación. Hay millones de formas de hacer que las cosas salgan mal

[@IIISpeeder]

@@Luis45ccs . En un principio pensaba a responder este comentario con que el usuario fue sustituido por un gorila. Pero al leer tu respuesta no pude evitar reflexionar y finalmente darte la razon. Es divertido y fructifero dejar a esos gorilas operar la maquina. Eso motiva y permite configurar los controles a prueba de jackass o dummies que honestamente soprenden con sus inferencias , ingenuas algunas veces, otras jaladas de los pelos. pero que en realidad existen. Saludos.

[@096dragonballz]

Qué triste por las personas afectadas y por el remordimiento de los operadores :( gracias por divulgar

[@onleemon]

Excelente video, un deleite total. Ya estas para hacer documentales sobre tecnologia 👏👏

[@JesusMartinez-zj1ig]

En el año 1991 en España sucedió un caso similar, se le conoció como el fallo del acelerador lineal del hospital clínico de Zaragoza.

[@shiki333]

04:21 eso es correcto, a veces pasa un error en una sucursal, entonces lo que hago es preguntarle al cajero que hizo?, que presiono, como cuando etc, muchas veces dicen que no saben, que no hizo nada, pero tambien hacen eso porque piensan que se les va a amonestar por eso, cuando en realidad solo queremos replicar el error.

[@FernandoHernandez-ye9ur]

Espectacular video, más explicativo que cualquier documental de Discovery Channel. En 20 min comprendí el funcionamiento más básico y superficial de esa máquina.

[@lucassolargrillo7187]

Soy estudiante de ingenieria informatica y nos dieron este caso en particular para aprender lo importante que es la fase de testing en los nuestros codigos. Muy buen video, 100% acorde a lo que sucedio en la realidad.

[@zeta9028]

5:58 ODEVOLVE PAITE NDE PECHORE @LUCAS SOLAR GRILLO AND GENERACIONES *HAAAÁ*

[@zeta9028]

and nde oreja-re

[@zerohack16]

Que gran caso, mas videos como este!, todo tu contenido me parece interesante como Ingeniero de profesión.

[@ferchoferefb]

Pensando en este problema escuchando como fueron sucediendo los hechos, no puedo creer que esos programadores tuvieran una tarea tan delicada siendo tan mediocres... Y también creo que en estos tiempos, el accidente del tesla que mato a dos personas en china, puede haber tenido un problema parecido en una sucesión de condiciones que produjeran que el auto se acelerara a 200km/h ... Saludos a todos desde Argentina!!! Te sigo y veo tus videos, y quiero felicitarte por tu contenido, de tan buena calidad !!! abrazo grande !!!! 🙋‍♂️

[@chienli971]

Soy fan de la manera que explicas casos de fallos de software... haz más plis

[@liquidscorpion4217]

Increíble , sigue creando videos de equipos médicos que fallan por el software o hardware me parece muy interesante

[@meyveliz]

acabo de encontrar tu canal y quiero decir que estan muy chingones tus videos saludos y mucha suerte.. saludos

[@juancamilozapataceballos500]

Que buen vídeo, cómo el del A346. Ojalá sigas subiendo más así. Saludos desde Colombia.

[@xaviporras]

Te amo calvito! Más vídeos así porfa!!!

[@kevinpoyonbal1353]

Exelente video, gracias por compartir la información. Esperemos más vídeos.

[@felipesantos-kb1ge]

no tengo mucha idea sobre programacion pero es muy interesante los casos que comentas, me gusta tu canal!

[@buho2194]

hacía días que no veía un tremendo vídeo así!, muchísimas gracias!

[@Luis_Nephew]

Me encanto el video.Y por supuesto me encantaria seguir viendo videos de estos temas. Me quede asombrado de todo lo que se tuvo que investigar para detectar el problema de los 8 segundos y que era debido a que la operadora era muy buena con el teclado. Siempre es dificil programar para el peor caso.

[@edsonnickslazarocamasca1588]

! Excelente video! 😲 es la primera vez que veo tu contenido y ya tienes un nuevo suscriptor.

[@cheturrin]

Magnífico trabajo de investigación y explicación como siempre. Me hubiera encantado que en el curso de ingeniería del software se hubieran expuesto estos casos y hacer más palpable lo inmersos que estamos en un mundo controlado por software. Este caso me recordó al de los autos de Toyota que aceleraba son control, precisamente por un error de software.

[@Luis45ccs]

Sin control

[@abregoel]

Saludos cordiales. Excelente explicación del accidente radiológico. Te invito a investigar el accidente radiológico de Panamá donde también un software estuvo involucrado (Multidata).

[@jorgeadx2008]

4:15 Moraleja del video, esto realmente aplica para muchísimos casos, en programación esto se vuelve crucial y muchas veces no se ve de esta manera

[@angeleswozniak]

Que genial información! Y qué buenas lecciones!

[@mikeguzman24]

Que clase de video! Excelentes habilidades comunicacionales y contenido. Nuevo suscriptor por acá.

[@davidafk6609]

Un video excelente, en serio manejas la información tremendamente bien, agradezco tu trabajo, no se nada de programación pero me siento atrapado por la historia y ahora se un poquito mas que ayer, quizas no me sirva esa info nunca, pero para mi que me gusta saber de todo esto es un gran regalo

[@joseoropeza8495]

Es increíble tu canal eres un genio me fascina los canales de tecnología al detalle 🎉🎉🎉🎉 es increíble tu canal

[@davidmedinacuevas1977]

Uno de los videos mas interesantes que he visto en youtube por un tiempo xD

[@facu6706]

Que buen docu alto laburo de investigación muchas gracias, nunca había escuchado de este caso, siento que de alguna forma esto me afecta, soy electrónico a punto de obtener mi título, estos aspectos de la seguridad en las máquinas siempre me han puesto muy paranoico al diseñar algo.

[@ingenierocristian]

Este es el video que le voy a presentar a mis aprendices cuando no quieran hacer la documentación de su firmware, gracias por este esfuerzo.

[@andresmarcano15]

Muy interesante historia. Y si a estos errores de software se le añade uno provocado por un golpe de rayo cósmico nos indica que la seguridad y realizar muchas pruebas es fundamental

[@mauriciozapata5862]

Muy buen video, me gusta mucho la forma en la que narras!!!

[@danyaracena222]

Muy buen contenido! Aporta mucho valor y utilidad para las mejores practicas.