Comment by inetknght
5 days ago
> 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.
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.
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.
> 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.
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.
6 replies →
You are definitely not a person i would hire.
You clearly dont understand that you dont get to make those decisions. Your users need software X to do Y as a business requirement. Are you going to tell them fuck off because you dont support windows? Sure, you could, once.
And no manager would ever okay someone writing a fuckton of driver shit or reverse engineering some protocols just so you can be high king and not use a specific OS.
Fact is business needs drive whats used, and you do not get a say in it, you might think you do, but you really dont. You can give information and options but ultimately it wont be your decision and youll support what the business needs you to support, or you wont be with the business anymore.
Yeah i agree vendors suck and so do license related shit, but you arent going to convince management that you could write a superior product AND support it for less than the cost the vendor would charge the company. And yes, this isnt always true, there are obviously some times when it is actually better to do it yourself, or use a foss solution. You still wont win in most cases. Users are going to use the thing they need and if youre blocking them from moving forward, youre more problem than the software youre trying to stop deployment of.
This type of flippant childish behavior isn't helping your cause.
I'm sure you can rewrite every piece of professional software yourself in a day for $100 and offer zero support. That will go over swimmingly in the real world.
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 [2] https://en.wikipedia.org/wiki/IEC_62304
Great. Let me know where you're going to find someone to certify it.
Point me at the certification requirements and we can figure something out.