Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is it time for a new Embedded Linux build system?

yoebuild.org

Post reply on HN
Print view View original

61–70 of 92 posts

Re: Is it time for a new Embedded Linux build system?

#61

Post by palata »

My experience is that Yocto is a bit like CMake: people hate the mess they make with it and blame the system, even though they never bothered learning to use it.

When someone starts with "why cross-compiling the system if it's bearable to compile it directly on the device?", it really sounds like they are just not comfortable with cross-compilation. To me it would be similar to say "why would you need a compiled language, with this weird compilation step that nobody understands, when you can just write in an interpreted language?". Except that developers wouldn't generally proudly admit that they don't know how to use a compiler.

A valid reason I see to require a new embedded linux build system would be if the existing ones (mostly buildroot and Yocto) were unable to build a modern OS (e.g. by not being able to integrate some security features). But I don't think that's the case. This article sounds more like very verbose marketing for a system claiming that it can do similarly without having to learn as much (which I honestly doubt).

To me it's often the same pattern:

* Meson is nice, but it doesn't remove the need to use CMake, and it's not fundamentally simpler or more powerful (it's more comfortable at most).

* Jujutsu is nice, but it doesn't remove the need to learn git, and it's not fundamentally simpler or more powerful.

* Yoebuild sounds like even if it got traction like Meson and Jujutsu, it wouldn't remove the need to interact with Yocto for embedded linux engineers.

As an embedded linux engineer, if anyway I have to interact with Yocto and therefore learn Yocto, why would I learn another one that isn't fundamentally better? Usually people who go for those "simpler" (at least on the surface) tools do it because they don't want to learn Yocto. And for an embedded linux engineer, isn't it a red flag to not want to learn the most famous embedded linux build system?

It reminds me of Balena/Resin, which seems like it's targetting people who are not embedded linux engineers, don't want to become embedded linux engineers, but still want to distribute an embedded linux. To me that's generally a red flag.

Re: Is it time for a new Embedded Linux build system?

#62

Post by actionfromafar »

palata wrote: post #61

My experience is that Yocto is a bit like CMake: people hate the mess they make with it and blame the system, even though they never bothered learning to use it. When someone starts with "why cross-compiling the system if it's bearable to compile it directly on the device?", it really sounds like they are just not comfortable with cross-compilation. To me it would be similar to say "why would you need a compiled lang…

CMake at least used to be like this: a black plastic bag of LEGOs, you empty it on the floor, there are some instructions there, but some of the images don't look like any of the pieces you see on the floor. Also there are some random rusty bolts, lint, and pieces from an Erector Set. There's an empty tape roll, someone wrote "buy more, ask forum" with a sharpie on it.

You can make great things with that, but it was easy to be "holding it wrong".

I still recommend CMake at work, it's the least offensive solution in most situations.

Re: Is it time for a new Embedded Linux build system?

#63

Post by actionfromafar »

throwawayqqq11 wrote: post #58
sollniss wrote: post #35

Earlier quoted context omitted.

You can generally remotely build for any supported architecture[1]. The build process will be painfully slow though if you have cache misses. [1] https://search.nixos.org/options?channel=26.05&query=boot.bi...

Nitpick: binfmt.emulatedSystems is not true cross compilation. It sets up a nixos to enable emulated native compilation. After painful tinkering, i prefer this way too. When i recall correctly, for cross compilation you'd have to use nixpkgs flags.

At some point it's a matter of perspective. If the emulated system is fast, it feels the same as "true" cross compilation. In the end it's a bunch of bits and bytes which produces some other bits and bytes when we poke it. If it goes fast, it's good. If it goes slow, it's painful.

Re: Is it time for a new Embedded Linux build system?

#64

Post by lpribis »

palata wrote: post #61

My experience is that Yocto is a bit like CMake: people hate the mess they make with it and blame the system, even though they never bothered learning to use it. When someone starts with "why cross-compiling the system if it's bearable to compile it directly on the device?", it really sounds like they are just not comfortable with cross-compilation. To me it would be similar to say "why would you need a compiled lang…

> My experience is that Yocto is a bit like CMake: people hate the mess they make with it and blame the system, even though they never bothered learning to use it.

I agree this is true a lot of the time, speaking as someone who has made many Yocto messes and later regretted. But you also can't discount all of the messes made by silicon OEMs that you are forced to deal with to use their SoCs.

E.g. I recently did a project with Yocto on a Zynq US+. Look at the meta-xilinx layerset (or, God forbid, petalinux) and tell me they haven't made a complete mess of it.

The complexity and lack of upstreaming in kernel and userspace for so many of these SoCs, coupled with non standard boot process and devicetrees means you will be forced to use these terrible OEM layers. I don't think a new build system can fix this at all, it's a cultural/commitment that needs to change from the OEMs.

At the end of the day, of you are doing any complex embedded Linux work as a small team, you must use Yocto because it's what the OEM supports. I don't have time or resource to debug DFX not working because some userspace tool was built with slightly different flags than expected by the flaky ass xilinx upstream.

Re: Is it time for a new Embedded Linux build system?

#65

Post by lpribis »

palata wrote: post #59
hparadiz wrote: post #47

Gentoo is literally designed for this but people keep coming up with other non-solutions. A Gentoo stage 3 with a custom kernel can run on a potato.

Doesn't Yocto come from Gentoo to some extent?

Bitbake (Yocto's build system) started originally as a fork of portage (gentoo package manager), but they have diverged a ton. Very similar concepts though.

Re: Is it time for a new Embedded Linux build system?

#68

Post by itomato »

sn wrote: post #51

This sounds like fun, but I'm not sure how changing build systems fixes the vendor problem. They will just ship their proprietary blobs built on top of this new build system instead of the old one, and will not change other behavior. Buying from vendors who upstream or minimally open source their work might help. Yes, skipping builds from source can be faster, and, I don't know that you need to throw away yocto to do…

Yes, and if they have done the hard work to deliver features in the kernel that provide a moat, that blob is the hardware.

Reversing and reimplementing the closed bits are what I want my Buildroot pipelines to do.

That’s my use case though; targeting COTS devices with (mainline) Linux support that don’t do all they could.

I have done it the ugly way (in production) and I want elegance in my old age.

Re: Is it time for a new Embedded Linux build system?

#69

Post by itomato »

kryptiskt wrote: post #53
nrdvana wrote: post #43

Earlier quoted context omitted.

It was true in 2005, but still? As I described in another post here, a modern strategy is to get a beefy server than can run the same ABI, then start a docker container and assemble a system from Alpine's package repo, then compile a kernel and a few in-house things, then extract a subset of that into an image. No cross-compile, and most of the useful software is in pre-built binary packages with the compile-time opt…

There are no beefy RISC-V servers. There are no beefy 32-bit ARM servers.

Beowulf time?

I had been maintaining a fork of the U of KY BDR with SBCs and Arm devices in mind, might need to revive it for RISC-V.

Re: Is it time for a new Embedded Linux build system?

#70

Post by nrdvana »

kryptiskt wrote: post #53
nrdvana wrote: post #43

Earlier quoted context omitted.

It was true in 2005, but still? As I described in another post here, a modern strategy is to get a beefy server than can run the same ABI, then start a docker container and assemble a system from Alpine's package repo, then compile a kernel and a few in-house things, then extract a subset of that into an image. No cross-compile, and most of the useful software is in pre-built binary packages with the compile-time opt…

There are no beefy RISC-V servers. There are no beefy 32-bit ARM servers.

> There are no beefy 32-bit ARM servers.

"Ampere processors natively support both 32 & 64 bit Android applications and require no binary translation for maximum instance density" ... "Run up to 120+ 3D cloud game instances per socket" ... "DRAM: 384GB - 512GB"

https://amperecomputing.com/solutions/arm-native

I've not personally tested this, but it very much appears that just like x86, you can use a 64-bit ARM kernel that has 32-bit support enabled to run a 32-bit userspace, likely compatible with docker, or even just in a chroot. Then with 120 cores, "make -j 120"

Post reply on HN