Embedded Linux developers meet for a Yocto project summit

Wookey, I'm glad you like OE's design --- because I was part of the design team and many BitBake concepts (e.g. the machine-overrides, gentoo-inspired recipes) are my childs :-) So I indroduced flexibility, but also complexity.

But then your article goes on to speak about Debian on embedded devices. I assume you know that those two things have very different architectures.

Back when BitBake / OpenEmbedded was created, the typical linux embedded device was running on StrongARM or Intel PXA with a mediocre 400 MHz clock or even less. Not to speak about old ARMv4 architecture and bad memory interfaces. This made it virtually impossible to compile something "on the device". Therefore the heckmeck with all this cross-compiling. While cross-compilation is conceptionally and practically way more complex, it allows one to use your fast i386 desktop computer to compile software that will later run on the ARM/MIPS/whatever target devices.

Contrary to this, Distributions like Debian, Fedora or Linux-From-Scratch compile on the i386 for the i386. Or on a MIPS for MIPS. That means you have need some system already running Linux with the same CPU architecture. Then you could use that to bringup your distribution. That complicates bootstrap. Nowadays there's a chance that you just can grab Debian packages for the right architecture and install them on your device, but back than this was a question of luck and chance, especially in the light of possible software, compilation or packaging errors.

Today ARM systems have 600 MHz to 1 GHz (like the Beagleboard). You get them already running with Linux. And suddenly compiling Debian SID packages on the board itself became feasible. That makes it way easier to follow upstream !

Apropos Upstream: this is probably what OpenEmbedded maybe did wrong. OpenEmbedded package makers seldom worked with upstream together (that's now a feeling, I didn't dig out facts about this). For example, an OE developer noticed "Oh, this configure *.m4 script tries to run an arm-compiled test binary while configuring, that won't work. I need to use the host-gcc for it". Then he made a patch, put the patch into OpenEmbedded and it worked. But upstream was not aware of this problem and never fixed the source. On the other side, at this time most upstream projects didn't care about embedded requirements.

I actually used BitBake/OpenEmbedded for commercial products. However, I only used a very small subset of OpenEmbedded. On the final device only about 40 packages got installed. Init-Scripts where different and I used way more from Busybox than OpenEmbedded. For example, OpenEmbedded hat it's own login/passwd and sysvinit utilities, while I used those from Busybox. Taking the good parts of OpenEmbedded in a controlled fashion allowed my company to deliver something that was functional, tested and (internally) well described. OpenEmbedded itself was (is?) a too fast moving target for that. But if you see OpenEmbedded as a repository of great cross-compilation recipes, then you can make quality products with not too much effort out of it.