Some companies have no choice but to run old systems.
For example in the labs I use there are plenty of equipment hooked up to PCs running Windows 95 and Windows 98. The equipment works fine. The proprietary software for the controller and the logging software is old and there is no version that works on newer systems. The only option is to buy a whole new kit which is a stupid waste of money. So we just use these stand alone Win 95/98 computers instead.
And that's fine... as long as you don't connect them to the network and expect them to interact with other clients. And that's often the case for these standalone machines and tools.
The problem we're having in the real world are all of the companies and schools that have 15 year old machines that they use for reading email and filling in spreadsheets that are connected to the internet because their corporate IT was a guy that liked computers in high school and was hired with zero training.
Shame too, since almost all of those cases would be well covered with Linux distributions, or now even Chromebooks.
In a lab that does clinical work, replacing a single instrument could mean having to re-validate all the tests the lab does, update protocols, get inspections from regulatory bodies, etc... it requires people to spend large amounts of time not doing their "regular" jobs.
Designing a system that is secure is part of the job. Accurately estimating the total cost of ownership is also part of the job.
Ultimately project management and ownership is responsible, but they won't be interested if we don't make our expectations clear.
Downvoting these sort of opinions is just saying it's too expensive to secure some things. To me that means we can't afford to computerize some things in the first place, at least not with the chosen tech stacks.
It depends on how you use the machine and how cautious you are. I ran an un-updated XP machine for 10 years and was never infected by anything.
OTOH, the people in the other departments (running up-to-date machines) fell multiple time for malicious email attachments while our developers department was never infected despite the fact we download stuff from the Internet on a regular basis (be it for libraries or tools) - stuff that doesn't even need sneaky means to get executed. Yet we are in theory subject to the "no software installation without permission from IT dept." internal rule.
So if those machines in that lab don't run an email client and are not used to browse the Internet, they are actually quite safe. The only threats that remain are worms spawning from local infected machines or infected USB pen drives.
The thing is, security can quickly become an unhealthy topic. It's so damn easy to FUD people.
My "new" Win7 machine has this "security advisory" that pops every time I copy a file from/to a network drive that say "this file can damage the computer" even when it's a freaking text file - and I do that all the time (BTW imagine what mental model of security it generates in the mind of non technical people - it's not protection or education, it's fearmongering).
So I went to disable this warning but I then paused for a moment, thinking - what if one day I make an actual mistake and get infected? Will I be blamed for disabling it?
It's so damn easy to say, "if you don't follow this PITA security measure, you will be held responsible for the consequences". I admit that like many I would submit to that. There's no point in gambling my job on this after all, and I have better things to do.
I think that the cyber-security topic needs to be sanitized. And the first thing to do would be to tell week-end security consultants, who don't understand a thing about security contexts and threat assessment, to keep quiet a little so that people that are actually in charge of cyber-security can listen and learn from actual experts.
You seem to be reading way more into my comment than was intended.
I'm just saying it's not cheaper to ignore technical debt. It's actually a bug somewhere in the operational budget or business plan.
If the system should run for thirty years on without an OS upgrade, design and budget for that up front. I promise that no one considered that when they configured a Windows XP box and threw it in a lab somewhere. And, hey, maybe that's OK in the short run. But there was no budget or business plan to replace those systems down the line either.
So, the problem was to support/buy such equipment/software in the first place, which only runs on proprietary software (Windows). Isn't it pretty clear that at some point, the support will end and you end up with such problems. If it would run on Linux, you could at least use a newer Linux and it still should work (although maybe with problems). Another better solution would be if the controller software itself was open, then you could maintain it yourself and port it over to newer platforms. Don't support the manufacturers which give you only closed software. If you do, then that was your choice, and you should accept that it will become useless at some point, and you will end up with such problems.
Yes, but there isn't a choice. You are imagining products which don't exist. Lab hardware is generally very specific and there is usually only a handful of machines suitable for a given application, all of which run out of date software even before they are purchased. The best machine our lab has for running gels appears to be from the 1980s and is using 5 1/4" floppies. Some clinical trials run for 5 years or longer - the equipment needs to be standardised for that period of time. At the moment our IT disconnect it from the network and they are used standalone, which seems sensible and would have been useful in this case.
Yes, there is a choice. You can just not buy from them. If there is no such manufacturer, than if people understand that it's of value to have hardware/software which they can maintain themselves, such market will be created. You could also build the hardware yourselves. But right now, if you ignore it and just buy the hardware anyway, you are kind of ignoring this. I mean, this will never solve the problem, it will always continue to be this way. But it's wrong to say that you have no choice. You accept how it is, and that is your choice, and by accepting it, you are supporting it to stay that way.
> If there is no such manufacturer, than if people understand that it's of value to have hardware/software which they can maintain themselves, such market will be created. You could also build the hardware yourselves.
I'm afraid most of the value is probably in the lab hardware itself, not the FOSS stack fetishism. As such you'd need to figure out how to ship better and/or cheaper lab hardware to gain market share, when an entrenched provider has already learned how to ship state of the art hardware. If you really believe market forces will value FOSS for FOSS's sake that highly, perhaps you'd like to start that hardware startup yourself? You make it sound so simple... perhaps you already started one? But for most, I think the Hobonson's choice I think you're actually proposing is between:
1) Continuing to do lab work with the proprietary hardware
2) Letting someone else replace you when you switch careers to work on your new hardware startup. Your replacement is unlikely to care as much about FOSS as you (after all, you were willing to quit over it!), and even if they do, their replacement likely won't. The perverse result of this is a decreased demand for FOSS lab equipment, not increased demand!
You might increase supply of FOSS lab equipment. Or (and I think this more likely) you'll go bankrupt before moving the needle. Speaking for myself, I can't convince myself of the untapped market potential of this niche, I don't know hardware, I'd be going up against incumbent experts, I'm not passionate about lab equipment... if I somehow acquired investor funding under these circumstances I would worry I had conned them more than I had convinced them of the merits.
Some "choice".
Better to keep doing lab work if that's what you enjoy, and perhaps agitate for less proprietary FOSS options if that's something dear to your heart. Maybe you'll cure cancer and save the lives of future developers of FOSS lab equipment.
> If it would run on Linux, you could at least use a newer Linux and it still should work
No, because if the same guys would be coding for GNU/Linux, it would mean a closed source binary compiled against a very old C library that most likely wouldn't even start in modern GNU/Linux.
Or try to access kernel features, drivers or pathname that no longer exist in modern distributions.
Using *BSD or GNU/Linux for laboratory hardware doesn't mean that the code is made available, or even if it is, it is cost effective to pay someone to port it.
Many of those XP systems have actually code available, at least in life sciences, just labs don't want to pay to port the code to new systems.
I think most C libraries are binary backwards compatible. But even if not, you could just use the old C library for that application and it should work - I don't see why it should not.
Also the Linux kernel should always be backwards compatible.
You could also place any missing files.
Even if that is all too complicated, you could just use an old Linux distribution or Linux kernel and backports patches for yourself, although not sure if that is easier.
What I'm saying is, it's good to have the choice and option to do that.
Of course, like you say, if you have that option but just don't do it because it takes time / money to do it, then that is your choice.
> I think most C libraries are binary backwards compatible. But even if not, you could just use the old C library for that application and it should work - I don't see why it should not.
If dynamic linking was used, the entry points might have been moved, the syscalls have changed, bugs are were being taken advantage of were fixed.
If static linking, the calls into the kernel might have changed or data read from /etc, /dev or other type of expectations from target OS.
So I really really doubt you can pick a static executable compiled against kernel 0.x.y, using a.out format and execute it in Ubuntu 16.04 LTS as example.
Actually, I just need to take the dust out of my Walnut Creek CD's to prove my point.
Nice how you avoided the issue of running code targeted for 0.98.1 (latest kernel release in 1992) against kernel 4.4.z.
Not to mention how disparate the file system structure, including device drivers, of something like Yggdrasil Linux 1.0 is compared with modern distributions.
As I said, easily verified by dusting off Walnut Creek CD's and picking a random binary from them.
If that was the case, it would be easy to upgrade the kernel on old Android phones -- in fact lots of people put lots of work into supporting older phones with newer kernels, and it's often impossible due to closed source driver blobs (exactly the same problem as usually strikes Windows)
For example in the labs I use there are plenty of equipment hooked up to PCs running Windows 95 and Windows 98. The equipment works fine. The proprietary software for the controller and the logging software is old and there is no version that works on newer systems. The only option is to buy a whole new kit which is a stupid waste of money. So we just use these stand alone Win 95/98 computers instead.