4 ms·

Lots of good replies on that thread. I have been doing embedded development for 30 years, and Yocto is the best build system that I have used for managing larg

Lots of good replies on that thread. I have been doing embedded development for 30 years, and Yocto is the best build system that I have used for managing large embedded systems. If you need to professionally manage multiple distributions across menagerie of different host and target machines, there simply is no other meaningful choice that operates at its scale. I first encountered BitBake before either the OpenEmbedded or Yocto projects existed. Since then, I have done professional embedded systems consulting for dozens of platforms, using Yocto almost exclusively in recent years. I have done everything with it, from simple board bring ups to implementing re-usable BSP layers used by multiple product families. I might be a little biased here, but I have used all of the other popular embedded build systems too. Other choices still have their place for smaller and simpler projects, just as one might choose something smaller than Linux for the kernel. However, Yocto and Linux have attracted unparalleled open source development and support resources. Other projects simply cannot hope to match their established output. These projects will not go away any time soon, which means LTS releases and stable infrastructure to host them, regardless of individual players or projects coming or going. What other choice exists with that kind of backing? For commercial projects that grow beyond a certain scope (i.e. most modern full-featured embedded systems), other choices simply do not match its existing capabilities. Of course, you can always fork a full server/desktop Linux distribution like Debian, but dressing up a standard distribution in embedded clothing often requires more customization. That comes with develop and maintenance costs, though I admit the lines do start to blur at a certain point. The BitBake/OpenEmbedded/Yocto/Poky ecosystem is huge and poses a long and steep learning curve, but it offers customization and extensibility unparalleled by any other offering that I have had the (mis)fortune of using in my career. The same is true for the Linux kernel ecosystem, right? Them's the trade-offs we make.

eschneider 5y ago
Yocto is fantastic and well documented but getting started is hard and nothing makes much sense until you fully understand it. Once it clicks, though, it’s great. Totally worth the effort.
synergy20 5y ago
I have been doing embedded linux for 22 years and sadly Openembedded/Yocto has been the worst build system ever. It's the Gentoo for embedded(where is Gentoo nowadays), over-engineered so much for most use cases unless you work at Windriver or Amazon that deals with lots of different boards from different vendors and you have unlimited resource to work with the complexity. If I got a codebase that uses Yocto/Openembedded, the first thing I do is to find the related patches there and convert them to buildroot/debian/openwrt/LTIB(old stuff)/etc depends on the hardware spec. I wasted too much time when there is a bug in Openembedded that could take forever to debug, layer over layer, override over override on those meta mazes, it always feels like you're fighting with openembedded/yocto itself instead of getting your work done. I since have been avoiding openembedded/yocto at all costs.
- dgfitz 5y ago
  There is a learning curve, but when crossed, it’s a beautiful system.
  - synergy20 5y ago
    same could be said to gentoo, from experience over 2 decades and at least 5 projects involved yocto(back then it was openembedded), for the same project, yocto will take 5x more time/efforts per my measurement. yes adding stuff is fine, building is the slowest but I can wait, however if something went wrong, be prepared to debug openembdded/yocto-itself for days, this does not exist in other alternatives: you debug your own code, not the framework there. It's over engineered, over rated, great for consultants to charge hours, terrible for companies(except for big guns) to deliver product fast. Sorry I have a strong opinion here but it just wasted too much of my time in the past.
    - nrclark 5y ago
      Buildroot is definitely much simpler, and more limited. That's a plus and a negative, depending on what you're doing with it. Do you have one board that you need to bring up in isolation? Buildroot is great. It's easy and fast. Do you want to share configuration across multiple designs? Buildroot hits its limits pretty quickly there. And Yocto really starts to shine. I worked at a company that used Buildroot to support 20 different boards, all in the same repo. The boards shared some level of common configuration across the whole repo, and groups of boards also shared some common configuration. The entire thing was managed by the C preprocessor as a pre-Buildroot step, and it was a gordian knot of emergent complexity. The catch is that Buildroot doesn't give you any tools to enable shared configuration, none at all. Buildroot doesn't know how to share build-products across multiple images, and doesn't even know how to _build_ multiple images or keep them separate without having to clean your workdir. It doesn't even track file dependencies, let alone configuration dependencies. It's terrible at knowing when a package is stale. Yocto is much, much better than Buildroot for handling these kinds of use cases. Images are just recipes, like any other kind of recipe. You can build 8 different images by just asking for each of them by name. Yocto won't rebuild anything that can be shared, and your images can be subclasses of each other which just add or remove a few packages or a bit of configuration. Yocto is also better at tracking/managing customizations. In Yocto, it's easy to express something like "use the upstream OpenSSH recipe, but do something custom for the config step, and add an extra post-build step, and add these 3 patches, but only add patch 3 on some designs, etc". In Buildroot, you have to do this in a global namespace using macro-processing in GNU Make. You have no control over the parse order of included Makefiles relative to the upstream files. It's messy and difficult to modify anything, and you have to understand each recipe's quirks and hooks. And the only programming language you have is GNU Make. In Yocto, there is an inheritance system that lets you use .bbappend files to override the behavior of any recipe you want. You can also stack multiple append files across different layers. If you need something exotic, you can express it as parse-time Python. Yocto is more complex up-front, but it pays off IMO.
