Old-school computing: when your lab PC is ancient
nature.com
nature.com
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.
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.
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.
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.
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
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.
Alternatively, you may take an embedded board standard like Comexpress that has a wide range of ports, including a bunch of real UART.
That doesn't stop their rampant use in those applications, regardless.
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.
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.
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/
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.
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).
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.
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).
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.
https://www.google.com/search?channel=fs&client=ubuntu&q=lap...
And perhaps invest in a few CompactFlash <-> IDE adapters, too.
Could probably dump it out through the serial port.
Or lzip! Has better recoverability properties: lzip.org
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!
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.
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.
TCL and Expect would be much better for that than Python.
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 ; )
Indeed. It still worked.
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.
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.
I am not a Windows user, so maybe a dumb question, but is this actually a thing?
And frankly: I like it ;-)
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!
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.
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.
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.
And that this task is often not the responsibility of a research IT professional, but a puzzled grad student.
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.)
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.
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.
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.
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.
Damn here I was hoping “ancient” meant some workstation from the 70s/80s. Should have known better tbh.
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.
I wonder if it still gets wheeled out on that cart to this day...
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.
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.
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).