
Feds spend billions to run museum-ready computer systems - twakefield
http://bigstory.ap.org/54fb0c2ad1e249658cde51c3c6380252
======
Johnny555
Using floppy disks and old hardware and software doesn't sound like a problem
if it still runs and does what it's supposed to do. I'm skeptical that
building a modern system would really save money since the temptation for
feature creep is too great.

~~~
rosalinekarr
> Using floppy disks and old hardware and software doesn't sound like a
> problem if it still runs and does what it's supposed to do.

It sounds like a problem to me for the simple fact that replacement parts are
near impossible to find, and it's clearly costing the taxpayer a lot of money.
That alone should be reason enough to upgrade.

It's also a huge security problem because many of these machines were designed
before modern security procedures were invented. How am I supposed to maintain
a cryptographically secure password system on a machine with a processor too
slow to run a hashing algorithm?

> I'm skeptical that building a modern system would really save money since
> the temptation for feature creep is too great.

So, because we might be tempted to add a few features, we shouldn't upgrade
technology? I don't understand where this weird pseudo-luddite mentality in
the tech world comes from. I see it all the time in tech forums, and I just
don't get it.

"If it's not broke, don't fix it" is a fun, catchy phrase, but it really
breaks down as soon as you try to apply it anywhere. "Hey, you should really
change the oil in your car." "If it's not broke, don't fix it."

~~~
Tiksi
That's because a lot of time the suggestion is more along the lines of "Why
bother changing your brake pads on your old car when you can just buy a new
car with new brake pads" than "You should really change the oil in your car."
Nevermind the fact that your old car is a truck that you need in order to haul
things, is easily repairable and you know how it works inside and out and
people are telling you to get a SmartCar to replace it when you really just
need new brake pads.

~~~
urmet
But now your old truck is 70 years old and all the replacement parts have to
be hand made by some people you called back from retirement. It's okay to keep
it running to show it off from time to time, but it's no way cost effective to
do any real work with.

------
nickpsecurity
The real problem is there's huge, legacy systems tied to these platforms that
they don't understand and are too risky to port/re-engineer. Think of our
military systems or payroll going down since software was ported wrong or
relied on underdocumented assembler or compiler feature.

There's some hope on reducing costs at least. Look up NuVAX for an example of
emulators being designed to work _exacly_ like old hardware for fraction of
price, space, energy, and so on. I haven't heard attempts but next step might
be instrumenting them to trace programs code/data for porting. Or binary
translation to modern architectures. I know DEC did latter for VAX-to-Alpha
port.

~~~
VMG
The private sector usually manages to keep it's systems updated. This here
seems like the typical incentive and accountability problems of government
bureaucracy.

~~~
fencepost
I'm not sure what private sector you're talking about, but the healthcare
industry keeps systems updated only due to regulatory requirements, and even
then there are a fair number of practices that stick with old systems and just
have their upstream providers (e.g. billing services) massage the data on the
way to its destination.

~~~
ptaipale
Take just a quick look at MUMPS. And they start new deployments, new projects
even today. With my tax money, here in Europe.

------
DanielBMarkham
Most federal systems that are anywhere over ten years old (and that's most of
them) are complete mysteries to the people who both use and maintain them.

A long time ago, I was responsible for such a system. I didn't ask for the
job; I simply was the smartest person in the room for too long.

I vividly remember one day we had a problem with folks in a remote location
entering things and those things getting mangled and/or lost on the way to the
system-of-record.

For one system, with maybe five thousand users and perhaps a few gigabytes of
traffic a month, I was on a call with 30 people spanning most of the Earth. I
learned that there were at least a dozen separate systems at that location
between the person entering the data and the data being sent to HQ. Each
system was old. Each system had a separate vendor which claimed to be the only
vendor to understand that system (Sometimes this was true. Many times they
were just bluffing.)

And -- and this was the kicker -- for each of our dozens of locations, each
location manager, because of their friendship with politicians, made their own
decisions about how machines were configured and which programs were
installed. They were complaining to us because things were bad, but they did
not feel like they answered to us.

I was responsible for fixing it.

At the end of that call, I was reminded of Arthur C. Clarke's quip: Any
sufficiently advanced technology is indistinguishable from magic.

But I doubt I thought of it in the way he meant it.

~~~
ramblenode
As a younger developer, I can't emphasize enough how much I enjoy hearing
these types of stories. :)

------
paavokoya
To be fair, my last employer (aerospace manuf.) ran an incredibly dated and
ancient OS with pretty decent results. It was simple, to the point, ugly as
hell but got the job done without needing constant updates etc etc. Also we
never had a problem with malware (because who writes malware for a 30 year old
OS?)

I understand this article mentions many different sectors and functions for
antiquated systems but sometimes an update simply isn't needed.

~~~
themodelplumber
> because who writes malware for a 30 year old OS?

Careful. I believe I just read an article (Wired?) about some hackers doing
exactly this.

