| This sounds like fun, but I'm not sure how changing build systems fixes the vendor problem. They will just ship their proprietary blobs built on top of this new build system instead of the old one, and will not change other behavior. Buying from vendors who upstream or minimally open source their work might help. Yes, skipping builds from source can be faster, and, I don't know that you need to throw away yocto to do that https://rootcommit.com/pub/conferences/2024/elce/yocto-binar... From the statement about "Caches builds so no piece of software is built twice." I'm guessing that the author has not enabled sstate caching https://docs.yoctoproject.org/dev/overview-manual/concepts.h... I'm a little doubtful on the post's assertion that yocto is only needed for "deeply embedded regulated products." For products that have to follow the https://en.wikipedia.org/wiki/Cyber_Resilience_Act coming up, they will almost certainly need: * SBOM management https://docs.yoctoproject.org/next/dev-manual/sbom.html * CVE (or its successor) tracking https://docs.yoctoproject.org/dev/security-manual/vulnerabil... * License management https://docs.yoctoproject.org/next/dev-manual/licenses.html And I'll echo what some other folks have said here: if you don't need features like that, bundle your custom bootloaders and kernel with a binary distribution like Debian and call it a day. |
Reversing and reimplementing the closed bits are what I want my Buildroot pipelines to do.
That’s my use case though; targeting COTS devices with (mainline) Linux support that don’t do all they could.
I have done it the ugly way (in production) and I want elegance in my old age.