Hacker News new | ask | show | jobs
by mort96 481 days ago
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.

1 comments

"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

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

You're not responding to what I'm saying, the questions I'm asking or the mistakes I'm pointing out. I'm done.
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

I don't know what you mean by "bodged binaries".