Now that's a name I haven't heard in a long time... a long time.

Posted Nov 23, 2024 0:23 UTC (Sat) by tialaramex (subscriber, #21167)
Parent article: NonStop discussion around adding Rust to Git

Thirty years ago I worked for a company which no longer exists, Tandem Computers. I was fresh out of school (it was a "year out" programme designed to provide management skills to engineers, which, in hindsight, is a bad idea but oh well) before University.

Tandem NonStop is very old but it had some unique capabilities which render it especially attractive if you're extremely risk averse, as some banks and other financial sector organisations are. Unfortunately the other thing about banks when it comes to buying hardware (as opposed to paying staff evidently) is that they don't like to give you any money, and I believe this meant Tandem began to struggle financially and was sold.

I guess I'm not surprised that the platform lives on even though I doubt many people involved in designing and building it - never mind the hardware it ran on originally - are still active. Risk averse people weren't very interested in buying a new machine but can be relied on to pay for your Extended Support, and your Further Extended Support and your No Really This Platform Is Obsolete Please Migrate Now support.

However, I do wonder if maybe the correct way to view the situation is that support for git, the software, on NonStop is not necessarily a good goal, while support for git the _version control system_ on NonStop is absolutely worthwhile. It sounds as though NonStop people do not have a modern C++ compiler, don't have Go, don't have Rust, actually it sounds though they don't yet have C17, which isn't even the current version of C, it's the previous version. None of which is a reason they shouldn't have Git's version control system, but it is a reason that they might not get (and indeed it seems already they're beginning not to get) shiny new things.

Now that's a name I haven't heard in a long time... a long time.

Posted Nov 23, 2024 0:53 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

The folks in these industries will simply continue to use the obsolete tech until it is physically impossible to repair or maintain. In 2019, the US Air Force announced that it had figured out how to launch a nuclear missile without 8" floppy disks. I'm not sure exactly when manufacture of those disks ceased, but it was certainly well before 2019, so either they continued to reuse old disks until they stopped working, or they had to buy used disks. If the latter, then I'm sure they had a fun conversation with their infosec people about low-probability-high-impact risks.

Source: https://www.nytimes.com/2019/10/24/us/nuclear-weapons-flo...

Now that's a name I haven't heard in a long time... a long time.

Posted Nov 23, 2024 9:20 UTC (Sat) by Wol (subscriber, #4433) [Link] (2 responses)

> Thirty years ago I worked for a company which no longer exists, Tandem Computers.

Same timeframe, a friend of mine worked for Stratus. I think they used a "better" - aka more expensive - approach to fault-tolerant computers, and Tandem pretty much put them out of business. But one of my memories is of my friend opening a case to a computer, pointing out the CPU board, and saying "if I pull that out, nobody will notice anything has happened - except us, because that's the main fault reporting computer which will go mad telling itself it's failed". He also said it was the norm for customers not to know their computers had suffered a major failure until the engineer turned up with replacement parts ...

I don't think upgrading those systems would be that complicated, although it probably would be expensive, especially given that there are probably few customers left ...

Cheers,
Wol

Now that's a name I haven't heard in a long time... a long time.

Posted Nov 23, 2024 13:30 UTC (Sat) by tialaramex (subscriber, #21167) [Link] (1 responses)

Yes, at Tandem the offered resilience was belt + suspenders + sky hook. If one of the local CPUs, or disks, or interconnect buses fails, those processes which must live on just have a recent checkpoint started on the other CPU, or disk, or interconnect (you can say whether your process is important in this way) and then if your entire computer fails, processes which are even more important just restart from a recent checkpoint on another machine at that site. Finally, if the entire site goes offline (e.g. meter destroys it, massive building fire) the absolutely critical processes automatically continue from a recent checkpoint in another data centre.

My understanding is that doing this in hardware is significantly more expensive and the practical benefit is very dubious, which means that over time "NonStop" goes from a solution requiring expensive custom hardware to a software system running on commodity hardware, without substantial difference in the results. I can't say how true that is in practice.

Now that's a name I haven't heard in a long time... a long time.

Posted Nov 24, 2024 0:50 UTC (Sun) by Wol (subscriber, #4433) [Link]

> and the practical benefit is very dubious

What happens to all the transactions that happened between the checkpoint and the failure?

Okay, I suspect that can be programmed around, but that probably means everything has to be coded in a batch manner, with checkpoints between each batch. Then it's down to the users to spot problems as the data is fed into the system, but once that's happened, it's guaranteed to flow through the system.

Cheers,
Wol

Now that's a name I haven't heard in a long time... a long time.

Posted Nov 26, 2024 7:56 UTC (Tue) by jpfrancois (subscriber, #65948) [Link] (1 responses)

What I fail to understand, is why they can't use git on the machine they use to develop as opposed to the machine the code runs on.
I mean, I have been developping code for ARM machine for 20 years, yet all my development is done on x86 or x86_64.
So what are this NonStop users doing with git ? Keeping track of their machine configuration ?

Now that's a name I haven't heard in a long time... a long time.

Posted Nov 26, 2024 9:50 UTC (Tue) by farnz (subscriber, #17727) [Link]

It's not uncommon for configurations to be stored in git, and for systems to read configuration from a checkout of the git repo. If you remove git from the supported toolset, then instead of configuration being "check in a config to your trusted git server, automation on the NonStop host will do the equivalent of git pull && git checkout protected/config && restart-services on a known schedule", it becomes "set up a system with remote access to the NonStop filesystem; have it do the git pull && git checkout protected/config, then synchronise the resulting checkout with the NonStop filesystem, then run restart-services on the NonStop system".

That's quite a lot of extra complexity (a whole system extra, plus redoing the code git already has for synchronising state from repo to filesystem, plus having to add new code for verifying that the git checkout on the NonStop system matches the repo state, instead of reusing git's existing code for comparing a working copy to the repo).