p_l

6 ms·

61.
by p_l 2mo ago
Honestly, a lot of it was not that hard to port if you really wanted, it's just that the ROI of replacing the entire stack including physical machines was not necessarily good. The parts where ROI was good got replaced already.
62.
by p_l 2mo ago
Politics. Just like with the previous AI Winter.
63.
by p_l 2mo ago
There's dozens of us! Dozens! /s (and all self-aware)
64.
by p_l 2mo ago
The thing is... not everything you need to track, not even all airplanes, will have transponders. Sometimes the transponders will be faulty, sometimes you have to direct a broken aircraft safely to the ground with no transponder available.
65.
by p_l 2mo ago
Do it manually and hacky, yes. At that point though, one could claim that they can do it in C as well and implement half of Objective-C
66.
by p_l 2mo ago
Unix team developed C partially to regain a bit of the state of the art that they were excluded to earlier, with added constraint of being very small machine so they couldn't just fit a state of the art language without making complex
67.
by p_l 2mo ago
Inline caches require runtime supports that were ideologically verboten to C++
68.
by p_l 2mo ago
IIRC not compiled (you can include the interpreter). But then Scheme was always less EVAL-friendly of the lisps
69.
by p_l 2mo ago
Linux actually has pretty long history of userspace drivers, and multiple kernel drivers have as their main if not only logic a way to link hardware interface with userspace app, or just providing transport interface. And android heavily us
70.
by p_l 2mo ago
The part where Windows applications built with C++ generally do not share C++ ABI DLLs with each other and the operating system except for certain well isolated ones is major part of it. GCC changing C++ ABI usually meant horrific time fo
71.
by p_l 2mo ago
Additionally a lot of the APIs if you go underneath, including native code components, are exposed through few variants of Binder (BeOS-derived IPC for the uninitiated) including userspace drivers. Binder APIs very much do not follow C ABI
72.
by p_l 2mo ago
More like the specific design of a vtable
73.
by p_l 2mo ago
Every new API since around NT5.2/6.0 era had to get explicit waiver to be provided as anything other than COM interface. Some additionally have weird hybridization going on IIRC that lets you have some kind of faster path but still h
74.
by p_l 2mo ago
Unaligned access was common issue on many RISCs, which depending on specific Unix variant and runtime settings might mean regularly getting SIGBUS for code ported from other architectures. Without BWX instructions from EV56 (21164A) you als
75.
by p_l 2mo ago
Arguably the ECL was just digging themselves deeper, the real failure was upper management fighting any suggestion that VAX has played out and should be replaced. EDIT: Then there's the infighting between "big ECL VAX" and ev
76.
by p_l 2mo ago
Seeing Postgres articles from Snowflake surprises me a lot though given how there's zero relation between Snowflake the product and Postgres itself EDIT: I now see it's mainly to do with pushing data out of customer's postgre
77.
by p_l 2mo ago
Another somewhat related error in strategy was trying to keep VAX alive for longer than it should have been, especially the ECL versions
78.
by p_l 2mo ago
The funny part is that arguably both HyperTransport and QPI descend from the interprocessor links designed for Alpha EV7
79.
by p_l 2mo ago
An important thing to consider is that DEC simply didn't have enough CPU design teams, which is also why Alpha essentially had only one-and-half model in the works throughout its history - and the half came from smashing smallest chips
80.
by p_l 2mo ago
FWIW Alpha pretty quickly went with mainly PCI + few legacy ISA slots for considerable chunk of the line, unlike competition which used proprietary buses that might have been faster but meant extra level of exotic in procurement
81.
by p_l 2mo ago
The issue was not that Alpha ISA was impossible to scale down. The issue was that DEC lacked the resources to run a completely new microarchitecture design to target low-power platforms, and the failure was trying to push an extreme perform
82.
by p_l 2mo ago
Decision to cease support was reputedly done by Compaq, coming as complete surprise to both Compaq-side and Microsoft-side NT teams. As for Alpha, funnily enough the first few years I knew of it, I knew only of NT use with them, because tha
83.
by p_l 2mo ago
Thinking longer about Alpha's imprecise faults made me realize that signaling NaNs can be quite useful in such case
84.
by p_l 2mo ago
That's the real problem with AGPL, IMO - it encourages copyright assignment to a corporate entity so it can launder it through dual-licensing
85.
by p_l 2mo ago
Yes, I agree it does a lot of heavy lifting there. Honestly that's why it needs to both have strict liabilities on operators/developers (no more "computer said so but computer can't be held liable"), as well as what
86.
by p_l 2mo ago
Because a computer can handle 100s of such calls simultaneously. Similarly, I worked on a system that used AI for approvals of payment for medical activities (in Germany) - it only could fail in favour of the patient (approving when a hum
87.
by p_l 2mo ago
FX!32 was good compared to what was available elsewhere (including for Itanium IIRC). I am not saying it had to compete with fully with x86 on consumer desktops from beginning, but it would have been more stable position, especially with kn
88.
by p_l 2mo ago
I somewhat suspect that if not for multiple materials (not from MS) promoting deep dependency on IBM PC specifics, it might have worked out.
89.
by p_l 2mo ago
Windows on Alpha and FX!32 were reasonably solid options, as was the general health of the Alpha ecosystem. The platform also was not overextended in dot-com boom as much as let's say Sun. Windows port was also pretty early, even if it
90.
by p_l 2mo ago
IIRC it was major part of intel's roadmap to establish it so that "future" of PC cpus would be locked down to Intel/HP partnership. And back then VIA was still noticeable competitor!

More ›