[HN Gopher] Yocto, RockPi and SBOMs: Building modern embedded Li...
       ___________________________________________________________________
        
       Yocto, RockPi and SBOMs: Building modern embedded Linux images
        
       Author : mvip
       Score  : 63 points
       Date   : 2025-02-21 19:34 UTC (3 hours ago)
        
 (HTM) web link (vpetersson.com)
 (TXT) w3m dump (vpetersson.com)
        
       | lukeh wrote:
       | Love Yocto! It has a learning curve but it took about a week from
       | nothing to an embedded image including Swift and Flutter apps,
       | U-Boot, etc. A curve worth climbing.
        
         | mvip wrote:
         | Yeah it definitely isn't straight forward. But it is
         | complicated for good reasons given how much more complicated
         | stuff it does behind the scenes.
        
         | themadsens wrote:
         | I always found buildroot a lot easier to fathom and harness.
         | And certainly flexible enough with the ability patch every
         | included recipe and package.
        
           | palata wrote:
           | I think it is easier. But for some projects it becomes harder
           | to maintain.
        
           | fullstop wrote:
           | I cut my teeth on Buildroot but greatly prefer Yocto now.
           | Buildroot is fast and loose, where Yocto forces you to do the
           | right thing.
        
       | Palomides wrote:
       | >you can't run "apt update"
       | 
       | if you want to get a little weird, you can tell yocto to compile
       | everything into deb packages and host them yourself with
       | something like aptly
        
         | mvip wrote:
         | Yeah that's true. But if these are embedded devices, you
         | probably want an A/B partition scheme with full transactional
         | updates and rollback.
        
         | dima55 wrote:
         | Or you can, you know, just run Debian.
        
       | palata wrote:
       | 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 do people have with
       | codenames? I can count and easily know that 5 comes after 4. But
       | I don't know how to compare Scarthgap and Dunfell (hell, I can't
       | even remember them).
        
         | lukeh wrote:
         | Yeah, I was a bit scared off by it and both the terminology and
         | the curious mixing of Python and bash can be a bit confusing.
         | But it's powerful and also very extensible without (generally)
         | having to fork upstream layers.
        
         | allo37 wrote:
         | I'm honestly impressed by how...well it works. Considering it's
         | building an entire, totally custom Linux distro from scratch it
         | requires a surprisingly little amount of hand-holding.
        
         | cushychicken wrote:
         | 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.e. supporting Linux distros for three hundred
         | different SOCs) rather than my problems (I.e. ship working
         | embedded software for one or two SOC platforms).
         | 
         | I've had a lot more success with buildroot as an embedded Linux
         | build system and I recommend it very highly.
        
       | dgfitz wrote:
       | I read just the title and wondered if this was a yocto post.
       | 
       | I have (accident) become the yocto SME at my $dayjob. Probably
       | the biggest positive has been free SBOM generation, and cooking
       | things like kSLOC counts into recipes.
       | 
       | The learning curve stinks, the build suite is very powerful.
        
       | kierank wrote:
       | It's crazy that you have to use this custom "embedded" tooling
       | when the vendor should be implementing support in vanilla Linux
       | distros.
        
         | fullstop wrote:
         | This is way harder to do with SBCs than you would think. You
         | don't have a BIOS.
        
         | palata wrote:
         | It is not "custom embedded tooling"! It is tooling you run on
         | your main machine to build a custom distro. Imagine you follow
         | the "Linux from Scratch" tutorial, then start writing scripts
         | to automate parts of that, and eventually create a framework
         | that allows you to create a custom Linux from Scratch. After
         | years of work you may end up with something that looks like
         | Yocto.
         | 
         | The whole point of using Yocto is that you want a custom
         | distro. You could build a totally "standard" distro with Yocto
         | but... at this point you can also just use Gentoo or Debian or
         | whatever works.
        
       | dgfitz wrote:
       | This toolchain is about half my dayjob.
       | 
       | Bitbake is a meta-compiler, and the tool suite is very powerful.
       | Just realize to this means you need to be an expert error-message
       | debugger, and able to jump into (usually c/c++) code to address
       | issues and flow patches upstream.
       | 
       | It really is gratifying when you finally kick out a working
       | image.
        
       ___________________________________________________________________
       (page generated 2025-02-21 23:00 UTC)