We desperately need a Medical Device Developer Linux distro. I know I’ve blogged about this before, but with all the wet-behind-the-ears kids thinking Agile is software engineering (it’s not) and that it is okay to push whatever steaming pile of excrement came out the back end of the nightly build onto the installed base because they are the Alpha testers . . . I have to vent again.
Our featured image was provided by blog.giddyup.io.
Actually what triggered this rant was Elive sending me an email touting their latest release, claiming they don’t sell anything and wanting $10 to download a new version. Oh, the 64-bit version isn’t official, just some 64-bit software in with 32.
We need a Medical Device Developer Linux distro that:
- Is 64-bit because our Yocto build systems tend to have at least 80GB if not over 120GB of physical RAM and at least 16 if not north of 20 physical core.
- Doesn’t have a virus running in the background constantly pulling/forcing/checking for “updates.”
- Has a back-end repo that allows the desktop to LOCK to only files contained at a specific point in time where it would never pull down anything added to the repo after that no matter how many times someone clicked the update button.
- Limited set of supported desktops: Mate (for certain). Cinnamon (probably). Budgie (possibly). No KDE or anything based on Qt because of licensing issues and the fact Qt has become a completely unusable framework for desktop and medical device development. Read this guy’s rant. His message inspired this post.
- Able to install a .deb file for custom dev tools, especially ones specific to a project.
- Limited number of packages in the repo. Mostly focused for development.
- Tested with NVIDIA!!!! (Sadly most distros don’t bother with this critical step because it cannot be done via automated test scrip. No, TDD and Agile are not Software Engineering!)
Why?
I’ve been in IT almost 40 years. The past decade has been spent in the embedded systems world, mostly medical devices. As part of FDA 510K filings, we have to document each and every piece of software used in the dev down to the version as well as each and every piece of software down to the version installed on the device. An independent 3rd party has to take our written instructions and starting from a bare box install the dev environment, do a full end-to-end build-then-deploy and follow it up with an audit of every file on the systems.
That last step kills most companies, especially first timers. When they diff the directory output the dates, sizes, and versions are nowhere near what is in the documentation.
Why So Strict?
The War Powers Act.
During the Pandemic you heard about GM spinning up a manufacturing line to make respirators, correct? Companies have to document to the level that any manufacturer anywhere in the world can be given our documentation and start making systems without any prior medical device manufacturing experience.
We Don’t Want “New Stuff”
We want a stable known universe. One wants to be able to hand the instructions to that 3rd party test facility and have it tell them
Install version 5.6.7 from this ISO, enter 5.6.7 when prompted, then install this list of software from the repo and disconnect from the Internet.
After they do that the binaries will be the exact same versions having the exact same size and exact same original dates.
For that companies and developers are willing to pay
Personally I would gladly pay $100/yr to have an ISO I could install on my machines and always get the exact same versions of files when I install anything from the remote repo.
Not “the latest version.”
Not last night’s busted pile of excrement.
The exact same version that we used 10 years ago when we first built the device.
Medical device in a box companies would most likely gladly kick in a couple thousand per year each for such a distro that came with that service. I’ve worked for some that would. We all have to deal with this (*&)(*&ing problem with each device. It’s not just creating the device the first time. Ten plus years from now if laws, regulations, science changes and you need to make a small change you have to use the exact same tools down to the version if you want to go through the “minor enhancement” approval path.
We end up having to burn disk images and beg the FDA to allow that or we have to set up our own hosting repo on the local network and point the ISO to that repo instead of the official ones.
Having to host it is a burden every medical device manufacturer has to endure.
Blackberry makes a fortune from QNX not because QNX is awesome but because they build a version of their OS for medical devices, push it through FDA approval _ and the version you purchase never changes _ companies are paying for that hermetically sealed never gets altered service.
We don’t care about the latest security patches because 99% of the time we
- unplug from the Internet after install connecting to an air-gapped local only network if we connect to any network at all.
- Run inside a VM that is either only up a few hours per day or has network access turned off once the install is complete.
What we have to stop is the fool
“I want to use THIS editor!”
“I want to use my favorite library!”
Those are the people we have to purge and purge early from the project to avoid failing clinical trials.
Summary
Companies and consultants with not-empty pockets have needed this for a decade. Instead of creating yet another useless Linux distro that can’t get a hundred downloads per month according to Distrowatch.org, create something that actually is needed. When you find yourself getting wheeled into ER for whatever reason, this absolutely has to work.
Your life can’t wait for someone to dig through the backlog of “User Stories” to fix that crash problem that happens . . . Yeah, that’s my world and I’m sick of kids thinking Agile is good enough for it. “Gathering feedback” via a body count is not Software Engineering. How would you like to be these Agile developers?