na85 5y ago
>I have been doing embedded development for 30 years What's your take on the various *BSD distros in the embedded space? A lot of BSD proponents like to talk about the stability and minimalism (a proxy for resource-efficiency I guess) of BSD in comparison to Linux. Is there any reason to reach for BSD in an embedded application these days?
- voakbasda 5y ago
  The BSDs fall into the class of server/desktop systems. They would be a great choice for certain classes of products (e.g. routers) where there exists strong feature alignment, but not something I would consider suitable for producing my usual minimal custom embedded systems. Generally, esoteric hardware support also will be better in Linux, so BSD would likely require porting or writing more drivers when bringing up a custom board. That said, BSDs have not my strongest area, so I would be curious to see others’ experiences and opinions.

eschneider 5y ago

Yocto is fantastic and well documented but getting started is hard and nothing makes much sense until you fully understand it. Once it clicks, though, it’s great. Totally worth the effort.

synergy20 5y ago

I have been doing embedded linux for 22 years and sadly Openembedded/Yocto has been the worst build system ever. It's the Gentoo for embedded(where is Gentoo nowadays), over-engineered so much for most use cases unless you work at Windriver or Amazon that deals with lots of different boards from different vendors and you have unlimited resource to work with the complexity. If I got a codebase that uses Yocto/Openembedded, the first thing I do is to find the related patches there and convert them to buildroot/debian/openwrt/LTIB(old stuff)/etc depends on the hardware spec. I wasted too much time when there is a bug in Openembedded that could take forever to debug, layer over layer, override over override on those meta mazes, it always feels like you're fighting with openembedded/yocto itself instead of getting your work done. I since have been avoiding openembedded/yocto at all costs.

dgfitz 5y ago
There is a learning curve, but when crossed, it’s a beautiful system.
- synergy20 5y ago
  same could be said to gentoo, from experience over 2 decades and at least 5 projects involved yocto(back then it was openembedded), for the same project, yocto will take 5x more time/efforts per my measurement. yes adding stuff is fine, building is the slowest but I can wait, however if something went wrong, be prepared to debug openembdded/yocto-itself for days, this does not exist in other alternatives: you debug your own code, not the framework there. It's over engineered, over rated, great for consultants to charge hours, terrible for companies(except for big guns) to deliver product fast. Sorry I have a strong opinion here but it just wasted too much of my time in the past.
  - nrclark 5y ago
    Buildroot is definitely much simpler, and more limited. That's a plus and a negative, depending on what you're doing with it. Do you have one board that you need to bring up in isolation? Buildroot is great. It's easy and fast. Do you want to share configuration across multiple designs? Buildroot hits its limits pretty quickly there. And Yocto really starts to shine. I worked at a company that used Buildroot to support 20 different boards, all in the same repo. The boards shared some level of common configuration across the whole repo, and groups of boards also shared some common configuration. The entire thing was managed by the C preprocessor as a pre-Buildroot step, and it was a gordian knot of emergent complexity. The catch is that Buildroot doesn't give you any tools to enable shared configuration, none at all. Buildroot doesn't know how to share build-products across multiple images, and doesn't even know how to _build_ multiple images or keep them separate without having to clean your workdir. It doesn't even track file dependencies, let alone configuration dependencies. It's terrible at knowing when a package is stale. Yocto is much, much better than Buildroot for handling these kinds of use cases. Images are just recipes, like any other kind of recipe. You can build 8 different images by just asking for each of them by name. Yocto won't rebuild anything that can be shared, and your images can be subclasses of each other which just add or remove a few packages or a bit of configuration. Yocto is also better at tracking/managing customizations. In Yocto, it's easy to express something like "use the upstream OpenSSH recipe, but do something custom for the config step, and add an extra post-build step, and add these 3 patches, but only add patch 3 on some designs, etc". In Buildroot, you have to do this in a global namespace using macro-processing in GNU Make. You have no control over the parse order of included Makefiles relative to the upstream files. It's messy and difficult to modify anything, and you have to understand each recipe's quirks and hooks. And the only programming language you have is GNU Make. In Yocto, there is an inheritance system that lets you use .bbappend files to override the behavior of any recipe you want. You can also stack multiple append files across different layers. If you need something exotic, you can express it as parse-time Python. Yocto is more complex up-front, but it pays off IMO.

na85 5y ago

>I have been doing embedded development for 30 years What's your take on the various *BSD distros in the embedded space? A lot of BSD proponents like to talk about the stability and minimalism (a proxy for resource-efficiency I guess) of BSD in comparison to Linux. Is there any reason to reach for BSD in an embedded application these days?

voakbasda 5y ago
The BSDs fall into the class of server/desktop systems. They would be a great choice for certain classes of products (e.g. routers) where there exists strong feature alignment, but not something I would consider suitable for producing my usual minimal custom embedded systems. Generally, esoteric hardware support also will be better in Linux, so BSD would likely require porting or writing more drivers when bringing up a custom board. That said, BSDs have not my strongest area, so I would be curious to see others’ experiences and opinions.