3 ms·

> Flippant comments to “just use Linux” are not understanding the realities of keeping 20yr old software in the medical, offshore drilling, etc industries. I m

> Flippant comments to “just use Linux” are not understanding the realities of keeping 20yr old software in the medical, offshore drilling, etc industries. I make such comments. Tell me: what exactly is problematic about medical, offshore drilling, etc industries which makes it difficult or impossible to switch? ... wanna hire me to work on that? I am convinced that, whatever the cost is, it will be cheaper than using software on a very-outdated very-proprietary operating system for another couple of decades.

tsujamin 10mo ago
To name a few (presumably): drivers, proprietary protocols, vendor warranties/support, licensing/relicensing, paying you to do the work, waiting for the work to be done/tested, paying for workforce re-training, justifying this to management etc. All these reasons suck, but they’re all reality in one industry or another sadly.
- tadfisher 10mo ago
  It was the same reality 20 years ago when they ditched DOS for Windows XP. At least now it's far easier to run most things in a VM.
- inetknght 10mo ago
  > drivers Linux kernel is open source and really easy to read, and also fairly easy to write drivers for. > proprietary protocols I've written many network softwares, and proprietary protocols aren't difficult to me. > vendor warranties/support Fuck vendor lock-in. Move to Linux. > licensing/relicensing Fuck vendors. > paying you to do the work ...is cheaper than paying vendors. > waiting for the work to be done/tested Here, let me demonstrate that it works... with many many many automated tests. > * paying for workforce re-training* Not really important if it's well-done. > justifying this to management A lot of business management can't see past their own nose until it comes to money. Do some maths and show them the cost savings in a presentation. They'll listen.
  - kube-system 10mo ago
    These things are not as trivial as you think they are when that computer is connected to industrial equipment that costs millions of dollars, you have no test environment, the original vendor no longer exists, and any failure or downtime at best will cause millions in financial losses, and at worst will maim or kill people. The best option in these cases is to isolate the system from external networks to keep it secured and keep operating until the organization can afford a major capital expenditure to replace everything.
    - AlotOfReading 10mo ago
      I work in automotive for OEMs and I've seen this at many factories. They still need to switch, because their technical issues are a supply chain risk for me. I don't want to hear that a batch is bad because they did abominable things to the software they were given. That's happened. I don't want to find out that they had a system die or get hacked and now things are shut down until some eBay seller mails replacements. Seen that. So on and so forth. I ran out of patience years ago for the inevitable results of letting an unaccountable third party own decision-making on your critical systems. I'd much rather have that argument when the CEOs aren't breathing down our necks.
      - kube-system 10mo ago
        My experience on this topic is mostly with regulated industries like healthcare and critical infrastructure. It was probably less of a headache because the only solution was to properly maintain what you had or buy something new. Nobody was fucking around with the software or they would have gone to prison.
    - inetknght 10mo ago
      > These things are not as trivial as you think they are when that computer is connected to industrial equipment that costs millions of dollars, you have no test environment, the original vendor no longer exists, and any failure or downtime at best will cause millions in financial losses, and at worst will maim or kill people. > you have no test environment That can be solved. > the original vendor no longer exists Even more reason that your company needs to upgrade. > That computer is connected to industrial equipment that costs millions of dollars ... any failure or downtime at best will cause millions in financial losses I heard a minute of downtime on an oil rig costs millions in financial losses. So a fuck-up is extremely expensive. Nothing new to me. I've also worked in industries where a fuck-up can cost lives. That's also extremely expensive. Trust me, there are software engineers and hardware engineers who know your pains and aren't afraid of how difficult you think this stuff is. Yes it's difficult, no it's not impossible. And it's a lot cheaper than you think if it's done right.
ErroneousBosh 10mo ago
Great. Let me know where you're going to find someone to certify it.
- inetknght 10mo ago
  Point me at the certification requirements and we can figure something out.
TheJoeMan 10mo ago
The issues are not technical, they are documentation and certification. Here is the specifications for medical device software [1] [2]. You can either keep using a legacy (windows-based) software package, or find the need to verify/validate the entirety of linux and all drivers and packages (software-of-unknown-providence aka. SOUP). You then have to devise a patching schedule/methodology, as right now you just tell the end user to apply the Windows security patches if they’d like. This is a high-cost that is hard to argue for despite the obvious advantages. [1] https://www.iso.org/standard/38421.html https://www.iso.org/standard/38421.html [2] https://en.wikipedia.org/wiki/IEC_62304 https://en.wikipedia.org/wiki/IEC_62304

