Live data from Hacker News

Yocto, RockPi and SBOMs: Building modern embedded Linux images

vpetersson.com

121–125 of 125 posts

Re: Yocto, RockPi and SBOMs: Building modern embedded Linux images

#121
post #48

Earlier quoted context omitted.

Yocto feels like a ball of mud duct taped together, but thankfully has good documentation. It reminds me of CMake. Buildroot is nice for relatively simple situations. Nixos is arguably better than both.

Their idiosyncrasies may look similar, but CMake has a much stronger skeleton of core algorithms and data structures for a build system than Bitbake. Specifically, as I mentioned in another reply, Bitbake does not model dependencies correctly. CMake does.

Can you elaborate a bit on the dependency-handling topic? I've always thought that Bitbake's dependency handling worked pretty well. It only has package-level granularity, but is quite good within that context.

Re: Yocto, RockPi and SBOMs: Building modern embedded Linux images

#122

Earlier quoted context omitted.

This is truth. I've done a lot of work bringing up custom boards with both Yocto and Buildroot and I rather like Yocto. But yeah, first project with Yocto was painful. It's rather well documented, but one really needs a good idea of what's going on to really know what you're even looking for. That said, once you get it figured out, it's very flexible and largely logical. :)

IME, the documentation is kinda useless when the going gets tough. But the code is surprisingly easy to follow.

The docs are good in the "I think there should be a way to do X" and if you have a good sense of how Yocto is organized, you'll know where to check if X exists. That's...not a trivial thing.

Re: Yocto, RockPi and SBOMs: Building modern embedded Linux images

#123
post #119

Earlier quoted context omitted.

Thus, we agree the bodged binaries were a mistake, and thus have reached an awkward understanding. Your use-cases might differ, but it does not change what the artifacts look like from a optimized low-end Yocto project. Best of luck, some of my most prized friends took 3+ years to agree with my perspectives. You should know I hold you very high regard =3

I don't know what you mean by "bodged binaries".

Upon the code audit, we saw heavily modified package builds where the linker was setup to strip off parts of partial libraries (far beyond what "strip --strip-unneeded" or even "-O3" would dare.) This meant the normal versioned ecosystem was always going to be out of date, potentially unstable, and difficult to curate properly.

Keep in mind there is zero justification for this trick unless constrained by minimal flash storage. My point was the situation shouldn't have featured in years (except in IoT garbage products), and using a standard build makes more sense these days even if the SoC costs $0.80/pc more.

YMMV, good luck... =3

Re: Yocto, RockPi and SBOMs: Building modern embedded Linux images

#124

Earlier quoted context omitted.

Their idiosyncrasies may look similar, but CMake has a much stronger skeleton of core algorithms and data structures for a build system than Bitbake. Specifically, as I mentioned in another reply, Bitbake does not model dependencies correctly. CMake does.

Can you elaborate a bit on the dependency-handling topic? I've always thought that Bitbake's dependency handling worked pretty well. It only has package-level granularity, but is quite good within that context.

As of five years ago when I last used it:

Bitbake doesn't model all changes that affect packages, so after certain changes, some packages that should be rebuilt, aren't. It is especially prone to happen when changing Bitbake variables (example: MACHINE_FEATURES), and these are a quite common way to change things about the image being built.

Re: Yocto, RockPi and SBOMs: Building modern embedded Linux images

#125

Earlier quoted context omitted.

IME, the documentation is kinda useless when the going gets tough. But the code is surprisingly easy to follow.

The docs are good in the "I think there should be a way to do X" and if you have a good sense of how Yocto is organized, you'll know where to check if X exists. That's...not a trivial thing.

True. For the most part, the documentation tells you what you can do in general terms and where (which file / variable). That is useful, but not enough to know how to do it.
Post reply on HN