El accidente del Airbus A400M se produjo por un problema de sofware[DE]

Según información del Spegel Online el accidente se produjo debido a un problema de Software de control de los motores que apagó tres motores del A400M.

[#1 Desactivado]

Siempre es culpa del informático.

[#5 silosenovengo]

#1

AMIGO PROGRAMADOR: ¡No te olvides de poner el WHERE en el DELETE FROM!

"los aviones van cayendo y los bancos van quebrando"

[#109 PythonMan8]

#5 Se ha localizado el código responsable:
trycatch (UndefinedEngineException e)

[#6 locolacolina]

#1 #2 Según pone se debió a un problema de calidad del software.

He intentado buscar noticias en castellano, pero no hay mucho que rascar, al menos en los principales medios. De todas formas no tardarán en echar la culpa a la planta de Sevilla, en Hamburgo o Toulouse son dioses (menudos zotes hay en ambas plantas)

[#21 Naeriel]

#6 #8 Según la noticia es un problema de calidad de la planta de Sevilla.

[#22 locolacolina]

#21 no lo dicen drectamente a mi modo de entender, pero lo dejan clarinete

[#47 Jiraiya]

#22 #21 Que se estrellara en Sevilla y no en Hamburgo o Toulouse supongo que afectará en algo.

[#56 Desactivado]

#47 Supongo que podemos descartar la opción de "piloto suicida que se estrella con el avión petado" y barajar la posibilidad de un fallo

[#119 seitansai]

#56 Parece un suicidio, sí, pero de una inteligencia artificial. El software tomó consciencia, vió de lo que iba eso de la aviación, consideró su futuro, y apagó los motores.

Nos hemos librado de skynet, pero solo por esta vez.

[#24 Naeriel]

#21 Home, ese "sehr wahrscheinlich" no deja demasiado a la imaginación Y lo que dice #23 , einräumen es reconocer.

[#45 Robus]

#24 ese "sehr wahrscheinlich" no deja demasiado a la imaginación



Si no hablas alemán, te aseguro que sí!

[#163 garnok]

#45 si, no lo entenderás pero si te lo dicen te acojonas

[#37 meneandro]

#6 Me parece muy muy extraño que hayan mandado a volar un avión con motores a los que no les hayan hecho mil test de funcionamiento, tanto mecánico como de software. Suena más a problema de integración de distintos sistemas de software entre si.

[#53 jazcaba]

#6 El problema se ha localizado en las Unidades de Control Eléctricas (ECU), que forman parte del FADEC (Full Authorority Digital Engine Control), el ordenador que controla el sistema de propulsión. En concreto, los ECU se encargan del motor y la hélice y han sido fabricados por un consorcio formado por la empresa alemana MTU y la francesa NECMA.

Osea, culpa de alemanes y franceses.

[#65 Desactivado]

#53 De hecho por ahora los aviones tienen la restricción de que no pueden volar con una temperatura mayor de ISA+35K debido a que la ECU no está bien refrigerada, me ha dicho un pajarito...

[#115 jazcaba]

#65

[#166 barney_77]

#65 Si te informas veras que temperatura ISA+35 quiere decir que no es la temperatura del modelo estandar de atmósfera a una altura determinada + 35. Esto es a nivel del mar no esta permitido volar un dia con 1013 milibares si la temperatura es mayor de 50 grados. Es una restriccion bastante común en aviación. Tu cuñao te ha dicho un dato irrelevante en este caso

[#67 calvinf]

#6 De hecho tenemos muy sobrevalorados a aquella gente, y, por experiencia, y generalizando un poco, suelen ser más torpes que los españoles a la hora de resolver problemas.

[#69 locolacolina]

#67 yo los lelvo sufriendo varios años... y en fin... para qué extenderme

[#77 redjhawk]

#69 #67 #6 Y ve y diles que se podría mejorar haciendo X e Y.... lo que dices@locolacolina... en fin....

[#120 seitansai]

#67 Los alemanes son muy buenos, en su campo de competencia. Pero si los sacas de ahí un solo metro se estrellan espectacularmente.

[#68 hellodolly]

#6 Pues en esta otra noticia
http://www.reuters.com/article/2015/05/19/us-airbus-a400m-idUSKBN0O417720150519
The Electronic Control Unit is one of two pieces of complex software that make up the engine control system, or FADEC, whose development was led by Munich-based MTU Aero Engines.

[#128 xizor]

#6 Pues dependera de donde se haya hecho el software.

[#181 diminuta]

#6 Dice que muy seguramente se trate de un problema de calidad en el software y que por tanto durante los últimos meses han cambiado el equipo de gestión al completo de la planta de Sevilla. En su momento fue la reacción del jefe de airbus al evidente retraso en las entregas, entre otros, a la Luftwaffe alemana.

[#48 Waskachu]

#1 o según los informáticos, nunca es culpa de un informático.

Muchos colegios de informáticos que querían, poco intrusismo etc etc Pero cuando hay un accidente bien que miran hacia otro lado...

[#60 Desactivado]

#48 negativo por obviar lo que se ha llevado tantas veces a portada: casos de becarios de 500€ que hacen software que la empresa vende por 50,000€.

La realidad responde a la teoría del charco de mierda, y la clave de esa teoría es que la mierda salpica, y que cuanto mas alejado estas, menos te salpica.

Tu comentario lo que hace es reforzarla, salpicando de mierda al currito de turno. En el capitalismo de la empresa privada, quien manda y organiza es el empresario, así que si hay una cagada, culpar al currito es hacerle un flaco favor a la decencia, la de ver el mérito, y en este caso, ver el demérito en quienes no organizan.

Lo de echar la mierda a los curritos es de ANTIPERSONAS, que es lo que explica que esto mas que una democracia parece una guerra civil en diferido.

No seas tan duro con tus semejantes, que un día puede que vengan a por ti, y nadie protestará... (bueno... yo si... que me encanta las causas perdidas )

[#105 Desactivado]

#60 casos de becarios de 500€ que hacen software que la empresa vende por 50,000€

Si no les gusta cobrar 500€ por hacer su trabajo, lo que tienen que hacer es dejar el trabajo, no hacerlo mal, por que al menos en este caso, hay vidas en juego.

No estoy diciendo que sea la culpa de los informáticos, ni mucho menos, como bien dicen por ahí, el peso del software dudo que lo llevasen becarios, pero lo "y como van hacer las cosas bien si no cobran una mierda?" no es excusa.

[#173 Trimax]

#60 Yo me pondría a repasar la cadena de subcontratas, consultoras, o como quieran llamarse. Vamos, lo que vienen siendo "cárnicas".

[#91 mmcnet]

#1 #2 #48 Decir que la culpa del accidente (siendo por causa del software) la tienen los informáticos es como decir que la culpa de que un edificio se derrumbe la tienen los albañiles.

En un proyecto de informático de un mínimo de envergadura, existe una jerarquía de especialistas (programadores junior, programador senior, analistas, jefe de proyecto,- etc.) cada uno con sus responsabilidades y cualificaciones.

Por encima de todo esto, están los empresarios, que toman decisiones del estilo "subcontrátame estos puestos, y cambiamos 10 programadores senior por 5 junior", "hay que cumplir este plazo sí o sí, ¿qué coño es esto de los tests unitarios y tests de integración" etc. etc.

Siguiendo la analogía, si un edificio se cae, la causa en la que pienso, de más a menos probable es:
- El promotor ahorró pasta, y usó materiales baratos y métodos de construcción demasiado rápidos.
- El arquitecto cometió errores de diseñó.
- Un jefe de obras era un chapuzas e hizo mal su trabajo, haciendo mal los forjados, por ejemplo.
- Algunos albañiles trabajaron mal, lo cual es responsabilidade de su supervisor (jefe de obra, el que sea).

Me apuesto un huevo a que en ese proyecto había subcontratación a punta pala, que más del 50% de los salarios se quedaba en bolsillos de intermediarios-amiguetes, que había jefecillos-mercenarios dispuestos a cualquiera cosa con tal de entregar, que no se utilizaban metodologías de programación defensiva, sistemas de pruebas intensivas y control riguroso del software, que hay un documento por ahí con problemas sin resolver con cientos de fallos anotados que alguien cambió de "grave" a "leve" por el puto morro y, SOBRE TODO, que esto no se va a estudiar en detalle y no sabremos más del asunto.

[#97 Waskachu]

#91 vamos a ver. El artículo no dice que la culpa sea de los programadores, dice que la culpa es del Software.

Dentro del desarrollo de software NO HAY esa jerarquía que describes. Es cierto que hay varios niveles, pasando por programadores normales a seniors y también el arquitecto. También es cierto que existe un grupo de testers que se encargan de testearlo todo...

Pero qué casualidad que cuando hay un fallo de software los programadores intentan echar balones fuera a la primera de cambio...

[#102 mmcnet]

#97 Pongo la aclaración por los comentarios con respecto a los programadores, no por la noticia.

Evidentemente, el problema es del software, pero me remito a mi comentario anterior. Claro que un equipo de programadores puede meter la gamba, pero me parece muy improbable que un grupo de programadores con la experiencia requerida y los recursos y tiempo necesarios para hacer bien su trabajo hayan cometido un error tan grave como ese.

[#129 Desactivado]

#91 Y como no se va a estudiar en detalle y no sabremos más del asunto, ya tienes perfectamente claro que en ese proyecto había subcontratación a punta pala, que más del 50% de los salarios se quedaba en bolsillos de intermediarios-amiguetes, que había jefecillos-mercenarios dispuestos a cualquiera cosa con tal de entregar, que no se utilizaban metodologías de programación defensiva, sistemas de pruebas intensivas y control riguroso del software, que hay un documento por ahí con problemas sin resolver con cientos de fallos anotados que alguien cambió de "grave" a "leve" por el puto morro

Ains...

[#96 Desactivado]

#48 En el ciclo de vida del software no solo están implicados informáticos, hay mucha mas gente, de hecho mas gente sin formación técnica que con ella (al menos en España). Realmente si un fallo tan grave como este llega a un avión real en vuelo, el problema no es del informático, el problema está a otro nivel.

La culpa del maquinista, del piloto, del informático... y los de corbata de rositas.

[#99 Waskachu]

#96 total, que la culpa es de Rajoy, no de las personas que desarrollan el software que falla (metiendo en el saco a testers, ojo)

[#100 Desactivado]

#99 Si vamos a hacer reducción al absurdo, habla con mi mano por favor.

[#104 Waskachu]

#100 tú me estás contando una historia, de que la culpa es de jefes de proyecto o no sé qué movida. Yo te estoy contando que la realidad es que existen metodologías de desarrollo de software que eliminan casi por completo fallos, desde luego fallos tan importantes como este...

Si esta metodología no se pone en funcionamiento, mal vamos.

Un programador puede cometer fallos, NO PASA NADA; y no pasa nada porque el software DEBE ser testeado y retesteado en mil entornos diferentes...

Ahora bien, cuando existe un fallo en el software final que hace que 3 personas mueran, habrá que buscar culpables. Desde luego, el que programó ese trozo de código que hizo que fallara tiene algo de culpa. El que no testeó el software debidamente también; y los respectivos supervisores también.

Resulta que ahora los programadores tienen responsabilidad cero?... Así sí mola eh...?

[#144 ummon]

#96 Efectivamente, siempre es muy fácil hablar sin saber…
Cuando un software falla en producción la culpa no es del desarrollador, la culpa es de una batería de pruebas ineficiente o inexistente.
Pero siempre es más fácil “ahorrar” en calidad de software y pruebas exhaustivas y echar la culpa al desarrollador.
El software sin fallos a la primera escritura no existe en el mundo real por más que se empeñen los corbata-mens…

[#55 Desactivado]

#1 A ver si van a empezar a rascar y va resultar que el desarrollo lo hizo alguna salchichera de españistan con 20 becarios explotados.

[#132 Desactivado]

#55 ¿Porqué? ¿Que los únicos informáticos que meten errores en el código trabajan para empresas españolas? ¡Es que hay que llegar a ser papanatas, joer!

[#74 Desactivado]

#1 ¿Te imaginas un mundo en el que cada arma usada para matar a alguien matara a su propio ejecutor?

[#83 frankiegth]

Para #1. Sí, pero esta vez no es una broma. Y no es la primera vez que ocurre que por culpa de un error en el software muere gente inocente. Recuerdo haber leido sobre una máquina de radioterapia en un hospital mal calibrada en su software que expuso a varios pacients a una radiación muy superior a la esperada causando la muerte a varios de ellos. No he encontrado la fuete que enlazarte, pero lei sobre el caso en un libro sobre ingeniería del software.

[#131 Desactivado]

#83 Si mal no recuerdo, la máquina se encontraba en Zaragoza. Y juraría que era marca Siemens, aunque en eso ya no me mojo.

[#27 Desactivado]

#19

O si supieran la de veces que no hay entorno de pruebas y/o certificación porque al economista de turno le parecen caros y no ve su utilidad.

[#40 OZYMANDIAS]

#27 sacto, eso es lo que suele pasar, para que tener un entorno de desarrollo, otro de prueba y produccion?, triple gasto, lo hacemos directamente en produccion y listo

[#81 redjhawk]

#40 Y si supierais la de veces que he escuchado de un programador (programador de cursillo de año) "para qué lo voy a hacer en el entorno de desarrollo si en el de producción lo arreglo en un periquete".... O ... "Si lo hago en producción me cuesta el doble"

[#152 Desactivado]

#81

Pero para eso hay unos procedimientos y una serie de gestores que deberían correr a collejas al susodicho.

[#151 Desactivado]

#40

no es el triple de gasto, pero si es una inversión considerable.

[#135 Desactivado]

#27 Supongo que en vuestras torres de marfil nunca os habréis enfrentado al simple caso de que un cliente necesita un entorno de producción para que su empresa sobreviva, pero no se puede pagar tener ese famoso entorno de pruebas y/o certificación.

[#9 Desactivado]

Sala de ingenieros de Airbus en Sevilla. Dos frikis hablan de sus cosas.


-Pues si tio, este nuevo simulador que me he montado utilizando el programa original del Airbus A400M es la polla. Utiliza los datos reales.
-Ostia, que guapo. ¿Y funciona?
-Ya te digo, y hago unas movidas que flipas.
-Como qué.
-Pues mira, puedo aterrizarlo incluso parando 3 motores.
-¿A ver?
-Mira, mira.
-Una cosa, ¿has desconectado la conexión remota del servidor de datos real?
-Estooooooooo ups. Tenemos un problema.

[#19 Mister_Lala]

#9 Si los usuarios supieran la de veces que "un fallo del sistema" en realidad es la coletilla para " el informático se conectó al entorno real en lugar de al entorno de pruebas sin darse cuenta y estuvo modificando cosas".

[#147 ummon]

#19 Es mucho más usual esta: Al Informático le obligaron a conectarse a Real y cambiar cosas en caliente, porque “había mucha prisa”….

[#28 Sc4ramouche]

#25 el programador que trabajara para una carnica subcontrata, trabajando explotado por 900 euros y al que ni siquiera le pagan las horas extras se merece encima morir.
joer, vaya justicia impartes tu

[#33 m_ark]

#28 Cobrar poco no es escusa para hacer un mal trabajo, ni para el programador ni para el de QA

[#35 Sc4ramouche]

#33 no tener los medios suficientes para tu trabajo desde luego que es una justificacion.

[#34 voromir]

El fallo de software no es la causa sino una consecuencia del problema.

[#89 Desactivado]

#34 Correcto. Yo diría que "El fallo de software que no ha sido detectado no es la causa sino una consecuencia del problema". Pero básicamente es eso mismo.

[#38 Desactivado]

no lo entiendo: para hacer una mierda pinchada en un palo, en el lenguaje que sea, tengo que montar una serie de tests para asegurarme de que no falle Y lo hago. Me están diciendo que metieron software crítico, que si falla muere gente (y de hecho, murió), sin probarlo adecuadamente? Deberían rodar muchas cabezas de directivos de mayor y menor rango

[#142 davokhin]

#38 Yo tampoco, normalmente el software de sistemas críticos se diseña con estándares altos (DAL A) con infinidad de test para verificar que no puedes tener ese evento Catastrófico. Habrá algo más que todavía no nos han contado...

[#23 Franctangerino]

Airbus reconoce problema de calidad en Sevilla planta = Airbus räumt Qualitätsproblem in Sevilla-Werk ein

[#25 Desactivado]

#23 Chapuceros, ojalá los programadores (y sus directores/jefes) fueran dentro de ese avión, aunque lo dudo.

[#43 gontxa]

#23 Claro, seguro que la metodología de programación la impone Sevilla. Y los procesos de desarrollo, pruebas y QA también... Es más, la culpa la tiene el becario. Los que han diseñado todo el circuito hasta que se implanta el software en producción han hecho un trabajo de puta madre

[#32 pacomix64]

Bueno... conociendo a esta gente... Siempre echan balones fuera. Ellos nunca cometen errores... Como por ejemplo poner a un psicópata en la cabina de un avión y dejarlo solito pilotando.
También faltó tiempo para decir que los pepinos contaminados venían de España... y como esas muchas más...

[#2 manuelpepito]

La culpa del informatico. Novedad.

[#18 Desactivado]

#2 Del informático novel sin supervisión y explotado.

[#61 Desactivado]

#18 ¿Habeis visto Estomago?

En la celda había uno que su labor era ser culpable...

Estoy aburrido de ver clamoroso casos de corrupción y delincuencia organizada, que terminan culpando al currito técnico de turno.

Solo hay que ver el robo armado del reflote bancario... Joder como protegen en el PPSOE a sus putos banqueros... ¿Son partidos nacionales o lobbies financieros? Me da que lo segundo.

[#133 Desactivado]

#61 Y qué tiene que ver el reflote bancario con que un avión de una multinacional europea tuviese un fallo y terminase en le suelo? Anda, búscate un calzador, que no tengo a mano.

[#63 otto_xd]

#2 Cuantos informáticos usan TDD/BDD, SOLID o cualquier metodologia para evitar desastres??
EL 99% del código no es determinante en la vida o muerte de las personas, y eso hace que el 99% de los desarrolladores seamos unos guarros del código de tres pares de pelotas.
Y cuando tienes a un tren a toda maquina, es muy difícil pararlo y cambiarlo de via.
Profesionalidad en nuestro mundo es lo que falta.

[#73 clstrife]

#63 Ninguna metodología evita desastres. Evita que vuelvan a aparecer si es que se identifica el porque ha sucedido.

La verdad es que me encanta cuando todo el mundo habla de todas estas metodologías como si fuesen la panacea. O bien es que sus proyectos son internos o bien es que son tremendamente pequeños. En la práctica tal y como las enseñan son casi imposibles de realizar. Por razones como:

- El proyecto lleva 10 años desarrollándose y sólo hay evolutivos, no vas a hacer tests de cosas de hace 10 años o que no sabes ni si se usan. Por lo que tu código nunca estará 100% probado.

- Con metodologias AGILE, no todos tus clientes validan tus desarrollos y por lo tanto o dejas de desarrollar o pasas del AGILE.

- Los requisitos de los clientes hacen que se cambien los modelos de datos de un dia para otro...

- La realidad te puede joder todo un diseño por algo que ningún actor conocía.

[#95 otto_xd]

#73 La calidad del SW va ligada a procedimientos y metodologias, negar eso es mucho negar.
Cuando hay legazy code de por medio, se puede ir introduciendo de forma escalonada dichas metodologias, empezar con un 0% de code coverage y poco a poco tener código seguro.
No es la panacea, pero obviamente es un paso que el 99% de la gente no se toma en serio, y luego pasan las mierdas que pasan.
Aqui somos muy de hacer QA con un ejercito de monos, en vez de invertir en un equipo que se encargue de hacer tests profesionales

Por cierto que AGILE poco tiene que ver con la calidad del código, pero bueno.

[#127 clstrife]

#95 Yo no niego la necesidad de una metodología o procedimiento. Niego la necesidad de las metodologías y procedimientos que surgen ¿Trending? o molones que sirven para venderte cursos de 8 horas a 1200€-3000€ que a duras penas puedes aplicar en tu día a día. Porque la metodología o procedimiento puede variar enormemente entre proyectos y clientes. Además de que en un proyecto no tiene porque trabajar una sola empresa.

A mí me gustaría ver a una persona en un sólo proyecto haciendo TDD. O explicarle a cualquier cliente que te ha pagado un 30% por adelantado que 1 mes o 2 meses después no va a ver nada porque estás escribiendo los tests.

La idea detrás del TDD me parece cojonuda, pero ponerla en práctica requiere de un dinero y una mentalidad que yo diría que pocos clientes se pueden permitir. Ahora bien, para un proyecto interno, una inversión para una propuesta a futuro perfecto.

Y yo ya te digo, si hablas de la calidad del software dime con que herramientas lo mides, entendiéndose como herramienta un atributo cuantificable con el que medirlo para saber que un código es de calidad y otro no. Y te lo pregunto porque parece que tú si sigues esto y me parecería interesante saber tu opinión.

[#14 Azucena1980]

Esto con XP no pasaba.

[#64 frankiegth]

Para #14. Si la vida en el aire dependiera de Windows XP acabariamos como los dinosaurios (o como los cajeros automáticos)...

[#70 Azucena1980]

#64 Siempre negativo, nunca positivo

[#75 frankiegth]

Para #70. Hubo una época en la que siempre era positivo. Coincidió justo con la época en la que no me enteraba de nada.
_{(CC #64)}

[#93 Desactivado]

spiegel es mierda sensacionalista. Van a barrer para casa pase lo que pase y echar la culpa a los del sur, en realidad ese es el estilo aleman.

[#71 ElLoboylaSoga]

Los sistemas militares se hacen en Alemania. Buen intento el de este periodicucho de barrer para casa. Los alemanes son la gran mierda de EADS desde el comienzo.

Si no mirad lo que ha ocurrido con Casidian.

Puta trampa mortal la unión europea con estos "socios". Responsables de 2 guerras mundiales y de la destrucción del sur de Europa.

[#26 tul]

deberian seguir tirando aviones hasta que les pongan unos sueldos dignos.

[#31 m_ark]

#26 no creo que sea un problema de sueldos dignos o no.

Si tienes programadores de baja calidad, debes emplear un buen sistema de calidad.

Debes intentar hacerlo lo mejor que puedas en tu puesto de trabajo, si consideras que cobras poco, a buscar otra cosa toca, pero no hay escusa para decir que como cobro poco, trabajo mal.

Subir el salario a los programadores no va a solucionar el problema, si tienes un programador "malo", no va a mejorar por mucho que le pagues.

Lo mismo suben los salarios, si, pero para gente nueva...

[#46 RojoVelasco]

#31 Y aun que tengas a los mejores programadores trabajando en ello. No se puede dejar la responsabilidad en la habilidad de un humano. Todos somos falibles. Lo unico que podemos hacer es consensuar unos procedimientos de validación y aplicarlos.

[#112 m_ark]

#46 Exacto, y eso empieza desde la fase de diseño, especificación, implementación y pruebas.

Desde mi punto de vista el problema está en la fase de pruebas por no haber cubierto esa posibilidad, si no estába contemplada como prueba, entonces quizás sea porque quién diseñó el plan de pruebas no hizo bien su trabajo.

[#88 mtps37]

#31 Si conoces el mundillo sabrás que los errores en el software son algo inevitable, uses programadores mejores o peores. Por eso te has de dotar de mecanismos que garanticen unos mínimos de calidad en el desarrollo e implantación de software, léase procedimientos estandarizados de ingeniería de software o normas internacionales de calidad (como tienen otras ingenierías), que las hay a cientos para el software, como son las ISO27000.

El problema en España es la la situación en la que esta la "ingeniería" informática, sin ningún tipo de regulación, sin ninguna responsabilidad penal por lo que se hace puesto que no se firma ni se responsabiliza personalmente nadie de nada (la culpa es siempre de la informática, así, de manera general e impersonal), con personal mal pagado y peor valorado, en la que no se suelen aplicar de manera estrictas esas normas, que casualmente, son imperativas en otras ingenierías cuyos proyectos siempre han de ir firmados, aun cuando no existan graves consecuencias por un fallo en el mismo.

[#92 Desactivado]

#31 Si pagas cacahuetes tendrás monos. No es cuestión de que los programadores mejoren si mejora su sueldo. Es cuestión de pagar lo que vale un especialista con experiencia. Como no lo pagan, tienen un programador con poca experiencia y probablemente mediocre.

Tienen lo que pagan.

[#3 gontxa]

Si no fuera porque ha muerto gente, sería cómico
Calidad de software lo llaman...

[#80 dmemesf]

Pues mira que a mi me da que más bien fue un error de sofTware

[#84 locolacolina]

#80 joder vaya ojo que tienes... no sé si lo puedo cambiar.

[#87 Dedalos]

#80 Los software pueden tener puertas traseras, y ser saboteados. Hoy en día no hace falta "aflojar uno cuantos tornillos" para que algo se joda, basicamente porque cada vez mas cosas tiene sistemas electronicos potencialmente hackeables desde control remoto. Detras de la industria militar hay muchos intereses comerciales, politicos y economicos.

[#41 soundnessia]

Si supieseis con que Software y versiones funciona alguN transporte publico os echaríais a temblar.

[#54 Waskachu]

#41 funcionan, sí o no?

Esto es como lo de los bancos y el Cobol. Que sí, que Cobol está obsoleto blablabla, pero a ver quién es el listo que viene a migrarlo...

[#58 jazcaba]

#54 Yo debo ser listo, lo he migrado con bastante exito.

[#59 Waskachu]

#58 tú solito? Menudo máquina no? Y cuánto ha costado la migración?

[#161 jazcaba]

#59 Pues eramos dos. tres años.

[#154 Desactivado]

#54

El COBOL no permanece por lo cojonudo que sea y porque sea complicado migrarlo. Permanece por el cristo de interfaces y dependencias que hay en los sistemas, relacionados con la pasta (bancos) por lo general y donde un error puede costar mucha pasta (y no en horas de programación precisamente)

El responsable dice "ni se te ocurra mirarlo" Luego vienen las risas en los efectos 2000 y similares.

[#72 K_os]

Acá tenemos al culpable:

[#86 Desactivado]

Osea, que los alemanes han hecho un código mal y los españoles no lo han testeado bien

#72 :D:D

[#42 pep009]

Les saldría el mensaje de "Antonio Caraculo no responde"

[#94 Desactivado]

spiegel es mierda sensacionalista. Van a barrer para casa pase lo que pase y echar la culpa a los del sur, en realidad ese es el estilo aleman.

[#51 Desactivado]

Esto con linux no pasa.

[#39 pablicius]

Siempre han dicho en artículos de divulgación que incluso un cuatrimotor puede apañárselas para seguir volando con solo uno de los cuatro motores. A la vista de este accidente ¿nos lo dejamos de creer, o apelamos a los condicionantes especiales (estaba despegando, era un avión de hélice...)?

[#52 chapinet]

#39 Cuando estan haciendo estos vuelos de prueba la verdad es que van bastante bajos y la putada que fue que se llevo por delante unas lineas de alta tension al intentar hacer el aterrizaje de emergencia.

[#85 dakota]

#39 si tienes altura puedes volar con un motor compensando la falta de potencia con un descenso suave, pero no puedes volar eternamente con un motor, ademas de la potencia llevas una asimetria impresionante, y eso hace que el vuelo sea mas critico (viento de costado, de cara o turbulencias y veras que gracia le hara al piloto volar con un motor)
el problema como dice #52 es que volaban bajos con lo cual al apagarse los tres motores empezo a perder altura y choco con los cables electricos, si no el avion podria haber aterrizado y aunque habria sido un aterrizaje muy complicado tal vez habrian sobrevivido

[#98 kesar]

sofware ?

[#57 slender_1]

Bueno, unos estrellan un avión por no testear bien el software, otros por no testear bien el perfil psicológico de sus pilotos. Eso, ya tal, ¿no Spegel?

[#62 Waskachu]

#57 lo mismo es...

[#66 Desactivado]

#57 Lo de la "calidad alemana" hace mucho tiempo que es un mito y nada más. De hecho el 80% de lo que producen es de calidad justita, o directamente infumable.

Lo jodido es que son tan cuadriculados que para ellos no cabe la posibilidad de equivocarse. Como no pueden admitir que (como todos) se equivocan, entonces se dedican a echar la mierda a los demás.

Luego pasa como con los pepinos... pero para entonces ya no se les oye disculparse ni admitir los errores.

[#16 koke21]

Seguramente se dejaron algún flag de pruebas o debug activado. No es la primera vez que pasa.

[#8 Desactivado]

Mi alemán no es muy bueno.
¿Quién y dónde se hizo ese software? ¿Los becarios de aquí o los seniors de Alemania?

[#12 locolacolina]

#8 no se menciona en el artículo, aunque creo que deja entender que es culpa de Sevilla.

[#49 Waskachu]

#8 no es muy bueno o no tienes ni puta idea?

[#13 Franctangerino]

Cada día dependemos más de la programación. Como no tomemos las medidas adecuadas, cualquier día la inteligencia artificial acabara con nosotros.

[#29 Peka]

#13 Pues estamos sin renovar el convenio de Consultoras, yo no digo mas.

[#44 RojoVelasco]

#13 Que tendrán que ver los cojones para comer trigo

[#76 Dedalos]

Yo no me creo nada..., a mi me huele a sabotaje.

[#15 nimux]

Pero ¿dice eso la noticia?
Yo lo único que he entendido del artículo es lo de "... durch Software-Probleme drei ..."

[#17 locolacolina]

#15 sí dice eso
Kurz nach dem Start der Testmaschine hatten drei Triebwerke von den Computern widersprüchliche Befehle erhalten und daraufhin die Leistung abgeschaltet.
Poco después del arancque de la máquina en pruebas (al avión se refiere), tres motores recibieron la orden desde el ordenador de apagarse. (traducción un poco libre)

[#20 Franctangerino]

#15 coño utiliza el traductor de Internet, así quizás lo entiendas un poco mejor.

"La investigación mostró un resultado claro: Poco después del inicio de la máquina de prueba de tres motores había recibido órdenes contradictorias de los equipos y luego apagar el poder."

Los programas no traducen bien, pero ayudan a no entender muy bien lo que dicen.

[#4 Tao-Pai-Pai]

Seguramente software libre, ha pasado muchas veces. Lo usan en las partes más críticas puesto que, siendo gratis, nadie responde de él ni se pueden buscar culpables.

[#7 acido303]

#4 Menuda gilipollez que acabas de soltar macho, espero que te hayas quedado bien.

[#10 gontxa]

#7 pero muuuuy grande.

[#79 mangrar_2]

#7 es un ignorante, no tiene ni puta idea de lo que habla.

[#106 Desactivado]

#79 No es un ignorante, es un troll, sabe muy bien lo que dice

[#140 avalancha971]

#79 Creo que el ignorante eres tú. Ignoras que sabe perfectamente de lo que habla y lo dice para tomaros el pelo a algunos

El comentario es claramente irónico, y el autor un conocido trol.

[#117 el_Tupac]

#7 Es un troll de la casa, siempre está diciendo este tipo de cosas para que le hagan casito.

[#11 Desactivado]

#4 Sí, en GITHUB tienes montones de códigos para ejecutar en los sistemas embebidos de un A400M. Yo mismo ahora mismo estoy haciendo el juego de la serpiente para ese modelo en concreto.

[#146 ummon]

#11 Anda…. Y yo buscando como loco en Sourceforge, va ser por eso que no lo encontraba. Ahora mismo voy a Git…

[#30 Desactivado]

#4 Joer... Crujimiento extremo.. descripción gráfica.

Chacho... menos mal que no había gatitos, grafeno o coletas en tu comentario, que si no, te mandan los negativos por contenedores.

[#36 ogrydc]

#4 ¿ha pasado muchas veces?

Sí, miles, las portadas están llenas de casos de aviones que se caen por fallos en el software

¿nadie responde por él?

Claro, con la licencia de software libre viene un bula papal que te exime de cualquier responsabilidad si decides instalarlo y ejecutarlo.

[#50 Desactivado]

#4 ¿Y piensas que si lo programa una empresa van a empapelar a alguien? Anda que no se testeará poco el software que lo controla todo antes de echar a volar al Airbus, pero bueno huele a programador resentido.

Si hubieses sido tu el que lo programó mal, te ibas a cubrir con las tropecientas mil pruebas que habrías pasado al software, así que mucho no te iban a hacer.

[#78 mangrar_2]

#4 la chorrada del día, ignorante

[#82 Desactivado]

#4 si ya pensábamos que eras tonto, ahora ya lo tenemos claro.

[#90 perrico]

#4 Tus trolleos no son ni graciosos. Dedícate a otra cosa.

[#169 Desactivado]

#4 ¿Pero todavía no te has arrojado a la vía? Jo macho, que lento eres...