"The Yocto Project (YP) is an open source collaboration project that helps developers create custom Linux-based systems regardless of the hardware architecture."
Though there was a related thread from 2018: https://news.ycombinator.com/item?id=18083506
Maybe I was using it wrong though. I think it’s a good idea.
That's a very mild way to express my feeling about it.
Maybe I'm asking too much, but Yocto/openembedded is the worst piece of software I've ever dealt with.
The build system is a huge pile of opaque and fragile scripts. It's so fragile, that if you don't put a space before a list of options, it would be concatenated with other options without a space, leading to incorrect options.
Because there are no lists, lists are just strings of space-separated words. Who needs proper data types?
There are no modularity either, everything is configured through strange variables with names like CONFIG_image_graphics_mesa_package=... God knows how this naming works.
Of course nothing is documented, and the discoverability is extremely low: everything is done through hundreds of opaque shell scripts, python scripts, half-baked python scripts for their build system.
The overall design of the build system is abysmally bad and fragile, and it's harder to get a notion how the things work than to just build everything with your own scripts.
Oh, and when something is wrong, build system just returns python stacktrace.
Is it that hard to use proper abstractions, data types, docstrings, introspection mechanisms so that everything would become transparent, obvious and sane?
And then the metadata is also funny, e.g. do_patch[depends] = "whatever:do_populate...". Variables are not just variables, they can contain metadata, sometimes important.
It feels like there are usage patterns, good practices and something more beautiful wanting to get out, but this is a domain where making a better build tool would break tons of recipes, so it feels like everytime they got a problem they added a quickfix and got forward without looking back.
The steep learning curve most of the time is unneeded, you are frenquently doing trivial to simple taks and hit one problem that gets you blocked for a while for things that you are easily able to do outside Yocto.
It is a shame that the good work they do is spoiled by the horrible "interface".
This is plain wrong. There is a whole bunch of manuals https://www.yoctoproject.org/docs/
And there are several books https://www.yoctoproject.org/learn/books/
Without understanding the philosophy behind the whole system and the recipe language just trying to "discover" something seems indeed mission impossible to me. Yes, the learning curve is steep. The recipe language is not always the least surprise if you don't understand it. On the other side, there is a lot of magic support in the system. If you know what you are doing writing recipes for new packages does not require much code.
Ah, yeah, the manual. I forgot another abysmally bad part of Yocto: the manual.
Yocto documentation is the single worst documentation I've ever dealt with. It's a huge giant wall of text which tells you... nothing concrete whatsoever.
Wanna know how to change an image fs or image format? Go figure with the manual, just look at these entries:
So concise, but even more useless. Which filesystems could I use? How to know that? Ah, don't bother.
The whole manual is a huge wall of text telling you what classes, tasks, recipes and dozens of other overengineered concepts are, but nothing about how to use them beyond the basic examples. Wanna build an fs for the device with a local storage and external ssd, good luck to figure out how: decoupling where machine starts and image ends, and which part should you modify.
> Without understanding the philosophy behind the whole system and the recipe language just trying to "discover" something seems indeed mission impossible to me.
Yeah, it's hard to introspect something which have dozens of concepts, yet no other form of introspection but file reading.
And I'm fine with file reading, but with yocto half of important stuff is concealed within the build system, leaving just strange config variables and gluing scripts on the surface, making it incomprehensible for a sane person.
git grep IMAGE_FSTYPES
I'm very far from claiming that Yocto is easy to understand. But you get much more than you pay for. What alternatives do you suggest with a similar functionality?
Do you think the Linux kernel documentation is better? The systemd source code easy to grasp? Still, they are widely used. I tend to say the price you pay for those is that you need to employ an expert and the expert needs to spend quite some time on it.
If you buy a product you are entitled to request something from your vendor. Good luck if you are a small company. I even tried when working for a 50,000 people corporation in the past and we got very little after many years of paying huge fees.
In open source it's take it or leave it. Preferably take it and contribute to make it better.
I never had to do anything even closely similar. My embedded systems have just one rootfs.
I would start looking here https://www.yoctoproject.org/docs/3.0/mega-manual/mega-manua...
Buildroot a great project with clear goals and good execution. Yocto is flexible to a fault, which makes it a lot more complex. But with that complexity comes a lot of power and fine-grained control over your builds.
Gentoo is quite intuitive by comparison.
Yocto is the wrong tool if you're looking for a good developer Linux. It's a great tool if you're looking for a way to make a highly customized Linux image. It provides good reproducibility and strict license mechanisms to make sure you don't run afoul of anybody's open-source license. It also provides you with tools to compile and include your own recipes, and easy ways to modify upstream recipes without needing to fork the Yocto repos.
Yocto is just another "The S in IOT stands for security" kind of problem.
I concur. I've tried Yocto, was appalled by it. Then I've taken Centos 8, and it was a breeze to build for it, safe for some minor troubles.
I would choose Centos/opensuse/fedora/custom distro over Yocto anytime.
I worked on Yocto for two years, it is over-engineered _a_ _lot_ to say the least.
The BSP companies like it though, my theory is that, since Yocto is so complex(unnecessarily), only them can solved the problem for clients.
It's a worse case comparing to gentoo for embedded space. Just use buildroot to bring up your board, much simpler and faster with top class documentation.
I also think Yocto is mainly an advantage for BSP vendors, but I think where the benefits might offset the complexity is when managing lots of client specific variations and adaptations for the same base BSP.
Yocto is, well, "acceptable" once you get the hang of it but I definitely get where the sentiment is coming from.
At least buildroot isn't that stupid, although of course it is still stuck in "recursive Makefile" hell.
> The minimal recipe provides an image with the least number of packages to be a bootable image
Here is what it is building, incomplete list, for install to the target rootfs:
- libx11, libxau, libxcb, libxcrypt, libxdmcp, libxrandr, libxrender, glib-2.0, "gnome-desktop-testing", gperf, openssl, perl, pixman, libsdl2, python3, sqlite3, various xorg-..
This isn't even the freaking desktop image! Also, no, sorry, no more Hob, that is now deprecated in favor of a django webinterface (Toaster).
If you are building a software image for an embedded device and you don't know every package that is going into it and why it is there, you need to stop. Look to the Android AOSP for what it takes - an in-depth understanding of the toolchain, strict choices for compilers and libc (none of this clang-experimental and your choice of uclibc, musl, glibc), stringent standards across the entire body of code you are compiling - no "uh this doesn't compile with PIE and hardening, just hack the CFLAGS". And there are ton more lessons there.
I wanted to give yocto a chance but after a week of getting nowhere I want to be with it, I turned back to buildroot.
I have shipped products with both buildroot and Yocto and I have to say I have fully moved over to Yocto now. Adding things like OTA are trivial, and I can inject extra tasks for enforcing rules or extracting license meta-data. But being able to create real packages is huge when you have a larger system and just want to test the new version of an application. With buildroot I have to manually copy the files around. Same thing if I want to add gdbserver, you cannot create a package repo to pull from you have to rebuild the whole image.
Buildroot really isn’t bad but it’s not totally solid and it’s not hard to mess it up either by not thinking or not reading the documentation.
Changing the config and rebuilding without cleaning is the most obvious thing although the docs explicitly tell you not to do that so that doesn’t really count.
Certain compiler build settings can result in a failed build.
It’s really only meant to be used for making cross compilers anyway and the root image generation is a sometimes useful thing. Personally if I want a rootfs it’s easy enough to make one from scratch.
Our CI system generates the SDK along with every build of our Yocto image. Another CI job grabs the SDK and uses it for some out-of-tree compilation work. It's very straightforward to automate that way.
From a CI system's point of view, what's the logical difference between [tar xf toolchain.tar.gz] and [./install_sdk.sh -yd .]?
Keep up the good work! Yocto is an amazing project, and I'm a heavy-user in my day job.
https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfI... is an attempt to help.
Disclaimer: I have not watched them yet.
Pretty sure I would have spent at least 10x more time building my own image from scratch.
"BitBake" is easy -- that's the command you run to rebuild "BitBake recipes" (a recipe is something like a Makefile, except that it's more "meta" -- it defines what to run in order to build software packages, i.e. how to find and build a source directory that may have Makefiles/CMakeLists/whathaveyou in it -- so I think it's a bit like e.g. an RPM spec file). So you run stuff like 'bitbake -c clean packagename' or 'bitbake -C compile packagename'. (BTW, I often want to do things in a single command -- is that possible? Reloading the whole cache every time gets old after a while.)
Fine okay, "Yocto" is presumably the name of the entire project. But what's Poky?
> Poky is a reference distribution of the Yocto Project®. It contains the OpenEmbedded Build System (BitBake and OpenEmbedded Core) as well as a set of metadata to get you started building your own distro.
Hrm, what's OpenEmbedded Core?
> OpenEmbedded-Core is a layer containing the core metadata for current versions
of OpenEmbedded. It is distro-less (can build a functional image with DISTRO = "nodistro") and contains only emulated machine support.
Hrm, okay. (BTW, for the people who don't know -- "metadata" most likely refers to a collection of "BitBake" recipes (i.e. a directory containing loosely related BitBake recipes), so the "core metadata" would likely be the recipe for at least the Linux kernel.) (BTW2, in BitBake, you customize recipes using "layers". The first layer contains recipes that build things in a generic way, and then you add other "layers" that contain "bbapend" files that override variables or commands in the lower-layer recipes to build something the way you need it.)
Okay, so is the "OpenEmbedded Build System" still part of the Yocto project? From Wikipedia: "BitBake is co-maintained by the Yocto Project and the OpenEmbedded project." Okay, that explains that a bit. But why are they separate in the first place?
Why does "Poky" have such a weird name, and what kind of recipes does it bring to the table? Looking at the repository (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta), that's quite a lot of useful packages.
One other question that just popped up in my mind: are there any Desktop Linux distros that use this as their build system?
When you "use yocto", you're likely just using parts of the OpenEmbedded project. Yocto takes all the flexibility of the OpenEmbedded project and packages together a functional setup (called Poky) that can be more easily customized to build custom images. (There are non-poky, non-openembedded components of yocto, but I'm not familiar with them).
The default packages shipped with Poky are I suspect just the minimal set required to get a network connected device with a GUI interface up. Remember that it's default setup is effectively suppose to be a "hello world" project.
I don't think so and I think that is not the goal of the project. It is more like a build system to meet the requirements of "I need to build a set of packages for architecture X and additionally a host SDK and a deployable system image", so it lets you whip up a recipe with your requirements and off you go.
The pronunciation is even more weird: "Pock-ee"
"Poky" in English means "small". The idea being that the distro is engineered to build small OS images for small embedded devices.
> It's located in a pokey little village in the middle of damn near nowhere.
Sure, but that doesn't mean "slow slow". The poke part of that that means something similar to "yoke".
A slowpoke is something that's slow and dragging you down with it.
Pocky is a brand of chocolate coated bisquit sticks. (Not very international, I have not seen them.) But using a trademarked (I assume) name might end up in trouble, so they changed the spelling but kept the pronunciation.