4 ms·

They have regular software updates. Just like Windows update, nobody do that regularly

petee 8y ago
Haha, that's surprising though, since these are important systems, if there is an update, doesn't it mean something really needs to fixed, i.e, gps rollover? Any bug left unpatched seems unacceptable Maybe I have more faith in the 'system' than I should...
- kijin 8y ago
  We're talking about the same manufacturer that's responsible for the 737 MAX fiasco. I'm not sure how much trust I would want to place in their software.
  - icebraining 8y ago
    You're putting trust in their software whether you upgrade it or not.
    - sslayer 8y ago
      You forget that Boeing doesn't own these planes. These aren't Tesla's. We are currently in an era were it seems to be expected that the manufacturer automatically update their software without the end user intervention, ie Tesla, Windows, Apple, etc... Thats not how it was done in the past, particularly when the bandwidth didn't exist.
      - icebraining 8y ago
        I don't see how this changes what I wrote.
  - throw0101a 8y ago
    Not necessarily. Different components could be made different companies. While flight controls and handling fly-by-wire could have been Boeing, the FMS could be (e.g.) Honeywell, GE. The FMS, AFCS ("autopilot"), and (primary) FCS are three distinct systems per ATA iSpec 2200: * https://en.wikipedia.org/wiki/ATA_Spec_100/iSpec_2200 https://en.wikipedia.org/wiki/ATA_Spec_100/iSpec_2200 Things can be more blurred with fly-by-wire, but can still be conceptually separate.
- knute 8y ago
  Sometimes, perversely, important systems are the _least_ likely to be updated. Operators require extensive testing before widespread application of the updates, which takes time.
- deleted 8y ago
  [deleted]
Yizahi 8y ago
I concur. For example in telecom getting operators to update anything is just a pain. Unless they are seeing service affecting issues, they are totally fine running decade old software. Also sometimes if they have lets say version 5 and current is version 12, latest, and they need some fix, then depending on the size and wealth of the company they may force manufacturer to create version 5 plus fix, making it a new branch just for them, even if all versions 6 to 12 were already tested in production.
- ethbro 8y ago
  I can speak from the enterprise side of this. Typically this is done because the work required to certify a new version (either internal or external certification) is prohibitively expensive. For core, business critical systems, a lot of large, non-technology businesses simply don't have a mirrored QA setup with enough coverage / integration simulation to work up through. So... faced with a heavy testing price to upgrade, risk due to incomplete testing environments, and known current version behavior... a lot of businesses punt and say "We want our version + only the fix for this issue we're experiencing." It's annoying from the software vendor side (QAing old_version + patch_x2 + patch_q5), but it absolutely makes sense from the business side. The summary reason is: because the customer doesn't have a flexible and testable infrastructure configuration. And that's not really something a software vendor can change.

Haha, that's surprising though, since these are important systems, if there is an update, doesn't it mean something really needs to fixed, i.e, gps rollover? Any bug left unpatched seems unacceptable Maybe I have more faith in the 'system' than I should...

kijin 8y ago
We're talking about the same manufacturer that's responsible for the 737 MAX fiasco. I'm not sure how much trust I would want to place in their software.
- icebraining 8y ago
  You're putting trust in their software whether you upgrade it or not.
  - sslayer 8y ago
    You forget that Boeing doesn't own these planes. These aren't Tesla's. We are currently in an era were it seems to be expected that the manufacturer automatically update their software without the end user intervention, ie Tesla, Windows, Apple, etc... Thats not how it was done in the past, particularly when the bandwidth didn't exist.
    - icebraining 8y ago
      I don't see how this changes what I wrote.
- throw0101a 8y ago
  Not necessarily. Different components could be made different companies. While flight controls and handling fly-by-wire could have been Boeing, the FMS could be (e.g.) Honeywell, GE. The FMS, AFCS ("autopilot"), and (primary) FCS are three distinct systems per ATA iSpec 2200: * https://en.wikipedia.org/wiki/ATA_Spec_100/iSpec_2200 https://en.wikipedia.org/wiki/ATA_Spec_100/iSpec_2200 Things can be more blurred with fly-by-wire, but can still be conceptually separate.
knute 8y ago
Sometimes, perversely, important systems are the _least_ likely to be updated. Operators require extensive testing before widespread application of the updates, which takes time.
deleted 8y ago
[deleted]

Yizahi 8y ago

I concur. For example in telecom getting operators to update anything is just a pain. Unless they are seeing service affecting issues, they are totally fine running decade old software. Also sometimes if they have lets say version 5 and current is version 12, latest, and they need some fix, then depending on the size and wealth of the company they may force manufacturer to create version 5 plus fix, making it a new branch just for them, even if all versions 6 to 12 were already tested in production.

ethbro 8y ago
I can speak from the enterprise side of this. Typically this is done because the work required to certify a new version (either internal or external certification) is prohibitively expensive. For core, business critical systems, a lot of large, non-technology businesses simply don't have a mirrored QA setup with enough coverage / integration simulation to work up through. So... faced with a heavy testing price to upgrade, risk due to incomplete testing environments, and known current version behavior... a lot of businesses punt and say "We want our version + only the fix for this issue we're experiencing." It's annoying from the software vendor side (QAing old_version + patch_x2 + patch_q5), but it absolutely makes sense from the business side. The summary reason is: because the customer doesn't have a flexible and testable infrastructure configuration. And that's not really something a software vendor can change.