Judging from this an approach might have been to port the 28 modules individually and check that everything returns the same data in Perl and TS versions:

"I took a long-overdue peek at the source codebase. Over 30,000 lines of battle-tested Perl across 28 modules. A* pathfinding for edge routing, hierarchical group rendering, port configurations for node connections, bidirectional edges, collapsing multi-edges. I hadn’t expected the sheer interwoven complexity."

Look how long SPARC, z/Architecture, PowerPC etc have kept going even after they lost their strong positions on the market (a development which is nowhere in sight for x86), and they had a tiny fraction of the inertia of x86 softare base.

Obliterating x86 in that time would take quite a lot more than what the ARM trajectory is now. It's had 40 years to try by now and the technical advantage window (power efficieny advantage) has closed.

To be clear if x86 is ever as unpopular as SPARC or PowerPC I would consider that to be obliterated.

I was thinking more like if it falls to 10% of desktop/laptop/server market share, which is still waaaaaay more then the nearly-dead architectures you listed.

90s x86 from ISA pov is already free to use, no? The original patents must have expired and there's no copyright protection of ISAs. The thing keeping the symbiotic cross-licensed duopoly going is mutating the ISA all the time so they can mix in more recently patented stuff.

AFAIK, most of event x86_64 patents are largely expired, or will be within the next 6 years. That said, efforts for a more open platform are probably more likely to be centered around risc or another arm alternative than x86... While I could see a standardization of x86 compatible shortcuts for use with emulation platforms on arm/risc processors. Transmeta was an idea too far ahead of its time.

Remembering the Mac ARM transition pain wrt Docker and Node/Python/Lambda cross builds targeting servers, there's a lot to be said for binary compatibility.

You're doing builds for Docker on your desktop for direct deployment instead of through a CI/CD service?

My biggest issue was the number of broken apps in Docker on Arm based Macs, and even then was mostly able to work around it without much trouble.

You want to be able to replicate the build in your local dev env. And you're not always working on a mature project, you first get it working locally. CICD tends to be slow and hard to debug.

90% of those problems effect people like you and I, developers and power users, not "regular" users of machines who are mostly mobile device and occasional laptop/desktop application users.

I suspect we'll see somebody -- a phone manufacturer or similar device -- make a major transition to RISC-V from ARM etc in the next 10 years that we won't even notice.

I agree, some will, but it may not be a more open platform from developer POV.

I don't think it works that way in practice.

Some distributions like Debian or Fedora will make newer features (such as AVX/VEX) mandatory only after the patents expire, if ever. So a new entrant could implement the original x86-64 ISA (maybe with some obvious extensions like 128-bit atomics) in that time frame and preempt the patent-based lockout due to ISA evolution. If there was a viable AMD/Intel alternative that only implements the baseline ISA, those distributions would never switch away from it.

It's just not easy to build high-performance CPUs, regardless of ISA.

That's off by an order of magnitude. The table lists 0.4 or so Gbit/s but I think that's per core.

Secrecy of communiations frequently constitutionally protected:

See p. 11 of https://www.sipotra.it/wp-content/uploads/2021/06/Comparing-...

Are you theorizing a CSMA related motivation or benefit in the Nagle algorithm or is this a tangential anecdote of those times?

CSMA further limits the throughput of the network in cases where you're sending lots of small transmissions by making sure that you're always contending for the carrier.

So I guess the answer is that CSMA networks get congested more easily and Nagle saves some traffic. (Applies to modern world as well in wifi)

Fossil produced electricity is unsustainably cheap. According to https://lowcarbonpower.org/region/California only half of electricity is low-carbon there. It's imperative to ramp down fossils use and production to mitigate the climate disaster so we can't afford to believe there's "abundant energy resources" in a situation like this.

I was counting solar and offshore wind as abundant energy resources. Also, nuclear, though that’s not state specific.

The demo recording-as-code seems cool (in https://github.com/karol-broda/snitch/tree/master/demo)

thanks :), havent really seen this much in other projects

There's remarkably little about the costs, given that's the main claim going for it vs the estabilished alternatives.

Yeah, if only we would define seconds to be 13.4% shorter than that are, we could have 100ks days. Also, ksecs would be a really convenient unit for planning one's day: a ~15 minute resolution is just right for just about any type of appointment.

Oh, and 1Ms weeks, consisting of 7 working days and 3 off days sound nice too.

One can dream! :-)

Much better to make seconds slightly larger than 2 seconds, and move to a dozenal system throughout. One hour is (1000)_12 novoseconds. A semi-day is (10000)_12.

Oh, we should switch our standard counting system to dozenal a well.