If parallelism adds indeterminacy, then you have a bug (probably in working out the dependency graph.) Not an unusual one - lots of open source in the 1990s had warnings about not building above -j1 because multi-core systems weren't that common and people weren't actually trying it themselves...
Whenever I traced them, those bugs were always in the logic of the makefile rather than in the compiler. A target in fact depends on another target (generally from much earlier in the file) but the makefile doesn't specify that.
Even the specific example in the article, the non-determinism was treated as a bug and was fixed (since by 2004 that was definitely a regression - we put a lot of work in, in the mid to late 1990s, to get bit level reproducibility - and even before that, those little details like timestamps were still deterministic variations, we had binary diff tools that could filter them out.)
What open source DNS servers have an API? (I saw someone elsewhere in the thread talking about doing this with dnsmasq, but it sounded like they'd cobbled something together, rather than the software handling it.)
I personally wouldn't use dnsmasq for this (as its far more suited as a recursive server and DHCP provider with some basic authoritative records, rather than an authoritative-only server), but every open source authoritative DNS server worth using about has RFC 2136 support.
PowerDNS has an API which is working pretty well, I've been using it to generate ACME certificates since a few years and I also built a DNS hosting service around it.
Bell labs was pushed aside because Bell Telephone was broken up by the courts. (It's currently a part of Nokia of all things - yeah, despite your storytelling here, it's actually still around :-)
TCC supports 32 (and I think 64?) bit chips, SDCC only targets 8 and 16, so their use cases don't overlap at all as far as I can tell from their homepages...
Back in the 90s gcc did a three-stage build to isolate the result from weakness in the vendor native compiler (so, vendor builds gcc0, gcc0 builds gcc1, gcc1 builds gcc2 - and you compare gcc2 to gcc1 to look for problems.) It was popularly considered a "self test suite" until someone did some actual profiling and concluded that gcc only needed about 20% of gcc to compile itself :-)
part of why rexec is "historical" is that Guido was looking at some lockdown work and asked (twitter, probably?) the community to come up with attack ideas (on a specific more-locked-down-than-default proposed version.) After a couple of hours, it was clear that "patching the problems" was entirely doomed given how flexible python is and it was better to do something else entirely and stop pretending...
Is it really creeping, though? Pretty sure I first saw the EBNF in the man page more than 20 years ago, it's just how that generation learned to write and discuss parsers. (What I'm getting at is that even if it is, that isn't a sign of it.)
Of course, 20+ years ago a big feature was platform compatibility, and since then we've gone from 10+ to 2ish, so if it's not explicitly enabling retrocomputing, it should be getting simpler, right?
reply