Not sure but I think it might have been getting close to what was possible - I remember reading about Michael Abrash working with John Carmack on all sorts of things to get acceptable framerates.

Black Mesa has a longer Xen and original designs took inspiration from retail Half-Life but weren't exact copies of map layouts etc.

Yeah Cry of Fear really pushed the GoldSource engine to its limits (I think it implemented a custom renderer but the models just push the base engine's limits with regards to maximum polygons and texture sizes).

I think the biggest reason is just better hardware. In 1998 many of the props were just blocky level geometry.

For whatever reason, Valve doesn't want to open source the engine so some people have taken it upon themselves to build a reverse-engineered engine (which now runs on Android, in the browser etc).

The Z from ZHLT ended up working for Gearbox Software.

Yeah Apple's latest round of breaking changes hasn't been addressed (and seemingly won't be).

The Linux and Mac ports happened in 2013 or so (presumably getting one working went a lot of the way to getting the other working, though there is some speculation that Apple poured in some money to help make it happen).

MacOS 10.15 dropped support for x86-32 binaries.

Later it became clear why: the Apple Silicon transition, and Rosetta 2, which is optimised for running x86-64 binaries on Apple's Arm64.

But the same change is looming on Linux: Ubuntu tried in 2019 but was persuaded not to, Fedora has tried more than once.

WINE 11 can run Win32 binaries on a pure 64-bit host OS without 32-bit libraries. So, you can run some 32-bit Windows games on 64-bit Linux and macOS which cannot run the 32-bit binaries of their own older versions.

Apple merely jumped first. I think it's not to be blamed here. It'll happen everywhere in time.

Oh that's right the - the 32-bit thing. Incidentally Valve experimented with 64-bit GoldSource 20+ years ago for servers at least but didn't really pursue it.

I used Jenkins for years at a previous job - for the longest time it was a confusing mess of pipelines coupled with being a fairly outdated version.

Once it was updated to latest and all the bad old manually created jobs were removed it was decent.

I used TeamCity for a while and it was decent - I'm sure defining pipelines in code must be possible but the company I worked at seemed to have made this impossible with some in-house integration with their version control and release management software.

This so much - I remember migrating from one CI system to another a few years ago - I had built all of our pipelines to pull in some secrets and call a .sh file that did all the heavy lifting. The migration had a few pain points but was fairly easy. Meanwhile, the teams who had created their pipelines with the UI and broken them up in to multiple steps were not happy at all.