Security through Seniority might be a good name for the mindset. :-)

~~~
paavokoya
Is there a term for when you say something knowingly broad but ALSO understand
there are specific cases where it doesn't apply? Like a simple term I can
paste onto the end of statements like (sic) or similar so that I can avoid the
nitpickers?

EDIT: honestly not being facetious just curious because this exact thing
happens constantly.

~~~
nickpsecurity
That's how models and rule work in general. There's a rule or pattern that
mostly applies but always exceptions.

In this case, the old systems were all torn apart by older hackers. There's
young ones, just a few, hacking mainframes and stuff now. The ease of finding
first flaws showed only reason they weren't found sooner is nobody cared
enough to look. Or couldn't afford the relics to play with. So, believing one
is safe just because computers are old is akin to Security via Senority.

Now, there are older approaches like tagged HW or dedicated lines whose
intrinsic properties reduce odds of attacks. Definitely apply any good
techniques from past to present situation. Just that it's old... especially
since it's older than _INFOSEC itself_... doesnt make it safer.

------
Animats
On the other hand, they're getting decades out of the software. Use the
bleeding-edge stuff, and it's obsolete in two or three years now. Use a
"cloud" service, and the service probably goes away within five years. The new
stuff has too much churn. Where will Rails be in ten years? Python? Java will
still be around; it's the successor to COBOL.

~~~
newnop
They're getting decades out of the software, but "about three-fourths of the
$80 billion budget goes to keep aging technology running". Is that worth it to
you?

~~~
HeyLaughingBoy
Depends. Where would that 3/4 be going if they invested in new technology?
Training? Support?

~~~
nickpsecurity
Nothing if they keep the interfaces the same. The real cost, immediate and
over time, is the port of the applications or systems to new HW and
toolchains. I can't overstate enough how many problems this can cause.
Especially if they don't have source for these apps or it's barely commented.

------
protomyth
I wonder, what would be your answer is someone came up to you and said "We
need a computer that we can maintain and keep in service for 50 years or more.
What should we do?".

~~~
Sanddancer
Take the IBM route. Write to a VM spec. Hardware comes and goes, but VMs last
forever. The System 38's virtual architecture is still used on modern AS/400
machines, so programs written in the late 70s will still work today without
needing to lift a finger.

~~~
protomyth
Yeah, that makes quite a lot of sense and is a proven technique. On a side
note, did they ever build a System 38 VM for something like VMWare, Virtual
Box, etc.?

------
gherkin0
Honestly, I don't see good solution to this until the rate of technological
change really slows down. It seems like your options are to either pay to
periodically re-engineer every system or pay to maintain obsolete hardware.

~~~
x0x0
Maybe pay for vmware or similar to run your old systems on modern hardware?

~~~
jrmcauliffe
Vmware virtualises 'modern' hardware.

------
panic
"Feds spend billions to maintain museum-ready buildings"

"Feds spend billions to enforce museum-ready laws"

These computer systems aren't even that old compared to many things the
government spends money on.

------
Shivetya
anecdotal, in the early to mid eighties I was in the US Air Force. The machine
I was first assigned to watch over was in the secure comm center. This
burroughs machine was the first non-tube computer made by burroughs. it could
boot from paper tape or card and was replete with blinking lights.

later I moved up in tech to a sperry/unisys system. all our personnel data and
such was loaded via cards, physical cards in multiple boxes till near 88.

So honestly I don't doubt they still do similar. I was just so glad we got out
of boxes of cards because having to fix runs each night got old and all for
bent card.

it got me into programming, turbo pascal at the time. why, when we moved off
physical cards it was then onto 360k floppies. The problem was, the
upload/download programs provided could take half an hour or more to transfer
to the 1100/70\. The turbo pascal program did it in five or less per disk
without issue.

------
syngrog66
On one hand it seems inefficient and perhaps dangerous to be reliant on such
old systems. On the other hand, the idea of a new software project to replace
it also sounds at risk of being extremely expensive and overly complicated.
Because of all the government contracting anti-patterns.

In theory there's a middle ground that avoids both these extremes. In reality,
with government software... I'm skeptical it will happen.

------
chx
I want to know only one thing: COBOL is named under Social Security so I
suspect the "outdated computer language that is difficult to write and
maintain" Treasury uses is not COBOL -- but oh god then what it is??

~~~
fiatmoney
Dating from 1960 ("the systems are about 56 years old"), and especially given
that the system in question is likely an IBM mainframe, Fortran would be my
guess.

Fortran can actually be surprisingly pleasant, at least as pleasant as C, but
I'm guessing their particular code is not.

~~~
bigger_cheese
Could be PL/I

------
tn13
Despite all the ipads and what note I have found a pen and notebook to be the
better note taking equipment than anything else.

If it is getting the job done cheaply and efficiently that required and better
than the alternatives it is the best technology to use.

------
jenkstom
Seems like a great opportunity for virtualization...

------
JackPoach
I think this deserves its own term - porkware

