Old-school computing: when your lab PC is ancient(nature.com)
nature.com
Old-school computing: when your lab PC is ancient
https://www.nature.com/articles/d41586-021-01431-y
157 comments
Yeah definitely. I swear, those old hard drives have a way of KNOWING when you're about to back them up and failing, just to spite you.
That's because you need to sneak behind them with a Hiren's Boot CD before the hard drive has time to kill itself.
Use Linux and ddrescue, gddrescue or similar instead of that crap.
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.
I wrote about it here: https://miscdotgeek.com/adventures-in-hard-drives/
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/
Most likely because the heads try to read a few back blocks that weren't accessed for years.
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).
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).
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.
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.
If recovery is critical, use lzip and not xz. The compression ratio is the same but xz archives are particularly vulnerable to corruption.
Out of curiosity, what in the file format makes it particularly vulnerable to corruption?
A little googling threw up this link:
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.
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.
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).
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).
If recovery is critical, store some parity bits too. par2 or something like that.
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.
I think hard drive images are rarely compressed, because it's just so slow.
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.
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.
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 serial adapters will give you a standard usb port at /dev/ttyUSBn, usable via minicom etc.
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'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."
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.
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 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.
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.
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).
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).
Yeah, in my book, Fujitsu-Siemens was one class above the Lenovo Thinkpads of late which are now a fading shadow of their former glory days.
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
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
I have one for private use.
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.
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.
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.
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.
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.
$20k is not that much when it comes to CNC machines. And why would you replace a perfectly good machine just because it's 30 years old?
Because the software is obsolete.
Software is not the selling point of those devices. As long as it works and everyone in the shop knows how to use it well, then it's fine.
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.
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.
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?
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.
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.
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
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.
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.
> 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.
Alternatively, you may take an embedded board standard like Comexpress that has a wide range of ports, including a bunch of real UART.
> 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.
That doesn't stop their rampant use in those applications, regardless.
Any reason you can't just use a PCIe RS-232 card? e.g. https://au.rs-online.com/web/p/serial-boards/8988545/
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.
[deleted]
> 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.
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.
I have an old toughbook for for this reason as well. I tried looking into some modern ultra ruggeds but damn they’re expensive.
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.
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.
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.
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.
https://en.wikipedia.org/wiki/Ddrescue can come in handy if the situation is bad.
> If you have something a lot older than that, it can get more complicated.
Could probably dump it out through the serial port.
Could probably dump it out through the serial port.
> Store it somewhere safe in .tar.xz format.
Or lzip! Has better recoverability properties: lzip.org
Or lzip! Has better recoverability properties: lzip.org
> 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.
And perhaps invest in a few CompactFlash <-> IDE adapters, too.
And perhaps invest in a few CompactFlash <-> IDE adapters, too.
Do be careful about powering off HDDs that have been possibly spinning for 20+ years. They might not spin back up.
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.
https://www.google.com/search?channel=fs&client=ubuntu&q=lap...
https://www.google.com/search?channel=fs&client=ubuntu&q=lap...
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!
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 was pretty anxious too. We ended up using tar, and it felt exactly like that XKCD comic on the topic:
https://xkcd.com/1168/
https://xkcd.com/1168/
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.
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.
Tibbo makes some neat products to do rs232 over Ethernet
Was looking for something like this for a project, they are neat, thanks!
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.
Yes. I always rejoice when i find a scan of an old manual somewhere and the last pages consist of that delightfull command list
>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.
TCL and Expect would be much better for that than Python.
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.
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.
> 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 ; )
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 ; )
iirc this even happened to BMW, where their config software ran on notebooks with Siemens(!) UNIX up to mid 2005 or so.
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.
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."
Indeed. It still worked.
Indeed. It still worked.
They used to make computers that lasted.
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
The computer is still going to work, no problem. Floppies on the other hand are bit riskier bet.
They still do. The problem is the software.
sorta. The smaller lithography processes for semiconductors actually do degrade faster. More static risk too. XT computers were practically electromechanical.
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.
Isn't that precisely what LTSC is meant for?
If you can get a license for it and if the software will run on it.
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.
> 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.
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.
[deleted]
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...
License servers taught me the lesson of open source software.
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).
> (or show a fullscreen ad for Edge)
I am not a Windows user, so maybe a dumb question, but is this actually a thing?
I am not a Windows user, so maybe a dumb question, but is this actually a thing?
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.
I've never seen one. Centre-of-the-screen and taking up about 50% of the area, yes, but never a maximised or full-screen window.
I have seen this screen after an update on my laptop: https://www.windowslatest.com/2020/11/15/windows-10-is-now-n...
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.
There is a very large region between "has to be completely air-gapped" and "better should not reboot randomly".
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.
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.
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.
I really hope they saved a full disk image to restore in case the hard drive failed.
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.
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.
And frankly: I like it ;-)
And frankly: I like it ;-)
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 ;-)
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!
[1] https://openvnmrj.org/
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'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 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.
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.
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...
This reminds me a lot of work I used to do in the controls world. We had a large amount of equipment all with proprietary networking to embedded systems that were basically Intel 386 systems running DOS. The big issue we had was they had spinning hard drives in them, which would fail, and replacing them meant we needed to replace all the nodes on the network, often hundreds of pieces of equipment. To make matters worse, the company was long out of business.
My boss came up with the idea of replacing the drives with industrial flash drives, so as the drives failed we replaced them. We had some issues getting drives that were small enough, as there was an issue with the BIOS and drives that were too big, but we were able to keep the systems running so we could eventually replace the whole networks while equipment was getting upgraded.
We had an even older system that was an entirely custom mainframe computer with 10" hard drives and modem banks that we all stayed far away from. It wasn't as critical, so it was even slower on replacement.
My boss came up with the idea of replacing the drives with industrial flash drives, so as the drives failed we replaced them. We had some issues getting drives that were small enough, as there was an issue with the BIOS and drives that were too big, but we were able to keep the systems running so we could eventually replace the whole networks while equipment was getting upgraded.
We had an even older system that was an entirely custom mainframe computer with 10" hard drives and modem banks that we all stayed far away from. It wasn't as critical, so it was even slower on replacement.
Oh, the days of 30-yr old PDP-8s running CNC milling machine s in the physics dept. machine shop....
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.
And that’s 10,000 1976 dollars. Today that would be at least $25,000, or more.
[deleted]
I used to (2012 - 2014) work on that Sounding Rocket program the article talks about. I never saw a monochrome screen, but the computers handling the telemetry monitoring during launches were old Dolch lunchbox style cases holding a single board PC with a really cruddy LCD panel. The computers were either 386s or 486s (depending on which one you got) running DOS 6 and a program written for telemetry monitoring in 1989 called 'tdp502.exe'. This was written in Borland Turbo C++ and was rather flaky.
Coming off a program with 2000s era equipment for telemetry and monitoring, going to this was a big shock and the pain of using such antiquated equipment made everything very difficult.
Coming off a program with 2000s era equipment for telemetry and monitoring, going to this was a big shock and the pain of using such antiquated equipment made everything very difficult.
As a research IT professional, this is our everyday. Not sure why it justifies an article in Nature, but cool to see some exposure.
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.)
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.)
I think the idea is to highlight this problem - especially as more and more labs have complex machinery with a PC as an essential component of it.
And that this task is often not the responsibility of a research IT professional, but a puzzled grad student.
And that this task is often not the responsibility of a research IT professional, but a puzzled grad student.
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'm not sure why it doesn't justify an article in Nature.
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.
Have you bought a hp ink cartridge lately? Chances are it was inspected by one of my machine vision system running on an old XP PC using old PCI cards and analog cameras. We're slow to upgrade these systems once they are running, especially if they've been transferred to outsource suppliers somewhere in Asia.
I’m going to draw from the article and from my personal experience (somewhat related viewpoint of computers in small companies’ chemistry labs) and point out the leading cause of this obsolete technology persisting: cost (or rather, price).
Mainly we’re dealing with deliberate decisions not to upgrade exclusively based on price. This is quite disturbing (as an economist). It’s probable that by keeping the prices high on software the companies reap benefits from those clients that are willing to pay (presumably for updated specifications and algorithms but mainly for compatibility with newer systems), they’re also relegating users by not providing a more convenient and reasonably priced upgrade path that covers merely the compatibility aspect.
Mainly we’re dealing with deliberate decisions not to upgrade exclusively based on price. This is quite disturbing (as an economist). It’s probable that by keeping the prices high on software the companies reap benefits from those clients that are willing to pay (presumably for updated specifications and algorithms but mainly for compatibility with newer systems), they’re also relegating users by not providing a more convenient and reasonably priced upgrade path that covers merely the compatibility aspect.
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.
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
Possibly you could run the full stack with Qemu or https://sheepshaver.cebix.net/
Might even work fast enough on a Raspberry Pi 4.
Might even work fast enough on a Raspberry Pi 4.
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.
> “If that board dies we’ll have to go onto eBay”
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.
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.
I always found it odd that SSDs die out within 5-10 years if they're not accessed frequently (i.e they're not suitable for long term archival storage) yet oldskool computers' storage of the 80's seem to last forever. It almost makes me want to buy some of this old tech since the storage longevity is markedly better.
Well, survivorship bias. Nobody is talking about their 80's computers that died by the 90's. And nobody can yet talk about tech from the 2010s that has lasted 40 years.
That said, yes older storage methods may have better longevity. Compare an SSD to game console ROM cartridges that last virtually forever. What fails in both older and modern storage hardware isn't really the per-bit magnetic storage, it's the environment necessary to access them, the power supply and spinning motor and moving head in a hard drive.
That said, yes older storage methods may have better longevity. Compare an SSD to game console ROM cartridges that last virtually forever. What fails in both older and modern storage hardware isn't really the per-bit magnetic storage, it's the environment necessary to access them, the power supply and spinning motor and moving head in a hard drive.
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.
> 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.
Damn here I was hoping “ancient” meant some workstation from the 70s/80s. Should have known better tbh.
You're dating yourself. XP from 2001 is 20 years old now. I get it, I cringe when I realize this too.
I worked at a company that maintained racks of DOS boxes to run a some custom code. The contractor that wrote the app also maintained the boxes.
My role as Sys Admin meant I was ready to decommission all four racks in favor of 4U worth of hypervisors.
He dug in, fought dirty and the whole company went under.
My role as Sys Admin meant I was ready to decommission all four racks in favor of 4U worth of hypervisors.
He dug in, fought dirty and the whole company went under.
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...
I wonder if it still gets wheeled out on that cart to this day...
I see a common problem with all of these examples.
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.
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.
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 ...
weird custom hardware that couldn't be replaced? or needed to be "official" and couldn't just be changed?
A lot of old things had custom hardware.
> 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?
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.
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.
On the software side, is emulation/virtualization a good solution here?
It can help but often these computers have a relatively custom control card built in - think ISA board designed to connect to some piece of machinery.
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).
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).
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.