Hacker News Reader

Comment by dima55 | Hacker News Reader

Yocto has no place on any machine that isn't heavily resource constrained. A "normal" OS like Debian gives you multitudes of advantages at the cost of a little extra disk space: thousands of packages available with one command, tons of available tools, support for many different architectures, cross-building. AND you can do both at the same time. At $JOB we have hardware with a vendor-provided yocto thing that has some binary hardware drivers. So we can't dump yocto completely. Instead we have Debian running in a chroot, talking to the binary driver running in native yocto via a pipe. Recommended!

View on HN

Yocto does have other benefits than just resource usage. It's also good if you want to customize your compiler options, or if you operate in a safety-critical context where you might need to trace the origins of your compiled binaries.

You can custom-build Debian packages in the same way. Rarely does anyone actually do it because it rarely actually matters.

I've found yocto package availability quite good, although you may need to add some non-default meta layers. Do you have some examples of what packages and especially architectures Yocto is missing compared to debian?

Also I would be interested to hear how debian has advantages in cross-building; I thought they native-compile all of their packages. Is that really the case that in debian that you can modify some existing deb source package (eg. change configure flags or apply some patch) and cross compile that into a .deb, like you can in Yocto?

Debian is a mainstream OS used by millions, while yocto is niche. Package availability isn't comparable, and you don't have to look hard to find missing things.

And yes. I can install a cross-compiler (from the stock repo!) and custom-build whatever (not 100% of the archive is cross-buildable yet, but most of it is). And most of the time you don't care about the details, and you don't need to cross-build anything: the full Debian archive is pre-built and available on all the supported architectures (whatever you care about is probably on that list).

And there's another big advantage. Developers might be using a different-architecture machine for their testing, and it's really nice to have an identical set of installed packages and version across dev and deployment boxes, even if they have different architectures. This is actually a very common case: people develop on their amd64 laptops, but the deployment might happen on an arm, or something.

That's a solid approach. Just make sure $JOB's legal dept is OK with Debian's license requirements (you have to tell customers how to modify your chroot), and with potential traceability/software supply-chain concerns.

Reply on news.ycombinator.com