Slashdot Mirror
America's Cities Are Running on Software From the '80s (bloomberg.com)
Even San Francisco's tech chops can't save it from relying on computers that belong in a museum. From a report: The only place in San Francisco still pricing real estate like it's the 1980s is the city assessor's office. Its property tax system dates back to the dawn of the floppy disk. City employees appraising the market work with software that runs on a dead programming language and can't be used with a mouse. Assessors are prone to make mistakes when using the vintage software because it can't display all the basic information for a given property on one screen. The staffers have to open and exit several menus to input stuff as simple as addresses. To put it mildly, the setup "doesn't reflect business needs now," says the city's assessor, Carmen Chu.
San Francisco rarely conjures images of creaky, decades-old technology, but that's what's running a key swath of its government, as well as those of cities across the U.S. Politicians can often score relatively easy wins with constituents by borrowing money to pay for new roads and bridges, but the digital equivalents of such infrastructure projects generally don't draw the same enthusiasm. "Modernizing technology is not a top issue that typically comes to mind when you talk to taxpayers and constituents on the street," Chu says. It took her office almost four years to secure $36 million for updated assessors' hardware and software that can, among other things, give priority to cases in which delays may prove costly. The design requirements are due to be finalized this summer.
San Francisco rarely conjures images of creaky, decades-old technology, but that's what's running a key swath of its government, as well as those of cities across the U.S. Politicians can often score relatively easy wins with constituents by borrowing money to pay for new roads and bridges, but the digital equivalents of such infrastructure projects generally don't draw the same enthusiasm. "Modernizing technology is not a top issue that typically comes to mind when you talk to taxpayers and constituents on the street," Chu says. It took her office almost four years to secure $36 million for updated assessors' hardware and software that can, among other things, give priority to cases in which delays may prove costly. The design requirements are due to be finalized this summer.
Yeah, today's bloat is incredible, and this era of shitty programmers with their toy programming languages is very disappointing. One can only imagine how many CPU cycles and electricity is wasted. Just a fun fact, Windows 95 required less ram (sometimes in order of a magnitude) than a basic calculator in any modern OS.
It blew my mind when I ran the Windows 10 calc.exe for the first time on a HDD system. It had a measurable loading time.
A program function as old as windows which was snappy on a 386 now has a human noticeable loading time-and a link to a privacy statement! But that's another rant.
So what you are saying indirectly is that you are the brain-damaged one since you speak of things you have zero knowledge of. VMS was one of the best designed OS's ever. It was light years ahead of all the Unix's flavors at the time.
For one, they actually had a working understand of the hardware on a conceptual level and could relate how their code would interact with the system. Ask your average JS coder how a computer works and grab some popcorn.
There's definitely a lot more going on nowadays with both the OS and application layer libraries. I doubt anyone can understand the entire stack the way people did back then.
In fact, I'll bet you can't figure out what machine code a simple line of JS code turns into either. And even if you did, that answer would be wrong in a few weeks when the next release of V8 comes out.
Due to the limitations of distribution methods and storage media of the time software was also far less bloated and much more stable at launch. You couldn't easily patch something post launch like you can now so you had to get it mostly right the first time. There is no such thing as bug free code but there is code with some bugs and then there is code that is mostly bugs.
I seem to recall a lot of older software that had a final version named something like 1.0.4. And those were only made available months after the initial release. In other words, you'd have software with glaring flaws that you'd have to put up with for months. Versus now, any major bug would be quickly patched up post launch and it's a matter of a few days, or even just a few hours of waiting.
Hahahahaha, modern software that is quickly patched is also broken about 99% of the time.
I recall products and code actually working as designed in the 80s. They had computers you could literally pull a running CPU out of the board and it would still continue to work correctly. If you think today's software is anywhere near as well written or reliable as software of the past, you are a fool. Today's software business is built on cheap coders pushing out crap as fast as possible. In the past we did actual engineering and testing to make sure things worked before we gave them to users. Today, we let the users's beta test software live and 'let it crash' is the moto of the ops folks.
"Those that start by burning books, will end by burning men."
AS/400 based system are some of the most reliable systems money can buy. They can handle insane amounts of workloads and can scale from small systems to complete mainframes.
OK, so I was actually looking into this a few days ago. I'm working on modernizing our build system, part of which includes running Jenkins jobs on AIX servers (to build an AIX client module. Whatever.) We fire off around 10 parallel jobs to build on AIX, Solaris/Sparc, Solaris/x86, Windows, Linux/x86, Linux/x64, and so on. I wanted to understand which ones take the longest because that's what I have to optimize.
Funny, the AIX, PA-RISC, and SPARC systems get absolutely crushed by any x86 system. They may get a lot of work done per CPU cycle but the newer systems have just so many cycles it doesn't matter. AIX, HP-UX, and Solaris might be heroes at getting lots of transactions done on a 100 MHz processor, yay for Big Blue, HP and SunSoft, but if I care about actual absolute throughput, just nope.