tsujamin 10mo ago

To name a few (presumably): drivers, proprietary protocols, vendor warranties/support, licensing/relicensing, paying you to do the work, waiting for the work to be done/tested, paying for workforce re-training, justifying this to management etc. All these reasons suck, but they’re all reality in one industry or another sadly.

tadfisher 10mo ago
It was the same reality 20 years ago when they ditched DOS for Windows XP. At least now it's far easier to run most things in a VM.
inetknght 10mo ago
> drivers Linux kernel is open source and really easy to read, and also fairly easy to write drivers for. > proprietary protocols I've written many network softwares, and proprietary protocols aren't difficult to me. > vendor warranties/support Fuck vendor lock-in. Move to Linux. > licensing/relicensing Fuck vendors. > paying you to do the work ...is cheaper than paying vendors. > waiting for the work to be done/tested Here, let me demonstrate that it works... with many many many automated tests. > * paying for workforce re-training* Not really important if it's well-done. > justifying this to management A lot of business management can't see past their own nose until it comes to money. Do some maths and show them the cost savings in a presentation. They'll listen.
- kube-system 10mo ago
  These things are not as trivial as you think they are when that computer is connected to industrial equipment that costs millions of dollars, you have no test environment, the original vendor no longer exists, and any failure or downtime at best will cause millions in financial losses, and at worst will maim or kill people. The best option in these cases is to isolate the system from external networks to keep it secured and keep operating until the organization can afford a major capital expenditure to replace everything.
  - AlotOfReading 10mo ago
    I work in automotive for OEMs and I've seen this at many factories. They still need to switch, because their technical issues are a supply chain risk for me. I don't want to hear that a batch is bad because they did abominable things to the software they were given. That's happened. I don't want to find out that they had a system die or get hacked and now things are shut down until some eBay seller mails replacements. Seen that. So on and so forth. I ran out of patience years ago for the inevitable results of letting an unaccountable third party own decision-making on your critical systems. I'd much rather have that argument when the CEOs aren't breathing down our necks.
    - kube-system 10mo ago
      My experience on this topic is mostly with regulated industries like healthcare and critical infrastructure. It was probably less of a headache because the only solution was to properly maintain what you had or buy something new. Nobody was fucking around with the software or they would have gone to prison.
  - inetknght 10mo ago
    > These things are not as trivial as you think they are when that computer is connected to industrial equipment that costs millions of dollars, you have no test environment, the original vendor no longer exists, and any failure or downtime at best will cause millions in financial losses, and at worst will maim or kill people. > you have no test environment That can be solved. > the original vendor no longer exists Even more reason that your company needs to upgrade. > That computer is connected to industrial equipment that costs millions of dollars ... any failure or downtime at best will cause millions in financial losses I heard a minute of downtime on an oil rig costs millions in financial losses. So a fuck-up is extremely expensive. Nothing new to me. I've also worked in industries where a fuck-up can cost lives. That's also extremely expensive. Trust me, there are software engineers and hardware engineers who know your pains and aren't afraid of how difficult you think this stuff is. Yes it's difficult, no it's not impossible. And it's a lot cheaper than you think if it's done right.

ErroneousBosh 10mo ago

Great. Let me know where you're going to find someone to certify it.

inetknght 10mo ago
Point me at the certification requirements and we can figure something out.

TheJoeMan 10mo ago

The issues are not technical, they are documentation and certification. Here is the specifications for medical device software [1] [2]. You can either keep using a legacy (windows-based) software package, or find the need to verify/validate the entirety of linux and all drivers and packages (software-of-unknown-providence aka. SOUP). You then have to devise a patching schedule/methodology, as right now you just tell the end user to apply the Windows security patches if they’d like. This is a high-cost that is hard to argue for despite the obvious advantages. [1] https://www.iso.org/standard/38421.html https://www.iso.org/standard/38421.html [2] https://en.wikipedia.org/wiki/IEC_62304 https://en.wikipedia.org/wiki/IEC_62304