My experience is that Yocto is a bit like CMake: people hate the mess they make with it and blame the system, even though they never bothered learning to use it.
When someone starts with "why cross-compiling the system if it's bearable to compile it directly on the device?", it really sounds like they are just not comfortable with cross-compilation. To me it would be similar to say "why would you need a compiled language, with this weird compilation step that nobody understands, when you can just write in an interpreted language?". Except that developers wouldn't generally proudly admit that they don't know how to use a compiler.
A valid reason I see to require a new embedded linux build system would be if the existing ones (mostly buildroot and Yocto) were unable to build a modern OS (e.g. by not being able to integrate some security features). But I don't think that's the case. This article sounds more like very verbose marketing for a system claiming that it can do similarly without having to learn as much (which I honestly doubt).
To me it's often the same pattern:
* Meson is nice, but it doesn't remove the need to use CMake, and it's not fundamentally simpler or more powerful (it's more comfortable at most).
* Jujutsu is nice, but it doesn't remove the need to learn git, and it's not fundamentally simpler or more powerful.
* Yoebuild sounds like even if it got traction like Meson and Jujutsu, it wouldn't remove the need to interact with Yocto for embedded linux engineers.
As an embedded linux engineer, if anyway I have to interact with Yocto and therefore learn Yocto, why would I learn another one that isn't fundamentally better? Usually people who go for those "simpler" (at least on the surface) tools do it because they don't want to learn Yocto. And for an embedded linux engineer, isn't it a red flag to not want to learn the most famous embedded linux build system?
It reminds me of Balena/Resin, which seems like it's targetting people who are not embedded linux engineers, don't want to become embedded linux engineers, but still want to distribute an embedded linux. To me that's generally a red flag.
CMake at least used to be like this: a black plastic bag of LEGOs, you empty it on the floor, there are some instructions there, but some of the images don't look like any of the pieces you see on the floor. Also there are some random rusty bolts, lint, and pieces from an Erector Set. There's an empty tape roll, someone wrote "buy more, ask forum" with a sharpie on it.
You can make great things with that, but it was easy to be "holding it wrong".
I still recommend CMake at work, it's the least offensive solution in most situations.
I get the feeling, it is a... "different" language. But I never understood the criticism about the documentation. At least in the last decade, I have always found the CMake documentation pretty good. Everything is documented.
Probably CMake is not a good fit for very, very big projects. But the vast majority of projects are not that big.
Usually what I see with CMake is self-inflicted pain, often where the devs start adding custom functions and mix it with python and stuff. If you keep it simple, it's very clear and does the job with surprisingly few keywords, I find. And I have setup tens of projects with CMake.
> My experience is that Yocto is a bit like CMake: people hate the mess they make with it and blame the system, even though they never bothered learning to use it.
I agree this is true a lot of the time, speaking as someone who has made many Yocto messes and later regretted. But you also can't discount all of the messes made by silicon OEMs that you are forced to deal with to use their SoCs.
E.g. I recently did a project with Yocto on a Zynq US+. Look at the meta-xilinx layerset (or, God forbid, petalinux) and tell me they haven't made a complete mess of it.
The complexity and lack of upstreaming in kernel and userspace for so many of these SoCs, coupled with non standard boot process and devicetrees means you will be forced to use these terrible OEM layers. I don't think a new build system can fix this at all, it's a cultural/commitment that needs to change from the OEMs.
At the end of the day, of you are doing any complex embedded Linux work as a small team, you must use Yocto because it's what the OEM supports. I don't have time or resource to debug DFX not working because some userspace tool was built with slightly different flags than expected by the flaky ass xilinx upstream.
> But you also can't discount all of the messes made by silicon OEMs that you are forced to deal with to use their SoCs.
Yes, totally! It's a bit sad because we don't usually have the luxury to select the hardware based on the quality of the BSP. First because they all seem to be terrible, and second because it is somehow "hidden" cost. One selects the hardware based on its price and capabilities, and the software part is left as an exercise.
But as you say it's not a problem of Yocto, it's a problem of the OEMs being in a position to make a mess because it doesn't have an impact on them. A bit like Apple is terrible for developers (in my experience) because anyway developers don't have a choice.
When someone starts with "why cross-compiling the system if it's bearable to compile it directly on the device?", it really sounds like they are just not comfortable with cross-compilation. To me it would be similar to say "why would you need a compiled language, with this weird compilation step that nobody understands, when you can just write in an interpreted language?". Except that developers wouldn't generally proudly admit that they don't know how to use a compiler.
A valid reason I see to require a new embedded linux build system would be if the existing ones (mostly buildroot and Yocto) were unable to build a modern OS (e.g. by not being able to integrate some security features). But I don't think that's the case. This article sounds more like very verbose marketing for a system claiming that it can do similarly without having to learn as much (which I honestly doubt).
To me it's often the same pattern:
* Meson is nice, but it doesn't remove the need to use CMake, and it's not fundamentally simpler or more powerful (it's more comfortable at most).
* Jujutsu is nice, but it doesn't remove the need to learn git, and it's not fundamentally simpler or more powerful.
* Yoebuild sounds like even if it got traction like Meson and Jujutsu, it wouldn't remove the need to interact with Yocto for embedded linux engineers.
As an embedded linux engineer, if anyway I have to interact with Yocto and therefore learn Yocto, why would I learn another one that isn't fundamentally better? Usually people who go for those "simpler" (at least on the surface) tools do it because they don't want to learn Yocto. And for an embedded linux engineer, isn't it a red flag to not want to learn the most famous embedded linux build system?
It reminds me of Balena/Resin, which seems like it's targetting people who are not embedded linux engineers, don't want to become embedded linux engineers, but still want to distribute an embedded linux. To me that's generally a red flag.