5 ms·

I'd love to know more on why Yocto is a bad idea and what could be an alternative. no sarcasm.

gvb 9y ago
An alternative (very popular) is buildroot https://en.wikipedia.org/wiki/Buildroot https://en.wikipedia.org/wiki/Buildroot
- versale 9y ago
  Why buildroot is better? I need some substance to present to get rid of Yocto, but I fail to verbalize my gut feelings.
  - gvb 9y ago
    I did not say it was better, I said it was very popular (I even weaseled on that - I did not say it was "most popular" because I don't know that). Better is a relative term and may be different between your use case and mine. I found the LWN article to be very useful: https://lwn.net/Articles/682540/ https://lwn.net/Articles/682540/ The full "wisdom" of the internet: https://www.google.com/search?q=buildroot+vs+yocto https://www.google.com/search?q=buildroot+vs+yocto
    - versale 9y ago
      Thanks! The article is useful indeed. It seems like people tend to say Yocto is a bad idea, but that's just their gut feelings (and mine as well) with no substance in it except yocto's complexity.
      - minipci1321 9y ago
        I have been trying to answer to myself the same question as you are, and below my personal experience of learning-curve climber: -- Yocto is complex without giving you anything much back in exchange. Pathnames are longer, directory names are counter-intuitive and do not emphasize the main task of a developer/integrator: work with the source code. Probably more bearable if one only checks out the whole tree, starts the build and go on lunch... but then comes the next item: -- Yocto is more resource demanding (again, personal, compared to some systems I used before): more memory, more CPU cores for the builder VM, more storage -- for the same build we did before. -- Yocto fails its promise to decouple the delivery from the FOSS sofgtware: every once in a while, a public repo goes offline, and angry customers call back. One still has to deal with the public repos you pull into the build, no matter what yocto advocates told you -- might as well copy it into the tree already. Buildroot suffers from some of the above as well (my BR experience dates from ~5 years ago, I am not a fan of it). On the flip side, Yocto is probably cleaner than buildroot for cross-building. It could also be easier in including new components into the build, haven't tried that. Over time, I worked out some personal indicators I use to gauge the building/versioning harness: -- how many macros and environment variables the makefiles / scripts / receipes contain and refer to. The lesser is the better; -- how easily I can navigate in the source code: how long pathnames, how much typing to go to another source file; how many additional pulls/checkouts/fetches/unpacks are required. etc. -- how "cross-clean" building it is: all required host-, target- and cross- tools need to live inside the same tree, and be built during the main build if necessary. Having a mandatory separate VM is usually an o_O sign.
        gvb 9y ago
        FWIW, buildroot now has the ability to build a complete cross build environment (I've used ARM and PowerPC). This is a configuration option: buildroot's cross or an external cross build environment. Buildroot does the Right Thing: all the required host-, target- and cross- tools need to live inside the same tree. This includes the option to build lib_.a (non-shared) cross libraries on the host, statically link against them for the target executable, and only install the target executable on the target installation (no carrying lib_.a baggage on the target file system). I've created a couple of simple buildroot packages and it was nearly trivial. The buildroot preference is touse cmake for the package build support - I went with that and was very happy with the level of effort required (low!).
Zigurd 9y ago
Yocto is not a bad idea in a vacuum. But Yocto doesn't have a good hardware platform for low cost IoT, so it is limited to a narrow category where Intel's mainstream CPUs can play. And to the slice of that market that won't go to Microsoft's IoT variant of Windows, nor to Android Things. I doubt there will be, for example, a Yocto-based car infotainment system.
- versale 9y ago
  As an example BMW is working on one http://events.linuxfoundation.org/sites/events/files/slides/elce-2016-mario-goulart-mikko-rapeli.pdf http://events.linuxfoundation.org/sites/events/files/slides/...
- sriram_sun 9y ago
  Automotive Grade Linux is a Yocto based distro for exactly that. I even saw job postings on LinkedIn for "AGL experience!" After I dug in a little bit, I found that it was just built on top of Yocto/OE. http://docs.automotivelinux.org/docs/getting_started/en/dev/reference/source-code.html http://docs.automotivelinux.org/docs/getting_started/en/dev/...

gvb 9y ago

An alternative (very popular) is buildroot https://en.wikipedia.org/wiki/Buildroot https://en.wikipedia.org/wiki/Buildroot

versale 9y ago
Why buildroot is better? I need some substance to present to get rid of Yocto, but I fail to verbalize my gut feelings.
- gvb 9y ago
  I did not say it was better, I said it was very popular (I even weaseled on that - I did not say it was "most popular" because I don't know that). Better is a relative term and may be different between your use case and mine. I found the LWN article to be very useful: https://lwn.net/Articles/682540/ https://lwn.net/Articles/682540/ The full "wisdom" of the internet: https://www.google.com/search?q=buildroot+vs+yocto https://www.google.com/search?q=buildroot+vs+yocto
  - versale 9y ago
    Thanks! The article is useful indeed. It seems like people tend to say Yocto is a bad idea, but that's just their gut feelings (and mine as well) with no substance in it except yocto's complexity.
    - minipci1321 9y ago
      I have been trying to answer to myself the same question as you are, and below my personal experience of learning-curve climber: -- Yocto is complex without giving you anything much back in exchange. Pathnames are longer, directory names are counter-intuitive and do not emphasize the main task of a developer/integrator: work with the source code. Probably more bearable if one only checks out the whole tree, starts the build and go on lunch... but then comes the next item: -- Yocto is more resource demanding (again, personal, compared to some systems I used before): more memory, more CPU cores for the builder VM, more storage -- for the same build we did before. -- Yocto fails its promise to decouple the delivery from the FOSS sofgtware: every once in a while, a public repo goes offline, and angry customers call back. One still has to deal with the public repos you pull into the build, no matter what yocto advocates told you -- might as well copy it into the tree already. Buildroot suffers from some of the above as well (my BR experience dates from ~5 years ago, I am not a fan of it). On the flip side, Yocto is probably cleaner than buildroot for cross-building. It could also be easier in including new components into the build, haven't tried that. Over time, I worked out some personal indicators I use to gauge the building/versioning harness: -- how many macros and environment variables the makefiles / scripts / receipes contain and refer to. The lesser is the better; -- how easily I can navigate in the source code: how long pathnames, how much typing to go to another source file; how many additional pulls/checkouts/fetches/unpacks are required. etc. -- how "cross-clean" building it is: all required host-, target- and cross- tools need to live inside the same tree, and be built during the main build if necessary. Having a mandatory separate VM is usually an o_O sign.
      - gvb 9y ago
        FWIW, buildroot now has the ability to build a complete cross build environment (I've used ARM and PowerPC). This is a configuration option: buildroot's cross or an external cross build environment. Buildroot does the Right Thing: all the required host-, target- and cross- tools need to live inside the same tree. This includes the option to build lib_.a (non-shared) cross libraries on the host, statically link against them for the target executable, and only install the target executable on the target installation (no carrying lib_.a baggage on the target file system). I've created a couple of simple buildroot packages and it was nearly trivial. The buildroot preference is touse cmake for the package build support - I went with that and was very happy with the level of effort required (low!).

Zigurd 9y ago

Yocto is not a bad idea in a vacuum. But Yocto doesn't have a good hardware platform for low cost IoT, so it is limited to a narrow category where Intel's mainstream CPUs can play. And to the slice of that market that won't go to Microsoft's IoT variant of Windows, nor to Android Things. I doubt there will be, for example, a Yocto-based car infotainment system.

versale 9y ago
As an example BMW is working on one http://events.linuxfoundation.org/sites/events/files/slides/elce-2016-mario-goulart-mikko-rapeli.pdf http://events.linuxfoundation.org/sites/events/files/slides/...
sriram_sun 9y ago
Automotive Grade Linux is a Yocto based distro for exactly that. I even saw job postings on LinkedIn for "AGL experience!" After I dug in a little bit, I found that it was just built on top of Yocto/OE. http://docs.automotivelinux.org/docs/getting_started/en/dev/reference/source-code.html http://docs.automotivelinux.org/docs/getting_started/en/dev/...