[Joel_Mckay]

"Part of why it gets so much criticism is that Yocto’s learning curve is pure brutality."

At one time when SoCs were RAM lean... and build specific patching, stripping and static linking was considered an acceptable tradeoff in the yocto build systems for IoT etc. The use-cases are extremely difficult to justify these days with 256MB of ram on a $5 SoC...

However, the approach was commercially unsustainable from maintainability, security, and memory-page cache-hit efficiency metrics. It should be banned given it still haunts the lower systems like a rancid fart in an elevator. =3

[mort96]

From experience, none of the difficulty of Yocto comes from the fact that it strips binaries; it builds stripped packages and puts debug info in separate -dbg packages, which is super standard in the Linux world.

Yocto doesn't do static linking unless you specifically ask for it, libraries end up as .so files in /usr/lib like on all other Linux systems.

When Yocto carries patches, it's typically because those patches are necessary to fix bad assumptions upstreams make which Yocto breaks, or to fix bugs, not to reduce RAM usage.

I don't understand where you're coming from at all.

[Joel_Mckay]

"I don't understand where you're coming from at all."

In time you may, but perhaps you were confused about the primary use-case context bringing up small linux SBM. The mess Yocto can leave behind was not something manufacturers prioritized, and there are countless half-baked solutions simply abandoned within a single release cycle. Out of date package versions, and storage space-optimized stripped/kludged binaries are the consequences. Historically, the things people did to get the minimal OS on flash also meant builds that are not repeatable/serviceable, buggy/unreliable (hence custom patches), and ultimately in mountains of e-waste.

My point was Yocto has always created liabilities/costs no one including its proponents wanted to address over the long-term. Best of luck =3

[mort96]

I might have been unclear. What I don't understand is how binary stripping and custom patches is associated with SoCs with low RAM, or why you claimed that it does static linking when it doesn't by default.

[Joel_Mckay]

It was mostly the low-end IoT and router markets that was the major driver behind space-optimized image builds. i.e. the various tricks people pull to get leaner builds made maintenance nearly impossible. On chip RAM was the initial constraint that fell, TLC flash became inexpensive, and ARM option performance hit practical levels. i.e. it became possible to install normal environments with a simple port.

The other point I was stating was today the low-end chip justifications no longer makes economic sense. The kernel maintainers already deprecated 32bit years ago.

"All software is terrible, but some of it is useful..." but if proves a liability, than it is just terrible. lol Have a great weekend =3

[mort96]

You're not responding to what I'm saying, the questions I'm asking or the mistakes I'm pointing out. I'm done.

[Joel_Mckay]

Thus, we agree the bodged binaries were a mistake, and thus have reached an awkward understanding. Your use-cases might differ, but it does not change what the artifacts look like from a optimized low-end Yocto project.

Best of luck, some of my most prized friends took 3+ years to agree with my perspectives. You should know I hold you very high regard =3

[cushychicken]

Buddy what the fuck are you talking about

Yocto launched in 2010

Buildroot launched in 2005

Both of these ecosystems coexisted in the era of sub $100 embedded Linux dev boards with way more than 256MB RAM

Yocto has no excuse for making toolchain and system configuration modifications as difficult as it does.

[svnt]

There is a big difference in just about everything relating to selling something with a sub $10 BOM and something approximating a “sub $100 dev board.”

The difference in unit volumes drives wide variances in tolerances of additional development difficulty/cost.

[Joel_Mckay]

Indeed, the economics of chip component choices at scale change development priorities. Depends on the use-case, and how much people are willing to compromise on the design. Performant SoC and Flash memory are no longer premium budget choices.

Some people seem irrationally passionate about the code smell of their own brand. =3