Live data from Hacker News

Yocto, RockPi and SBOMs: Building modern embedded Linux images

vpetersson.com

51–60 of 125 posts

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

#51

I am actually scared of switching jobs in case my next job doesn't involve yocto. How would I make use of the countless hours I have already invested in this piece of software? Countless keywords and the dark magic of the ever changing syntax. But when it works it works..

> How would I make use of the countless hours I have already invested in this piece of software? Countless keywords and the dark magic of the ever changing syntax.

That sounds like sunk-cost fallacy. What if you switch jobs and they use something else that just works without needing dark magic syntax? If it's the best tool then so be it, but I question your reason for clinging to it.

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

#52

I am actually scared of switching jobs in case my next job doesn't involve yocto. How would I make use of the countless hours I have already invested in this piece of software? Countless keywords and the dark magic of the ever changing syntax. But when it works it works..

Just curious, what is the procedure that does NOT involve Yocto? I guess a ton of shell scripts? Where can I learn it (i.e. build a Linux system for any embedded system without using Yocto or similar tools)? Is the LFS project the first place I should visit? Background: I just switched to Ubuntu 22.04 for my daily use (mostly coding for side projects) but TBH I'm just using it as Windows. I use a Macbook Pro for work…

> Just curious, what is the procedure that does NOT involve Yocto? I guess a ton of shell scripts? Where can I learn it (i.e. build a Linux system for any embedded system without using Yocto or similar tools)? Is the LFS project the first place I should visit?

There are other tools in the same space like buildroot, but I would personally tend to recommend LFS to start from the fundamentals and work up, yes.

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

#53
post #44

As someone in the Software Supply Chain business. Yocto SBOMs are considered low quality because they include things that do and do not exist in the final compiled artifact. When you compare what exists inside, physically from a binary perspective, what is included in the manifest, and what is generated in the build root, you will find they will never align unless you get creative and map artifacts together. Today th…

How would yocto adjust their approach to improve their SBOM output? It would seem to be a nearly impossible thing to automate.

To be clear, it isn’t just a yocto problem. It is an industry wide issue and usually requires resolution between binary, build, and manifest or SCA. But at the end of the day developers are still very creative.

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

#54
Yocto can be incredibly simple, this is my favorite example: https://github.com/bootlin/simplest-yocto-setup/

Only the kernel and bootloader usually need to be specialized for most modern arm boards: the userland can be generic. Most of the problems people have with yocto are due to layers from hardware vendors which contain a lot of unnecessary cruft.

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

#55
post #12

Earlier quoted context omitted.

Or you can, you know, just run Debian.

i was going to just comment "but systemd" but i just found out debian ostensibly supports uninstalling it and installing openRC instead and that makes me like debian more. I use debian for generic VMs, prod VMs are 50/50 gentoo and ubuntu. I've been messing with Devuan too as my primary linux VM on my desktop PC. At one point i had it booting to fully logged in in around 8 seconds (after the bootloader selection thin…

Also Yocto supports systemd. I’m using it in my build.

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

#58

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…

There’s also SkiffOS (https://github.com/skiffos/SkiffOS).

It’s a project that uses buildroot to create a small Linux for a specific device that’s only used to start a container.

I’ve wanted to try it sometime after getting headaches with both Buildroot and Yocto. Particular adding more libraries tends to break things.

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

#59
post #13

It's crazy that you have to use this custom "embedded" tooling when the vendor should be implementing support in vanilla Linux distros.

There's a lot more to Yocto than just building the kernel. It's still useful when kernel support is upstreamed, such as including vendor tooling and test programs.

Upstreaming also takes a very long time and is usually incomplete. Even when some upstream support is available you will often have to use the vendor specific kernel if you want to use certain features of the chip.

Nobody can wait around for upstream support for everything. It takes far too long and likely won't ever cover every feature of a modern chip.

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

#60
Q: How do you guys centrally update field devices?

I am working on professionalizing our IOT setup that currently consists of a few dozen raspberries which run docker containers. They are individually updated by sshing into them and running apt update manually. Docker containers are deployed with a commercial solution. I want to have a centralized way to update the OSes, but it does not really make sense for our small team to introduce yocto knowledge, because that would make us fall behind development schedule even more. Also, the hardware needs are just too boring to justify rolling our own os. I have not yet found a hardware independent Linux distro that can be reliably updated in an IOT context.

I am now looking if we can buy ourselves out of this problem. Ubuntu Core goes in the right direction, but we don't want to make us dependent on the snap store. Advantech has a solution for central device management with Ota updates, maybe we are going that route.

How do you guys update field devices centrally? Thanks!

Post reply on HN