• Every NASA crewed launch to ISS from US soil is on a stack that uses Linux for avionics: Falcon 9 and Dragon 2. The Starlink constellation is also a massive deployment of Linux nodes in space.

      The backup NASA commercial crew system from the 737 Max people hasn’t flown people yet and probably won’t this year, perhaps never. They somehow managed to have two critical software failures on their first orbital flight test, either of which would have caused loss of vehicle without intervention. Both should have been caught with comprehensive testing.

  • The only real “problem” would be the lack of certifications, which are quite hard to get.

    Real Time Operating Systems (RTOS) are normally used for these tasks, but, AFAIK there are already projects using linux with patches to make it run a RTOS kernel.

    In my opinion, I think it all depends on what part of the plane it is running. If it is a core sensor, providing real time data, it makes a lot of sense to use a RTOS. It needs to prove it can run its tasks on time, and the scheduler needs to be understandable. There’s also a lot of overhead with running a full OS with processes, which don’t make sense for a sensor which only function is to provide data over a CAN/LIN bus.

    But, for other things, like dashboard visualizations, music for the aircraft, entertainment, and those non-critical-realtime needs, then it makes a lot of sense to run linux. After all, you’d get access to a lot of already built software and a working dev environment.

    And don’t get me wrong, this is clearly BS from boeing to keep selling their closed source software. There are already open source RTOS systems, like FreeRTOS. I do not mean to keep those real time systems closed, but to use a full OS where it makes sense and a RTOS where that makes more sense. Both open source!

      • I remember there were talks about merging the patches and making it an option when building. I don’t know the current status of that.

        On real time operating systems, like freertos, not only the kernel is real time but everything else is too. Like: you can guarantee your call on the I2C and SPI won’t take more than 5ms, for example, even with hardware issues. The whole environment is built around the hardware realtime concept.

    • That makes sense, and yeah I imagine the problem isn’t the entertainment system.

      I just don’t get the the last paragraph. I don’t know if using Linux affects their code being OS or not. If they’re just running it on top of Linux and not modifying it, it probably won’t be a GPL violation to keep it closed.

      • Boeing has their own RTOS, which they might be using on more than “real time critical” software. What I mean is: embrace open source, be it Linux or some other OS more specific for that task, but open source all the things!

    • I doubt they run on windows tbh. If they take issue with with monolithic design of Linux, then windows would be an even bigger problem.

      Also, most of the devices in question are probably small controllers, incapable of running windows. (Microsoft are struggling to run it on arm so…)

  • Something to understand here, it is exactly the same with the automotive industry. It is almost never about the actual safety, let me explain.

    If you work as a safety engineer in a company like Boeing the name of the game is to not be responsible for the safety of a component at all. You always hide behind some kind of certifications then always ask a contractor to do it. The contractor might be scared too so will ask for a subcontractor and so on until someone is in an obscure juridiction or brave enough to just develop the software like almost anyone else but just with someone rubber-stamping the paperwork.

    The safety engineer will have the paperwork so for them, it is safe! If there is an issue this is not them.

    So for them Linux is absolutely out of the question, who wants to sign a paper for it?