I worked as a lab assistant in the Pychology department at the University of California at San Diego from 1974 to 1976. The lab I worked in had a PDP-8 minicomputer. While I was there they added a 32K word hard drive for $5000, and upgraded the core memory from 6K bytes to 12K bytes for another $5000. I sometimes think about what I could get nowadays with $10,000.
a PDP-8 is not 30 years old... it was released in 1965. The last batch was in '74, according to wikipedia. That's ~50 years old. Remember, 2000 was 20 years ago.
Thank heaven for RS232 and documented ASCII command sets.
Having to replace working equipment because the software that you paid for can't be transferred to a new computer is a nightmare Often, the old equipment works just fine because the laws of physics haven't changed.
But equally often, by the time it's that old, it's being used for a tiny subset of its original, perhaps for exactly one repetitive procedure. In those cases, it's often easy to whip up a little Python program that talks to the RS232 port via a USB-RS232 converter.
Will the Python program last any longer? Maybe not, but at least its source code is in text format.
Glad it was helpful. It can be super handy to be access the serial port on a piece of equipment that’s not next to you… through a local virtual com port.
I my previous job we used "Moxa Serial to Ethernet Converter" [read-only in one way] to connect with almost 100 machines in various laboratories around the country to get spectography(and other "BIG OIL" stuff) data into my distributed SQLITE and MS-SQL databases back in HQ.
Worked really well. One of the oldest machine was some 286 connected to some freaky gasoline density aparatus :)
In many cases you can't simply upgrade software, as software for such machines does not support anything else - and you can't really reverse engineer drivers for 50 different machines in sane amount of time.
Most of really expensive machines provide some kind of output over serial interfaces - it seems to be industry standard, but I forgot the name for it.
Surprised a lot of this stuff is RS-232. I have a collection of old engineering/telecom test equipment I used for a project and while some of it did offer RS-232 connection, GPIB is probably a bit more common.
Depends on the industry. Chemistry lab equipment like spectrometers more frequently used RS232. But someone does make an inexpensive USB-to-GPIB adapter that basically enumerates as a COM port, making programming pretty easy.
I used to work at an institution where we had this fluorescently activated cell sorter machine that was hooked up to a computer running windows XP and the proprietary software you of course cannot upgrade (as outlined in the article). Since it was so old, IT airgapped it. No USB sticks even. Data left that machine via freshly burned CD rom. It was no 80s machine at least.
You weren't supposed to leave your data clutter on the machine after you burned it onto your disc, but people certainly got lazy with that. If it did crash one day, IT would just have to find another pc running XP to install the proprietary software on. Plenty of ancient equipment floating around random closets at that place. Benefits of a physical installer disc.
I guess it's good to have some mundane article in Nature.
Because otherwise Nature mostly attracts high profile papers, that means that articles in Nature are more likely to be wrong than articles in other journals. (Interesting findings are more likely to be wrong.)
A lot of people will not believe something is real unless there’s an article that can be cited about it. So I guess it helps for when someone demands a source.
Only the back half of nature magazine contains scientific papers. The front half is articles like this one that are meant for a general audience. That part part is surprisingly readable and often quite interesting.
It’s a huge problem, and only getting worse. It contributes to the problem of non-repeatability in science. Also the inability to fix stuff by throwing money at it was one of the reasons I left research computing.
I think most of the world is like this. New equipment means big CapEx asks. A lot of manufacturing runs on an old XP machine held together by ebay parts and duct tape
In some industries the machines can be around a century old if not more, and were converted to computer control only "recently" (as in decades ago). From that perspective, the rapid change in computing is the anomaly.
That's the beauty of open source software and standard protocols like RS232. No matter how long ago the software has been developed you can port it to newer (and more mantainable) machines.
This is also going to be a big Charlie Foxtrot with today's equipment and mobile apps and web portals.
It doesn't matter that you have contemporary hardware to run it on, the developer is gone, their servers are gone, and the app isn't in the store anymore.
All the big machines with computers in them run really old hardware. Airplanes, trains, etc have lifetimes measured in decades. The manufacturers stockpile parts, because these old chips are no longer for sale.
One piece of advice I would offer to people using really old x86 hardware for lab or other purposes, which has hard-to-replace software on it. Find a way to use clonezilla to take an image of the whole (fat16?! fat32?) filesystem, and also of the disk as a whole including partitions. Store it somewhere safe in .tar.xz format. Additionally take images of whatever original install media you can find.
I'm talking about stuff like where you find a system running a CNC milling machine from 1992 with a 60MB IDE hard drive in it.
You might need to pull the hard drive and connect it to a somewhat newer system in order to boot from clonezilla and take the image. Something from the early 2000s with an ATA/33 controller on it should be backwards compatible to almost all of the oldest IDE hard drives. Can be quicker and easier than trying to run clonezilla on the native hardware (or on systems which have no idea of how to boot from a CD-ROM or USB).
If you have something a lot older than that, it can get more complicated. Never personally needed to take a disk image of something with a MFM/RLL ISA HDD controller card driving an old 5.25" 10MB/20MB type drive, but it's probably possible. I bet you could get the controller card working in a 1999 vintage Pentium 3 in the ISA slot with enough hackery.
I once had a hard drive fail this way. It was a 60GB SATA disk from around 2006. I powered down the machine to drop in a couple of new disks and gave the machine a much needed dusting.
When it restarted it had the click of death. The freezer trick worked long enough for me to grab the few kb of data I really needed from that disk.
If you are powering off a very old system that spends most of its life powered on, don't let the hard drives or power supply cool down. Do your best to keep your work as brief as possible and get the thing turned back on before it assumes room temperature. These components tend to run the hottest, you can have cold solder joints contract and stop making contact when they cool down.
Also check any socketed chips and make sure they are fully seated. Chip creep happens when frequently thermal-cycled boards cause the IC's to slowly lift themselves out of their own sockets.
As I recall the origin of Clonezilla was as a GPL/open source licensed community built alternative to Ghost, but to fulfill exactly the same functionality.
I haven't read through the link properly, so I'm as yet unable to comment on the merits of xz or the lack thereof; posting it here for other readers who might be curious, as I was.
I can't say that I've ever seen a corrupt xz file that wasn't in a place where a bzip2 or lzip or anything else wouldn't have also been hosed (a very thoroughly failed ext4fs file system on a dying hard drive).
It could be a situation where it's "how bad are you hosed" - for example a bit flipping in a text document can pretty easily be fixed by hand (though it could be completely missed, and critical to be sure) - but a compressed format could either recover losing a "sector" or so, or simply be impossible to restore anything from it.
There's an argument that you're better off knowing you lost data than having most but with a hidden flaw - but either way you want multiple copies and preferably in a format that contains error detection AND correction - and itself is stored on a filesystem that provides similar (ZFS for example).
I wouldn't use compression at all wherever possible. Those old drives are likely at least two orders of magnitude smaller than modern ones, so storing everything uncompressed, or even the entire disk image shouldn't be problematic. Plain uncompressed files would also be easier to recover in the unlikely, but possible, event of failure of the media used to salvage them to.
Also, it can be a nice trick to take a fs-structure dump: list of all files on disk, with associated sizes, permissions, and md5 hash.
It should be much smaller (and faster) to take such a snapshot, but priceless if you ever suffer corruption for e.g identifying & verifying inodes, restoring permissions etc.
Also useful for identifying which files are vanilla (same as installed from package) so can be restored by other means (finding original package). For that reason, a dump of installed packages w/ version is also useful.
This is literally the reason why I keep my ancient panasonic CF and 1st gen latitudes and thinkpads around.
The laptops have the huge advantage that they have a serial port, which allows to rescue pretty much everything given that you implement an adapter software for it.
I wish modern hacker laptops had an easy non-proprietary way to get a serial port.
The only alternative we have is using an Arduino based solution...but that's like a downgrade compared to 20 years ago.
USB to serial/paralel adapters are good enough for most hobby projects but aren't suitable for professional or latency critical applications like industrial, audio, arcade retro-emulation and CNC machines.
There's too many variables in the way, like the USB to X chip used in that converter plus the driver for it and how the OS scheduler handles the USB stack and API calls, all this causing major jitter in the communication timing.
In uni we still had air-gapped Win2K/98 computers for the robotics labs since in the days prior to Windows XP, your app could write directly to the serial/paralel ports, so you could have your program use 100% CPU load, jitter-free, to poll the serial/paralel port, that's why they were used in CNC. For example your Win/DOS program would directly drive the cutting head in real-time through the paralel port. You can say goodbye to that via USB converters unless you want your expensive machine mangle its cutting head.
My embedded systems prof from uni would only buy Fujitsu (Siemens) laptops as they were the only ones who still sold models with serial and parallel ports on modern hardware even as late as 2017(!), so if you're a professional or serious hobbyist in this space I suggest you grab one of those before they become scarce and overpriced like how high-end CRTs have now become.
There are companies in Taiwan/China making custom X86 barebones/motherboards using modern hardware and old ports but they're low volume and destined for the industrial market so they have eye-watering prices.
> There are companies in Taiwan/China making custom X86 barebones/motherboards using modern hardware and old ports but they're low volume and destined for the industrial market so they have eye-watering prices.
Alternatively, you may take an embedded board standard like Comexpress that has a wide range of ports, including a bunch of real UART.
Fujitsu Siemens Notebook not just had a serial and a paralell port, they also had a 3:4 monitor (I think is the way better format for a notebook). So I bought one of the latest models :-).
For industrial use Siemens has a notebook called "Field PG". It has 2xEthernet and even the newest models have a real serial port (and also ProfiBus if you need that).
> USB to serial/paralel adapters are good enough for most hobby projects but aren't suitable for professional or latency critical applications like industrial, audio, arcade retro-emulation and CNC machines.
That doesn't stop their rampant use in those applications, regardless.
You beat me to it. There are some good ones out there but they are rare. I have not had to do it recently so I can no longer recommend any.
What is really annoying is how over the place the USB ones are in quality and drivers. The rub is they almost work. In many cases they are fine. But some of them have very odd modes of working fine then becoming jittery. What is also annoying is you can find a brand that 'works great' then the next batch they switched something out. Then there are some out there if your software does not play with the rts cts 'pins' correctly the whole thing will get out of wack. So your can end up in a condition where it works rock solid on real hardware but the USB will refuse to work correctly because you did not follow the 'standard', or worse sorta work.
"There are companies in Taiwan/China making custom X86 barebones/motherboards using modern hardware and old ports but they're low volume and destined for the industrial market so they have eye-watering prices."
Many of those small industrial grade mainboards, especially the Mini-ITX ones, are also employed in game / slot machines and have plenty of serial ports, GPIOs, etc. There's a market for used ones on Ebay and elsewhere.
There also are cheap PCI-E to RS232 adapters that cost less than 10 bucks delivered, so serial ports aren't really a problem unless one needs them on a laptop.
Actually there are also moderately priced Mini-PCIE to RS232 adapters, but bringing flat cables out of a laptop doesn't seem that practical.
my CNC works just fine with USB. The USB connection is only moving the gcode data, which is being pre-queued to a microcontroller (not really the scenario you're describing).
You can do 99.9% of "realtime" tasks with non-realtime systems that have been carefully tuned linux systems (multiple cores, remove all daemons, tune CPU scheduler) and I think thats a much better approach than trying to prop up old tech.
Devil's advocate though. Does that still work when you then overlay something like Windows 98 in KVM? A lot of the ancient software was (unfortunately) Windows centric
Your CNC works via USB because, like you said, the microcontroller in the CNC does the motor control.
What I was referring to is that in the old days, PCs would control the CNC cutting head directly via paralel port, there was no microcontroller in the middle. These setups do not work wit a USB converters.
I keep hearing about these beasts, but I am really struggling to see that after all these years it makes more sense to use a 20-30 year old CNC instead of spending the capital to buy a new one. To me the cost tradeoff seems pretty clear, even up to replacing a $20K device.
If your are in a job shop, and have 50 jobs set up on the machine that each only happen a few times every year or two, replacing the controller means months to years of hell as some little tweak is going to be needed for each of those jobs as they happen.
Quite often, CNC machining is not the first step in making a part. Thus scrapping a part is a very expensive, and could lose a client if it happens more than once after you "update" a machine.
There are very rational, very strong incentives to be conservative with computers used in industry.
CNC machines are not smartphones, they don't go obsolete very quickly. If you keep them well maintained and calibrated they'll do the job for multiple decades. Makes sense to keep the running for as long as possible as they're never scrapped but sold on to cash strapped shops.
what's the problem with that, as long as it works and can be kept working without too much expense? Do you get rid of a car as soon as they stop updating the software in it?
For serial connectivity, I always just use a terminal server (like from Perle). They're just boxes that allow you to make serial console connections via ssh/telnet over a TCP port (or if you must through a virtual COM port driver). These are used widely in datacenters to connect to switches which have serial console ports for configuration.
They're not unreasonable in cost (start at like $100 for 2 ports), tons of features, and not flaky like the USB-rs232 adapters. Not so sure about latency, but throughput is fine.
I personally do for some applications, but sometime I was the portability of a laptop, but with a serial port. Some ultraruggeds do have serial ports and even less PCIe slots I believe.
> I wish modern hacker laptops had an easy non-proprietary way to get a serial port.
Dell docking stations like the PR02X provide serial/parallel ports directly from the laptop, and Dell Latitude laptops with the E-Port docking connector were made until ~2016.
Both the PR02X and Latitude laptops with an E-Port are readily available on eBay for reasonable prices.
I've successfully used an E6220 with the PR02X to bitbang out the parallel port for a project.
About a week ago I wrote in a comment here that "Some of us (masochists) actually like RS-232!". It's nice to be reminded that I'm not the only one!
My primary laptop is an (8-year-old!) ThinkPad W530 that I can't bring myself to part with (it's a beast and still outperforms many of today's more "modern" laptops).
It doesn't have an actual serial port built-in but it does have an (34mm) ExpressCard slot. Luckily, I managed to find a card with an actual RS-232 serial port that connects to the host using PCIe, NOT USB.
I'm going to be quite sad once the W530 gives up the magic smoke. I have stockpiled spare hardware in preparation of that day, however.
> You might need to pull the hard drive and connect it to a somewhat newer system in order to boot from clonezilla and take the image. Something from the early 2000s with an ATA/33 controller on it should be backwards compatible to almost all of the oldest IDE hard drives. Can be quicker and easier than trying to run clonezilla on the native hardware (or on systems which have no idea of how to boot from a CD-ROM or USB).
Also note that Parallel ATA host bus adapters exist and then you don't even need an old PC, just a ~$20 adapter for a modern one.
although some modern PC BIOSes have problems with manually entering the heads/cylinders as you might find on the label of an IDE hard drive from 1992. additionally I have found that modern udma/133 parallel ata drive controllers have less than perfect compatibility with some very old IDE stuff. while a 'vintage' motherboard like something with an intel 440fx or 440bx chipset from the very late 1990s should work.
All IDE drives are linear block devices and the CHS numbers set in BIOS are only necessary to make the BIOS happy. The types and CHS numbers were relevant for MFM/RLL harddrives without integrated controller. The IDE interface is essentially an simplified ISA bus on a cable and all of what should be called controller resides on the harddrive, in fact that is what both IDE (Integrated Drive Electronics) and ATA (AT Attachment, as in "AT bus" = "16-bit ISA") acronyms alude to.
If you only intend to access the drive from Linux (ie. clonezilla) you can simply ignore the BIOS settings as Linux kernel will detect the drive correctly even when it is not configured in BIOS at all.
Yes absolutely. If it's running and you can get access to I/O on it to copy data off via serial or something (let's say it's running MS-DOS 3.3, 5.0 or 6.2), use something like laplink to transfer as much off as possible before taking it down for intrusive maintenance.
I once worked for a large, urban Episcopal church. Since it was non-profit, parishioners could donate their old computers for a tax write-off. Amongst my many duties, I converted these hulks into network terminals. They ran Novell (DR) DOS on a Novell 3.12 network. I used third world cheapo compatible NICs since my annual computer budget was in the few hundreds of dollars. And as long as the patch cord wiring system held up the thing actually worked...
I'm not sure if it was necessary or they just hadn't needed to change it, but one of the undergrad physics practicals at Cambridge used a Windows 9x machine (I think it was 98, at least as of 2008). Seeing "It is now safe to turn off your computer" again at the end of the session was oddly comforting.
I'm always a bit worried about using a Windows 10 machine in the lab. You never really know when it will decide to update and randomly reboot (or show a fullscreen ad for Edge). Unfortunately with the EOL of Windows 7 there aren't many alternatives. Lots of lab hardware (especially from small manufacturers) is still Windows only. That is a problem you didn't have with your 386 machine running DOS.
You can buy a license just fine (with some finagling) from a reseller, even though it's pricey.
I don't see any reason why your software should refuse to run under LTSC, unless it's too reliant on parts of the OS that shouldn't be depended on anyway. I've had games etc run just fine on it.
> I don't see any reason why your software should refuse to run under LTSC, unless it's too reliant on parts of the OS that shouldn't be depended on anyway. I've had games etc run just fine on it.
Which seems to be the standard for a lot of proprietary software. The objectives are to: get the software shipped ASAP, lock in the users.
This often means cutting corner. For instance, if there's a Windows public API to see who's logged in and their permissions that works across OSes they might use that, but you can also check the username directly. Or, what I've seen, they'll check the home directory path and assume that's the user that's logged in. Oops, the home directory moved between OS versions so our "test who's logged in" method only works on Windows ??? and not the more recent versions or even older versions. But that's fine, our customers are paying us $10k/seat and have no alternatives. Some users may find a workaround, but most won't.
I have been trying to get my experimental group to move off their computers off windows but I unfortunately don't have that sway, plus they're wedded to labview. That's the one value of linux even with its warts.
We managed to get away from proprietary software for our simulations needs and moved to oss that runs on both Windows and Linux.
But we have not been able to get rid of Labview & Windows in the lab.
I'll be happy to hear about your experience here...
In my field, labview has been mostly replaced by python for building experiment control systems. Some groups manage to run their labs on Linux with maybe one dedicated Windows machine for stubborn hardware. In my setups we use quite a lot of Windows-only hardware, to Linux is not really an option.
OK, do you have any reference for the python modules they use?
I must admit that for GUI, nice interactive plots, motion control & DAQ, it's a bit difficult to be on par with Labview.
In particular, it's usually quite easy and fast in Labview to hack together a small VI to do something like move, grab data, plot, repeat with the ability to zoom, change scale, etc while the acquisition is running.
Do you know of any example combining all or part of these functionalities?
I like using PyQt5 for the GUI and PyQtGraph for interactive plots. Using matplotlib as a Qt widget is also possible, but it is quite slow and tends to leak memory when dynamically updating the data. On Windows I use the NI VISA library with pyvisa for most hardware access. There are open source alternatives for Linux such as pyvisa-py and linux-gpib that work quite well for most devices connected with Ethernet, USB, and GPIB.
Even on windows xp/7, I know people running hours-to-days long simulations routinely unplugging their ethernet so the IT department / windows daemons / tooth fairy won’t randomly reboot it and make a project late.
If only we could do that!
But with ldap accounts, nfs-mounted files and Labview licence server, everything stops working whenever the network is down/unreachable...
There are surely certificates with expiration dates on these systems, so when the internal clock goes beyond that date, some stuff will stop working. I guess then someone would write a date mapping tool (calendars repeat themselves every 28 years, with matching weekdays and leap years, although in 2100 this rule will break).
I am a windows user, and have never seen one. I'm not saying they don't exist, but it sounds more like something added on by whomever manufactured the PC, not a core part of the OS.
Connecting your critical equipment to the internet is never a good idea. And if you don't connect it to the internet, the support status of the OS it runs shouldn't really matter much.
Then maybe only give it access to the LAN so it's easier to get data off of it.
There's also a hacky workaround where you disable all of 5 services that relate to Windows Update to effectively prevent Windows from knowing updating software is a thing. You do have to edit the registry manually to do this. If you leave at least one, it'll turn the other ones back on. This is a very much malware-like behavior tbh. And, of course, do this at your own risk because Windows is written in C and known for containing obscene numbers of nasty vulnerabilities resulting from manual memory mismanagement.
It's possible to "break" Windows Update reversibly (I discovered this by accident on a computer with a large HDD and small SSD a while back). Change the location of the default `ProgramFilesDir` and `ProgramFilesDir (x86)` keys in `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion` to not be `C:\Program Files` and `C:\Program Files (x86)` respectively. EG move them to a different drive. Don't move the various programs inside. IME, everything works, except that Windows Update will check only the new location for some Microsoft programs, not fall back to the default, and fail with an unintelligible error code.
One of my fondest memories was accompanying my then partner to another city, so she could use their particle accelerator for her research. I didn't get to go anywhere near the accelerator and so I just wandered the city, had dinner and whatnot.
It was mostly operated from a command line and she was run through how to operate the equipment and do her tests, then left pretty much to her own devices with the accelerator.
At a bit after midnight, I get a couple of text messages, her firings all went to plan, but she can't figure out the command line in order to archive and copy the data to her personal drive. Cue a 1am phone call trying to figure out what the operating system was and what commands were at our disposal. Thankfully it was unix based and everything went smoothly, but it was fun and I was glad to feel useful on the trip!
Nice story, I got a bit of panicked after I read about that call. I can iamgine her fear of losing all the hard work becuase she was not able to export it.
I did work about a decade ago for a company that made trophies. The kind you win and sit on a shelf. Their engraving machine was running on an original IBM XT or AT, with two 5.25" floppy drives and a couple of old school floppy disk containers on the desk which contained all their fonts, etc. I warned them that the machine would fail eventually and they should replace it soon. "But it still works."
sorta. The smaller lithography processes for semiconductors actually do degrade faster. More static risk too. XT computers were practically electromechanical.
In 30 years we'll have plenty of computers from 2020 that are still used. Survivor bias is strong, we just don't see all the computers from the 90s that already gave up the ghost
I did a fair bit of work around 2010 for a fellow who ran a EEG machine at a neurology clinic. It ran Windows 98, and was connected to the Internet. I cleaned that thing of malware more than once. Replacement was prohibitively expensive unfortunately, as it require replacing the entire unit, not just the PC portion of it.
Reading this then remember comments on that article about the AMD's new thing taking advantage of TSMC's 3D fabrication where a datacenter worker said they'd use CPUs "up to seven years" insinuating that's a upper time limit that would be undercut as the chips "go out of date" sooner.
Scientific computing (computational science) is a pain in many ways but the aversion to churn and honestly waste the rest of the cs/it world takes as natural is one small valuable nugget. I wish devs in general had a longer outlook when the make things in general.
I occasionally troll Craigslist locally for old hardware for my collection and for fun. I recently got a top of the line — for the late 90s — Graphtec 24” vinyl cutter/plotter, complete with PowerMac 9500 with CRT and Jaz drive all for 40 bucks. It works great, has Mac OS 9 and Illustrator and everything else that I need for the setup. The owner’s dad ran a sign business until he passed away, then the son used it for hobbies for years. I’d like to modernize it a bit and shrink the Mac out of the equation, but the system just works for now.
Nice, that's a pretty good deal! I just dug up an old Jaz disk myself -- just have to figure out which of my machines (if any) has a drive.. Ahh, the good ol' days ! haha
The comms protocol itself is sending to 25-pin serial at 9600bps, so it’s pretty simple to rig up another way. The stuff sent is just monochrome vector art. I was thinking of either finding or making an open source (maybe Python) lib to talk to the protocol and then yeah, probably running it on a Pi as a service I could send right to from my computer. The plotter is about waist-high, so it’s pretty large. I figured I could velcro a Pi to the underside pretty easily and serve via wifi.
> Forney at one time had a stack of ten of her 1987 Toshiba laptops that she’d bought on eBay for $10 to $12 each. “We’re down to our last one,” she says.
I don't remember all the details but if my memory ain't failing me there was something similar with the software used to interface with the iconic McLaren F1 car. Only about 60 of those cars have been produced (at least for the road, maybe more for competition) and the mechanics servicing these cars had to stockpile old laptops because the proprietary software/interface had never been ported to modern technology. Eventually a few years ago McLaren assigned developers to the task and a new version was made. I think they did it because they were running low on the pile of old rusty dusty laptops ; )
Oh wow, I didn’t know this before: BMW’s DIS (Diagnosis and Information System) runs on SCO OpenServer 5.
And this was something used in the field by mechanics!
But I'm quite sure, the ones before used SINIX... And nowadays all the digital electronic parts in these old cars are eWaste because nobody can configure them anymore. And looking at the D-guy with his automatic transmission this is mostly a documentation problem.
> To work with current Windows versions, the team would have to replace the whole microscope. The marginal potential gains aren’t yet worth the US$400,000 expense, Cherr reasons.
Unfortunately there is not much information given on this particular example, but that definitely sounds like throwing the baby out with the bathwater? If the Windows XP computers are just interfacing with the microscope, surely it would be cheaper to just reimplement this interface (of course, the alternative of leaving everything as it is is even cheaper, until you get a ransomware infestation)? Or are they talking about Windows XP Embedded directly controlling the microscope?
They're talking about Windows XP, client, directly controlling the microscope -- usually through a 16-bit driver. Vista redid the driver stack and broke compatibility with these. The driver is provided by the device manufacturer, who has little interest in providing new software for old hardware.
How do you know your reimplementation isn’t subtly changing data? All research must be reproducible, and that includes the instrument and software chain as well.
I've worked with similar microscopes. One of them, worked perfectly fine for the tasks it was assigned to, but the software would only work up to Windows XP.
To make matters worse, the whole system was hostile to any changes or updates. We didn't have an installer for the program but disk images to restore the system with the controller software already installed. The computer also had a hardware key connected to validate its licenses. Finally due to some validation checks the software performs, the controller software can't be placed on a virtual machine.
One way you can deal with this is by getting the longest service contract you can afford when you buy the equipment. We had a slightly newer microscope with a service contract that was still good when the XP to Win7 transition happened. It took some prodding of the vendor, but they eventually came down and replaced the controller PC free of charge. Eventually those service contracts run out, and you are left with a perfectly good microscope, and an aging computer.
One experience I was lucky to have as a graduate student was bumping into a set of four old SGI Indy O2s running SGI Irix and driving an old (~£5m) MRI scanner. As a child of the 80s, SGI Irix was the missing OS that I hadn't actually used: Mac-like in GUI but with solid unix underpinnings. It was -- in my mind, at least -- the "Mac OS 9" version of OS X.†
Actually driving the things was a slightly different experience. The software was horrible to program in, old, klunky, but feature rich and very hackable. It made me question my gnu/BSD knowledge every time I typed, e.g. 'ps auxw' and got a usage statement; `vi` was ancient and definitely not vim running in a compatibility mode; and the `del` key issued kill (or maybe SIGHUP -- can't remember) signals. I learnt a lot.
That machine was finally replaced when a professor nearby moved on, his former department didn't want his old machine, and I commandeered the department of physics's official (and excellent) Man and Van to help replace it with another microimaging system that I built using a mix of old hardware and open-source software [1], for which I am lucky enough to have lots of electronic schematics to go with and the relevant firmware. It's still going now, several years later. My old PI is still trying to get the money to replace it with a modern Bruker instrument -- which will be far less hackable, far more locked down, and come with a hardware DRM dongle; but doesn't require a postdoc (like me!) to (re)build and maintain.
† Yes, I realise that was NeXT, but I've still never actually seen a NeXT machine in the flesh. I'd love to!
My high school physics dept were still using a then 20 year old BBC Micro to run experiments which only worked with a specific piece of ultrasonic experiment gear.
I wonder if it still gets wheeled out on that cart to this day...
At the company in which i am the head of IT, we are - right at this moment when i type this - running a production batch of stuff we produce on a filling machine controlled via an C64 board. And it "just works", and as long as you can buy a working C64 for under 100 Euros i would see absolutely no need to change anything.
I would explore whether the Ultimate-64 FPGA-based C64 clone board would work for you, as that would give you long term confidence on keeping the platform running.
Thank you for the hint, i will look into this... i think my boss would be happy if he knows that the > 100.000 € production line is not dependent on some obscure tech his "it guy" is keeping somehow alive ;-)
We also had to buy a new device to measure something on work (>100000 CHF) just because an old PC died with Win3.1.
PCs in industry in the long term are just a pain in the ...
> some computers still run on Microsoft Windows XP (released in 2001), because of the need to maintain compatibility with a scanning laser confocal microscope and other imaging equipment
Damn here I was hoping “ancient” meant some workstation from the 70s/80s. Should have known better tbh.
And it gets more complicated when you have non-x86 hardware - you may be perfectly able to emulate the software but have no way to connect to the controller board (think Apple II controlling a machine).
There is a market niche here for a computer with every lab interface under the sun (ISA, RS232, RS485, BNC Ethernet, etc) capable of running/backuping virtualized legacy OS's and with a clear upgrade line and good support. There are "industrial PC's" with legacy interfaces, but the software side is not resolved.
157 comments
[ 4.4 ms ] story [ 235 ms ] threadHaving to replace working equipment because the software that you paid for can't be transferred to a new computer is a nightmare Often, the old equipment works just fine because the laws of physics haven't changed.
But equally often, by the time it's that old, it's being used for a tiny subset of its original, perhaps for exactly one repetitive procedure. In those cases, it's often easy to whip up a little Python program that talks to the RS232 port via a USB-RS232 converter.
Will the Python program last any longer? Maybe not, but at least its source code is in text format.
TCL and Expect would be much better for that than Python.
Worked really well. One of the oldest machine was some 286 connected to some freaky gasoline density aparatus :)
In many cases you can't simply upgrade software, as software for such machines does not support anything else - and you can't really reverse engineer drivers for 50 different machines in sane amount of time.
Most of really expensive machines provide some kind of output over serial interfaces - it seems to be industry standard, but I forgot the name for it.
Because otherwise Nature mostly attracts high profile papers, that means that articles in Nature are more likely to be wrong than articles in other journals. (Interesting findings are more likely to be wrong.)
And that this task is often not the responsibility of a research IT professional, but a puzzled grad student.
It doesn't matter that you have contemporary hardware to run it on, the developer is gone, their servers are gone, and the app isn't in the store anymore.
I'm talking about stuff like where you find a system running a CNC milling machine from 1992 with a 60MB IDE hard drive in it.
You might need to pull the hard drive and connect it to a somewhat newer system in order to boot from clonezilla and take the image. Something from the early 2000s with an ATA/33 controller on it should be backwards compatible to almost all of the oldest IDE hard drives. Can be quicker and easier than trying to run clonezilla on the native hardware (or on systems which have no idea of how to boot from a CD-ROM or USB).
If you have something a lot older than that, it can get more complicated. Never personally needed to take a disk image of something with a MFM/RLL ISA HDD controller card driving an old 5.25" 10MB/20MB type drive, but it's probably possible. I bet you could get the controller card working in a 1999 vintage Pentium 3 in the ISA slot with enough hackery.
When it restarted it had the click of death. The freezer trick worked long enough for me to grab the few kb of data I really needed from that disk.
I wrote about it here: https://miscdotgeek.com/adventures-in-hard-drives/
You can do block checks regularly, which takes a looong time on high capacity drives (or is impossible on newer ones due to firmware restrictions).
Also check any socketed chips and make sure they are fully seated. Chip creep happens when frequently thermal-cycled boards cause the IC's to slowly lift themselves out of their own sockets.
https://www.nongnu.org/lzip/xz_inadequate.html
I haven't read through the link properly, so I'm as yet unable to comment on the merits of xz or the lack thereof; posting it here for other readers who might be curious, as I was.
There's an argument that you're better off knowing you lost data than having most but with a hidden flaw - but either way you want multiple copies and preferably in a format that contains error detection AND correction - and itself is stored on a filesystem that provides similar (ZFS for example).
It should be much smaller (and faster) to take such a snapshot, but priceless if you ever suffer corruption for e.g identifying & verifying inodes, restoring permissions etc.
Also useful for identifying which files are vanilla (same as installed from package) so can be restored by other means (finding original package). For that reason, a dump of installed packages w/ version is also useful.
The laptops have the huge advantage that they have a serial port, which allows to rescue pretty much everything given that you implement an adapter software for it.
I wish modern hacker laptops had an easy non-proprietary way to get a serial port.
The only alternative we have is using an Arduino based solution...but that's like a downgrade compared to 20 years ago.
There's too many variables in the way, like the USB to X chip used in that converter plus the driver for it and how the OS scheduler handles the USB stack and API calls, all this causing major jitter in the communication timing.
In uni we still had air-gapped Win2K/98 computers for the robotics labs since in the days prior to Windows XP, your app could write directly to the serial/paralel ports, so you could have your program use 100% CPU load, jitter-free, to poll the serial/paralel port, that's why they were used in CNC. For example your Win/DOS program would directly drive the cutting head in real-time through the paralel port. You can say goodbye to that via USB converters unless you want your expensive machine mangle its cutting head.
My embedded systems prof from uni would only buy Fujitsu (Siemens) laptops as they were the only ones who still sold models with serial and parallel ports on modern hardware even as late as 2017(!), so if you're a professional or serious hobbyist in this space I suggest you grab one of those before they become scarce and overpriced like how high-end CRTs have now become.
There are companies in Taiwan/China making custom X86 barebones/motherboards using modern hardware and old ports but they're low volume and destined for the industrial market so they have eye-watering prices.
Alternatively, you may take an embedded board standard like Comexpress that has a wide range of ports, including a bunch of real UART.
For industrial use Siemens has a notebook called "Field PG". It has 2xEthernet and even the newest models have a real serial port (and also ProfiBus if you need that).
Check out how many ports and devices they can fit into a modern thin and light without compromising repairability
https://www.youtube.com/watch?v=hS2uogVMK8U
https://www.youtube.com/watch?v=bXmlgc7Qyhc
That doesn't stop their rampant use in those applications, regardless.
What is really annoying is how over the place the USB ones are in quality and drivers. The rub is they almost work. In many cases they are fine. But some of them have very odd modes of working fine then becoming jittery. What is also annoying is you can find a brand that 'works great' then the next batch they switched something out. Then there are some out there if your software does not play with the rts cts 'pins' correctly the whole thing will get out of wack. So your can end up in a condition where it works rock solid on real hardware but the USB will refuse to work correctly because you did not follow the 'standard', or worse sorta work.
Many of those small industrial grade mainboards, especially the Mini-ITX ones, are also employed in game / slot machines and have plenty of serial ports, GPIOs, etc. There's a market for used ones on Ebay and elsewhere. There also are cheap PCI-E to RS232 adapters that cost less than 10 bucks delivered, so serial ports aren't really a problem unless one needs them on a laptop. Actually there are also moderately priced Mini-PCIE to RS232 adapters, but bringing flat cables out of a laptop doesn't seem that practical.
You can do 99.9% of "realtime" tasks with non-realtime systems that have been carefully tuned linux systems (multiple cores, remove all daemons, tune CPU scheduler) and I think thats a much better approach than trying to prop up old tech.
What I was referring to is that in the old days, PCs would control the CNC cutting head directly via paralel port, there was no microcontroller in the middle. These setups do not work wit a USB converters.
Quite often, CNC machining is not the first step in making a part. Thus scrapping a part is a very expensive, and could lose a client if it happens more than once after you "update" a machine.
There are very rational, very strong incentives to be conservative with computers used in industry.
I'm pretty sure they haven't updated the software on the elevator in my building in over 20 years but I'm fine with that.
They're not unreasonable in cost (start at like $100 for 2 ports), tons of features, and not flaky like the USB-rs232 adapters. Not so sure about latency, but throughput is fine.
Dell docking stations like the PR02X provide serial/parallel ports directly from the laptop, and Dell Latitude laptops with the E-Port docking connector were made until ~2016.
Both the PR02X and Latitude laptops with an E-Port are readily available on eBay for reasonable prices.
I've successfully used an E6220 with the PR02X to bitbang out the parallel port for a project.
My primary laptop is an (8-year-old!) ThinkPad W530 that I can't bring myself to part with (it's a beast and still outperforms many of today's more "modern" laptops).
It doesn't have an actual serial port built-in but it does have an (34mm) ExpressCard slot. Luckily, I managed to find a card with an actual RS-232 serial port that connects to the host using PCIe, NOT USB.
I'm going to be quite sad once the W530 gives up the magic smoke. I have stockpiled spare hardware in preparation of that day, however.
Also note that Parallel ATA host bus adapters exist and then you don't even need an old PC, just a ~$20 adapter for a modern one.
If you only intend to access the drive from Linux (ie. clonezilla) you can simply ignore the BIOS settings as Linux kernel will detect the drive correctly even when it is not configured in BIOS at all.
Could probably dump it out through the serial port.
No, use tar.lz
http://lzip.nongnu.org/
http://lzip.nongnu.org/safety_of_the_lzip_format.html
http://lzip.nongnu.org/xz_inadequate.html
Or lzip! Has better recoverability properties: lzip.org
And perhaps invest in a few CompactFlash <-> IDE adapters, too.
https://www.google.com/search?channel=fs&client=ubuntu&q=lap...
I don't see any reason why your software should refuse to run under LTSC, unless it's too reliant on parts of the OS that shouldn't be depended on anyway. I've had games etc run just fine on it.
Which seems to be the standard for a lot of proprietary software. The objectives are to: get the software shipped ASAP, lock in the users.
This often means cutting corner. For instance, if there's a Windows public API to see who's logged in and their permissions that works across OSes they might use that, but you can also check the username directly. Or, what I've seen, they'll check the home directory path and assume that's the user that's logged in. Oops, the home directory moved between OS versions so our "test who's logged in" method only works on Windows ??? and not the more recent versions or even older versions. But that's fine, our customers are paying us $10k/seat and have no alternatives. Some users may find a workaround, but most won't.
I am not a Windows user, so maybe a dumb question, but is this actually a thing?
There's also a hacky workaround where you disable all of 5 services that relate to Windows Update to effectively prevent Windows from knowing updating software is a thing. You do have to edit the registry manually to do this. If you leave at least one, it'll turn the other ones back on. This is a very much malware-like behavior tbh. And, of course, do this at your own risk because Windows is written in C and known for containing obscene numbers of nasty vulnerabilities resulting from manual memory mismanagement.
It was mostly operated from a command line and she was run through how to operate the equipment and do her tests, then left pretty much to her own devices with the accelerator.
At a bit after midnight, I get a couple of text messages, her firings all went to plan, but she can't figure out the command line in order to archive and copy the data to her personal drive. Cue a 1am phone call trying to figure out what the operating system was and what commands were at our disposal. Thankfully it was unix based and everything went smoothly, but it was fun and I was glad to feel useful on the trip!
https://xkcd.com/1168/
Indeed. It still worked.
Scientific computing (computational science) is a pain in many ways but the aversion to churn and honestly waste the rest of the cs/it world takes as natural is one small valuable nugget. I wish devs in general had a longer outlook when the make things in general.
Might even work fast enough on a Raspberry Pi 4.
I don't remember all the details but if my memory ain't failing me there was something similar with the software used to interface with the iconic McLaren F1 car. Only about 60 of those cars have been produced (at least for the road, maybe more for competition) and the mechanics servicing these cars had to stockpile old laptops because the proprietary software/interface had never been ported to modern technology. Eventually a few years ago McLaren assigned developers to the task and a new version was made. I think they did it because they were running low on the pile of old rusty dusty laptops ; )
from this article, whereas
> "I have a prospective customer supporting a U.S. missile defense system that is buying parts on eBay,"
from
https://www.pcworld.com/article/249951/if-it-aint-broke-dont...
If it ain't broke, don't fix it.
Unfortunately there is not much information given on this particular example, but that definitely sounds like throwing the baby out with the bathwater? If the Windows XP computers are just interfacing with the microscope, surely it would be cheaper to just reimplement this interface (of course, the alternative of leaving everything as it is is even cheaper, until you get a ransomware infestation)? Or are they talking about Windows XP Embedded directly controlling the microscope?
To make matters worse, the whole system was hostile to any changes or updates. We didn't have an installer for the program but disk images to restore the system with the controller software already installed. The computer also had a hardware key connected to validate its licenses. Finally due to some validation checks the software performs, the controller software can't be placed on a virtual machine.
One way you can deal with this is by getting the longest service contract you can afford when you buy the equipment. We had a slightly newer microscope with a service contract that was still good when the XP to Win7 transition happened. It took some prodding of the vendor, but they eventually came down and replaced the controller PC free of charge. Eventually those service contracts run out, and you are left with a perfectly good microscope, and an aging computer.
Actually driving the things was a slightly different experience. The software was horrible to program in, old, klunky, but feature rich and very hackable. It made me question my gnu/BSD knowledge every time I typed, e.g. 'ps auxw' and got a usage statement; `vi` was ancient and definitely not vim running in a compatibility mode; and the `del` key issued kill (or maybe SIGHUP -- can't remember) signals. I learnt a lot.
That machine was finally replaced when a professor nearby moved on, his former department didn't want his old machine, and I commandeered the department of physics's official (and excellent) Man and Van to help replace it with another microimaging system that I built using a mix of old hardware and open-source software [1], for which I am lucky enough to have lots of electronic schematics to go with and the relevant firmware. It's still going now, several years later. My old PI is still trying to get the money to replace it with a modern Bruker instrument -- which will be far less hackable, far more locked down, and come with a hardware DRM dongle; but doesn't require a postdoc (like me!) to (re)build and maintain.
† Yes, I realise that was NeXT, but I've still never actually seen a NeXT machine in the flesh. I'd love to!
[1] https://openvnmrj.org/
I wonder if it still gets wheeled out on that cart to this day...
And frankly: I like it ;-)
Equipment without well-documented interface protocols -- or better yet, open protocols.
It was a lowly printer that ended up infuriating RMS and establishing the FSF and the GPL.
Damn here I was hoping “ancient” meant some workstation from the 70s/80s. Should have known better tbh.
Which is why things like this exist: https://www.assured-systems.com/us/product/atx-intel-g41-cor...
And it gets more complicated when you have non-x86 hardware - you may be perfectly able to emulate the software but have no way to connect to the controller board (think Apple II controlling a machine).