Isso me fez lembrar de um caso mais recente, o MCAS (Sistema de Aumento de Características de Manobras), software que foi apontado como principal causador na queda de duas aeronaves. Depois dos acidentes houve até fechamento do espaço aéreo para os aviões equipados com esse sistema. As operações já foram retomadas. Porém, hoje se sabe que o defeito realmente estava na programação do sistema.
Sou formando de física médica, atualmente as maquinas de de radioterapia contam com duas câmaras detectoras de radiação independentes que param o sistema de emissão de radiação caso passem de determinada unidade monitora (dose).
E aquela famosa frase: "Se vc tem 2, vc tem 1 e se vc tem 1 vc n tem nenhum" Redundancia é sempre bem vinda e falaria ser ate algo indispensavel nesses casos, que bom que as maquinas modernas foram moldadas com base nos conhecimentos adquiridos por erros passados
E se o hardware das cameras falhar existe uma detecção da máquina pra interromper o processo nesse caso? Percebe que apesar de termos mecanismos de segurança tudo é passivo de erro.
Muito interessante o caso. Já programei em assembly, e sei que é bem complicado fazer grandes programas com ele. Ainda mais para controle de um equipamento perigoso ! Mas é um absurdo deixarem na mão de somente uma pessoa, pois é um equipamento de responsabilidade. Tanto que houve casos fatais !!!
Como programador eu gostei demais desse tema. Nunca ouvi falar dessa história. Realmente serve como estudo de ética, pois nesse acontecimento tinha muita coisa errada!! falta de teste, documentação falha, programador anônimo, empresa se negando a aceitar que poderia ter errado. Chega ser sinistro!
Esse caso dá no minimo uma série do discovery, ou no minimo um longametragem, sem dúvida que existem centenas de informações não levantadas e teorias... uma dela é que o próprio dono da empresa seja o programador. Pois o cara pode ser o programador, e contratar engenheiros para fazer a parte do hardware.
@@ederangelo21 Cara, eu ia escrever isso aqui agora, e achei seu comentário. Pra mim, pessoalmente, eh meio lógico/óbvio deduzir que o programador era o dono, um dos donos, ou alguem do alto escalão da empresa, pois essa seria A ÚNICA razão que a empresa teria pra não dar nome aos bois. Eu sou formado em engenharia de computação e inclusive já trabalhei em uma empresa do ramo médico que fazia máquinas de eletro-encefalograma para neonatos (basicamente para captar a atividade cerebral de bebês). O dono da empresa também dobrava de programador chefe, e revisava todo o código que eu e mais um outro cara escreviamos, alem de escrever boa parte do código ele mesmo. Esse cenário eh muito comum nessa área de engenharia médica.
Quando entrei na faculdade a primeira coisa que mostraram para gente foi essa história, além de explicarem que se um dia a gente for pegar um serviço nunca pegar software medicos e nem software de contabilidade, pois demandam muito trabalho e segurança como mostrado no caso da terac 25. Pra quem e desenvolvedor eu alerto que se for pegar um software desse tenham o maximo de cautela!! 😅😅 A análise de requisitos e prototipagem de software e fundamental pra evitar isso. Nessa época as empresas de tecnologias não eram tão avançadas. Hoje em dia e quase impossível acontecer isso novamente por causa da engenharia de software e análise de software. Onde se tem protocolos rigorosos pra verificar o software em conjunto com a empresa e com os stakeholders.
Pera aí meu, a faculdade dizer para os alunos nunca pegarem softwares medicos e contabilidade? Que bizarro! O lance da faculdade deveria ser formar profissionais capazes de trabalhar nos ramos mais complicados, e não instruí-los a fugir disso rs. Mas essa e outras histórias de erros de software que ceifam vidas também caíram já no início da minha faculdade. Inclusive, eu fiz trabalho sobre o Therac.
@@vsadev Levando em consideração modos práticos, essa é a realidade. Faculdade de TI não é como faculdade de medicina, que busca te ensinar a não cometer erros. Se vc se graduou em TI, sabe muito bem que a graduação em TI ensina apenas o beabá. Esse tipo de instrução, os orientadores dão para os que querem se aventurar como profissionais liberais. Pois, é um trabalho complexo, que requer especialização, que geralmente não vale o custo, de alto risco envolvido, que em caso de falha cabe um processo fudido. Então, não tem nada de bizarro, tirando o fato de que não é o cenário ideal. Mesmo que a pessoa seja especialista, é fortemente recomendado não fazer esse tipo de trabalho sozinho.
Imagina um profissional sozinho ser especialista em segurança da informação, direito, contabilidade e testes, no mínimo. Então, mais uma vez, não tem nada de bizarro na recomendação.
Caramba, sou técnico de engenharia clínica e nunca tinha ouvido falar desse caso. É uma pena os fabricantes terem demorado a ouvir os relatos. A segurança em equipamentos médicos é algo primordial.
Mas depende também da postura ética da fabricante. Pode ser também que eles possam pensar assim: o que é mais caro pra companhia? Refazer os testes e mitigar todas as falhas potenciais que surgiram durante os testes, e aplicar testes mais rigorosos e feitos por instituições independentes, para evitar vícios nos testes, ou pagar as indenizações de ações judiciais? Se as ações judiciais resultarem em valores bem menores do que melhorar a segurança do produto, então vamos pagar as ações, não interessa se vai custar a vida de alguém... 😕
o problema é que a maquina simplesmente foi lançada por estudos base, por isso todo esse equivoco, mas se não fosse por isso, hoje não teríamos os equipamentos que hoje temos pra tratamentos.
@@MatheusGelinski o que eles tinham de estudo cientifico na epoca era muito pouco, como o pedro disse na introdução, por uma deformação e destruição da materia oranica, eles descobriram a quimioterapia, mas isso tudo era feito por software, o que pode levar a erros por comunicação da maquina.
Fiz técnico em informática, curso de programação e agora estou na faculdade de Ciência da Computação e em todos eles, bem no início, os professores fazem questão de falar sobre o therac-25 e enfatizar os problemas
Relato de bugs que não foram identificados pelo editor: 13:28 - Repetiu o Zoom no Mapa 13:38 - Esqueceu de cortar o vídeo e o Loos repetiu o que estava falando Devem existir outros bugs. Alguém encontrou outros?
[13:51] Um bug da boca dele que, ao falar "Limita", expele uma gota gigante de saliva que cai próxima ao indicador da mão esquerda e fica na mesa o restante do vídeo.
Isso me faz lembrar de um certo produzido por algumas empresas e tidos como seguros. Os mesmos produtos foram e são obrigatórios para exercer a cidadania: acesso a serviços públicos, escola por crianças, etc. Sempre bom ver como dá pra confiar 100% ou cegamente em algo que uma empresa, interessada em vender seu produto, diz ou afirma.
@@AngeloFSPmas aí pode-se alegar que o erro é de quem escreveu o chat gpt. Em essência o cometário acima tá correto, software faz o que foi programado pra fazer, os erros advém de situações não previstas e devidamente tratadas pelo programador.
Radiação cósmica pode alterar bits na memória do computador de forma aleatória. Existem até memórias RAM mais caras que conseguem detectar quando isso acontece e corrigir automaticamente o erro. Mas se você estiver no espaço, a quantidade de radiação é tão grande que nem elas conseguem detectar tudo. Por isso que mais de 50% da memória em naves espaciais são dados duplicados ou redundantes. Então dá pro código errar "sozinho" sim kkkkk
Eu sou programador e tenho neurose com uso correto de variáveis de tamanhos certos assinadas ou não para aplicação simples do dia a dia. Imagine se fosse em uma máquina dessa
Além de boa prática para ajudar quem irá revisar posteriormente, a leitura do que ele está recebendo, ou pelo menos deve receber, através da nomenclatura recebida, ajuda a construir a lógica na cabeça e entender o que a variável deve ou não receber. Continue assim
Sobre este caso, é muito simples, uma empresa tao bagunçada que nao fez testes e nem nada antes de lançar a THERAC-25 tenho quase 100% de chace de ter sido O FILHO do dono da empresa, quem escreveu tais códigos, nenhuma empresa encobre funcionários, mas se tratando do próprio filho, tenho absoluta ctz que este é o caso❤ por isso nem a justica achou o responsável
Acho que o pior erro de software de história foi com o MCAS do Boeing 737 MAX que resultou na queda de duas aeronaves. Poderia ter um video sobre esse caso.
Isso se a gente contar a vez em que o robô do Musk praticamente agrediu um engenheiro dentro da fábrica. Esse nível de automação tem que parar somente nas ferramentas que a gente usa. Se começarmos a dar IA para as máquinas brincarem, não falta muito pra humanidade se autodestruir numa Skynet da vida real.
Aquela máxima "seguro morreu de velho", serve de lição para nunca confiarmos em um único recurso de segurança, é interessante sempre utilizar uma redundância.
@@rodrigoeduardo9199 Não, eu assisto pelo celular (no RUclips padrão) e consigo mesmo assim deixar em segundo plano. Eu só aperto o botão home pra sair do RUclips e o vídeo continua rolando em pop-up na tela. OBS: Isso só acontece no canal Ciência Todo Dia.
Lembrei do problema do software de controle do avião da Air France, que também dava erro em uma situação específica e foi responsável por pelo menos 2 acidentes graves.
Foi os softwares da Boing que dava erro. Hoje eles são os conjuntos de aeronaves mais seguros do mundo, por conta que eles corrigiram e focaram muito no software
@@IsraelLeite Sim, mas o problema foi como o software de controle reagia naquela situação. Antes da atualização do software nunca tinha dado problema. A solução foi alterar o software, os pitôs e a rotina de manutenção. Tem um episódio do canal aviões e músicas falando sobre isso
Pedro, tem mais um detalhe interessante: muito do software que fazemos, não é o produto final, como bibliotecas e etc. Isso é, é possível que as pessoas que desenvolvem softwares tenham o seu código executado nas mais diversas aplicações, e algumas delas muito sensíveis. Então mesmo que na inocência se faça um código pra resolver algo pequeno e simples, tem que ter cuidado
Em missões críticas, JAMAIS a segurança de um equipamento pode ser provida apenas por software. Na automação industrial, por exemplo, o CLP (Controlador Lógico Programável) comanda os motores que fazem as partes da máquina se moverem, e existem sensores de indicam ao CLP quando o motor deve ser desligado, mas sempre haverá interruptores que cortam a alimentação do motor (conhecidos como chaves "fim de curso") caso o sensor ou algum outro componente lógico falhe.
Perfeito conteúdo! Sou especialista em engenharia de qualidade de software e essa abordagem foi magnifica! Trazendo o caso a tona e contextualizando com nossos dias atuais!
No final desse video, eu fiquei pensativo, meu peito se encheu de desespero, medo, triste...não sei o que é mas obrigado por me proporcionar tais sentimentos !
Já tinha visto o video do Kyle Hill sobre esse tema mas é sempre interessante ver de novo, e até fiquei mais chocado em saber que nunca descobriram quem foi o programador, achei que o Kyle só nao quis dizer quem era.
É paia man, mas nn conseguimos culpar nenhum dos dois, pq além da empresa ter "contratado" uma pessoa que programa por hobby, as documentações do equipamento provavelmente nem falariam sobre isso
Desculpe Pedro pelo atraso de 1 minuto, sim, eu sei que muita coisa aconteceu desde que o video lançou. Mas o software do meu despertador para o seu video bugou e só disparou 1 minuto depois... :/ (Para exclarecer, galerinha das respostas, isto foi uma *piada*, piada em referencia ao exemplo dos despertadores que houve no inicio do video. Não é preciso brigar nos comentarios)
Eu tinha visto esse caso no Gustavo Pinheiro do Starks e bem legal que mais canais brasileiros estao trazendo essa notícia obscura a tona sobre essa história do Therac-25
Pedro por favor, por falar em bug de maquinas, poderia me explicar por que seus vídeos são os únicos videos do RUclips que eu consigo assistir em modo picture-and-picture ?????
Como sempre, ótimo vídeo. Ao meu ver o erro não foi (por natureza) de código, foi falta de revisão de pares + assembly (quem sabe, sabe) + fraude por parte da empresa, só então o código teve a oportunidade de ser um problema. Qualquer parte da máquina que fosse desenvolvida dessa forma teria tido problemas do mesmo nível.
Eu tinha um rádio relógio 100% analógico. Na hora programada ele ligou corretamente na estação de rádio sintonizada. O único problema é que a rádio estava fora do ar, sem tocar nenhum som. Naquele dia eu cheguei atrasado 1 hora no trabalho. Lição aprendida: Além de mudar a estação do rádio eu programei meu relógio de pulso para despertar como redundância.
O problema não era apenas a segurança da maquina ser 100% dependente do código, e sim o fato de que o desenvolvimento de um sistema tão delicado negligenciou praticas de programação já consolidadas na epoca, muito provavelmente pela busca de alto lucro e baixo custo da empresa irresponsável. Até hoje vemos empresas que praticam o mesmo, tratam testes e qualidade como obrigação, custo e não um investimento. Sempre bom relembrar casos assim, pena que as pessoas juridicas se educam pelo bolso e não pela fatalidade do ocorrido. É frustrante ver esse cenário sendo da area de TI.
Na minha época de programador eu dizia ao meu chefe "pô o programa fez besteira" e o meu chefe retrucava dizendo "vc fez besteira. A máquina obedece o código que vc programou". A transferência de culpa é tão velha quanto Adão e Eva. Pior que a Therac-25 foi o software dos novos aviões B737 MAX que derrubou dois deles cheios de gente dentro. Por isso um software precisa ser exaustivamente testado em todas as condições possíveis porque o bug está lá desde o início só esperando determinada condição acontecer.
No 737 Max o problema vai além do software, passa principalmente pela negligência da Boeing. Os engenheiros projetaram o avião com apenas UM sensor para o MCAS - que é normal ter danos por choques com objetos e pássaros, sem nenhuma outra redundância, sendo que a aviação é justamente segura por possuir muita redundância para tudo. Então, basicamente o software tinha uma única fonte de informação e, apesar de falta de sanity check no seu código, o início de tudo foi a Boeing querer economizar em sensor e em treinamento
Isso tudo faz muito sentido. Eu pretendo ser desenvolvedor no futuro, e quero me tornar um profissional que sabe o que está fazendo, para não comerer erros assim (e que eles sejam corrigidos no tempo certo).
Caramba nunca tinha ouvido falar antes! Pedro gosto muito do jeito que são contados os fatos nesse tipo de conteúdo, como é feito o desenrolar dos fatos e no final com um tom de esperança e uma lição, assim como no vídeo sobre o Robert Oppenheimer. Certamente esse é um dos canais favoritos que sigo. Sucesso sempre!
História muito triste, foi mencionada no meu curso de sistemas de informação, a pergunta que fica é, vai ter ep do sinapse sobre isso? acho que seria uma boa ouvir o Greg falar sobre
Uma observação, não é possível confiar numa máquina pois esta só faz o que seus desenvolvedores criam atraves de um processo de desenvolvimento. Portanto ao "confiar na máquina" Na verdade a confiança é depositada nos desenvolvedores e no seu processo. Ótimo vídeo, tmj.
O maior erro humano é querer desenvolver algo que corrija seus erros sabendo que no caminho, haverá mais erros. É como dizem, na gana de querer corrigir erros, se cria mais erros.
Trabalho com hardware há 53 anos e software quase o mesmo tempo. Achei este trabalho muito interessante. Vou divulgsr este video para os outros dinossauros da informática que eu conheço. Por falar em mensagens de erro: são os maus comuns erros importantes de todos os softwares.
Ótimo vídeo, parabéns Pedro e a equipe. Isso tudo que foi mostrado faz muito sentido, e é triste que tenha ocorrido tanta negligência. Ao meu ver, o erro não é da própria máquina, e sim de quem a fez, nós não somos perfeitos, por isso as máquinas que criamos também não são. Eu pretendo ser desenvolvedor no futuro, e quero me tornar um profissional que sabe o que está fazendo, para não comerer erros assim (e que eles sejam corrigidos no tempo certo).
Bugs em máquinas de radioterapia são ruins, mas imagina em um Airbus A330. Ta certo que ninguém sabe se foi um bug que quase derrubou o voo Qantas 72, mas ainda sim, os sistemas críticos exigem uma robustez para esse tipo de coisa não acontecer. No voo Qantas 72, o piloto recebia um alerta que o avião estava caindo, então o avião mergulhava sozinho para recuperar velocidade, os dados da ADIRU pareciam ter erro no I/O da memória, fazendo os dados se misturarem. Se o avião tivesse mais duas ADIRU, os passageiros jamais teriam sofrido fraturas.
Na verdade existe um bug muito pior, que fez muita gente cometer suicídio e a falência de inúmeras empresas, ele é chamado de bug do milênio, ocorreu pq os anos era definido apenas por 2 algoritmos em todos os computadores globais, e quando chegaram no ano 2000, o computador reconheceu como 00 e reiniciou todo o sistema, fazendo quase todos os computadores perderem todas as informações, pesquise é muito interessante
@@cesarmayhem E falta de redundância em hardware, pois a boeing construiu o Max com apenas um sensor do MCAS enviando informações para o software. Logo a redundância é que torna a aviação tão segura! O sensor dando problema, como ocorreu (normalmente devido a colisões com objetos e pássaros), ele envia dados errados para o software, que por sua vez não possuía uma checagem mais adequada.
Em meu primeiro ano no curso de ciências da computação aprendemos sobre o therac 25 mas não tão aprofundado quando a relação de hardware e sim sobre o software apenas, obrigado por trazer tanto conteúdo sobre o assunto
Parabéns pelo vídeo! Já tinha visto falar sobre o caso em canais gringos e, devido a relevância do tema, me surpreendi vendo que não haviam videos em português sobre a história. Parabéns pela iniciativa, como sempre, um vídeo milimetricamente bem feito.
Já conhecia o caso, inclusive vi vários vídeos de autores diferentes, mas nenhum explicado de forma tão clara. Aproveitando o ensejo, gostaria muito que fizesses um vídeo sobre o incidente com o voo 72 da Quantas, operado por um Airbus A330, que saiu do aeroporto Changi em Singapura com destino a Perth, na Austrália( aquela cidade que o Lito, do Aviões e Músicas, adora pronunciar o nome ), em 7 de outubro de 2008. Leigos normalmente não o classificariam como falha de software mas, sob o ponto de vista da Engenharia de Software atual, é uma falha, embora não possa ser classificado como bug.
Em 13:38, temos um erro de software dessa I.A.! Esse cara é claramente junção de hardware e software, uma vez que é impossível um humano saber tanto 😂😂😂🤣. Pedrão, só uma correção: "Automobilismo" diz respeito ao esporte a motor (competições de automóveis). Para a indústria automotiva, nós do ramo usamos o termo "automobilística" ou "automotiva" mesmo. Parabéns pelo canal! Sou inscrito há anos e sempre aprendo muito com você.
Vídeo maravilhoso, sou da área do desenvolvimento e esse é um exemplo perfeito do porque um software precisa de testes extensivos e tempo para desenvolvimento. Assim os responsáveis conseguem olhar através de diferentes cenários e pontos de vista.
Esse vídeo apareceu bem depois de mim ir para um hospital e fazer radiografia. Você está me rastreando?? Edição 1: Acabei de fazer teste de sangue. Foi dolorido...
Que história macabra e interessante ao mesmo tempo!!! Faço curso de Técnico de informática e esse vídeo serviu como um alerta das reponsabilidades que eu tenho que ter na minha futura profissão para evitar casos como esse!!!
Mesmo considerando o momento em questão, sabendo das dificuldades tecnológicas, seria prudente ter um medidor de radiação independente da máquina que pudesse verificar se era compatível o nível de radiação informado por ela, com o que estava realmente sendo liberando.
15:30 "parar pra refletir o quanto que a gente confia nas máquinas" Eu quando vou ensianr qualquer coisa sobre computação (ou máquinas em geral) pra qualquer pessoa: NUNCA CONFIE NA MÁQUINA
Pra vc ver o poder que um hardware tem! Ele poderia travar a maquina antes da desgraça acontecer mesmo com o software escrito errado e se o operador fizesse algo errado
PARABÉNS. São casos como esse que demonstram a necessidade absoluta de NUNCA confiarmos cegamente em equipamentos/sistemas/programações desenvolvidos e/ou projetados/montados pelos Seres Humanos, porque SOMOS FALÍVEIS! Toda ATENÇÃO e CHECAGEM, às vezes até a EXAUSTÃO , são IMPRESCINDÍVEIS! Como outro RECENTE exemplo, veja o caso do BOEING 737 MAX 8 !!! EXCELENTE ARTIGO e RELATO.
Plot Twist : A programação da maquina foi feita pelo CHAT GPT e vendida aos diretores da empresa canadense por um viajante do tempo clandestino de 2042 😳
Pedro desculpa mas você está errado, o pior erro de software da história foi o do Boeing 737 MAX que vitimou 346 pessoas, acho que ganha de longe desse que você mostrou aí...
ali não foi erro, o código estava certo com o que eles queriam, o problema foi, nao avisar a tripulação sobre o novo sistema e o sensor só receber dados de um Pitot
Você está errado. O problema não era o TCAS, e sim indicador de ângulo de ataque e a falta de treinamento por parte da companhia. O erro de indicação é mais hardware do que software. Não fala merda.
@@blitzkow1917 parabéns você sabe mais que a Boeing. Pois a própria empresa diz que a falha foi do software. Claro que também faltou a redundância no caso dos sensores, mas houve sim erro no software do sistema MCAS.
@@MattVanelucci Primeiramente, não é a boeing que faz o relatório, a boeing é a INVESTIGADA. Outra coisa, ta literalmente no relatorio final que a maior falha foi falta de treinamento. Problema de indicação mesmo sem redundancia nos sensores JAMAIS deveria derrubar um avião. Não foi software.
13:38 o software de Pedro Loos dando um bug
Shiu, ele pode te ouvir
Vc aqui? Te acompanho tbm!
Faz crossover faz plz vocês são os pikas da galaxia da ciência BR!
@olaciencia eu fiquei esperando uma piada com bugs, mas foi só um bug mesmo
Ps: te amo✌️✌️
Sim eu até voltei o vídeo achando eu tive um dejavu
Isso me fez lembrar de um caso mais recente, o MCAS (Sistema de Aumento de Características de Manobras), software que foi apontado como principal causador na queda de duas aeronaves. Depois dos acidentes houve até fechamento do espaço aéreo para os aviões equipados com esse sistema.
As operações já foram retomadas. Porém, hoje se sabe que o defeito realmente estava na programação do sistema.
Sou formando de física médica, atualmente as maquinas de de radioterapia contam com duas câmaras detectoras de radiação independentes que param o sistema de emissão de radiação caso passem de determinada unidade monitora (dose).
Bom saber, brigadão.
E aquela famosa frase:
"Se vc tem 2, vc tem 1 e se vc tem 1 vc n tem nenhum"
Redundancia é sempre bem vinda e falaria ser ate algo indispensavel nesses casos, que bom que as maquinas modernas foram moldadas com base nos conhecimentos adquiridos por erros passados
Obrigado pela informação :)
E se o hardware das cameras falhar existe uma detecção da máquina pra interromper o processo nesse caso? Percebe que apesar de termos mecanismos de segurança tudo é passivo de erro.
@@As4votá, e o que você tem a agregar?
Muito interessante o caso.
Já programei em assembly, e sei que é bem complicado fazer grandes programas com ele. Ainda mais para controle de um equipamento perigoso !
Mas é um absurdo deixarem na mão de somente uma pessoa, pois é um equipamento de responsabilidade. Tanto que houve casos fatais !!!
Como programador eu gostei demais desse tema. Nunca ouvi falar dessa história. Realmente serve como estudo de ética, pois nesse acontecimento tinha muita coisa errada!! falta de teste, documentação falha, programador anônimo, empresa se negando a aceitar que poderia ter errado. Chega ser sinistro!
Um belo exemplo de procedimentos dentro da Engenharia de Software.
Vários elos que fecham uma corrente.
Esse caso dá no minimo uma série do discovery, ou no minimo um longametragem, sem dúvida que existem centenas
de informações não levantadas e teorias... uma dela é que o próprio dono da empresa seja o programador.
Pois o cara pode ser o programador, e contratar engenheiros para fazer a parte do hardware.
@@ederangelo21 Cara, eu ia escrever isso aqui agora, e achei seu comentário. Pra mim, pessoalmente, eh meio lógico/óbvio deduzir que o programador era o dono, um dos donos, ou alguem do alto escalão da empresa, pois essa seria A ÚNICA razão que a empresa teria pra não dar nome aos bois. Eu sou formado em engenharia de computação e inclusive já trabalhei em uma empresa do ramo médico que fazia máquinas de eletro-encefalograma para neonatos (basicamente para captar a atividade cerebral de bebês). O dono da empresa também dobrava de programador chefe, e revisava todo o código que eu e mais um outro cara escreviamos, alem de escrever boa parte do código ele mesmo. Esse cenário eh muito comum nessa área de engenharia médica.
Sim, eles foram negligentes, como se o erro que estava acontecendo fosse em uma torradeira.
Quando entrei na faculdade a primeira coisa que mostraram para gente foi essa história, além de explicarem que se um dia a gente for pegar um serviço nunca pegar software medicos e nem software de contabilidade, pois demandam muito trabalho e segurança como mostrado no caso da terac 25.
Pra quem e desenvolvedor eu alerto que se for pegar um software desse tenham o maximo de cautela!! 😅😅
A análise de requisitos e prototipagem de software e fundamental pra evitar isso. Nessa época as empresas de tecnologias não eram tão avançadas.
Hoje em dia e quase impossível acontecer isso novamente por causa da engenharia de software e análise de software. Onde se tem protocolos rigorosos pra verificar o software em conjunto com a empresa e com os stakeholders.
Pera aí meu, a faculdade dizer para os alunos nunca pegarem softwares medicos e contabilidade? Que bizarro! O lance da faculdade deveria ser formar profissionais capazes de trabalhar nos ramos mais complicados, e não instruí-los a fugir disso rs. Mas essa e outras histórias de erros de software que ceifam vidas também caíram já no início da minha faculdade. Inclusive, eu fiz trabalho sobre o Therac.
@@vsadev Alguém vai pegar e ser responsavel por matar pessoas, mas melhor n ser tu né ?
@@vsadev Levando em consideração modos práticos, essa é a realidade. Faculdade de TI não é como faculdade de medicina, que busca te ensinar a não cometer erros. Se vc se graduou em TI, sabe muito bem que a graduação em TI ensina apenas o beabá. Esse tipo de instrução, os orientadores dão para os que querem se aventurar como profissionais liberais. Pois, é um trabalho complexo, que requer especialização, que geralmente não vale o custo, de alto risco envolvido, que em caso de falha cabe um processo fudido. Então, não tem nada de bizarro, tirando o fato de que não é o cenário ideal. Mesmo que a pessoa seja especialista, é fortemente recomendado não fazer esse tipo de trabalho sozinho.
Imagina um profissional sozinho ser especialista em segurança da informação, direito, contabilidade e testes, no mínimo. Então, mais uma vez, não tem nada de bizarro na recomendação.
@@davidcarvalho9500 claramente não era o caso do cara
Caramba, sou técnico de engenharia clínica e nunca tinha ouvido falar desse caso. É uma pena os fabricantes terem demorado a ouvir os relatos. A segurança em equipamentos médicos é algo primordial.
Up!
Mas depende também da postura ética da fabricante. Pode ser também que eles possam pensar assim: o que é mais caro pra companhia? Refazer os testes e mitigar todas as falhas potenciais que surgiram durante os testes, e aplicar testes mais rigorosos e feitos por instituições independentes, para evitar vícios nos testes, ou pagar as indenizações de ações judiciais? Se as ações judiciais resultarem em valores bem menores do que melhorar a segurança do produto, então vamos pagar as ações, não interessa se vai custar a vida de alguém... 😕
o problema é que a maquina simplesmente foi lançada por estudos base, por isso todo esse equivoco, mas se não fosse por isso, hoje não teríamos os equipamentos que hoje temos pra tratamentos.
@@MatheusGelinski o que eles tinham de estudo cientifico na epoca era muito pouco, como o pedro disse na introdução, por uma deformação e destruição da materia oranica, eles descobriram a quimioterapia, mas isso tudo era feito por software, o que pode levar a erros por comunicação da maquina.
Isso se chama capitalismo meu amigo se está dando lucro dane-se o resto!
Fiz técnico em informática, curso de programação e agora estou na faculdade de Ciência da Computação e em todos eles, bem no início, os professores fazem questão de falar sobre o therac-25 e enfatizar os problemas
Relato de bugs que não foram identificados pelo editor:
13:28 - Repetiu o Zoom no Mapa
13:38 - Esqueceu de cortar o vídeo e o Loos repetiu o que estava falando
Devem existir outros bugs. Alguém encontrou outros?
[13:51] Um bug da boca dele que, ao falar "Limita", expele uma gota gigante de saliva que cai próxima ao indicador da mão esquerda e fica na mesa o restante do vídeo.
percebi isso tbm
@@maxdolabella mds kkkkkkkkkkkkkkkkkkkkkkkk
@@maxdolabella KKKKKKKKKKKKKKKK
Vocês não perdoaram nada
Isso me faz lembrar de um certo produzido por algumas empresas e tidos como seguros. Os mesmos produtos foram e são obrigatórios para exercer a cidadania: acesso a serviços públicos, escola por crianças, etc. Sempre bom ver como dá pra confiar 100% ou cegamente em algo que uma empresa, interessada em vender seu produto, diz ou afirma.
Isso foi falado em uma aula da minha facul de engenharia de software. Escrever códigos para máquinas clínicas é uma responsabilidade tremenda
Eu sou programador, e esse caso é super importante para nós
É aquela velha máxima: "O software não erra, erra quem escreve o código"
Se o chat GPT é um software, então códigos escritos pelo chat GPT são infalíveis 😮
@@AngeloFSP Claro que são falhos, os próprios desenvolvedores do chat GPT não recomendam usar ele como fonte de estudo ou desenvolvimento
@@sergiolucas3096 eu sei, só tava ironizando o comentário do brother alí 😆
@@AngeloFSPmas aí pode-se alegar que o erro é de quem escreveu o chat gpt. Em essência o cometário acima tá correto, software faz o que foi programado pra fazer, os erros advém de situações não previstas e devidamente tratadas pelo programador.
Radiação cósmica pode alterar bits na memória do computador de forma aleatória. Existem até memórias RAM mais caras que conseguem detectar quando isso acontece e corrigir automaticamente o erro.
Mas se você estiver no espaço, a quantidade de radiação é tão grande que nem elas conseguem detectar tudo. Por isso que mais de 50% da memória em naves espaciais são dados duplicados ou redundantes.
Então dá pro código errar "sozinho" sim kkkkk
cara um dos canais mais satisfatórios que assisto. parabéns a toda equipe. você são muito bons.
Essa história é sinistra, já conhecia, mas é sempre bom ouvir pelo Loss.
Também acho
Conheci ela ano passado pelo kyle hill no half-life stories.
O pior de tudo é as empresas, que defendem o produto até a morte e não dão a minima se houve um erro real
Eu sou programador e tenho neurose com uso correto de variáveis de tamanhos certos assinadas ou não para aplicação simples do dia a dia. Imagine se fosse em uma máquina dessa
Meu professor usou esse caso como exemplo de mal uso de concorrência
Além de boa prática para ajudar quem irá revisar posteriormente, a leitura do que ele está recebendo, ou pelo menos deve receber, através da nomenclatura recebida, ajuda a construir a lógica na cabeça e entender o que a variável deve ou não receber. Continue assim
E eu pensando que só eu era assim ! 😅😅😅
@@MrViniciusml vlw
@samukadesouza8720 varios milhoes de programadores nesse mundão e vc pensou q era o único q segue essa boa prática. É....
Sobre este caso, é muito simples, uma empresa tao bagunçada que nao fez testes e nem nada antes de lançar a THERAC-25 tenho quase 100% de chace de ter sido O FILHO do dono da empresa, quem escreveu tais códigos, nenhuma empresa encobre funcionários, mas se tratando do próprio filho, tenho absoluta ctz que este é o caso❤ por isso nem a justica achou o responsável
Acho que o pior erro de software de história foi com o MCAS do Boeing 737 MAX que resultou na queda de duas aeronaves. Poderia ter um video sobre esse caso.
Eu ia comentar justamente sobre isso. Acredito que foi mais grave em relação ao número de vítimas
@@eugeniomsjr E o prejuízo financeiro foi enorme também, quantos aviões ficaram no chão enquanto resolviam a situação.
Perfeito
Isso se a gente contar a vez em que o robô do Musk praticamente agrediu um engenheiro dentro da fábrica. Esse nível de automação tem que parar somente nas ferramentas que a gente usa. Se começarmos a dar IA para as máquinas brincarem, não falta muito pra humanidade se autodestruir numa Skynet da vida real.
A Netflix fez um filme sobre esse caso
Aquela máxima "seguro morreu de velho", serve de lição para nunca confiarmos em um único recurso de segurança, é interessante sempre utilizar uma redundância.
Tem um bug muito bom no canal do ciência todo dia, todos os vídeos desse canal eu consigo assistir em pop-up mesmo sem ter RUclips premium
Eu tbm consigo, adorei o bug hahaha
tem navegadores que tem pop up nativo,talvez seja isso,ou até extensões
@@rodrigoeduardo9199 Não, eu assisto pelo celular (no RUclips padrão) e consigo mesmo assim deixar em segundo plano. Eu só aperto o botão home pra sair do RUclips e o vídeo continua rolando em pop-up na tela.
OBS: Isso só acontece no canal Ciência Todo Dia.
Comigo também acontece, e com alguns outros pouquíssimos canais além do Ciência todo dia
Pior que só nesse canal eu consigo isso
Esse conceito de "as máquinas erram menos" não deveria ser relativo? Já que os erros das máquinas tbm são humanos, mas todos os acertos tbm são.
Lembrei do problema do software de controle do avião da Air France, que também dava erro em uma situação específica e foi responsável por pelo menos 2 acidentes graves.
Não, do air France foi o erro no pitô de velocidade que congelou
Foi os softwares da Boing que dava erro. Hoje eles são os conjuntos de aeronaves mais seguros do mundo, por conta que eles corrigiram e focaram muito no software
O erro de software foi no boeing 737 Max 8, as empresas a Lion Air e outra que não lembro agora, mas não foi a airfrance
@@IsraelLeite Sim, mas o problema foi como o software de controle reagia naquela situação. Antes da atualização do software nunca tinha dado problema. A solução foi alterar o software, os pitôs e a rotina de manutenção. Tem um episódio do canal aviões e músicas falando sobre isso
@@thalesflorindomacieldaroch429 Esse foi outro
Sou engenheiro de computação e até hoje - lastimavelmente - nunca tinha ouvido falar deste caso. Vídeo extremamente útil!
Pedro, tem mais um detalhe interessante: muito do software que fazemos, não é o produto final, como bibliotecas e etc. Isso é, é possível que as pessoas que desenvolvem softwares tenham o seu código executado nas mais diversas aplicações, e algumas delas muito sensíveis. Então mesmo que na inocência se faça um código pra resolver algo pequeno e simples, tem que ter cuidado
Ótimo alerta, Pedro.
Nos últimos anos fiz raios-x e nem pensei nisso, agora vou passar a ter mais medo de raio-x e evitar ao máximo..
Pedro, você poderia trazer um vídeo sobre, a imortalidade quântica.
Em missões críticas, JAMAIS a segurança de um equipamento pode ser provida apenas por software. Na automação industrial, por exemplo, o CLP (Controlador Lógico Programável) comanda os motores que fazem as partes da máquina se moverem, e existem sensores de indicam ao CLP quando o motor deve ser desligado, mas sempre haverá interruptores que cortam a alimentação do motor (conhecidos como chaves "fim de curso") caso o sensor ou algum outro componente lógico falhe.
No erro 54 tem um erro do Pedrão! 😪 hahahaha Excelente vídeo! (13:37)
Up!
Loos é um gênio
A magia do replay imediato sks
Eu vi e achei que tinha escutado coisas kkkk
Gotcha! E um pouquinho antes, tem um errinho de edição quando aparece o mapa de Washington...
Perfeito conteúdo! Sou especialista em engenharia de qualidade de software e essa abordagem foi magnifica! Trazendo o caso a tona e contextualizando com nossos dias atuais!
No final desse video, eu fiquei pensativo, meu peito se encheu de desespero, medo, triste...não sei o que é mas obrigado por me proporcionar tais sentimentos !
Já tinha visto o video do Kyle Hill sobre esse tema mas é sempre interessante ver de novo, e até fiquei mais chocado em saber que nunca descobriram quem foi o programador, achei que o Kyle só nao quis dizer quem era.
É paia man, mas nn conseguimos culpar nenhum dos dois, pq além da empresa ter "contratado" uma pessoa que programa por hobby, as documentações do equipamento provavelmente nem falariam sobre isso
Ótimo vídeo como sempre. Mas pela primeira vez, vi um erro que deixaram passar na edição 13:38 😅
13:38 por falar em falha 😅 parece até que deixou de propósito pra ver se notamos. Vídeo excelente. Parabéns
Desculpe Pedro pelo atraso de 1 minuto, sim, eu sei que muita coisa aconteceu desde que o video lançou. Mas o software do meu despertador para o seu video bugou e só disparou 1 minuto depois... :/
(Para exclarecer, galerinha das respostas, isto foi uma *piada*, piada em referencia ao exemplo dos despertadores que houve no inicio do video. Não é preciso brigar nos comentarios)
É
@@yThllsO comentário acima contém humor indireto e óbvio (não tão óbvio pelo jeito)
questão qual é a necessidade de atacar dessa forma?@@yThlls
@@Tupin7quim se fosse humor de verdade na internet a frase não séria tão curta e tão sem alma como foi
É óbvio o comentário. A pessoa que já começou segunda-feira com essa negatividade. Melhor se ater ao elogio que o cara fez pro canal. @@Tupin7quim
Questão do filme "Eu, Robo" que o a maquina calcula o percentual de chances de sobrevivência e salva a vida dele conforme o resultado.
Eu tinha visto esse caso no Gustavo Pinheiro do Starks e bem legal que mais canais brasileiros estao trazendo essa notícia obscura a tona sobre essa história do Therac-25
Pedro por favor, por falar em bug de maquinas, poderia me explicar por que seus vídeos são os únicos videos do RUclips que eu consigo assistir em modo picture-and-picture ?????
Existe um outro caso de bug de software que causou inúmeras mortes, mas causando a queda de um avião.
E foi a pouco tempo isso.
Como sempre, ótimo vídeo. Ao meu ver o erro não foi (por natureza) de código, foi falta de revisão de pares + assembly (quem sabe, sabe) + fraude por parte da empresa, só então o código teve a oportunidade de ser um problema. Qualquer parte da máquina que fosse desenvolvida dessa forma teria tido problemas do mesmo nível.
Eu tinha um rádio relógio 100% analógico. Na hora programada ele ligou corretamente na estação de rádio sintonizada. O único problema é que a rádio estava fora do ar, sem tocar nenhum som. Naquele dia eu cheguei atrasado 1 hora no trabalho. Lição aprendida: Além de mudar a estação do rádio eu programei meu relógio de pulso para despertar como redundância.
Caraca amigo, vc consegue ouvir o alarme do relógio de pulso? Então meu sono é de pedra mesmo! kkkkkkkkkkkkkkkkkkkkkkkkkkkkk
@@Palitinho15eu não consigo acordar nem com o despertador do celular. Os toques padrão parecem canções de ninar.
Por precaução, eu coloco vários alarmes na sequência a cada 5 minutos.
isso aconteceu numa época em que não era comum usar celular como despertador
@@CarlosRibeiroRC, eu coloquei o toque de alvorada do quartel no despertador.
O problema não era apenas a segurança da maquina ser 100% dependente do código, e sim o fato de que o desenvolvimento de um sistema tão delicado negligenciou praticas de programação já consolidadas na epoca, muito provavelmente pela busca de alto lucro e baixo custo da empresa irresponsável. Até hoje vemos empresas que praticam o mesmo, tratam testes e qualidade como obrigação, custo e não um investimento. Sempre bom relembrar casos assim, pena que as pessoas juridicas se educam pelo bolso e não pela fatalidade do ocorrido. É frustrante ver esse cenário sendo da area de TI.
Na minha época de programador eu dizia ao meu chefe "pô o programa fez besteira" e o meu chefe retrucava dizendo "vc fez besteira. A máquina obedece o código que vc programou". A transferência de culpa é tão velha quanto Adão e Eva.
Pior que a Therac-25 foi o software dos novos aviões B737 MAX que derrubou dois deles cheios de gente dentro. Por isso um software precisa ser exaustivamente testado em todas as condições possíveis porque o bug está lá desde o início só esperando determinada condição acontecer.
A culpa é minha, eu coloco em quem eu quiser
No 737 Max o problema vai além do software, passa principalmente pela negligência da Boeing. Os engenheiros projetaram o avião com apenas UM sensor para o MCAS - que é normal ter danos por choques com objetos e pássaros, sem nenhuma outra redundância, sendo que a aviação é justamente segura por possuir muita redundância para tudo. Então, basicamente o software tinha uma única fonte de informação e, apesar de falta de sanity check no seu código, o início de tudo foi a Boeing querer economizar em sensor e em treinamento
Isso tudo faz muito sentido. Eu pretendo ser desenvolvedor no futuro, e quero me tornar um profissional que sabe o que está fazendo, para não comerer erros assim (e que eles sejam corrigidos no tempo certo).
Esse é o problema, ela segue exatamente o que a gente diz pra ela seguir 😅
Caramba nunca tinha ouvido falar antes! Pedro gosto muito do jeito que são contados os fatos nesse tipo de conteúdo, como é feito o desenrolar dos fatos e no final com um tom de esperança e uma lição, assim como no vídeo sobre o Robert Oppenheimer. Certamente esse é um dos canais favoritos que sigo. Sucesso sempre!
História muito triste, foi mencionada no meu curso de sistemas de informação, a pergunta que fica é, vai ter ep do sinapse sobre isso? acho que seria uma boa ouvir o Greg falar sobre
Uma observação, não é possível confiar numa máquina pois esta só faz o que seus desenvolvedores criam atraves de um processo de desenvolvimento. Portanto ao "confiar na máquina" Na verdade a confiança é depositada nos desenvolvedores e no seu processo. Ótimo vídeo, tmj.
Esse caso pra mim é igual Chernobyl é um erro humano, de cagada do inicio ao fim
E quem leva a culpa é a pobre da radiação
@@Italo-oh4ee né
Factual
O maior erro humano é querer desenvolver algo que corrija seus erros sabendo que no caminho, haverá mais erros.
É como dizem, na gana de querer corrigir erros, se cria mais erros.
avanço tecnologico nao e um erro e uma conquista@@bowserlv100
Trabalho com hardware há 53 anos e software quase o mesmo tempo.
Achei este trabalho muito interessante. Vou divulgsr este video para os outros dinossauros da informática que eu conheço.
Por falar em mensagens de erro: são os maus comuns erros importantes de todos os softwares.
Lembro de ter visto esta história em algum lugar, depois no final do ano passado vi no canal do Stackz e agora verei novamente
Ótimo vídeo, parabéns Pedro e a equipe. Isso tudo que foi mostrado faz muito sentido, e é triste que tenha ocorrido tanta negligência. Ao meu ver, o erro não é da própria máquina, e sim de quem a fez, nós não somos perfeitos, por isso as máquinas que criamos também não são. Eu pretendo ser desenvolvedor no futuro, e quero me tornar um profissional que sabe o que está fazendo, para não comerer erros assim (e que eles sejam corrigidos no tempo certo).
Bugs em máquinas de radioterapia são ruins, mas imagina em um Airbus A330. Ta certo que ninguém sabe se foi um bug que quase derrubou o voo Qantas 72, mas ainda sim, os sistemas críticos exigem uma robustez para esse tipo de coisa não acontecer. No voo Qantas 72, o piloto recebia um alerta que o avião estava caindo, então o avião mergulhava sozinho para recuperar velocidade, os dados da ADIRU pareciam ter erro no I/O da memória, fazendo os dados se misturarem. Se o avião tivesse mais duas ADIRU, os passageiros jamais teriam sofrido fraturas.
O caso dos Boeings 737 Max, até aonde acompanhei parece ter sido falha de software
Na verdade existe um bug muito pior, que fez muita gente cometer suicídio e a falência de inúmeras empresas, ele é chamado de bug do milênio, ocorreu pq os anos era definido apenas por 2 algoritmos em todos os computadores globais, e quando chegaram no ano 2000, o computador reconheceu como 00 e reiniciou todo o sistema, fazendo quase todos os computadores perderem todas as informações, pesquise é muito interessante
@@cesarmayhem E falta de redundância em hardware, pois a boeing construiu o Max com apenas um sensor do MCAS enviando informações para o software. Logo a redundância é que torna a aviação tão segura! O sensor dando problema, como ocorreu (normalmente devido a colisões com objetos e pássaros), ele envia dados errados para o software, que por sua vez não possuía uma checagem mais adequada.
Demais a reflexão sobre não confiar cegamente em máquinas !
Na verdade, isso foi uma falha humana, pois foi um humano que fez o código e não preveu o bug
Inteligente
Em meu primeiro ano no curso de ciências da computação aprendemos sobre o therac 25 mas não tão aprofundado quando a relação de hardware e sim sobre o software apenas, obrigado por trazer tanto conteúdo sobre o assunto
Falaria para meu patrão a seguinte pergunta. Se nós erramos pq um software ou uma máquina não erraria, já que é feita por nós?
Parabéns pelo vídeo!
Já tinha visto falar sobre o caso em canais gringos e, devido a relevância do tema, me surpreendi vendo que não haviam videos em português sobre a história.
Parabéns pela iniciativa, como sempre, um vídeo milimetricamente bem feito.
Hal 9000 me ensinou que pior que uma maquina errar é uma maquina acertar e seguir com exatidão seu protocolo
Máquina alguma erra, quem erra é quem programa ela
Já conhecia o caso, inclusive vi vários vídeos de autores diferentes, mas nenhum explicado de forma tão clara.
Aproveitando o ensejo, gostaria muito que fizesses um vídeo sobre o incidente com o voo 72 da Quantas, operado por um Airbus A330, que saiu do aeroporto Changi em Singapura com destino a Perth, na Austrália( aquela cidade que o Lito, do Aviões e Músicas, adora pronunciar o nome ), em 7 de outubro de 2008.
Leigos normalmente não o classificariam como falha de software mas, sob o ponto de vista da Engenharia de Software atual, é uma falha, embora não possa ser classificado como bug.
botaram o estagiário pra programar tudo
Em 13:38, temos um erro de software dessa I.A.!
Esse cara é claramente junção de hardware e software, uma vez que é impossível um humano saber tanto 😂😂😂🤣.
Pedrão, só uma correção: "Automobilismo" diz respeito ao esporte a motor (competições de automóveis). Para a indústria automotiva, nós do ramo usamos o termo "automobilística" ou "automotiva" mesmo. Parabéns pelo canal! Sou inscrito há anos e sempre aprendo muito com você.
13:31 alguém esqueceu de cortar essa parte.....
Vídeo maravilhoso, sou da área do desenvolvimento e esse é um exemplo perfeito do porque um software precisa de testes extensivos e tempo para desenvolvimento. Assim os responsáveis conseguem olhar através de diferentes cenários e pontos de vista.
Tá aí um vídeo q eu n esperava ver zuando o Palmeiras 🤣🤣🤣🤣🤣🤣
Kakaka, serião?
@@brunomarques64981:13
Não sou palmeirense , só passo raiva com a Seleção Brasileira !
Mas onde no vídeo você viu ou ouviu isso ?
@@LuisAntonioMenghi1:15
@@LuisAntonioMenghina hora da conversa do chat gpt
Pedro vc poderia fazer um vídeo sobre a hidrazina e como ela foi banida do senário do automobilismo!!!
Esse vídeo apareceu bem depois de mim ir para um hospital e fazer radiografia. Você está me rastreando??
Edição 1: Acabei de fazer teste de sangue. Foi dolorido...
Que história macabra e interessante ao mesmo tempo!!! Faço curso de Técnico de informática e esse vídeo serviu como um alerta das reponsabilidades que eu tenho que ter na minha futura profissão para evitar casos como esse!!!
Petição para o Pedro mudar o nome do canal para "Ciência a cada 3 dias" 😅
👇
Já tinha ouvido falar no caso mas nunca com uma explicação real das consequências das dosagens e afins. Excelente vídeo!
Pedro faz um video explicando sobre o raio-globular "raio-bola" porfavor 😅
To tentando entender sobre a existência dele
Mesmo considerando o momento em questão, sabendo das dificuldades tecnológicas, seria prudente ter um medidor de radiação independente da máquina que pudesse verificar se era compatível o nível de radiação informado por ela, com o que estava realmente sendo liberando.
O programador era sobrinho do dono da empresa kkkkkkk
Ou talvez seja o próprio dono
Esses casos me fascinam e fazem eu ter certeza que eu quero fazer algo na área de TI
Um erro de HARDWARE muito bom foi um bit flip acho que por volta dos anos 2000 que mudou o resultado de uma eleição em shaerbeek em bruxelas.
Salve Pedro! Duvido tu fazer um vídeo sobre o césio 137,um caso de acidente radioativo aqui do Brasil. Fort abraço 🤙🙏
Desculpa pelo atraso de 4 MESES.
Desculpa pelo atraso de 5 MESES
Desculpe pelo atraso de 6MESES
Desculpe pelo atraso de 6 MESES
desculpa pelo atraso de 8 meses
15:30 "parar pra refletir o quanto que a gente confia nas máquinas"
Eu quando vou ensianr qualquer coisa sobre computação (ou máquinas em geral) pra qualquer pessoa: NUNCA CONFIE NA MÁQUINA
Quem escreveu o código foi o Pablo Marçal
Pega o código kkk
Um dos melhores canais do RUclips brasileiro! Mil vezes melhor que TV aberta.
Pessoas esquecem que máquinas são feitos por humanos
Pra vc ver o poder que um hardware tem! Ele poderia travar a maquina antes da desgraça acontecer mesmo com o software escrito errado e se o operador fizesse algo errado
Eu tava vendo esse vídeo e quando eu vi tinha 365 mil visualizações kkkkkkkkkkk
Faz vídeo sobre o Universo 25 por favor 🙏
Tirei 2 em uma prova na faculdade usando chatgpt (direito penal). QUASE reprovei por conta disso
Cara, você sempre tem que pedir a fonte das informações e conferir. Chatgpt auxilia, mas não serve como substituto integral do seu trabalho.
Aprendeu???
Kkkkkkkkk
Dentro da Eng. de software vemos isso como sistemas críticos: missão, segurança e negócio. Creio eu que esse se enquadre no de segurança.
Teve também o erro de software da Boeing no 737 MAX, que resultou na queda de dois avião, esse erro não seria pior?
Faz pouco tempo que acompanho o canal mas tenho gostado bastante! Que legal um canal de ciências assim
O chat gpt dizendo que o Palmeiras tem mundial enquanto o Pedro diz que o chat gpt não é confiável HAHAHA
PARABÉNS. São casos como esse que demonstram a necessidade absoluta de NUNCA confiarmos cegamente em equipamentos/sistemas/programações desenvolvidos e/ou projetados/montados pelos Seres Humanos, porque SOMOS FALÍVEIS! Toda ATENÇÃO e CHECAGEM, às vezes até a EXAUSTÃO , são IMPRESCINDÍVEIS!
Como outro RECENTE exemplo, veja o caso do BOEING 737 MAX 8 !!!
EXCELENTE ARTIGO e RELATO.
Vocês também reparam que o chat gpt disse que o Palmeiras tem mundial ?
Era um exemplo mostrando que as inteligências artificial não são totalmente certas
Toma kkkkk
@@PabloUmRapazneste caso tava certo
Cara que vídeo fenomenal, sou formado em ciências da computação e esse erro nunca foi mencionado na faculdade!
1:10 Todos os dislikes desse vídeo vieram de torcedores do Palmeiras.
Isso é o que acontece quando se manda o código direto para produção sem testes automatizados, code review e QA
Plot Twist : A programação da maquina foi feita pelo CHAT GPT e vendida aos diretores da empresa canadense por um viajante do tempo clandestino de 2042 😳
Não tem os vídeos desse canal serem ruim. Parabéns 🤩
Pedro desculpa mas você está errado, o pior erro de software da história foi o do Boeing 737 MAX que vitimou 346 pessoas, acho que ganha de longe desse que você mostrou aí...
ali não foi erro, o código estava certo com o que eles queriam, o problema foi, nao avisar a tripulação sobre o novo sistema e o sensor só receber dados de um Pitot
Ele não tá errado. Só tava desatualizado.
Você está errado. O problema não era o TCAS, e sim indicador de ângulo de ataque e a falta de treinamento por parte da companhia. O erro de indicação é mais hardware do que software. Não fala merda.
@@blitzkow1917 parabéns você sabe mais que a Boeing. Pois a própria empresa diz que a falha foi do software. Claro que também faltou a redundância no caso dos sensores, mas houve sim erro no software do sistema MCAS.
@@MattVanelucci Primeiramente, não é a boeing que faz o relatório, a boeing é a INVESTIGADA. Outra coisa, ta literalmente no relatorio final que a maior falha foi falta de treinamento. Problema de indicação mesmo sem redundancia nos sensores JAMAIS deveria derrubar um avião. Não foi software.
Aprender na escola: ✖️
Aprender com o Ciência todo dia: ✅️🗿
Primeiro
e quem perguntou?
@@TokiSytEu
@@anonimo_4937 obrigado soldado, você me salvou 🫡
@@TokiSytTMB
Tema perfeito, gostaríamos de mais videos como esse por favor.
Vi essa historia no canal do Stackz, achei bem interessante!
Um abraço Stackz ❤
as pessoas esquecem o principal sobre máquiinas: apesar de reproduzirem menos erros que os seres humanos, elas ainda são criadas por seres humanos.