@theorytoe The answer is that there's this simple and nice make(1), and then people complicate it, and that introduces portability problems, and then
and then people shout at you that your Makefile doesn't work on VMS, and then a one-liner gets bloated into 30 lines of horseshit. The xz vulnerability is more like an autotools vulnerability: shit can sneak right in there because no one even wants to *look* at configure.ac or anything in the m4/ directory. So they think they can have something simpler and easier to manage if they abandon the ball of mud and start over with a new system for expressing a dependency tree, not realizing that when the portability cult arrives, they will have you compiling a million test programs to find out how big uint64_t and int32_t are, because if you put portability checks around types added for portability, you get double the portability. When looking at the code to see exactly what this unholy build system was called, the first thing I saw, near the top of their configure script (which is a bare shim that just invokes other build scripts) was that they override $JOBS, because even if you have taken care to set $JOBS to a number that makes sense on your machine, attempting to execute jobs in parallel triggers Python threading bugs on AIX. I haven't ever even logged into an AIX system and I don't think I know anyone that uses it, so I definitely don't want the build to slow to a crawl for that.

Portability is really nice, but this portability cult formed, and they try to turn the act of hacking on cool shit into a bureaucratic phantasmagoria, and then once those people reach critical mass, it's all "THAT FILE HAS A BASH-ISM IN IT" and "THAT'S UNDEFINED BEHAVIOR PER C11 AND THE DSM-V" and then people fuck off to elsewhere. In the mean time, there are people that throw a fit if your code wouldn't work on 1's complement systems that use EBCDIC instead of ASCII, and they end up producing code that isn't even backwards-compatible with itself, so you try to update a piece of software and there's an entire Gordian knot of dependencies to rebuild because library $x v1.1.0.2 is not compatible with $x v1.1.0.1. Unix people used to be able to joke that Windows users had to reformat and reinstall every month; that joke hits a little too close to home nowadays, when all of this complete shit code goes out of its way to be theoretically compatible with a system that runs Xenix, but is not compatible with a system from a year ago.

Somewhat related, I recently read some commentary :dmr: had about the fan-fiction that X3J11 tries to pass off as a standardization effort, and it seems pretty clear why most of the post-ANSI extensions were completely ignored by the authors of the C programming language:

> The fundamental problem is that it is not possible to write real programs using the X3J11 definition of C. The committee has created an unreal language that no one can or will actually use.

You see this same pattern repeat over and over again: process wonks and "best practices" fascists come in and make a tower of incomprehensible and self-contradictory rules and the effect is to kick people out of the language/ecosystem/OS so that they can be petty bureaucrats and issue memoranda to a depopulated nation as the lords of the tumbleweeds.