Linux OS Is Best for Medical Devices(hackernoon.com)
hackernoon.com
Linux OS Is Best for Medical Devices
https://hackernoon.com/linux-os-is-best-for-medical-devices-rcy32bq
30 comments
Somewhere, someone has released a medical device running on Linux and they have installed unattended-upgrades or a similar thing xD
And probably by accident, at that. Ubuntu's default apt configuration is rather... chatty.
Or, they have released a medical device with customized Linux software and not shared the source as the license requires because it's "proprietary information".
Are you seriously recommending that people disable security updates as though that somehow makes anything better?
Automatic updates? Yes.
If the alternative is a medical device running in an untested configuration, that may well be worse.
Instead, updates should be verified by the manufacturer and pushed out on a schedule.
If the alternative is a medical device running in an untested configuration, that may well be worse.
Instead, updates should be verified by the manufacturer and pushed out on a schedule.
To elaborate on the parent's point, you should not be running automatic updates because you should be running manually verified and rigorously tested updates before you push a change in a safety-critical component. This is because an update to every device containing that component introduces a correlated failure mode. If the change is bad, you risk harming or killing everybody at the same time. This is in contrast to standard hardware failures modes which are much more likely to be uncorrelated, so the chance of harming everybody at the same time is (1 / FailureRate) ^ N. If a safety-critical system requires updates and can not verified and tested in context before being deployed it is criminally irresponsible to deploy such a system. Both automatic and no updates are similarly inadequate in much the same way that even though cardboard is stronger than tissue paper, neither is an adequate bridge building material for a car-carrying bridge.
tl;dr Both no updates and automatic updates are criminally irresponsible. If you can not verify and test updates in context for an appropriate amount of time to verify safety stop before you kill somebody.
tl;dr Both no updates and automatic updates are criminally irresponsible. If you can not verify and test updates in context for an appropriate amount of time to verify safety stop before you kill somebody.
"Security updates" are for things doing all kinds of network stuff - exposing ports, running untrusted code inside sandboxes, that sort of thing. Your insulin pump should absolutely not be doing any of those things.
There's a few DIY insulin pumps, and surprisingly one of them recommends a full apt upgrade: https://openaps.readthedocs.io/en/latest/docs/Customize-Iter...
Reproducibly insecure kernel probably sitting on that network.
That is the biggest engineering challenge for these products. Having timely, effective, accurate SOUP anomaly reviews are critical to ensure that you have patches for issues in the wild, so you don't end up in a situation where you are running vulnerable software for years and years.
This is also why you see a lot of RHEL and SLES in healthcare - commitments for EOL and support timelines are key, and drive a lot of planning for device makers.
This is also why you see a lot of RHEL and SLES in healthcare - commitments for EOL and support timelines are key, and drive a lot of planning for device makers.
Linux also doesn't constantly stream telemetry from devices that are being used in a HIPAA-bound setting unlike Windows which is going be sending everything from operational metadata to memory dumps back to Microsoft who will mine, selling and eventually leak it all.
[deleted]
Linux could be a good choice for some medical devices, but certainly not those where any malfunction could result in the death of a patient. Linux isn't intended to be used for fault-tolerant computer systems, as such systems use specially designed hardware and operating systems.
The problem is that medical devices can literally kill when they malfunction (The Therac-25 is a great example https://en.wikipedia.org/wiki/Therac-25)
The problem is that medical devices can literally kill when they malfunction (The Therac-25 is a great example https://en.wikipedia.org/wiki/Therac-25)
I know that some x-ray devices uses OpenBSD on the hardware that process and send the images to the hospital network.
Which is exactly the OS you choose when you when you're pushing medical data through network stacks. I could belabor the usual arguments regarding "secure by default" configurations, but I'm sure HN readers have heard them before.
No word at all about QNX? I'm surprised it's not even evaluated, let alone recognized as a serious contender.
Can we talk about how, in the first graphic, the "open-source distributions" that garner mention are Debian, Mint, Gentoo, and Slackware? Centos seems like a conspicuous absence.
CentOS was discontinued,
Any Engineer here (preferably EU-based) that wants to join an early stage medical devices start-up? (vested equity offered)
Probably best to use the whoishiring monthly thread: https://news.ycombinator.com/user?id=whoishiring
Thank you. But it was very on topic since it is about medical devices. Just a shot in the dark.
Why the downvote?
Otherwise the 'blue screen of death' becomes all too literal.
Linux has no real-time capabilities and guarantees! Maybe with some crazy patch. But recommending general Linux kernel for medical applications is dangerous. It can not even play and capture audio in RT!!
I hear this argument a lot, but the reality is that most devices that need realtime support will either be using the rt patched kernel, or be using application specific mcu's that handle real-time constraints while the Linux system just acts as the main control hub and orchestrator.
There's nothing "crazy" about the preempt-rt patch and coding your application to use the scheduler policies/priorities. Like anything else worth having in open source, it takes practice to learn or money for consultants.
Being able to freeze a Linux software image and know there is nothing that is constantly trying to update it at the merest appearance of an Internet connection is important so we can do any investigation required of us.