5 ms·

strategically, the selling of its ARM department was a big mistake, the x86-IoT obviously can not make up for that and take off. Intel has tried multiple times

by ausjke 9y ago

strategically, the selling of its ARM department was a big mistake, the x86-IoT obviously can not make up for that and take off. Intel has tried multiple times for the embedded market, so far not that great. I'm now watching the yocto project for what Intel is the main force behind, it is a bad idea(over engineered to say the least) with a few good people running it.

versale 9y ago
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/...
deleted 9y ago
[deleted]

by ausjke 9y ago

versale 9y ago

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/...

deleted 9y ago

[deleted]