SoylentNews is people
SoylentNews
Open Source Initiative bans co-founder, Eric S Raymond:
Last week, Eric S Raymond (often known as ESR, author of The Cathedral and the Bazaar, and co-founder of the Open Source Intiative) was banned from the Open Source Intiative[sic] (the "OSI").
Specifically, Raymond was banned from the mailing lists used to organize and communicate with the OSI.
For an organization to ban their founder from communicating with the group (such as via a mailing list) is a noteworthy move.
At a time when we have seen other founders (of multiple Free and Open Source related initiatives) pushed out of the organizations they founded (such as with Richard Stallman being compelled to resign from the Free Software Foundation, or the attempts to remove Linus Torvalds from the Linux Kernel – both of which happened within the last year) it seems worth taking a deeper look at what, specifically, is happening with the Open Source Initiative.
I don't wish to tell any of you what you should think about this significant move. As such I will simply provide as much of the relevant information as I can, show the timeline of events, and reach out to all involved parties for their points of view and comments.
The author provides links to — and quotations from — entries on the mailing list supporting this. There is also a conversation the author had with ESR. The full responses he received to his queries are posted, as well.
(Score: 2) by Grishnakh on Thursday March 12 2020, @02:50AM (4 children)
Obviously the people doing MCAS could have used a bit of extra input.
Please educate yourself before making absolutely incorrect posts like this. There was nothing demonstrably wrong with the MCAS software: according to all evidence we have, the MCAS software worked exactly as it was supposed to. It took input from a single sensor, and make excessively-large adjustments to the elevators, fighting against the pilots, and flew the planes into the ground, just as it was programmed to. The software worked perfectly.
The problem with MCAS wasn't the software; it was the systems engineers (probably taking orders from managers) who thought it'd be a great idea to take input from a single sensor that frequently ices up, and to perform excessively-large adjustments (a later change they made from the initial design of the MCAS), and then the managers who thought it'd be a great idea to not mention MCAS in the manual and not bother training pilots on it because that might require them to get a new type rating for the aircraft which would be very expensive and eliminate the 737MAX's advantage. The software engineers simply took the specification they were given and wrote software that did exactly what the spec said.
(Score: 0) by Anonymous Coward on Saturday March 14 2020, @12:50AM (1 child)
The engineers who developed the system *DID* develop it with a 3 sensor system (not even 2!!!!) intending it to have failover if any one sensor was giving erroneous readings. The system as implemented and written off for the aircraft had 2 sensors, the system itself documented to be switched off by an MCAS switch that had been on the older 737 models (the -NG?) and would have allowed the powered trim adjustments to work as expected if there had been runaway trim adjustments from the MCAS unit before it was shutdown. However, between the engineers signing off on the MCAS and its implementation in the 737MAX, someone had it handed over to a different team for 'revisions' these included making the 2nd MCAS sensor optional as part of a much more expensive 'addons' package, and of removing the MCAS switch from the control clusters in order to make room for some other change they did (maybe digital displays?)
This was all discussed on one of the flight forums linked from this very website when the whole 737MAX debate was going on months ago. The key point being: the engineers did everything they were supposed to. Some management, possibly one or two 'complacent' signoff engineers, and a low budget indian staff made revisions after the fact to allow them to cost cut and 'feature price' necessary safety features, which is what lead to the cascade of design failures that caused two planes to crash and hundreds of lives to be lost. The upper management as well as the people who signed off on it need to tried, convicted, and executed in a very flashy and public show trial. The actual engineers who did their jobs, signed off correctly and weren't responsible for these later alterations should be thanked for their service and ideally helped to find jobs at another company. Boeing itself, needs to die.
(Score: 0) by Anonymous Coward on Saturday March 14 2020, @12:56AM
The system was SIGNED OFF with either the 2 or 3 sensor variant. The changes to the 1 sensor system happened AFTER the FAA inspection and testing of the system but before it was installed into the planes. Somehow the FAA didn't manage to catch this change and the planes were able to ship with the 1 sensor, 2nd optional system without requiring a comprehensive (and expensive!) review of the changes. One of the reasons systems were so slow to change in the past was that ANY modification to the system no matter how small would require the retesting of the entire module/system as well as cascading those tests to any larger systems it was involved in. Testing that would prove both time consuming on the order of years, and expensive to implement. The 'streamlining' that happened with the FAA helped eliminate much of this re-testing and oversight and directly lead to the situations that allowed this homicidal negligence to happen.
(Score: 2) by barbara hudson on Sunday March 15 2020, @04:49PM (1 child)
You're building flight-critical software and you notice that there's only ONE sensor and it doesn't raise alarms? What's your failure mode? What if the sensor ices up or is defective? Or a bird strike takes it out?
Even cars have multiple headlights and taillights. Redundancy. Dual hydraulic braking circuits. Brakes on every wheel.
Heck, even humans have guilt-in redundant sensors. Two eyes, two ears. Even the brain is divided into two hemispheres, and the failure of part of one can sometimes be compensated for by the other (especially if you're left-handed or ambidextrous).
SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
(Score: 2) by Grishnakh on Tuesday March 17 2020, @01:41AM
You're building flight-critical software and you notice that there's only ONE sensor and it doesn't raise alarms? What's your failure mode? What if the sensor ices up or is defective? Or a bird strike takes it out?
You obviously haven't worked on flight-critical software. It doesn't work that way.
First off, the original story was that the MCAS was not really flight-critical, and would only make very small adjustments within a small range, and that justified the single sensor.
But more importantly, software like this is requirements-based. The requirements are written by systems engineers, and then translated into DOORS. This auto-generates a lot of the code, which is then filled in by software engineers to satisfy the requirements. It's totally a waterfall process. If the code doesn't satisfy the requirements, it fails; it doesn't matter if the requirements are wrong. The things you're asking ("what if...") are questions for the systems engineers, not the software engineers.
Yes, you're right about redundancy of course, but again this isn't the job of a software engineer in aerospace, that's the job of the systems engineer. Those are the people who really failed, and they did so most likely because they were required to make the requirements this way by managers (under direction of executives) who wanted to avoid the 737MAX having a different type certification.