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

101–110 of 125 posts

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

#101

Post by Joel_Mckay »

mort96 wrote: post #99
Joel_Mckay wrote: post #97

Earlier quoted context omitted.

"I don't understand where you're coming from at all." In time you may, but perhaps you were confused about the primary use-case context bringing up small linux SBM. The mess Yocto can leave behind was not something manufacturers prioritized, and there are countless half-baked solutions simply abandoned within a single release cycle. Out of date package versions, and storage space-optimized stripped/kludged binaries a…

I might have been unclear. What I don't understand is how binary stripping and custom patches is associated with SoCs with low RAM, or why you claimed that it does static linking when it doesn't by default.

It was mostly the low-end IoT and router markets that was the major driver behind space-optimized image builds. i.e. the various tricks people pull to get leaner builds made maintenance nearly impossible. On chip RAM was the initial constraint that fell, TLC flash became inexpensive, and ARM option performance hit practical levels. i.e. it became possible to install normal environments with a simple port.

The other point I was stating was today the low-end chip justifications no longer makes economic sense. The kernel maintainers already deprecated 32bit years ago.

"All software is terrible, but some of it is useful..." but if proves a liability, than it is just terrible. lol Have a great weekend =3

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

#102

Post by mort96 »

Joel_Mckay wrote: post #101
mort96 wrote: post #99

Earlier quoted context omitted.

I might have been unclear. What I don't understand is how binary stripping and custom patches is associated with SoCs with low RAM, or why you claimed that it does static linking when it doesn't by default.

It was mostly the low-end IoT and router markets that was the major driver behind space-optimized image builds. i.e. the various tricks people pull to get leaner builds made maintenance nearly impossible. On chip RAM was the initial constraint that fell, TLC flash became inexpensive, and ARM option performance hit practical levels. i.e. it became possible to install normal environments with a simple port. The other p…

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

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

#103

Post by unitexe »

cushychicken wrote: post #86
PhilipRoman wrote: post #64

Earlier quoted context omitted.

Not what you're looking for, but https://sbabic.github.io/swupdate/swupdate.html It's meant (I think?) for immutable style distros like Yocto. You basically create a cpio archive and a manifest of what file goes in which partition (plus bells and whistles like cryptography). It's a good idea to have double buffering, so that if boot fails to come to a reasonable state, the device will revert after a few tries. IMO th…

+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 but didn't do anything else with it.

Nonetheless, if I wanted to implement my own OTA update solution swupdate & WFX seem like a beautiful combination.

If I may ask, how far did you take it?

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

#104

Post by Joel_Mckay »

mort96 wrote: post #102
Joel_Mckay wrote: post #101

Earlier quoted context omitted.

It was mostly the low-end IoT and router markets that was the major driver behind space-optimized image builds. i.e. the various tricks people pull to get leaner builds made maintenance nearly impossible. On chip RAM was the initial constraint that fell, TLC flash became inexpensive, and ARM option performance hit practical levels. i.e. it became possible to install normal environments with a simple port. The other p…

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

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

#105

Post by planckscnst »

msarnoff wrote: post #24
codetrotter wrote: post #21

Last time I tried Yocto, some people here on HN suggested that I try Buildroot instead. I don’t see so many mentions of Buildroot in this thread yet. If you are interested in Yocto it might be worth having a look at Buildroot as well. I liked it a lot when I tried it. My thread from years ago, where people told me about Buildroot: https://news.ycombinator.com/item?id=18083506 The website of Buildroot: https://buildro…

I think, in a lot of cases, the choice between Buildroot and Yocto comes down to "which one does the SoC vendor support."

Buildroot is easy to use even without vendor support

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

#106

Post by bestouff »

mort96 wrote: post #76
RobotToaster wrote: post #61

Earlier quoted context omitted.

That doesn't sound very performant.

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.

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

#107

Post by [deleted] »

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

[deleted]

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

#108

Post by ahartmetz »

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

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 rebuild them. I just resorted to rebuilding everything after making that kind of change.

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

#109

Post by ahartmetz »

eschneider wrote: post #92
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.…

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.

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

#110

Post by ahartmetz »

xedrac wrote: post #48
bibabaloo wrote: post #33

Earlier quoted context omitted.

I agree. I don't understand how people prefer buildroot. Buildroot feels like an adhoc system of glued together Makefiles, whereas yocto actually feels like it was built for purpose.

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.
Post reply on HN