Hacker News Reader

Comment by nrclark | Hacker News Reader

QNX really needs to modernize if they want to survive. Their tooling ecosystem is stuck in 2008, and their kernel's performance is pretty low. IIRC, the kernel itself is also single-threaded, and can't take advantage of multiple CPUs (even if tasks can be SMP scheduled).

Their moat is supposedly their ASIL certification, but I see that value shrinking more and more over time for the following reasons:

1. If your product has a software-related failure, customers won't care about all of your certifications. Only the end product.

2. I'm not convinced that the QNX kernel is less buggy than the Linux kernel. Also, most failures don't tend to be kernel related.

View on HN

>If your product has a software-related failure, customers won't care about all of your certifications. Only the end product.

If you're in a market where a ASIL certification is needed, the customers ONLY care about this certifications. I keeps them out of jail.

Can you point me at some more detailed rules that support your assertion? Not trying to argue - I’m actually interested to read more details on that.

It’s not really a rule, but rather in some environments you have to be able to say in court that you did everything you could to make sure your software worked safely and correctly. Sometimes you will be risking criminal charges if you can’t.

It's the reason why some companies, like IBM [disclosure: I work for Red Hat], seem to sell products even though there seems to be little rational reason why customers would buy them, as in they have poorer performance or quality at a much greater price. Those products are certified against dozens of financial, safety, security or other standards, and customers in certain markets (government, military, nuclear, automotive etc) simply have to buy the certified products. The consequences of not doing so range from products not being supported, all the way to going to jail for gross negligence.

Edit: I wrote a rather highly rated HN comment about why Red Hat makes money last year: https://news.ycombinator.com/item?id=35588297

Another example of this is FIPS-140 crypto. It is objectively bad crypto in the 2020's. But it's mandated in some settings for either bureaucratic reasons or due to regulatory capture.

The truth is, too many managers have never read the ISO document, and follow the CYA methodology, and ask for everything to be certified. The ISO just says (bare with me with this stupid simplification) “do whatever you want, but make sure p(disaster)<1e-20. You have to be able to justify decisions, but will not helt having certified frameworks, os, and tools, if you did a bad FMEDA

Following this logic it seems to be a good choice to buy RHEL because you have no chance running linux with those probability margins that you just wrote. Electronic components might have those. So stay out of jail

There is NO market where “ASIL” is required. Of course if something happens you better have a safety case as described in the ISO26262, or a good excuse. That being said, that a system has a safety case according to ISO26262 ASIL D, does bot mean at all that all pieces must be certified.

Currently working in a project where ASIL D is reached by having an independent microcontroller, whatching out the whole QM mess.

>There is NO market where “ASIL” is required

Define “required”. If every single legal department at every single major automotive company says “we must obtain ASIL-B certification for our gauge cluster software or we can’t sell cars”, does it matter if regulators don’t overtly mandate it? The legal environments of all of the major automotive markets make it a de facto requirement.

The ISO26262 was defined by the automakers themselves (almost all were represented in the committee) so yes, they want to follow it. There is no legal requirement. It does not specially help in case of litigation either.

It's not legally mandated, but the dynamics of the regulation and the risk-averse nature of companies mean that it's effectively become a requirement to compete: if you don't have it, you're only going to sell to the rare company that is willing to stick their neck out and deal with novel arguments in the paperwork themselves. For commercial aerospace that is none of the manufacturers.

(someone else might come along and certify it themselves, effectively acting as a middleman, but then they're going to get most of the money)

QNX Muon removed the global kernel lock so it has much better multi-core performance.

https://www.qnx.com/developers/articles/rel_7063_0.html#what...

There is a very large installed base of machines running on QNX, including medical equipment, radio communications, railway switches, automotive modules, etc. Most manufacturers are upgrading in small steps and absolutely do not want to start from scratch with their software layer. Most manufacturers are upgrading in small steps and have no desire to start from scratch with their software layer. At best, they will add a touch screen, an arm processor and an Android system, but only for the interface. The critical parts will remain under QNX. The same is true for VxWorks, a large proportion of industrial PLCs, electrical networks, water and sewage systems depend on VxWorks. QNX and VxWorks are omnipresent but invisible systems.

What kind of tooling modernization would even make a difference?

At least SDP 8.0 overhauled the kernel to not be locked to a single thread anymore, which is nice IMO

> kernel's performance is pretty low

Can you elaborate on this? How is it "low"

They did, in the next sentence

Reply on news.ycombinator.com