Comment by fargle | Hacker News Reader

Comment by fargle | Hacker News Reader

Parent Full thread

I have worked with both vxWorks and Integrity, both DO-178 and "standard" version. Both products, both vendors, are absolute garbage. But the certified ones are actually worse because they are frozen.

As far as the "semblance to reality", no that is real. Interfacing to a complex product is complicated. It's simpler to just get rid of driver models and layers and just avoid the entire thing. If you are DAL-A, then why not just be a foreground-background task and skip the "value added" OS layer. It's more reliable, and it's orders of magnitude simpler.

And at the end of the day, the integrator is responsible for all of it anyway. So i'd rather be responsible for 1-2 orders of magnitude less code than some unresponsive 3rd party and their crappy RTOS. And make no mistake - both vxWorks and "Integrity" are not just unresponsive, but absolute garbage. They exist because of ONLY checkbox compliance bureaucracies. You can quote all the "9's" you want - those nines were bought and paid for by the integrator, not the RTOS vendor.

Take the F-35 for example. It's one, and not the only one, that has eschewed COTS RTOS middleware.

That is a weird choice of example because the F-35 avionics software literally runs on Integrity-178.

https://www.ghs.com/customers/lockheedf35.html

https://www.lynx.com/press-releases/lynx-mosa.ictm-selected-...

You have literally linked a press release stating a F-35 system upgrade program has chosen a COTS hypervisor. Still completely the opposite of your claim that the F-35 program has eschewed COTS RTOS middleware.

For that matter, I have not used the vxWorks system, but I have used the Integrity system and literally every one of your technical characterization generalizations (1 million lines of OS, compiler is a out-of-date port, IDE is a Eclipse plugin) is wildly incorrect. Do you care to say the actual truth on any of those to show your actual familiarity on the topic?

they threw away integrity and picked lynx for mission systems on F-35

> Both products, both vendors, are absolute garbage.

Could you concretely explain how? I've never worked in this field and have just seen the typical rhetoric, which makes sense to me (e.g. when considering Ada's safety's higher than rust).

i wish i could, but that's part of the problem. possibly -the- problem.

i've worked on vxworks, integrity, and qnx. if you are a licensee (which is ridiculously expensive), you typically see most or all of the code for this type of embedded os. and it's uniformly atrocious.

but, since it's proprietary, you can't review it or critique it publicly. all you can see is glossy press releases and whitepapers. i assure you, pull the curtain back, and what you find is beyond bad.

it's the exact same issue with internet-of-crap devices, which is more widely known. just slapping a "safety critical" label on a product or paying millions for certification doesn't fundamentally change anything: they will put out the cheapest thing they can get away with. things like DO-178, MISRA, etc. even formal-methods. are supposed to help, but they don't, especially with low-level code like an embedded os. the effort spent certifying means even less time and money available ensuring things like that their drivers flush/invalidate caches correctly and that they use memory barriers right. certification doesn't prove that at all.

we need to make ALL safety critical and security software open-source or at minimum source-available, even if it retains a proprietary license.

Thank you! Do you have visibility into the certifications or business structure here? Like how does a company enter this space with random subpar software? Do the certifications automatically preclude open source software at the moment?

> Like how does a company enter this space with random subpar software?

i don't think they did. they date back to the 1980s and there was a time when just about every printer and wireless router (WRT54) ran on vxworks. they didn't start out doing safety and security. but then much of that embedded space got eaten up, rightly so, by Linux.

so the companies focused more on security safety, automotive, aerospace, side of the market.

but then SoCs keep changing, ports to PPC and RISC-V, multicore. and lots and lots of new drivers for new hardware.

at the same time, compiler technology stopped being driven by proprietary vendor tools and the open source compilers and debuggers eclipsed the proprietary ones in terms of quality. so now what was once secret-sauce is just repackaging open-source.

so less and less real tech to differentiate themselves. and of course mergers and acquisitions happened to most (i believe green-hills is still founder owned)

so: - aging base software that was embedded, but not necessarily designed for safety - much less market share due to Linux - continuous need to add features to keep up with hardware and competition - original engineering teams and management long gone - result: sky-high prices, less money for engineering. it's a death spiral.

> Do the certifications automatically preclude open source software at the moment?

not at all. obviously, not any sprawling typical open-source hobby project is going to be suitable. but for example i like the FreeRTOS/OpenRTOS/SafeRTOS model, and take for example seL4 which is very interesting. and SQlite.

an RTOS, especially a safety-critical one, should be a tiny, simple, thing. 10-50KSLOC. what's making the commercial ones big and complicated are features being pushed by dying companies desperate to differentiate themselves and lock big programs into their product.

Reply on news.ycombinator.com