[SystemSafety] State of the art for "safe Linux"

[Paul Sherwood]

Hi Andy,

Thank you for jumping in - please see my comments below

On 2024-08-09 18:05, andy at the-ashworths.org wrote:
> -  “admin” and “paperwork” are important elements of
> engineering. By ignoring these, the task is simply coding;

I agree in principle, but these days software engineers are able to 
automate quite a lot.

There remains a perception that safety requires lots of content in Excel 
spreadsheets and Word documents, which can put people off.

> -  in signing off a safety critical review, the engineer is accepting
> responsibility for their work and is demonstrating accountability,
> another important element of engineering.

Totally agree.

But most software engineers have not had to consider the possibility 
that their work might directly contribute to harming people. If pressed 
many may back away from that responsibility - either because of impostor 
syndrome, or reasonable concern about their own skill level, or because 
they don't trust the leadership/processes/motivations/capabilities of 
their employer.

> I propose therefore that you list be modified to a single item as
> follows:
> 
> Could it be that…
> - most “software engineers” are not actually engineers?!

You may be surprised to learn that I wholeheartedly agree, so long as we 
acknowledge that "most" means more than half.

> In saying this, I’m not trying to diminish the importance of
> developers and coders; I’m trying to identify that software
> development should sit within an established engineering framework
> with appropriate checks and balances commensurate with the level of
> safety of the product.

For many years I have been trying to distinguish the term "software 
engineer" from "developer" and "programmer" and "coder", because as you 
say there is much more needed than just programming.

Incidentally I used to disfavour "hacker" too, until I learned that many 
expert open source contributors would refer to themselves proudly as 
"hackers"...

And before folks pile in with "see, they're just hackers, amateurs" etc. 
I invite everyone to have a read of this document, which describes the 
Linux kernel's actual implementation of "real time" scheduling...

https://www.kernel.org/doc/html/latest/scheduler/sched-deadline.html

If you find any mistakes, I am confident that the kernel community would 
welcome your contributions and be keen to fix.

> Sadly, there seems to have been a steady
> decline in the recognition of engineering over the last 20+ years (and
> its not just in the software field) and that has contributed to the
> current environment where we have situations like Ottawa Light Rail
> Transit, Boeing, Tesla self-driving mode, OceanGate’s submersible,
> etc. Not all of these are safety related, but I feel that in all
> cases, management hubris has over-ridden sound engineering principles.

I wholeheartedly agree.

> I am really not sure what the answer is… somehow we need to move
> away from the “shareholder value” model of projects and get back
> to understanding we’re delivering a product that not only has to
> work but has to ensure that it doesn’t kill its userbase.

+1 and thank you for your comments

br
Paul