Honestly, I'd preferably make it so that stock movement is frozen for a time except for laid off employees

P.S. SMTP isn't well designed for slow and intermittent network protocols, it's designed so that you can bang it out on teletype by paying a grad student a twinkie and coffee and that should hopefully translate into simple implementation across different systems (only to relearn all the lessons of more complex ones, badly)

After about third earnings call (which happened a tiny bit before the trading window for our stock grants opened), I (re)learned the hard lesson that even if we delivered and I had actual, material, move the needle impact on corporate financials, that would not translate in any way to stock price. Except maybe if I pushed it really, really, down by causing an avalanche of problems that resulted in some big name deal going down.

The stock prices are vibe based, once its publicly traded your share value will be based on whatever vibes pushed numbers in excel around earnings call, and it's perfectly normal occurrence to beat expected earnings per share for 3 quarters straight and every quarter get a different vibed-off reason as to why the price should go down.

And from the point of microcoded system like x86 and 680xx were (including 68060) it is important to how many microinstructions your instruction stream will decode - something that greatly favours ISAs that are not orthogonal - and major reason why x86 often has 1.2-1.6 ratio of microinstruction to instruction for overall program code.

Orthogonality makes it problematic because while it's easy in "interpreter microprogram" style of old and easy to program in assembly for, it means that for example for 68k you have to deal with many addressing modes for every operand - whereas x86 pretty much fuses it between 1 to 2 instructions because only one operand can have any computed address, and scope of available computation is limited (even compared to just 68000).

This means that while both architectures can use "translation microcode" approach, one (x86) will easily decode into one or two 72bit instructions (using P6 here) with worst case involving somewhat rare 3 operand form of memory address (which still can only happen for one operand of the instruction, not both)

The non-technical parts I won't dispute.

[1] The reason being that she was found in Tennessee while being searched for a crime in another state, thus allowing them to treat it as interstate fugitive from a crime scene

This is literally my point - the people involved in shift to RISC had figured it was a problem, and one aspect that made x86 easier to optimize long term (outside of Intel's huge market share) was that x86 had at most one memory operand per instruction (with certain exceptions). m68k's orthogonality meant both decode and execution are long-term harder, especially since you're going to have to support software that already uses those features - x86 has less of a legacy baggage there by virtue of not being as nice early on.

Clean break towards simpler internal design backed by compiled code statistics led most vendors - including intel - towards RISC style. Intel just happened to have constantly growing market share of their legacy design and never committed fully to abandoning it while lucking out in their simplistic design making it easier to support it long term.

Part of the effort to ditch x86 was to destroy competition that existed due to second sourcing agreements. After already trying and losing in court the case to prevent AMD and others from making compatible chips, Intel hoped to push IA-64 for the lucrative high performance markets it dominated in PCs, and prevent rise of compatible designs from other vendors.

N.b. 68000 was supposed to be a 16bit extension of 6800, which among others resulted in hilarious two layers of microcoding.

AS for IBM PC, 68000 had major flaw of being newer while 8086 had been available for longer and with second sources - 68000 was released at the same time as reduced capability 8088, while equivalent reduced capability model for 68k arrived in 1982.

Turns out m68k orthogonality results in explosion of complexity of the physical implementation and is way harder to optimize, especially since compilers did use that. Whereas way more limited x86 was harder to write code generation for, but it meant there was simpler execution in silicon and less need to pander to slow path only instructions. And then on top of that you got the part where Intel's scale meant they could have two-three teams working on separate x86 cpu at the same time.

X86 is comparatively simple, with limited indirect addressing support to the point it can be inlined in execution pipeline, and many instructions either being actually "simple" to implement, or acceptable to do in slow path. M68k (and VAX even more) are comparatively harder to build modern superscalar chip for.

68k like VAX was seen as dead avenue not only compared to RISC

Our ZUS is broken because someone let basic anti-fraud checks go out of hand without review, Tories got caught literally redesigning entire benefit system with goal of slowly dismantling it (curiously after their redistricting of NHS the system suffered massive loss in efficiency and capability)

But when RAPL and similar tools to throttle CPU are used, the CPU time gets reported as kernel_task - on linux it would show similarly as one of the kernel threads.

Similar approaches are utilized in other areas of british government, unfortunately.

HP-designed later cores were much faster and omitted x86 hardware support replacing it with software emulation if needed, but ultimately IA-64 rarely ever ran with good performance as far as I know.

Pretty sure it was Itanium that finally turned "Sufficiently Smart Compiler" into curse phrase as it is understood today, and definitely popularized it.