Te respondo citado, sin insultar, y porque creo que se está...
Pablo R. (Root Rat) - e/acc@root_rat
14 views
Nov 01, 2026
~4 min read
Advertisement
1
Te respondo citado, sin insultar, y porque creo que se está cuñadeando por encima de muchas posibilidades. Lo hago desde un espíritu absolutamente constructivo, espero que lo aprecies así Daniel.
Vamos por partes.
En el tema del tren no voy a entrar en detalles que ya bastante ruido hay. Hablemos de tu tesis a modo general.
La frase que rebates no la dice nadie que haya certificado algo. En crítico no se habla de antiguo o moderno, se habla de proven in use. Las normas de seguridad funcional como IEC 61508, EN 50128 o DO-178C permiten justificar seguridad con horas de servicio acumuladas sin fallos peligrosos, y un SIL 4 implica una tasa de fallo peligroso por debajo de 10⁻⁸ por hora. Eso no se demuestra con tests, se demuestra con años de operación o con métodos formales. Cada línea que reescribes pierde ese crédito y vuelve a cero, con su análisis de riesgos, su validación independiente y su evaluador externo.
El documento del F-35 es el JSF AV C++ Coding Standards, que deriva de MISRA C. Prohíbe excepciones, memoria dinámica después de la inicialización, recursión, RTTI y buena parte de la librería estándar. O sea que lo que se usa en un avión de combate es C++ amputado hasta parecerse a C con clases, y congelado desde 2005.
Me llama la atención, siendo tú un experto; que en todo el hilo no salga Ada ni SPARK cuando hablamos de sistemas críticos. SPARK permite probar formalmente ausencia de errores en tiempo de ejecución, y es lo que se usa en control de tráfico aéreo como iFACTS en Reino Unido o en la línea 14 del metro de París, que se hizo con método B y código Ada generado a partir de la prueba formal.
Con la NASA pasa exactamente lo mismo. Decir que usa C++ para todo se queda muy corto. El estándar de código de JPL y las reglas Power of Ten de Holzmann prohíben recursión, memoria dinámica tras la inicialización y bucles sin límite. F Prime, el framework en C++ que voló en Ingenuity, sigue esa misma filosofía, reserva toda la memoria al arrancar y usa un subconjunto muy controlado del lenguaje. Es C y C++ recortados hasta que sean predecibles, la misma premisa que el F-35.
Las ofertas de empleo no enseñan la arquitectura del sistema crítico. Docker, Java o Qt en General Dynamics te dicen que hay HMI, simulación, herramientas y sistemas de misión. Nadie mete un runtime con recolector de basura ni contenedores en un lazo de control con requisitos de tiempo real duro, porque la latencia no es determinista y eso no lo certifica nadie. Y el Patriot es defensa antiaérea, no un misil balístico, por cierto.
Lo de SpaceX es verdad, Dragon vuela C++ sobre Linux. SpaceX no ha publicado su estándar de código, pero Crew Dragon está certificada por NASA para llevar astronautas, y eso exige cumplir la Clase A de software de NASA, que obliga a tener un estándar de codificación y verificarlo. Lo lógico es que vaya por el mismo camino de C++ restringido. Luego usan procesadores comerciales sin endurecer y lo compensan con tres unidades redundantes, cada una con dos procesadores comprobándose entre ellos y votación cuando no se ponen de acuerdo. Ellos mismos explican que eligieron C++ por la cantera de ingenieros y las herramientas, no porque sea más fiable ni por ninguna otra cuestión.
Lo de que Raytheon migre de FORTRAN a C++ es una decisión de mantenibilidad y de mercado laboral, no de fiabilidad, que es por lo mismo que SpaceX eligió ese stack. FORTRAN no tiene ningún problema intrínseco de corrección, sigue siendo la referencia en cálculo numérico y medio HPC corre sobre él.
El 486 del Hubble es lo mismo. Se eligió porque está caracterizado hasta el último transistor, aguanta radiación mejor que nodos más pequeños y tiene errata conocida. En espacio se vuelan RAD750, que es un PowerPC de finales de los 90, precisamente por eso.
Vamos por partes.
En el tema del tren no voy a entrar en detalles que ya bastante ruido hay. Hablemos de tu tesis a modo general.
La frase que rebates no la dice nadie que haya certificado algo. En crítico no se habla de antiguo o moderno, se habla de proven in use. Las normas de seguridad funcional como IEC 61508, EN 50128 o DO-178C permiten justificar seguridad con horas de servicio acumuladas sin fallos peligrosos, y un SIL 4 implica una tasa de fallo peligroso por debajo de 10⁻⁸ por hora. Eso no se demuestra con tests, se demuestra con años de operación o con métodos formales. Cada línea que reescribes pierde ese crédito y vuelve a cero, con su análisis de riesgos, su validación independiente y su evaluador externo.
El documento del F-35 es el JSF AV C++ Coding Standards, que deriva de MISRA C. Prohíbe excepciones, memoria dinámica después de la inicialización, recursión, RTTI y buena parte de la librería estándar. O sea que lo que se usa en un avión de combate es C++ amputado hasta parecerse a C con clases, y congelado desde 2005.
Me llama la atención, siendo tú un experto; que en todo el hilo no salga Ada ni SPARK cuando hablamos de sistemas críticos. SPARK permite probar formalmente ausencia de errores en tiempo de ejecución, y es lo que se usa en control de tráfico aéreo como iFACTS en Reino Unido o en la línea 14 del metro de París, que se hizo con método B y código Ada generado a partir de la prueba formal.
Con la NASA pasa exactamente lo mismo. Decir que usa C++ para todo se queda muy corto. El estándar de código de JPL y las reglas Power of Ten de Holzmann prohíben recursión, memoria dinámica tras la inicialización y bucles sin límite. F Prime, el framework en C++ que voló en Ingenuity, sigue esa misma filosofía, reserva toda la memoria al arrancar y usa un subconjunto muy controlado del lenguaje. Es C y C++ recortados hasta que sean predecibles, la misma premisa que el F-35.
Las ofertas de empleo no enseñan la arquitectura del sistema crítico. Docker, Java o Qt en General Dynamics te dicen que hay HMI, simulación, herramientas y sistemas de misión. Nadie mete un runtime con recolector de basura ni contenedores en un lazo de control con requisitos de tiempo real duro, porque la latencia no es determinista y eso no lo certifica nadie. Y el Patriot es defensa antiaérea, no un misil balístico, por cierto.
Lo de SpaceX es verdad, Dragon vuela C++ sobre Linux. SpaceX no ha publicado su estándar de código, pero Crew Dragon está certificada por NASA para llevar astronautas, y eso exige cumplir la Clase A de software de NASA, que obliga a tener un estándar de codificación y verificarlo. Lo lógico es que vaya por el mismo camino de C++ restringido. Luego usan procesadores comerciales sin endurecer y lo compensan con tres unidades redundantes, cada una con dos procesadores comprobándose entre ellos y votación cuando no se ponen de acuerdo. Ellos mismos explican que eligieron C++ por la cantera de ingenieros y las herramientas, no porque sea más fiable ni por ninguna otra cuestión.
Lo de que Raytheon migre de FORTRAN a C++ es una decisión de mantenibilidad y de mercado laboral, no de fiabilidad, que es por lo mismo que SpaceX eligió ese stack. FORTRAN no tiene ningún problema intrínseco de corrección, sigue siendo la referencia en cálculo numérico y medio HPC corre sobre él.
El 486 del Hubble es lo mismo. Se eligió porque está caracterizado hasta el último transistor, aguanta radiación mejor que nodos más pequeños y tiene errata conocida. En espacio se vuelan RAD750, que es un PowerPC de finales de los 90, precisamente por eso.
Dani Sanchez-Crespo@DaniNovarama
Como "no tengo ni puta idea de lo que hablo", os traigo una lección sobre diseño de sistemas críticos.
La frase es: "Los sistemas modernos se programan con plataformas antiguas como COBOL / FORTRAN / mainframes porque son más fiables"
Veamos unos cuantos ejemplos (sigo):
La frase es: "Los sistemas modernos se programan con plataformas antiguas como COBOL / FORTRAN / mainframes porque son más fiables"
Veamos unos cuantos ejemplos (sigo):
2
Y ya termino que menuda chapa.
Que lo nuevo reduzca el riesgo no cuadra con ninguna curva de fiabilidad de software. La tasa de defectos es máxima tras el despliegue y baja con el uso, y cada cambio la vuelve a subir. La interoperabilidad depende de que la interfaz esté especificada y tenga pruebas de conformidad, no de la edad del código ni del hardware.
Tampoco se puede medir igual disponibilidad que seguridad, y las propias normas lo separan. Lo que en ferrocarril se llama RAMS, siglas de fiabilidad, disponibilidad, mantenibilidad y seguridad en inglés, trata la seguridad por un lado y el resto por otro.
Un sistema fail-safe que ante un fallo lleva todo al estado seguro está cumpliendo su función de seguridad, y parar los trenes, como se hizo, es exactamente eso. Si eso pasa a menudo el problema es de fiabilidad y disponibilidad, cuántas veces falla y cuánto tarda en volver a estar operativo, y eso se analiza con otras herramientas y otros indicadores como el MTBF, el tiempo medio entre fallos.
Que lo nuevo reduzca el riesgo no cuadra con ninguna curva de fiabilidad de software. La tasa de defectos es máxima tras el despliegue y baja con el uso, y cada cambio la vuelve a subir. La interoperabilidad depende de que la interfaz esté especificada y tenga pruebas de conformidad, no de la edad del código ni del hardware.
Tampoco se puede medir igual disponibilidad que seguridad, y las propias normas lo separan. Lo que en ferrocarril se llama RAMS, siglas de fiabilidad, disponibilidad, mantenibilidad y seguridad en inglés, trata la seguridad por un lado y el resto por otro.
Un sistema fail-safe que ante un fallo lleva todo al estado seguro está cumpliendo su función de seguridad, y parar los trenes, como se hizo, es exactamente eso. Si eso pasa a menudo el problema es de fiabilidad y disponibilidad, cuántas veces falla y cuánto tarda en volver a estar operativo, y eso se analiza con otras herramientas y otros indicadores como el MTBF, el tiempo medio entre fallos.