9 ms·

Whereas using Yocto is a long process of learning how it works to make your first build, and then learning again when you want to update some dependencies.

gallexme 6y ago
Afaik yocto is the go to when u need to manually specify every version and have everything in ur hands Took my boss like 2 months to get lamp stack fully working Or need deeper customizations / very special operating systems
- swiley 6y ago
  idk it's pretty easy to patch buildroot to customize the packages. At this point my go to for image creation is guix though.
  - gallexme 6y ago
    Does guix build for any embedded ish devices? Like u-boot+ custom dtb's kernel etc? Mmh I should have a look at how guix n nixos support rpi and similar devices, maybe it's adaptable
    - bfrog 6y ago
      Nix is very much customizable, at every level. It's also in my experience much much faster than bitbake and friends.
    - swiley 6y ago
      Yes, see the recent changes to the guix system image command (the info/web pages haven't been updated for it quite yet.)
ephaeton 6y ago
This is true. Plus add debug bitbake, and debugging (or ignoring) broken caching, missing make semantic (delete a result artifact and see bitbake claim there's nothing to do) and generally causing a massive head-ache. But ... it has all the hooks you need, and even if it's a particularly ugly and broken behemoth, you can slowly steer it roundabout in the direction you want it to go. yocto also has more apes hitting the typewriter, so in some distant future it might even be sensible. My colleagues have evaluated buildroot vs. yocto several times, only to end up in yocto each time. I stopped challenging them: Once you have to hook into the build process in various places and implement your "around" hooks, yocto, while still sucking, and still standing in your way, and still pointing every gun there is at your feet ... doesn't make it impossible to achieve your goal without rewriting the whole thing. Also you can make more money with using a complicated, shiny tool, of course. NB: I'm using yocto professionally for three years now after a decade of experience in cross-building embedded targets using NetBSD. It is no joy (in contrast to NetBSD). If you don't have a problem that involves rewriting half of buildroot, choose buildroot :D
codethief 6y ago
FWIW we recently started using the Yocto-based BalenaOS[0] in our project and have been rather happy with it because we get to focus on developing and running our software and don't have to bother with the low-level hardware stuff too much. Unfortunately, as we're getting closer to shipping our product, we've realized that Balena seems to be rather cavalier when it comes to respecting software licenses. They offer pre-built .img files and Docker base images but don't provide a comprehensive list of licenses (let alone the source code) of third-party software components anywhere, as this issue[1] attests to. I'm currently talking to one of their customer service representatives and, as of this morning (when they sent me another email), they don't even acknowledge that this is an issue. Looks like we'll now have to compile this list on our own. :\ [0]: https://www.balena.io/os https://www.balena.io/os [1]: https://github.com/balena-os/meta-balena/issues/1955 https://github.com/balena-os/meta-balena/issues/1955
- ephaeton 6y ago
  I don't know BalenaOS, but if it's yocto based, using this bbclass might help you out: https://gist.github.com/weber-martin/fa9ca5bdceffc9504175f6e629571f06 https://gist.github.com/weber-martin/fa9ca5bdceffc9504175f6e... add "extra_license" to your IMAGE_CLASSES_append in your (machine, distro) config. add EXTRA_COPY_LIC_ROOTFS = "1" to your liking. You will end up with a directory of licenses, including license texts, of the packages you have in your image. Yeah you will have to build your image yourself, but isn't that $trivial with yocto (FSVO $trivial ?)
  - codethief 6y ago
    Thanks so much, I will look into this! :)
bradfa 6y ago
Coming from spending a lot of time working in OpenEmbedded build systems to now trying to work in buildroot has been quite painful and annoying for me. Buildroot lacks a LOT of the features and capabilities which OE and bitbake offer. Possibly I am just not familiar enough yet with buildroot, or I just am too stuck in thinking how OE/bitbake work, but I much prefer working with OE/bitbake over using buildroot in a professional context. Yes, OE/bitbake have a MUCH steeper learning curve once you get past the "hello world" level of examples. But once you're trying to do somewhat complicated things, I have found OE/bitbake to be amazingly flexible and easy to customize.
- varjag 6y ago
  No you have it exactly right, Yocto is a lot less pain unless you just configure your vendor's default BSP.
  - bradfa 6y ago
    I've never found vendor provided OE BSP layers to be easy to use or useful beyond initial proof-of-concept type work. In general, hardware vendor provided software has sucked greatly in my experience. Taking the vendor provided thing and then removing a lot of the junk, or taking the upstream software project and then selectively cherry-picking some key changes which the vendor has made works pretty well. But this isn't a fast process and requires quite a bit of education about how/why the vendor has done things a certain way and how the upstream open source code in question works. But long term it's been a much better solution for the projects I've worked on when I've been able to do this.
    - varjag 6y ago
      I'm not saying vendor BSPs are easier or harder to use in OE, but that OE is a lot easier if you do extensive modifications. And especially if you have a family of related products.
fullstop 6y ago
I used buildroot since 2011 and yocto since 2019. Both have their strengths, and their weaknesses, but I actually prefer yocto now since it is more predictable in what it builds. Buildroot is faster to launch and run, but I'm infinitely more confident that everything will build again after cleaning with Yocto than I am with buildroot because Yocto creates a sysroot for each recipe which contains only the specified dependencies, unlike buildroot which contains whatever has been installed into "target" by that point in the build process. This is even more troublesome when using multiple cores to build since the state of "target" is changing rapidly based on how quickly different packages are able to be built and installed. Yocto is slow and bitbake can be a pain until you get it, but it's really an amazing thing once you understand it and can leverage what it has to offer. Layers are wonderful if you need to support multiple devices which share a common base. By using a shared state cache, I can have other developers building complete images in minutes rather than hours. I am happy that I took the time to learn how to use Yocto, even after having a good experience with buildroot.
- ephaeton 6y ago
  I concur with your technical argument, except for the trust of what's being built. I have repeatedly found the shared state cache to be the achilles heel of my builds. You never want to have a false-positive hit in your cache, yet yocto has repeatedly bit me with that. I have had instances where bitbake claimed it was done, just to find wrong or missing artifacts in my image. Cleaning and rebuilding from scratch is a continuous exercise that's IME sadly necessary. ...let alone letting others use my build directories! I accept yocto's right to exist, but I'm far from being happy for using it.
  - fullstop 6y ago
    I don't want to be the person who says "you're doing it wrong", but you probably are doing something wrong. I've been using this for quite a while and have never had to clean the world to get things straightened out, or had a false positive in the cache. One thing that I had to do, however, was run bitbake-hashserv when running the shared state cache. Even so, this was because I was getting cache misses. If I may ask, what are you doing when it claims to be done but things aren't in a good state? If you're deleting files / directories manually instead of using bitbake commands you're going to have a bad time.
varjag 6y ago
If there is one main reason Yocto very much won over Buildroot in production use, it's the ease of managing dependencies. (started with crosstools in mid-00s myself, used buildroot for better half of a decade)

gallexme 6y ago

Afaik yocto is the go to when u need to manually specify every version and have everything in ur hands Took my boss like 2 months to get lamp stack fully working Or need deeper customizations / very special operating systems

swiley 6y ago
idk it's pretty easy to patch buildroot to customize the packages. At this point my go to for image creation is guix though.
- gallexme 6y ago
  Does guix build for any embedded ish devices? Like u-boot+ custom dtb's kernel etc? Mmh I should have a look at how guix n nixos support rpi and similar devices, maybe it's adaptable
  - bfrog 6y ago
    Nix is very much customizable, at every level. It's also in my experience much much faster than bitbake and friends.
  - swiley 6y ago
    Yes, see the recent changes to the guix system image command (the info/web pages haven't been updated for it quite yet.)

ephaeton 6y ago

This is true. Plus add debug bitbake, and debugging (or ignoring) broken caching, missing make semantic (delete a result artifact and see bitbake claim there's nothing to do) and generally causing a massive head-ache. But ... it has all the hooks you need, and even if it's a particularly ugly and broken behemoth, you can slowly steer it roundabout in the direction you want it to go. yocto also has more apes hitting the typewriter, so in some distant future it might even be sensible. My colleagues have evaluated buildroot vs. yocto several times, only to end up in yocto each time. I stopped challenging them: Once you have to hook into the build process in various places and implement your "around" hooks, yocto, while still sucking, and still standing in your way, and still pointing every gun there is at your feet ... doesn't make it impossible to achieve your goal without rewriting the whole thing. Also you can make more money with using a complicated, shiny tool, of course. NB: I'm using yocto professionally for three years now after a decade of experience in cross-building embedded targets using NetBSD. It is no joy (in contrast to NetBSD). If you don't have a problem that involves rewriting half of buildroot, choose buildroot :D

codethief 6y ago

FWIW we recently started using the Yocto-based BalenaOS[0] in our project and have been rather happy with it because we get to focus on developing and running our software and don't have to bother with the low-level hardware stuff too much. Unfortunately, as we're getting closer to shipping our product, we've realized that Balena seems to be rather cavalier when it comes to respecting software licenses. They offer pre-built .img files and Docker base images but don't provide a comprehensive list of licenses (let alone the source code) of third-party software components anywhere, as this issue[1] attests to. I'm currently talking to one of their customer service representatives and, as of this morning (when they sent me another email), they don't even acknowledge that this is an issue. Looks like we'll now have to compile this list on our own. :\ [0]: https://www.balena.io/os https://www.balena.io/os [1]: https://github.com/balena-os/meta-balena/issues/1955 https://github.com/balena-os/meta-balena/issues/1955

ephaeton 6y ago
I don't know BalenaOS, but if it's yocto based, using this bbclass might help you out: https://gist.github.com/weber-martin/fa9ca5bdceffc9504175f6e629571f06 https://gist.github.com/weber-martin/fa9ca5bdceffc9504175f6e... add "extra_license" to your IMAGE_CLASSES_append in your (machine, distro) config. add EXTRA_COPY_LIC_ROOTFS = "1" to your liking. You will end up with a directory of licenses, including license texts, of the packages you have in your image. Yeah you will have to build your image yourself, but isn't that $trivial with yocto (FSVO $trivial ?)
- codethief 6y ago
  Thanks so much, I will look into this! :)

bradfa 6y ago

Coming from spending a lot of time working in OpenEmbedded build systems to now trying to work in buildroot has been quite painful and annoying for me. Buildroot lacks a LOT of the features and capabilities which OE and bitbake offer. Possibly I am just not familiar enough yet with buildroot, or I just am too stuck in thinking how OE/bitbake work, but I much prefer working with OE/bitbake over using buildroot in a professional context. Yes, OE/bitbake have a MUCH steeper learning curve once you get past the "hello world" level of examples. But once you're trying to do somewhat complicated things, I have found OE/bitbake to be amazingly flexible and easy to customize.

varjag 6y ago
No you have it exactly right, Yocto is a lot less pain unless you just configure your vendor's default BSP.
- bradfa 6y ago
  I've never found vendor provided OE BSP layers to be easy to use or useful beyond initial proof-of-concept type work. In general, hardware vendor provided software has sucked greatly in my experience. Taking the vendor provided thing and then removing a lot of the junk, or taking the upstream software project and then selectively cherry-picking some key changes which the vendor has made works pretty well. But this isn't a fast process and requires quite a bit of education about how/why the vendor has done things a certain way and how the upstream open source code in question works. But long term it's been a much better solution for the projects I've worked on when I've been able to do this.
  - varjag 6y ago
    I'm not saying vendor BSPs are easier or harder to use in OE, but that OE is a lot easier if you do extensive modifications. And especially if you have a family of related products.

fullstop 6y ago

I used buildroot since 2011 and yocto since 2019. Both have their strengths, and their weaknesses, but I actually prefer yocto now since it is more predictable in what it builds. Buildroot is faster to launch and run, but I'm infinitely more confident that everything will build again after cleaning with Yocto than I am with buildroot because Yocto creates a sysroot for each recipe which contains only the specified dependencies, unlike buildroot which contains whatever has been installed into "target" by that point in the build process. This is even more troublesome when using multiple cores to build since the state of "target" is changing rapidly based on how quickly different packages are able to be built and installed. Yocto is slow and bitbake can be a pain until you get it, but it's really an amazing thing once you understand it and can leverage what it has to offer. Layers are wonderful if you need to support multiple devices which share a common base. By using a shared state cache, I can have other developers building complete images in minutes rather than hours. I am happy that I took the time to learn how to use Yocto, even after having a good experience with buildroot.

ephaeton 6y ago
I concur with your technical argument, except for the trust of what's being built. I have repeatedly found the shared state cache to be the achilles heel of my builds. You never want to have a false-positive hit in your cache, yet yocto has repeatedly bit me with that. I have had instances where bitbake claimed it was done, just to find wrong or missing artifacts in my image. Cleaning and rebuilding from scratch is a continuous exercise that's IME sadly necessary. ...let alone letting others use my build directories! I accept yocto's right to exist, but I'm far from being happy for using it.
- fullstop 6y ago
  I don't want to be the person who says "you're doing it wrong", but you probably are doing something wrong. I've been using this for quite a while and have never had to clean the world to get things straightened out, or had a false positive in the cache. One thing that I had to do, however, was run bitbake-hashserv when running the shared state cache. Even so, this was because I was getting cache misses. If I may ask, what are you doing when it claims to be done but things aren't in a good state? If you're deleting files / directories manually instead of using bitbake commands you're going to have a bad time.

varjag 6y ago

If there is one main reason Yocto very much won over Buildroot in production use, it's the ease of managing dependencies. (started with crosstools in mid-00s myself, used buildroot for better half of a decade)