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)
