Comment by ernst_klim | Hacker News Reader

Comment by ernst_klim | Hacker News Reader

Parent Full thread

>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?

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".

> Of course nothing is documented, and

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.

> 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....

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.

> Wanna build an fs for the device with a local storage and external ssd, good luck to figure out how

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...

> Which filesystems could I use? How to know that?

A simple

  git grep IMAGE_FSTYPES

brings you up a long list. File meta/classes/image_types.bbclass seems particular promising. And there it is

https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/cl...

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 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.

Reply on news.ycombinator.com