My MAX has been updated. Was rebooting every 5 hrs or so
Easy fix!
…and conventional backup instruments would mean business as usual.
Well Peter, this is an issue only on ASPEN MAX with SW V2.10 and V2.10.1.
V2.10.2 is already available from March, so impact should be very limited.
Another ASPEN AD but this time caused by a faulty graphics chip which causes a reboot. The box is being restricted to VFR flight only, which is likely to render the whole aircraft illegal for IFR.
eddsPeter wrote:
I will update the software next time, when being at maintenance.
This failure is covered by FAA AD 2019-01-02
Per airwothiness directive, ADS-B in should be disabled before next flight in IMC or at night or within 25 hrs of time in service from the 7th of february (whichever occurs first).
Aspen restart failure with ADSB in Germany
A while ago Aspen had the problem, that some incoming ADSB-In-Weather signals caused a restart problem on the unit. As ADSB-weather is normally not supported in Europe, that was no problem. But since Garmin has installed their ADSB-Weather-Broadcaststation at Friedrichshafen it became a problem. We had this on our flight to Greece, the Lynx got the signaI and the Aspen restarts. I will update the software next time, when being at maintenance.
alioth wrote:
That’s not a side effect of OOP, it’s a side effect of a parallel system (whatever it may be – a multithreaded program, several programs working on the same thing, etc).
As you say, OOP is orthogonal to parallelism. In fact the first major object-oriented programming language (SIMULA) was designed in the mid-1960s long before parallel programming was common even in the academic community. Interestingly, it featured co-routining which is a pseudo-parallel control structure.
Timothy wrote:
When Object Orienting Programming first came out, and we hadn’t yet fully embraced and understood it, it was amazingly difficult to track down some really abberent behaviour caused by process timing
That’s not a side effect of OOP, it’s a side effect of a parallel system (whatever it may be – a multithreaded program, several programs working on the same thing, etc). It’s still far from a solved problem, and things like race conditions can be very difficult to track down even if you’re writing in straight C. Thread safety is still a massive issue today whether you use OOP or not.
There are some languages designed explicitly for parallelism, such as Erlang, which make it less error prone.
Peter wrote:
I am afraid that “computer science” is not wot it used to be in the 1970s, when you did CPU registers, the accumulator, etc.
I entered the “CS scene” in the late 1970s, first taught at the university in the early 1980s and today (after some detours in research institutes and industry) still teach at the university. I can assure you that students still learn about CPU registers. At my university CS bachelor students do that already in their first year.
I grant you that there can be a major difference between what students learn at a research university compared to a regional university college, but that only underlines my point that we have lots of programmers with poor training and thus poor understanding of what they really are doing.
I am afraid that “computer science” is not wot it used to be in the 1970s, when you did CPU registers, the accumulator, etc. I recall going on a date with a girl c. 2000 who had just finished a computer science masters and she got as far as java, php, javascript… so the rot goes back many years.
Also those 1970s and 1980s people cut their teeth on 8080/6502/Z80/etc assembler because that’s all there was. Today you can skip all that. And no employer is going to be training low level programming.
And what you did at univ becomes irrelevant within months of leaving – because you forgot it, and your first job doesn’t use any of it. Very few graduates go into a job which is a match for their skills or ambitions. Most end up doing crap jobs, just short of sweeping the office floor. But then most graduates are, and always have been, unemployable…
Also people in some sectors of the US technology business move on fairly quickly. I recall one old friend who went to work for a company in California telling me how the standard of living of programmers is so high. They can go surfing at the weekends or even after work, so The Job is not really a big feature of their life. If you make it too hard, they will just take a walk.
but programmers who don’t check all input data at least for syntactic correctness in a critical application should be shot
I suspect that you would then have to certify the input checking doesn’t do any harm… The relevant detail might be that you licensed some confidential protocol document, maybe even got some library to implement it…
