Hacker News new | past | comments | ask | show | jobs | submit login
If It Ain't Broke, Don't Fix It: Ancient Computers in Use Today (2012) (pcworld.com)
70 points by pmarin on Jan 25, 2015 | hide | past | favorite | 46 comments

Im a dabbling electronic musician, so I understand a lot about keeping very old technology functional in the modern world. A lot of these old synths (all mine are digital synths) are irreplaceable with newer technology. My stuff goes as far back as the mid 80s, but there are people that restore and maintain even older hardware. Recently a synth tech restored a couple of Crumar GDSs. These were CPM based S100 bus computers with audio synthesis cards and a program that let you design sounds using a terminal interface, they play them with a music keyboard. These old synths are very difficult to keep going compared to something like a MiniMoog from the same era, because they are dependant on software, 8" floppies, and operating systems and terminals far out of common usage. Nonetheless this is a pretty amazing machine, and a very cool restoration:


Even more amazing is that there are still a few 19th century steam engines being used:


Mechanicville, NY 3 Phase Hydroelectric Plant built in 1897 and still running the original generators: http://edisontechcenter.org/Mechanicville.html

I'd like to know about people still using ancient computers that suck. Like a guy still struggling with an eMachines iMac clone running Windows ME,

or a company using a drowning mainframe with an army of legacy coders constantly plugging the leaking holes, or nightmare layers of integration

I don't have personal knowledge of the mainframes in use at my employer but we might qualify based on talking to the coders that work on the mainframes.

I guess you can find a lot of that on TheDailyWTF.

> Replacing these old systems with modern machines, she explains, would cost millions of dollars and could potentially disrupt national security.

My god...

The private companies who aren't willing to save money by switching are one thing (apparently the market is okay with slow store management), but the US and British governments?

That's very scary.

Changing systems means having to do massive amounts of retraining of staff, the potentials of lost productivity during the migration if/when the system goes down, etc. Plus you're going to have to find someone who can convert the old records to the new format, have a path of converting new to old if something goes wrong, etc. So, governments, like any entity, continue to use the old systems because the projects to convert them are inevitably multi-year and multi-million dollar projects that may not even completely work. While many users would like to move off the systems, the replacements may indeed be much more expensive than they can budget for.

Exactly. Also in a small business all the risk and aggravation falls squarely on the owners shoulders with no way (or reason anyway) to blame anyone. Not anywhere near like simply writing a check and getting a new refrigerator delivered. Not unheard of either (not this example but others) where an owner will feel loyalty to employees who are operating the machines and/or feel that they have to keep them around for other jobs that they do anyway.

On the other hand, no one is going to suddenly disclose a 0-day for the DEC PDP-11 anytime soon.

That's almost entirely opposite. Entire classes of vulnerabilities have been discovered since PDP days, such as format string vulns. Programs written in that era are practically guaranteed to have such vulnerabilities.

On the other hand, there has been separate I&D models of PDP-11, and these are the models where UNIX is most common.

Although considering the PDP-11 came long before "the internet", they might have a solid air-gap defense.

Governments are particularly vulnerable to the sunk costs fallacy, especially when the press can't distinguish between operating cost and capital cost and operates on an annual budget cycle. My go-to example is the whole Nimrod MRA4 fiasco, which involved discovering that aircraft made 50 years ago had non-interchangeable parts that didn't match the drawings. The Nimrod airframes were not airworthy and could not be made airworthy in a cost-effective manner, but nonetheless kept flying for years until one caught fire in midair with the loss of all aboard.

Edit: far more than you wanted to know on the subject https://sites.google.com/site/militaryairworthiness/

This one surprised me least of all. The issue with upgrading these systems to newer technology, especially on general purpose operating systems, is that they're far less reliable, precisely due to the fact that they are more powerful and flexible, and hence, more complex.

The first rule of critical systems is to reduce complexity, and their current systems probably found the sweet spot between useability and simplicity decades ago.

The guy using the IBM accounting machines though... Dear god man! It sounds like the museum would've handed him a new system on a platter, in exchange for his old system. Take the upgrade!

They are built like crap too, you can put a PC in a rack mount case but that don't make it a server. The kit from DEC, Sun, SGI, HP et al from the 80s and 90s was rock solid and would keep going for 20, 30, 40 years, easily. Modern kit you would be lucky to reach 3 years.

Do they use HDDs? If so, does that mean the older HDDs had less failures?

Why is it scary? There's plenty of other old technology (materials, propellents, etc.) that is in these systems I would worry about before I ever worry about a DEC system.

Remember the story about running a navy ship on Windows NT? Fool me twice...

I don't blame them for sticking with the DEC stuff :-)

