Yes, there was a brief humorous reference to that in the article: "The correct approach would be to run config after editing the kernel config, but the plot restricts us from doing that."
For normal usage on amd64 and i386(?), it is recommended not to compile the kernel. I think the article is geared to Developers and testers of OpenBSD.
> And now I will be patenting this technique to prevent anyone else from doing something so idiotic.
For years i was searching for an answer to the question: why some company registers so many patents. It never occured to me that this might be the answer.
Thanks for the hint.
I’m not sure using a build farm to dynamically relink the kernel at boot might would solve the problem.
I think the core issue is that it needs to keep two complete copies of the kernel in memory at the instant in time where it hands off from one to another.
Adding a ccache dependency to the bootup sequence would be in keeping in tone with the rest of the article though.
>And now I will be patenting this technique to prevent anyone else from doing something so idiotic. Should you find yourself stranded on a remote planet and your last means to reestablish communication with earth is relinking an openbsd kernel in only 32 megabytes, we can work out a license in exchange for a cut of your book deal.
What a fun post!
> The object files are so large because the kernel is initially compiled with debug symbols.
Is there a way to build without producing debug symbols in the first place?