Hacker News Reader

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 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 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).

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

I have one for private use.

> 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.

$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.

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?

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.

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.

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.

> 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.

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.

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/

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).

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.

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.

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).

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.

https://en.wikipedia.org/wiki/Ddrescue can come in handy if the situation is bad.

> 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.

Ghost and VMware converter are good tools for this as well

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.

Clonezilla is good too. So is PING.

>.tar.xz

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

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...

> 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.

> If you have something a lot older than that, it can get more complicated.

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