4 ms·

>I personally haven’t been impressed with yocto That's a very mild way to express my feeling about it. Maybe I'm asking too much, but Yocto/openembedded is th

>I personally haven’t been impressed with yocto 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?

rafa1981 7y ago
Example: PACKAGE_native_append += "something". "append" is a keyword, but the "native" is just a separate list of native packages, yet both are appended to a variable name separating it by underscores. They use the same "syntax". If my memory serves me correctly, if not in this example "+=" is required sometimes after "append", even if they seem redundant. Someone politely explains you why this works as it does, it makes sense, yet you wonder why you need to hit a gotcha when all you are doing is something as simple as adding an item to a list (as a space separated string). 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".
anthk 7y ago
I hated it, too. Also, OpenWRT, what a nightmare to build against. Now if netbsd was ported to the zipit z2, I would switch in no time.
usr1106 7y ago
> Of course nothing is documented, and This is plain wrong. There is a whole bunch of manuals https://www.yoctoproject.org/docs/ https://www.yoctoproject.org/docs/ And there are several books https://www.yoctoproject.org/learn/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.
- ernst_klim 7y ago
  > There is a whole bunch of manuals 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: https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#ref-images https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.... https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#var-IMAGE_FSTYPES https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.... 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.
  - usr1106 7y ago

rafa1981 7y ago

Example: PACKAGE_native_append += "something". "append" is a keyword, but the "native" is just a separate list of native packages, yet both are appended to a variable name separating it by underscores. They use the same "syntax". If my memory serves me correctly, if not in this example "+=" is required sometimes after "append", even if they seem redundant. Someone politely explains you why this works as it does, it makes sense, yet you wonder why you need to hit a gotcha when all you are doing is something as simple as adding an item to a list (as a space separated string). 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".

anthk 7y ago

I hated it, too. Also, OpenWRT, what a nightmare to build against. Now if netbsd was ported to the zipit z2, I would switch in no time.

usr1106 7y ago

> Of course nothing is documented, and This is plain wrong. There is a whole bunch of manuals https://www.yoctoproject.org/docs/ https://www.yoctoproject.org/docs/ And there are several books https://www.yoctoproject.org/learn/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.

ernst_klim 7y ago
> There is a whole bunch of manuals 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: https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#ref-images https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.... https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#var-IMAGE_FSTYPES https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.... 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.
- usr1106 7y ago