6 ms·

> I’m just not inclined to agree that civil society can’t continue to run on millions of lines of COBOL for another 60 years. It certainly can. > Java 8 and Py

by _bxg1 6y ago

> I’m just not inclined to agree that civil society can’t continue to run on millions of lines of COBOL for another 60 years. It certainly can. > Java 8 and Python 2 on the other hand are a far more serious threat. When systems can’t get off end of life technology they miss security updates, performance enhancements, and new features. This seems contradictory. Is it not also a problem that COBOL hasn't been getting security updates for years (I assume)? Are COBOL systems typically isolated from the outside world in some way?

bokwoon 6y ago
I think it's probably because COBOL has almost no dependencies. Correct me if I'm wrong. > The real horsemen of the legacy apocalypse is the depth of the dependency tree. Modern software development stacks abstraction on top of abstraction.
mech422 6y ago
Sort of... COBOL programs are usually batch programs, and grab input from tape rather then the net. Interactive stuff tends to only be run on internal networks (3270 terminals used to be the norm).
- _bxg1 6y ago
  Yeah, I wondered if it was something like that. Sounds like input is sanitized before it even touches that system. Which begs an interesting train of thought: could we make systems that last longer by doing a better job of isolating pieces of them from the outside world? If malicious input never reaches your code, does it even need security updates?
  - mywittyname 6y ago
    The rubber has to meet the road. Users have to interface with the software. "Backend" software tends to be very long lived because it's not client facing. Clients don't care that the software was written in Java2 and uses some weird-ass collection of korn shell scripts to keep things moving. These scripts usually just need to eat data from one location, and poop it into another. And because these systems are old, they are well tested and battle hardened. But that backend is no good without some form of user interface. This is almost always the place where things break down. There are many more people involved in the decision making for UX, and we have more and more devices with different use-cases. Most tech-ish companies can't afford to ignore completely new computing paradigms for decades.
    - _bxg1 6y ago
      At the risk of stretching the metaphor, what I'm talking about are bearings that separate the wheel from the rest of the car. Maybe you have a thin, outward-facing server that does nothing but authenticate, validate, and sanitize input data, and then redirects that to some internal system that knows for sure exactly what it's going to get, and doesn't get to talk to the outside world directly, and therefore doesn't have to worry about attacks.
      - giantrobot 6y ago
        Congratulations, you just invented "middleware".
draw_down 6y ago
That was my reaction too. Then I started thinking how these old systems must be absolutely ridden with awful holes, certainly much worse than something like Java 8. It's just that there's less information about them generally available. But if you manage to learn the details about one of them... oh boy. Not only would whoever owns the system probably not know for a while, when they did notice they'd have to figure out how to hire someone before they could hope to fix it.
deleted 6y ago
[deleted]
fiddlerwoaroof 6y ago
IBM still maintains the platform: I’m sure there’s still system updates and the like, IBM just has done a better job maintaining backwards compatibility than “modern” stacks: e.g. the AS/400 has gone through a couple different CPU architectures without requiring that programs be recompiled because it was designed to decouple the code output by a compiler from the machine code of the underlying platform.

by _bxg1 6y ago

bokwoon 6y ago

I think it's probably because COBOL has almost no dependencies. Correct me if I'm wrong. > The real horsemen of the legacy apocalypse is the depth of the dependency tree. Modern software development stacks abstraction on top of abstraction.

mech422 6y ago

Sort of... COBOL programs are usually batch programs, and grab input from tape rather then the net. Interactive stuff tends to only be run on internal networks (3270 terminals used to be the norm).

_bxg1 6y ago
Yeah, I wondered if it was something like that. Sounds like input is sanitized before it even touches that system. Which begs an interesting train of thought: could we make systems that last longer by doing a better job of isolating pieces of them from the outside world? If malicious input never reaches your code, does it even need security updates?
- mywittyname 6y ago
  The rubber has to meet the road. Users have to interface with the software. "Backend" software tends to be very long lived because it's not client facing. Clients don't care that the software was written in Java2 and uses some weird-ass collection of korn shell scripts to keep things moving. These scripts usually just need to eat data from one location, and poop it into another. And because these systems are old, they are well tested and battle hardened. But that backend is no good without some form of user interface. This is almost always the place where things break down. There are many more people involved in the decision making for UX, and we have more and more devices with different use-cases. Most tech-ish companies can't afford to ignore completely new computing paradigms for decades.
  - _bxg1 6y ago
    At the risk of stretching the metaphor, what I'm talking about are bearings that separate the wheel from the rest of the car. Maybe you have a thin, outward-facing server that does nothing but authenticate, validate, and sanitize input data, and then redirects that to some internal system that knows for sure exactly what it's going to get, and doesn't get to talk to the outside world directly, and therefore doesn't have to worry about attacks.
    - giantrobot 6y ago
      Congratulations, you just invented "middleware".

draw_down 6y ago

That was my reaction too. Then I started thinking how these old systems must be absolutely ridden with awful holes, certainly much worse than something like Java 8. It's just that there's less information about them generally available. But if you manage to learn the details about one of them... oh boy. Not only would whoever owns the system probably not know for a while, when they did notice they'd have to figure out how to hire someone before they could hope to fix it.

deleted 6y ago

[deleted]

fiddlerwoaroof 6y ago

IBM still maintains the platform: I’m sure there’s still system updates and the like, IBM just has done a better job maintaining backwards compatibility than “modern” stacks: e.g. the AS/400 has gone through a couple different CPU architectures without requiring that programs be recompiled because it was designed to decouple the code output by a compiler from the machine code of the underlying platform.