Simply because time passes differently in different gravitational potentials, and there is no absolute, universal time that we can all synchronize to; if that would be possible to exist (i.e., the absolute universal time), it would contradict both special and general relativity.

oh... let's also mention backward compatibility... There is very good software written out there that does not need to be changed and that perhaps will never need to be changed as long as there is hardware to run it, and z/OS is backwards compatible (including binary compatible) with decades ago systems (for some applications, binary compatibility can go back to 1964, except in the case of rare CICS macros that can be modified or software emulated).

Mainframes are more than "just linux clusters with HA". People who want to learn more should read a bit more about mainframes and in particular about the IBM Z and the Telum CPU, for instance from https://ieeexplore.ieee.org/do..., that is used in those systems. And yes, a mainframe can run "Linux on zSystems", but most companies buy them to run z/OS (https://en.wikipedia.org/wiki/Z/OS), sometimes keeping some special applications on an Linux on Z LPAR. It is indeed possible to do a lot with HA clusters, but not everything.

Logical Line Of Code

From Stout, on car recalls by 2020, “more than 50% of recalls involved electronic component defects related to software-based defects”: https://www.stout.com/en/news/... And from IEEE spectrum https://spectrum.ieee.org/soft... “30% of the defects were related to software integration.” Those numbers only tend to increase with more reliance on software platforms in modern cars (to the point that modern EVs platforms are even being considered “software-defined-vehicle" by the industry).

I wish I had more technical references from the top of my head, but unfortunately, I don’t, although I remember reading some papers from sources such as IEEE Transactions on Reliability a few years ago (if my old mind serves me well) that mentioned the predicted car software defect issue in >2020 cars. In any case, this makes a bit of sense, as car software is a less mature technology compared to mechanical components that had a hundred years to evolve and to be optimized, and as such, car software naturally should be at least a bit more prone to more defects at this moment in time. With time, the car software will improve significantly, as long as companies don’t fall into the “newer is always better” trap (or that stricter car software quality assessment and verification regulations prevent this from happening).

  My, admittedly poor, understanding of modern cars is that while most control-related subsystems in EVs are actual software, in ICEs, several of the points you raised (critical systems as, e.g., ignition, abs, pressure) are mostly directly synthesized in FPGAs or ASICs -- software is mostly used in the monitoring layer that is used to bring information to the dashboard, but not to actually control those systems, which are also mostly independent, or in the configuration layer, that can be used by vendors or enthusiasts to re-parametrize (configure) those units, but not to completely change functionality. Still, critical control is primarily performed directly by fixed, predictable, and formally verifiable electronics. But again, this might be my poor understanding of modern cars.

  Nevertheless, a quick search also reveals that modern and future EVs have about three times more software: https://spectrum.ieee.org/elec... or https://www.goldmansachs.com/i... or https://www.automotiveworld.co...

  Finally, modern EV platforms are even being considered "software-defined-vehicle" by industry, and one of the most relevant business strategies of automakers (originated by Tesla, if my memory doesn't fail me) is that you buy the hardware of the car, but you never own the software. The company can do whatever it wants, whenever it wants, with the software subsystems, including over-the-air updates that will certainly bring "new features" that nobody asked for and that will also almost certainly bring additional bugs.

Mechanical parts, yes. But the least trustworthy part nowadays is not some mechanical part; it is software... And let's not get into the not-so-challenging issue of using some simple SDRs to create fake GPS signals and make a mess of the modern EVs self-driving capabilities (something that is pretty easy to do nowadays by any respectable undergraduate in CS or Physics). Don't get me wrong, I love EVs and I wish I could trust at least one of them, but we are not there yet.

Not really; have you ever considered the amount of software that goes into an EV? I would guess there would be much fewer LLOCs in an ICE car, even if modern ICEs would probably still have hundreds of millions of LLOCs. Also, software is usually significantly more complex than mechanical hardware and more complex to analyze and debug (and nowadays, "software engineers" are less formally trained compared to mechanical engineers).

Recently? IBM Q?

And well, IBM has led the patents in the US for 29 years straight... many of them related to two-nanometer processes, and quantum computing... E.g.: https://fortune.com/2023/01/06...

Wait... you are talking about Sierra and Summit... Both systems are based on POWER9 CPUs, so relatively old technology from 2017... And they remained the first and second fastest systems in the TOP10 list by a large margin for 2 years, and afterward, Summit kept 2nd place for good additional 2 years, while Sierra was only below Summit during this entire epoch... and they are still the 5th and 6th systems after all these years.

The EPYC Frontier will probably keep the first position for only one year, as Aurora should become fully online soon (hopefully).

Anyway, having all these CPUs around is a good thing, and the ISA variety provides healthy competition. And I truly don't understand why many people like to trash Power machines - and usually people who never actually used Power systems (which, if you can afford them, are simply as stable as it gets before moving to mainframe worlds - e.g., in how many off-the-shelf intel/amd servers, every highe-end ones, do you have hot-swappable PCIe?). People can complain about IBM, and their "Power bill" (pun intended), but Power is a great ISA, and the CPU architectures implementing it have also been consistently great throughout computing history - beyond being an essential part of the very evolution of RISC architectures.

As mentioned in another reply above, remember that, unlike most people's x86 CPUs, each Power10 core has eight-way simultaneous multithreading, so for most use cases, a 24-core Power10 chip has the equivalent of 192 cores (which is also valid for floating point operations, as the Power CPU does have 8 FPUs per core).

EPYC Genoa is also an amazing CPU, but it does have only 2-way SMT, thus also equivalent to 192 cores. I don't know if it has more than one FPU per core (for floating points operations, it is a bit useless if you can do 192 threads but has only one FPU per core), but I would certainly love to use one though! I am planning to get a new PowerEdge soon to replace an aging R820, so who knows... :-)

Some people cannot pay the down payment, and others are not eligible for financing as they arrived in the US not so long ago... Oh, and sometimes you need to work in a place where acquiring is simply not an option, especially if you are around California.

Great, thanks! Interesting review; it shows that POWER8 is a better-performing CPU, but that it is also consuming significantly more energy than regular Xeons of the same generation... Beyond that, as previously mentioned, if you have applications that require low latency cache access, Power CPUs with massive L3 and L4 caches and memory bandwidth usually win (thus the SAP advantage in the anandtech review that you mentioned); and in many applications requiring high floating point threading, they should consistently also beat same generation x86s (the anandtech review could not cover openFOAM it seems), as it was published for monte carlo simulations in finance industry-standard and audited benchmarks ( e.g., https://www.hpcwire.com/2015/0... ).

Anyway, it is a good thing that we have multiple ISAs and multiple CPUs implementing them. There are different markets for multiple vendors and multiple ISAs (although I see IBM pulling out from classical computing to concentrate on quantum computing, just as they did with typewriters and mechanical and vacuum tube calculation machines in the past). Although I would be happy to see one day in the future, RISC-V or any other open ISA ruling them all :D

Well, they already get enough royalties from anything in classical computing anyway. It seems that IBM is now placing most efforts in inventing Quantum computing systems and in getting as many Quantum computing patents as they can.