Current challenges with using Linux in aerospace applications
phoronix.com
phoronix.com
https://jobs.boeing.com/job/hazelwood/embedded-linux-senior-software-engineer-virtual/185/51449210064
https://jobs.boeing.com/job/st-louis/embedded-linux-lead-software-architect-chief-virtual/185/51449210736This makes general-purpose Linux systems a hard sell -- Ubuntu and RHEL have e.g. FIPS-validated encryption stacks, but they're generally older releases (currently Ubuntu 20.04 is certified and 22.04 certification is pending), and of course limiting your choice of distro is unwelcome for computational researchers. For data at rest, there are certified self-encrypting hard drives, but they are very hard to source, in part because the FIPS 140-2 suite is also very old, and the newer FIPS 140-3 suite is not yet certified.
There are probably ways around this, the diversity and flexibility of Linux cuts both ways, so you can maybe do a FOSS VM infrastructure on top of a certified hypervisor, and get the best of both worlds that way, but it's a lot of work.
And unlike in the aviation-safety world, it's not clear that the certified solution is technically better. It has pluses and minuses, but the biggest plus is administrative, not technical -- it's easy to check.
Whoever tells you otherwise has got a bridge to sell, as well as some compliance- and "security"-facilitating "solutions" on top.
At a certain level, folks dropped any real pretense that the compliance regulations in industry were for anything other than shifting liability around and ensuring you can check the right checkbox when doing sales or getting audited.
Actual security varied widely, and had zero relation to the compliance checklists.
We're also working on FIPS 140-2 and 3, and support pretty much every compliance framework we can find.
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.
Automotive:
Things that are almost Linux, like LynxOS
Lighter RTOSs like VxWorks.
If it's simple box it may be bare metal.
Oh, and sometimes Windows (but generally not for anything with a safety effect).
In addition to Synergy BSP
Sarcasm, no?
https://tidbits.com/2019/10/21/six-reasons-why-ios-13-and-ca...
I thought we handled this years ago and coming from aviation experts is rather strange that they don't know the industry has migrated away from having a singular operating system that can't die to having a series of redundant fail-safes to fall back to when it does. It's strange to see the places where the microkernel debate still rages on....and how little investment is being made by those complaining multibillion $$ international corporations into projects like fuschia, RTOS, ZephyerOS, GNU Hurd, MIT Mach (or even Darwin), or even Minix!
I think these arguments are disingenuous and while they are valid the various organizations making them seem to aggressively not want to find solutions. I smell a strong desire to hold the vanguard of what they have built until they retire and can be unconcerned with compliance...understandable to a degree but harmful in the long run to be going so fast in the wrong direction.
Maybe Linux isn't a good fit, that's fine but they clearly don't care about that, they just don't want to implement anything and Linux is a convenient scape goat to not have to contribute back into an open source project even one on a BSD license
That's a terrible security approach. The article makes good points.
His position is more nuanced than that. For a full set of relevant quotes, see https://yarchive.net/comp/linux/security_bugs.html
For instance, this quote seems particularly relevant to this article:
"
[...]
In fact, all the boring normal bugs are _way_ more important, just because
there's a lot more of them. I don't think some spectacular security hole
should be glorified or cared about as being any more "special" than a
random spectacular crash due to bad locking.
[...]
To me, security is important. But it's no less important than everything
*else* that is also important!
Linus
"I think this should go down in history as one of the most meaningless statements ever made.
Thus, is it more or less important that the software functions or that it is free of all security issues?
If there was a condition that your UI became a different shade of grey in your web browser: you wouldnt buy a domain, create a catchy name, generate a logo and scream from the rooftops.
He is just saying: there are important security bugs, there are important functional bugs- they are equally important.
Insignificant security bugs are not more important than deadlocks; which if you were depending on the kernel for a life critical system could kill you.
You could also say it's simply a separate domain to care about security above all else. That is true in all things. If safety was your top priority when designing a saw, you would not design a saw at all and the world would not have the use of saws. So, for the saw designer, the top priorities mostly have to do with how well it cuts. It's someone's job to think about safety as their main whole job, but it's someone else.
I don't see anything so crazy about either of these two concepts.
And sure, no one is forcing the maintainers to adopt a different view, but we can judge them for having a bad or incorrect view, and point out issues that arise from that.
And maintainers are not being asked to focus on security above all else, just to treat security vulnerabilities like vulnerabilities instead of just bugs.
The maintainers view is absolutely incorrect and flawed, ultimately it doesn't matter because distributions pick up their slack.
It's perfectly fine to provide constructive criticism for the bus and advocate for positive change.
Aside from that, we clearly disagree, so I really wish you would stop replying to me since this discussion isn't going to go anywhere.
A nice nieche* can excell in*
Thanks phone keyboards.