Old DEC computers would have done exactly the same thing NT did on that ship, which is also exactly the same thing current Windows, Linux, and OS X systems do.

The problem they had was that someone entered a zero in a form field that was not allowed to be zero. The application that received this zero used it as the denominator in a divide, and so incurred a divide by zero exception.

That application did not have a divide by zero handler, and so NT did the same thing pretty much every operating system does in that case, and it killed the application.

That application happened to be vital for engine operation, and so the ship was dead in the water and had to be towed to port.

It might seem shocking that they did not enforce important rules like "this field cannot be zero" on the data entry form, or that they did not handle divide by zero exceptions in a mission critical application (or at least have a procedure for restarting the application if it died), but this ship was a testbed for experimental software so maybe those things get added later, once they have determined that the new system works well enough to continue developing?

At least, I hope it was something like that, and not something like the subcontractor who did the data entry terminals thought the application would do the data validation, and the subcontractor who did the application thought the terminals would do it.

But see, if they'd been using Linux, they would have had the kernel source and they could have patched the SIGFPE handler to do a virtual longjmp back to the part of the program that did form entry.

You don't need the kernel source to do that.

Sure, one could patch the application too, but that can also be done on NT.

Now let's consider the culture involved in writing software for the respective systems. Do you want the typical point n click weenie writing the software to control your military hardware?

I didn't think Linux was vulnerable to the 45-day forced-reboot bug.

Are you talking about the Windows 95/98 49 day time rollover bug? That didn't affect NT either.

True, now you have a full 497 days.


Still better than 208.5 days. :)




(I mean, in case anyone else was curious like I was.)

Kernel developer thread:


> Are you talking about the Windows 95/98 49 day time rollover bug?


> That didn't affect NT either.

Oh. OK.

The IBM 402 has been at the Computer Museum for several years.

So has the iPhone.

Its a three year old article, I wonder if the unit record equipment user has changed anything, other followups, etc.

Much like the list of steam engine users, giving antique users free publicity guarantees that they'll do anything to make sure they do not upgrade. Even if they have to remove the boiler and rotate the steam engine by electric motor, or have to run the books on the URE and in quickbooks, they'll "have to" do it for publicity.

I don't think most of these people get their paying customers from this sort of publicity.

> Today, he simply connects a serial port between the CoCo and a PC, with the PC acting as a virtual disk drive emulator.

From the third page, I find this fascinating - does anybody know more about it? Is it an FTP or something else?

EDIT: here's his website, http://users.axess.com/twilight/sock/

very interesting that it supports osx as there are so few modern apple computers that have any way of using an rs232 port, I think the last macbook pro with an express card slot was released in 2011. perhaps a usb to rs232 is used.

It must require an Xserve, they had serial ports. :-)

(But more seriously, USB->Serial converters work with Mac OS X, I used one to connect a Palm m105 to a G3 iBook running Mac OS X 10.1 way back when. More currently, it seems the OS itself ships with drivers for FTDI's converter chips nowadays, although I haven't used that capability).

It supports TCP/IP as well, and with OS-9 I think at least it's possible to connect to that directly using a serial-to-LAN bridge. It also supports local IP connections as well, which makes it useful for emulators, as DriveWire is much more capable and featureful than simply loading disk images.

Most people use usb-serial adapters whether on Mac, Windows or Linux. Source: I wrote it ;)

My kids are using our 8-bit battlestation to learn computing. Its excellent - far better than giving them an rPi, which they just get frustrated with. Turn on the old Oric Atmos machine, boot up a disk full of software, have a great afternoon. I do get a bit tired of the ol' "10 PING : GOTO 10" trick, though .. ;)

If anything does break you can use your modern 3D printer to make hard-to-find replacement parts.

Everything new is old again. o_O

There are some things where 3D printing is not an option, especially oldschool wire wrap backplanes. If you can get a 3d printer to create a rig that can print the functional equivalent of http://upload.wikimedia.org/wikipedia/commons/d/d1/Computerp... , I will eat my hat.

Some boards like this were assembled with the help of CNC wire wrap equipment. I don't think they were fully automated - more like the computer positioned the tools for the operator. On a board with thousands of wires, this eliminated some operator error (he didn't have to follow a list of connections on a sheet of paper anymore.)

Functionally equivalent? ... why couldn't you just design a PCB that's pinout-compatible?

Parent had mentioned 3d printer. Of course using a modern pcb layout program would be the right tool for the job, as well as a good psychologist to deal with the madness that follows from tracing all those wires.

Then again, I guess one could potentially rig up a program that took gerber files for a many layered pcb design and have it output a 3d model for forming a chunk of multilayer plastic circuit board. You'd need a printer that has multiple heads for depositing conductive materials though. I'd question its reliability in such an environment as an old mini though.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact