Hacker News Reader

Comment by diminoten | Hacker News Reader

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

View on HN

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.

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

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

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.

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.

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

Yes.

> That didn't affect NT either.

Oh. OK.

True, now you have a full 497 days.

https://support2.microsoft.com/kb/2553549

Still better than 208.5 days. :)

https://access.redhat.com/solutions/68466

Fixed:

https://www.kernel.org/pub/linux/kernel/v2.6/longterm/Change...

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

Kernel developer thread:

http://thread.gmane.org/gmane.linux.kernel/1132515

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?

Reply on news.ycombinator.com