4 ms·

Think about how absolutely insane some assumptions would have to be for this to be a problem. These are the kinds of things that separate commercial software f

Think about how absolutely insane some assumptions would have to be for this to be a problem. These are the kinds of things that separate commercial software from open source software: in many organizations, commercial programmers typically write to a spec, and the specs usually come managers asking for specific, needed things without both a proper understanding of the larger picture and a nuanced understanding about how those specific pieces intimately fit in to the larger picture. Open source is usually written by people who take pride in what they write, so even though a 32 bit timer for millisecond events almost certainly won't still be running 50 days after you've started a program, they'd still consider, "What if it overflows? Should I handle that event, or should use 64 bits instead?" instead of, "Not in the spec. Why should I care?" And with bad programming practices comes unmaintainability. You want the department who wrote that code several years ago to open it up again, fix some things, then give you a new version? Well, that's going to take months and hundreds of thousands of dollars because they're not set up like that. It's a stupid game with stupid results, yet we have so many apologists who think that if companies with money do it, it must be right.

sheepybloke 5y ago
This post is filled with assumptions. In aviation, the specs generally come down from the OEMs like Boeing or Airbus, who have systems engineers who've done a lot of work creating the specs and defining the nuances. Granted, there are errors (and external bosses who push requirements), but when they are seen down the line by a supplier, they get raised and discussed with the systems engineers at the OEM. Generally, these specs are pretty tight and specific. For something like this, the OEM probably had the operating time set to something like 25 days (over 3 weeks of never turning the plane off once), which gives the timer plenty of room. However, if the customer then doesn't restart for more than 6 weeks, and that's outside of the OEM's specs for the plane, then you're going to have issues no matter what. The actual larger cost is not the maintenance or updates but the verification. There are definitely issues, especially when it's a code base you've been maintaining for 15-20 years, but generally it's the verification that takes the most effort, since often you're not just verifying the new functionality but downstream functionality as well.

sheepybloke 5y ago

This post is filled with assumptions. In aviation, the specs generally come down from the OEMs like Boeing or Airbus, who have systems engineers who've done a lot of work creating the specs and defining the nuances. Granted, there are errors (and external bosses who push requirements), but when they are seen down the line by a supplier, they get raised and discussed with the systems engineers at the OEM. Generally, these specs are pretty tight and specific. For something like this, the OEM probably had the operating time set to something like 25 days (over 3 weeks of never turning the plane off once), which gives the timer plenty of room. However, if the customer then doesn't restart for more than 6 weeks, and that's outside of the OEM's specs for the plane, then you're going to have issues no matter what. The actual larger cost is not the maintenance or updates but the verification. There are definitely issues, especially when it's a code base you've been maintaining for 15-20 years, but generally it's the verification that takes the most effort, since often you're not just verifying the new functionality but downstream functionality as well.