Even if that's the ideal (and a very expensive one in terms of time and resources), I really don't think it accurately describes the maintainers of the very long tail of small open-source projects, especially those simple enough for the relevant features to be copied into a few files' worth of code.

Like, sure, projects like Linux, LLVM, Git, or the popular databases may fit that description, but people aren't trying to vendor those via LLMs (or so I hope). And in any case, if the project presently fulfills a user's specific use case, then it "going somewhere next" may well be viewed as a persistent risk.

I suppose the idea would be, they don't have to maintain it: if it ever starts to rot from whatever environmental changes, then they can just get the LLM to patch it, or at worst, generate it again from scratch.

(And personally, I prefer writing code so that it isn't coupled so tightly to the environment or other people's fast-moving libraries to begin with, since I don't want to poke at all of my projects every other year just to keep them functional.)

Adjusting the "1" upward in sqrt(1-x) does not seem to help at all.

For reference, the coefficients given are [1.5707288, -0.2121144, 0.0742610, -0.0187293]: if we optimize P(x) = (π/2 - arcsin(x))/sqrt(1-x) ourselves, we can extend them to double precision as [1.5707288189560218, -0.21211524058527342, 0.0742623449400704, -0.018729868776598532]. Increasing the precision reduces the max error, at x = 0, by 0.028%.

Adjusting our error function to optimize the absolute error of arcsin(x) = π/2 - P(x)*sqrt(1-x) on [0,1], we get the coefficients [1.5707583404833712, -0.2128751841625164, 0.07689738736091772, -0.02089203710669022]. The max error is reduced by 44%, from 6.75e-5 to 3.80e-5. If we plot the error function [0], we see that the new max error is achieved at five points, x = 0, 0.105, 0.386, 0.730, 0.967.

(Alternatively, adjusting our error function to optimize the relative error of arcsin(x), we get the coefficients [1.5707963267948966, -0.21441792645252514, 0.08365774237116316, -0.02732304481232744]. The max absolute error is 2.24e-4, but the max relative error is now 0.0181%, even in the vicinity of the root at x = 0. Though we'd almost certainly want to use a different formula to avoid catastrophic cancellation.)

So it goes to show, we can nearly double our accuracy, without modifying the code, just by optimizing for the right error metric.

[0] https://www.desmos.com/calculator/nj3b8rpvbs

Given that turning an active call stack into a serializable form is such a rare feature even in functional languages, iteration with an explicit stack ends up as the only practical choice for this use case.

(Also, for this particular problem, we can implement a much simpler iterative routine: create an explicit stack of forests, initially containing the initial forest. While the stack is not empty, pop a forest: if it is not nil, push its tail, then if its head tree is not empty, accumulate the value and push the sub-forest. If you're starting with a tree, then stick it in a synthetic forest. This all comes out to ~15 LOC, with no mutability except for the accumulator and stack.)

[0] https://en.wikipedia.org/wiki/Remez_algorithm

And if you greatly restrict supply at a given price point, without changing the underlying demand, you'll end up with much higher prices and lower total volume, so we wouldn't enjoyed all the compounding benefits from access to energy.

As far as I understand: GNU Linux-libre, a distribution, excludes the ability to update proprietary CPU microcode. Oliva, an important Linux-libre maintainer, says that (e.g.) Intel's proprietary microcode is inherently a backdoor, and that the ability to replace it only with new proprietary microcode is also a backdoor and an attack. Furthermore, new microcode updates cannot plausibly benefit the user and may only cause further harm to the user, thus Linux-libre (as distributed) makes efforts not to facilitate them.

Garrett is arguing against this notion, saying that microcode updates can very plausibly benefit the user in ways that cannot be mitigated in higher layers; that there have been no publicly-known cases of a microcode update introducing security vulnerabilities that were not already present; and thus, that it is beneficial to the user to have the ability (but not the requirement!) to update microcode blobs.

Both of them seem to agree it is better to have free software over proprietary blobs in all components of the system, though they both accuse each other of not fully standing for that position (Oliva accuses Garrett of "overlooking" the inherent backdoor nature of proprietary microcode; and Garrett takes issue with Olivia treating "installable software" as ethically distinct from firmware ROMs w.r.t. software freedom).

Personally, I'm not a fan of software or libraries that take active measures to make me use them in a certain way, so I'd lean toward Garrett's position, but thankfully no one is forcing me to use Linux-libre.

[0] https://ourworldindata.org/grapher/annual-co2-emissions-per-...

As if paper sources are any less susceptible to becoming increasingly unavailable over time...