3 ms·

The Yocto package format supports a mix of inheriting BitBake package files, Bash and Python. It's over-engineered and unpleasant. Values can easily be defined

The Yocto package format supports a mix of inheriting BitBake package files, Bash and Python. It's over-engineered and unpleasant. Values can easily be defined 3 or 4 layers away from the file you are looking at, either in one of the many configuration files (that can be overridden by other configuration files), or in one of the files the package is inheriting from. Add clunky and unintuitive tools to the mix, and Yocto can easily be an unpleasant experience, at least for teams over a certain size. It does make switching between architectures really easy and sweet, though, but that's about it.

iBelieve 8y ago
I'm currently using Yocto for an embedded Linux project, and agree that it just feels so overly complicated for what we're using it for. I've written packages for Arch Linux in the past, and that's a breeze compared to writing bitbake recipes. The ability to modify existing recipes through append files is nice, but that seems like it could be handled in a normal distro just by forking a package and making changes.
woodrowbarlow 8y ago
i recommend anybody who shares this opinion should take a look at buildroot as an alternative. if you've ever configured and built the linux kernel, you'll feel right at home with buildroot's approach to configuring and building an entire filesystem image.
codetrotter 8y ago
Having just found Yocto yesterday and built my first custom image that I made by extending the layer in the OP, I am not yet "married to" Yocto. Yocto initially appeared to be exactly what I was looking for. When someone else raised concerns about Yocto ITT I somewhat brushed them off, mainly because they were talking about managing the layers on a headless system. I used Yocto from the command-line on my workstation, so a) I am not on a headless system and b) even if I was doing this on a headless server, everything I have done so far would be done exactly the same way. But, since then, multiple other people have raised concerns about Yocto. I also talked to one of the mods on /r/raspberry_pi and they said something similar. I looked through some past discussions about Yocto on /r/raspberry_pi using the search feature on Reddit, and found a couple of other similar experiences. After looking through what has been said, I find that these concerns resonate with me rather deeply. They are all pointing to a single sentiment that seems to be rooted in similar real-world experiences; Yocto makes things complicated in a way that with time will make managing things needlessly complex and which will result in a lot of wasted time. I was still a bit inclined to think though that perhaps these experiences were had long enough ago that Yocto has since improved, but after a little bit of further thought I realized that fundamentally Yocto is engineered in the fashion that you and others are pointing to as being a fundamental flaw of the system. I am going to try Buildroot instead. Same guy that wrote the post I shared in the OP also made a post about using Buildroot. https://jumpnowtek.com/rpi/Raspberry-Pi-Systems-with-Buildroot.html https://jumpnowtek.com/rpi/Raspberry-Pi-Systems-with-Buildro...

iBelieve 8y ago

I'm currently using Yocto for an embedded Linux project, and agree that it just feels so overly complicated for what we're using it for. I've written packages for Arch Linux in the past, and that's a breeze compared to writing bitbake recipes. The ability to modify existing recipes through append files is nice, but that seems like it could be handled in a normal distro just by forking a package and making changes.

woodrowbarlow 8y ago

i recommend anybody who shares this opinion should take a look at buildroot as an alternative. if you've ever configured and built the linux kernel, you'll feel right at home with buildroot's approach to configuring and building an entire filesystem image.

codetrotter 8y ago

Having just found Yocto yesterday and built my first custom image that I made by extending the layer in the OP, I am not yet "married to" Yocto. Yocto initially appeared to be exactly what I was looking for. When someone else raised concerns about Yocto ITT I somewhat brushed them off, mainly because they were talking about managing the layers on a headless system. I used Yocto from the command-line on my workstation, so a) I am not on a headless system and b) even if I was doing this on a headless server, everything I have done so far would be done exactly the same way. But, since then, multiple other people have raised concerns about Yocto. I also talked to one of the mods on /r/raspberry_pi and they said something similar. I looked through some past discussions about Yocto on /r/raspberry_pi using the search feature on Reddit, and found a couple of other similar experiences. After looking through what has been said, I find that these concerns resonate with me rather deeply. They are all pointing to a single sentiment that seems to be rooted in similar real-world experiences; Yocto makes things complicated in a way that with time will make managing things needlessly complex and which will result in a lot of wasted time. I was still a bit inclined to think though that perhaps these experiences were had long enough ago that Yocto has since improved, but after a little bit of further thought I realized that fundamentally Yocto is engineered in the fashion that you and others are pointing to as being a fundamental flaw of the system. I am going to try Buildroot instead. Same guy that wrote the post I shared in the OP also made a post about using Buildroot. https://jumpnowtek.com/rpi/Raspberry-Pi-Systems-with-Buildroot.html https://jumpnowtek.com/rpi/Raspberry-Pi-Systems-with-Buildro...