While this is critical for an airplane (as well as an automobile) I would think the seeds of this would be desirable in corporate application servers as well. While someone might not lose their life if an app server goes down the "move fast and break things" culture only gets you so far before a culture with adult supervision and an eye toward stability is required.
Every FOSS library rightly comes with a license that states in all caps that "THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND". That is pretty directly opposed to the kind of "We guarantee this software will perform within spec 100% of the time" assurances that airplane manufacturers want.
Being physical devices, even if the design adheres to the spec any individual CPU might still be defective of course. You can only test "is it still good" by periodically running one through a test suite and re-certifying that it still returns the correct answers, but there is never any guarantee that it won't break a second later due to freak circumstances. You can get down to acceptable margins though.
In Railways I have seen two systems running on the same processing and doing a check of the results and then sending it out. If something is opposed then it fails gracefully and safely.
As more and more of our comms move into closed-gardens over the internet, the opportunity for a bug to indirectly result in injury or death grows. All it takes is a bug in a billing system that prevents a delinquent customer from contacting emergency services..
Engineering guilds (and governments) are simply not able to cope with the concept of software being critical, but the key thing at the time was that software engineering was not even acknowledged as “engineering” by the local Engineering guild (which was stuck in a loop around the physicality of civil, electronics and mechanical engineering).
They still haven’t figured it all out.
Computers would probably have ended up alot better if we'd taken that sort of an approach, but it's much too late now.
That said, when it comes to safety-of-life systems, there are very stringent processes in place. Linux does not even remotely fit into its workflows. Linux will never be a safety system, and we should be glad that it isn't.
Come off it. Even if software was that superhumanly complex (most software actually isn't all that complicated, most of it isn't even new, and it has a unique benefit that it can be easily isolated and modularised in a way that physical things usually cannot, and you can easily "checkpoint" things that work and iterate), civil engineering is just as complex and fraught. Buildings, bridges, railways, etc have thousands upon thousands of interlocking details to get right. Structural physics, ground conditions, materials, electrics, HVAC, drainage, specification and sourcing of parts, safety, regulations, building scheduling. It goes on and on. And fixing stuff is more than pushing a new commit.
You cannot overbuild for software. You can over scale. But we don't have plumbing, electricity, foot, space, structural capacities as numerical behavioral properties that we can overshoot.
Both are complex but code is arbitrarily complex. The ways things can go wrong is unbounded.
That's quite a unique take.
> You cannot overbuild for software.
What does that even mean?
> But we don't have plumbing, electricity, foot, space, structural capacities as numerical behavioral properties that we can overshoot.
Sure we do. Ask Texas how the Winter was the past few years. Ask Arizona how their water's doing.
To me, it is exceedingly clear almost every other industry of this planet has far far better developed industrial practices and standards. They can go to school & learn how to do the thing.
There's simply no common accepted curiculum for how to actually build good software. There's too many possibilities, too many ways to success, and so few common threads that actually winnow down succes or failure. Software has a couple cobbled together Christopher Alexander style Design Patterns that can kind of inform some repeatedly usable ideas. And we have millions upon millions of libraries, each of which probably could become a library that is in the top 10% of usage, if conditions were right. But there's just so little rhyme or reason to it all. Software is all happenstance.
You can try to snark your way out of this & shade the difference out, but it should just be so obvious & clear. Software is not as mature. It's practitioners have infinitely more possibilities & exponentially less constraints. Most of it ends up working fair, in such a degree that it's near impossible to judge how far from optimal or how much better it could be working. Almost nothing else is so adrift, so unable to measure & understand how sucessful it is. This should just be clear & obvious. Your protests don't move me. It should be obvious.
If anything, software is more bounded than the physical world. A software program is composed of discrete states. The number of such states is finite and bounded by the memory of the computer (you can only form so many different program states in a finite memory space). In contrast, just cutting a board to length has an uncountably infinite number of ways for it to be wrong.
I've heard this before, shortly before an architecture astronaut is invited into a meeting sans biscuits.
There’s ton of cookie cutter systems being built, especially as things like could bring standardization (mostly to achieve vendor lock in, but that’s different point).
Building 100th web app for some random business isn’t whole new thing.
This is a lie software devs tell themselves to justify producing a shitty product while simultaneously patting themselves on the back for the brilliance they must posses to navigate such wondrous complexity.
But I agree with the point. I think we are at the stage where we view coders (who’s main job should be to “just” write great code) and engineers (who’s main job should be to build safe and cost effective solutions to problems) as interchangeable.
Those are different jobs.
All cell phones in the USA are legally required to be able to call 911 even if they don't have an active carrier contract.
At the moment any coder can claim to be a software engineer.
Certification is needed so we can draw a distinction between those who can code, and those can can engineer software solutions, as well as holding them to a higher standard.
Whether it's software engineer or another domain is immaterial, the title "engineer" is heavily protected and making use of it without the degree is liable for pursuit the same way claiming to be a doctor and delivering medical advice when one is not: in the same way as with the Hippocrates oath, engineers are held to a high moral standard of ethics and integrity. The words "élite de la nation" often comes up - and often in derogatory ways from outsiders - but it is borne out from these requirements, that engineers are to be placed in position of great power and corresponding responsibility, meaning they have a duty to call the shots in high stakes situations in ways that go beyond technical knowledge and mastery but also factor in intellectual and moral values.
One can get a masters degree in computer science and/or software development though, which is the same "knowledge level" of studies (an engineering degree doubles as a masters degree), but that does not make one an engineer, which is a corps (in the same sense that e.g US Marines are a corps). This dates back to Napoleon and the creation of "classes préparatoires" and public (state-owned) engineer schools, heavily inspired by the military. Case in point Polytechnique is a military school (although the goal is not to produce armymen), and entering any of the three french military corps (the navy, the air force, and the "ground" army) as an officer goes through the same classe préparatoire process.
This design has been relaxed over time and for quite a time there are private engineering schools that don't require going through these first two prépa years, but they still require the state certification to legally produce engineers.
What do you call audio engineers?
https://www.computer.org/product/education/professional-soft...
Of course, most of the best software engineers have no certifications.
If software engineers screw up code for say a pacemaker, or an airplane, or a self-driving car, they should be held to the same standards as a civil engineer who was negligent in a bridge design which led to deaths.
For pacemakers the FDA already certifies medical devices based on the entire design, manufacturing, and testing process of which software is only one part. Requiring certification for the programmers involved would be just stupid and accomplish nothing.
Nothing irrational for pushing for it either. Plenty of advantages. It's mostly irrational cranks arguing against it because they think they will lose some degree of freedom.
As I said though, it will happen eventually, and inevitably.
Of course, Linux is mostly competing with Windows and Mac OS, not airplane RTOSes.
Thing is, are they expecting someone to do a linux based RTOS for free? Like just pull it off kernel.org and set it up in the airplane?
You can run multi billion dollar companies that way (Reddit, Twitter, Meta, Tesla), hell you can get richest-man-in-the-world by shitting on everything.
Solaris had a more conservative approach than Linux though and people obviously didn't go in for that, thus IllumOS is essentially dead.
In my opinion, we are still in a "pioneer" phase of software engineering, where expansion (aka "software is eating the world") is prioritized over consolidation. But I think this is already starting to change; one example I've observed (in corporate application servers) being an increased focus on software supply chain management.