For example, look at the recent minix release notes listing the well known theoretical advantages of a micro when a driver fails. Then look at the actual release notes where ARM USB is broken and crashes the entire kernel, in practice.
So with a theoretically superior microkernel design, you could restart a crashed driver in theory, although in practice when drivers crash they take the kernel with them. So you could recover from an error although in practice it doesn't work.
With a theoretically inferior monolithic design, you can't (easily) restart a crashed driver. Monoliths work around that problem by not crashing. See linux USB support on ARM. So you can't recover from errors, that don't happen anyway, so in practice it doesn't matter.
In actual deployment it doesn't matter anyway because software of a low enough quality to suffer severe driver problems most likely won't live long in the marketplace, and most driver software issues are a symptom of the device hardware being damaged, destroyed, or removed. So if your mass spectrometer A/D converter was vaporized by literal lightning, it doesn't really matter if the kernel crashes; besides the lightning probably vaporized the CPU at the same time.
One event like this is an anecdote. A couple is a trend. A couple decades of this in the marketplace, well thats something else.
Device drivers in QnX are completely separate processes that use send/receive/reply to communicate with the kernel, just like every other process. On top of that they have the ability to talk to hardware. If a device driver causes a bus to be locked and never unlocked or if a device driver starts talking to ports that it has no business talking to then that can cause a problem. So as long as hardware is involved device drivers can cause trouble for all the other processes on the system.
But in QnX those are very rare instances, I've never seen one but my QnX days preceded the arrival of USB.
Privately held company, very small, very wealthy.
Curious how this stacks up against the likes of Amazon's or Twitter's stuff. Or do they have Qnx based setups, as well?
Broadcasts of capacity seekers and offerers. Along the lines of 'I have 50 40' containers sitting in Panama, Colón, destination Rotterdam, bids in by 14:00 GMT tomorrow'.
This would then get broadcasted to all parties that were capable of taking on all or part of that load, within a guaranteed delivery time through just about every medium you can think of with the exception of carrier pigeons.
This does not compare at all with Amazon or Twitter, though twitter uses 'Erlang' in their stack somewhere and quite a bit of the philosophy Erlang uses dovetails with the way you build such systems (which is perfectly logical because Erlang came out of Ericsson and they had problems that were mostly synonymous with message switching).
I'm not aware of either using QnX in their setup.
It does make me wonder if the world should have just gotten better at state machine construction. This seems like if you kept it simple, things would have been straight forward to scale. (Not necessarily easy.)
Which is all to say that I do question how QNX really helped here. Seems more a side detail that neither helped nor hurt the effort.
That is, that you had a network transparent message passing system with high reliability is the key. That it was implemented at the OS level seems a side detail.
That is, if you were to want to build something like that today, I would remove "at the OS level" from the primary constraints in building this solution. Granted... depending on the rest of the requirements, it is highly possible one might go sans OS and just have an FPGA solution. Odds are, though, that would be overkill and more restrictive in possible solutions than necessary.
This is precisely my thought on microkernels. At face value, what is there not to like? In practice, the idea seems overly restrictive and makes it very hard to do some things that you sometimes wish to do.
This was not a theoretical exercise, it built a very deep and wide defensible moat, every Monday was a day pushing a record number of messages through the system since its inception, in other words, growth was continuous and downtime unbelievably (by todays standards) low. Which had a lot to do with the intrinsics of the OS.
And you have my word that without QnX as the cornerstone of that development it would have simply never happened. You can believe me, you don't have to but you're asking me for my reasons and then you proceed to dismiss them on the basis of your theories.
Practice > Theory any day.
If that is your argument, then it seems a moot subject. We'll never know. If Twitter had originated on a microkernel based operating system, would it have gotten the traction it did? Beats me. Not even sure how you could approach such a question.
Now, I fully agree with the view that historically a major way to get these was to go with a solution like QNX. My point is merely that the reliability of other solutions is not as far behind as they used to be. To the point that limiting yourself to only run on one of these systems seems overly restrictive. (And again, that is in today's world. Not the one of 20+ years ago. Probably not even the world of 5+ years ago.)
A huge swath of the real time world (process and industrial control, all kinds of embedded gear) runs on microkernels. They're enormously successful, just not very visible.