Do not use Yocto or OpenEmbeded
In short
I do not like common embedded "solutions" like OpenEmbeded, Yocto, or their predecessors.
They are most of the time a problem, not a solution, and hide all the interesting parts behind complex build systems and tend to promote the wrong approach to embedded systems (from my point of view at least).
I'll try to explain why here.
Inconsistency
Or "Don't do it ... but we're doing it anyway".
Most of these solutions states that it's not possible (which is false) or not a good idea (false too) to use common distributions on embedded systems.
But as it's impossible for users to continuously update their systems by rebuilding everything each time or continuously track all their tools and packages for security or stability issues, they finally ... reproduce exactly the same kinds of mechanisms, creating new distributions ....
Impossible to maintain
As I partly exposed in the previous point, when you use one of the common image builder solutions, you have to take care of tracking security patches, fixes, or any kind of upgrades.
You must endorse the role of the software packagers from the distribution and make sure each version of each library is supported by each software, and so on.
In common distributions, this job is made by the package maintainers, and most of the time shared among many distributions.
When using common distributions, security issues are reported by the whole community, and fixed quite quickly.
When using a custom system, built by you, used only by you, you're the only one performing tests, no one helps you. You're out of the community, on your own.
Hiding information and knowledge
The sets of scripts used to build the system tends to become a mess of hundreds of chunks, overriding one another for the sake of modularity, and making it very complicated to identify the source of failure when the process fails.
The end user doesn't know how things are done, it becomes some kind of magic, and knowledge is kept hidden, which is the opposite of the open-source philosophy.
This goes up to a point where even "professionnals" do not know what they are doing, and provide a Yocto Board Support Package (BSP) only because they have to (because all the others are doing it), but include links to unbundled binaries within their packages or worse, provide multiple compilers which are in fact only links to a single one, making the results unusable.
Huge amount of disk space used
Each BSP tends to download sources for everything, including the cross-compilation toolchain when it's not badly bundled as binaries, and build everything from sources, which results in huge directories of tens of GigaBytes (or hundreds of them) while the whole project should fit in barely more than a few hundred Megabytes.
Not using distribution provided tools
Many of theses solutions either rebuild most of the tools or bundle binaries (and associated libraries) for them, while these tools are available in most common distributions.
The problem is that those tools are out of the distribution packaging process, and will not receive fixes or improvements.
If the tools from common distributions lack some specific functionality or have bugs, then the right way to do it is to help fix or improve existing, bundled tools, not get out of the distribution path and start doing things on the sideways.
(Bad) Experiences
Of course, I also have a few (lot ?) of bad experiences with these tools.
Even if I managed to use them once or twice (OpenWRT on a WRT54GL ... and that's the only one !) I have had many problems with these tools. They range from impossibility to reproduce the same result on different computers, to impossibility to make changes as it broke the whole build process.
Conclusion
The problem is that I'm not the only one experiencing these problems.
But what's bad is that rather than going back to common "old" working solutions and writing tutorials or sharing knowledge, people know bundle their whole mess in containers in order to "make it easier to reproduce and share".
That's not sharing, that's obfuscating.
Sad.