Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yocto, RockPi and SBOMs: Building modern embedded Linux images

vpetersson.com

Post reply on HN
Print view View original

111–120 of 125 posts

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

#111

Post by IshKebab »

ahartmetz wrote: post #108
cushychicken wrote: post #18

Earlier quoted context omitted.

Part of why it gets so much criticism is that Yocto’s learning curve is pure brutality . Out of the box configurations for Yocto images and recipes are fabulous. Trying to modify those configurations below the application layer… you’re gonna have a bad time. Opaque error messages, the whole layers vs recipes vs meta issues, etc. I also can’t shake the feeling that yocto was made to solve a chip company’s problems (I.…

I have found that whatever my Yocto question is, reading (edit: bitbake -e and) 1-3 pages of pretty simple recipe and / or Bitbake code (Python) gives me the answer. Apparently, none of the people who complain have gotten far enough to run into the real problem... Bitbake is a shitty build system. Its dependency modeling is incomplete, so if you change some variable that influences many packages, you have to manually…

Ha kind of ironic that there's a comment above that says this is an advantage over Buildroot.

In my opinion the task Yocto and Buildroot do means it is impossible to have reliable incremental builds. They're simply wrangling too many other unreliable build systems (autoconf, make, etc.). For example OpenSBI's Make based system doesn't do incremental builds correctly. I always have to build from scratch.

The only way it could really work reliably is if everything it builds used Bazel or one of its brethren.

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

#112

Post by ahartmetz »

IshKebab wrote: post #111
ahartmetz wrote: post #108

Earlier quoted context omitted.

I have found that whatever my Yocto question is, reading (edit: bitbake -e and) 1-3 pages of pretty simple recipe and / or Bitbake code (Python) gives me the answer. Apparently, none of the people who complain have gotten far enough to run into the real problem... Bitbake is a shitty build system. Its dependency modeling is incomplete, so if you change some variable that influences many packages, you have to manually…

Ha kind of ironic that there's a comment above that says this is an advantage over Buildroot. In my opinion the task Yocto and Buildroot do means it is impossible to have reliable incremental builds. They're simply wrangling too many other unreliable build systems (autoconf, make, etc.). For example OpenSBI's Make based system doesn't do incremental builds correctly. I always have to build from scratch. The only way…

At a client they use an obscure system called e2factory to build images and that one does model dependencies correctly. It creates a little chroot environment for every package build and errs on the side of rebuilding if in doubt. It's probably less flexible than Bitbake with Yocto, but incremental builds totally work. You might need some all-encompassing integration to get more fine-grained dependencies, but tracking what goes into a build is possible with standard build systems (mainly autoconf / make and CMake / Ninja in this case).

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

#113

Post by WhyNotHugo »

cushychicken wrote: post #18
palata wrote: post #9

Yocto is pretty great! Unfortunately I feel like it gets a lot of criticism, but usually from people who haven't gotten to learn it. Like "I had to spend 2h on Yocto and this thing suuuuucks , I threw a docker image there and called it a day". Which is a pity, because when used correctly it's really powerful! From the article, I can't help but mention that one third of the "key terminology" is about codenames. What d…

Part of why it gets so much criticism is that Yocto’s learning curve is pure brutality . Out of the box configurations for Yocto images and recipes are fabulous. Trying to modify those configurations below the application layer… you’re gonna have a bad time. Opaque error messages, the whole layers vs recipes vs meta issues, etc. I also can’t shake the feeling that yocto was made to solve a chip company’s problems (I.…

For the typical use case (building a highly customised, target specific image for a pre-defined applications), what’s the main advantage of using Yocto over Gentoo (eg: creating images with Catalyst)?

It seems that they’re both well catered for that goal, but Gentoo really is designed for you to dig in deeper if you want (rather that trying to abstract everything away).

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

#114

Post by dezgeg »

WhyNotHugo wrote: post #113
cushychicken wrote: post #18

Earlier quoted context omitted.

Part of why it gets so much criticism is that Yocto’s learning curve is pure brutality . Out of the box configurations for Yocto images and recipes are fabulous. Trying to modify those configurations below the application layer… you’re gonna have a bad time. Opaque error messages, the whole layers vs recipes vs meta issues, etc. I also can’t shake the feeling that yocto was made to solve a chip company’s problems (I.…

For the typical use case (building a highly customised, target specific image for a pre-defined applications), what’s the main advantage of using Yocto over Gentoo (eg: creating images with Catalyst)? It seems that they’re both well catered for that goal, but Gentoo really is designed for you to dig in deeper if you want (rather that trying to abstract everything away).

Yocto cross compiles. I don't think Gentoo can do that?

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

#115

Post by IshKebab »

ahartmetz wrote: post #112
IshKebab wrote: post #111

Earlier quoted context omitted.

Ha kind of ironic that there's a comment above that says this is an advantage over Buildroot. In my opinion the task Yocto and Buildroot do means it is impossible to have reliable incremental builds. They're simply wrangling too many other unreliable build systems (autoconf, make, etc.). For example OpenSBI's Make based system doesn't do incremental builds correctly. I always have to build from scratch. The only way…

At a client they use an obscure system called e2factory to build images and that one does model dependencies correctly. It creates a little chroot environment for every package build and errs on the side of rebuilding if in doubt. It's probably less flexible than Bitbake with Yocto, but incremental builds totally work. You might need some all-encompassing integration to get more fine-grained dependencies, but trackin…

That sounds like a good design.

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

#116

Post by ahartmetz »

IshKebab wrote: post #115
ahartmetz wrote: post #112

Earlier quoted context omitted.

At a client they use an obscure system called e2factory to build images and that one does model dependencies correctly. It creates a little chroot environment for every package build and errs on the side of rebuilding if in doubt. It's probably less flexible than Bitbake with Yocto, but incremental builds totally work. You might need some all-encompassing integration to get more fine-grained dependencies, but trackin…

That sounds like a good design.

Well, it has downsides, too - one needs to specify all dependencies for every package. That includes transitive dependencies, so some of these dependency lists look pretty weird. "I need video codecs to build the mouse driver?!" (not a true example, but along these lines)

But with that information, everything that goes into a package goes into the build signature. Environment variables and all.

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

#117

Post by cushychicken »

unitexe wrote: post #103
cushychicken wrote: post #86

Earlier quoted context omitted.

+1 for swupdate. Implemented it three or so different times at this point and really like it.

I have also implemented it 3 times. Local updates from file system or USB and networked updates with the mongoose web page & the REST API. Quirky to configure when supporting all these methods at the same time but smooth and reliable once done. Never got to implement a full OTA update system. SWUpdate supports suricatta & Siemens WFX for this. I played around with WFX and got OS updates working on my local network bu…

I’ve only ever done hard connect updates over USB and manually pushed updates over local network. The team I was on was on track to switch over to pulled updates using Suricatta but I left before they switched them on.

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

#118

Post by mort96 »

bestouff wrote: post #106
mort96 wrote: post #76

Earlier quoted context omitted.

Why not? The only overhead I can see is some storage and memory overhead due to duplicate libraries, and some possible small startup time penalty? Containers are just normal Linux processes after all, it's not like there's a VM involved

Dont forget having multiple versions of a library will blow up your cache.

Just to the degree that there's more machine code competing for the same limited page cache... nothing about having multiple versions of one library is worse for cache than having the same amount of machine code across different libraries. It's not ideal, but considering how lean you could make the host system, it's a minimal cost.

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

#119

Post by mort96 »

Joel_Mckay wrote: post #104
mort96 wrote: post #102

Earlier quoted context omitted.

You're not responding to what I'm saying, the questions I'm asking or the mistakes I'm pointing out. I'm done.

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".

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

#120

Post by unitexe »

cushychicken wrote: post #117
unitexe wrote: post #103

Earlier quoted context omitted.

I have also implemented it 3 times. Local updates from file system or USB and networked updates with the mongoose web page & the REST API. Quirky to configure when supporting all these methods at the same time but smooth and reliable once done. Never got to implement a full OTA update system. SWUpdate supports suricatta & Siemens WFX for this. I played around with WFX and got OS updates working on my local network bu…

I’ve only ever done hard connect updates over USB and manually pushed updates over local network. The team I was on was on track to switch over to pulled updates using Suricatta but I left before they switched them on.

Cool, thanks for sharing!
Post reply on HN