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

41–50 of 92 posts

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

#41

Post by nrdvana »

okanat wrote: post #26
KingMachiavelli wrote: post #18

Earlier quoted context omitted.

Embedded just means ARM 99% of the time and it's cheaper and easier to use native ARM servers (AWS has them cheap) than to make 100% of software cross compile. Some parts of the firmware might need to be cross compiled but those projects are designed to cross compile.

Your target build environment often differs significantly from your server environment, so you end up needing a different toolchain and all of the problems that come with cross-compilation anyway. The toolchain and ABI settings that produce small, battery or instruction cache efficient are usually not you want on servers.

I'm not familiar with the problems that would cause "target build environment often differs significantly from your server environment". If you have an ARM server, then you should be able to download and run Alpine docker images, and then fetch most system utilities from the Alpine package repo and then compile a kernel and a few other binaries on top of that, then export an image.

The main reason to not run Debian is that Debian usually makes lots of compile-time decisions for you, and chooses to maximize the enabled options of the software. Alpine makes the opposite choices for you, creating very minimal feature sets.

It's been working well for me, but my use cases is a lot more like a custom in-house DDWRT firmware kind of a thing. If you've experienced additional constraints that make this pattern unworkable, I'd be interested to hear about them.

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

#42

Post by Brian_K_White »

zamadatix wrote: post #30
jimktrains2 wrote: post #22

Earlier quoted context omitted.

> I don't quite understand why "embedded" has historically meant learning a completely separate tool. Because historically, and I would argue should still, refer to very limited hardware, in terms of memory, processing power, and energy.

If you're sticking the Linux kernel into something you've already past the scale this should require a separate build system to accomplish.

I guess this was just so true everyone found it uninteresting like saying water is wet eh?

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

#43

Post by nrdvana »

drdexebtjl wrote: post #25
cbrake wrote: post #2

I’ve been experimenting with what a next-generation embedded Linux build system might look like: native builds on the target architecture, modern language package managers as first-class citizens, and AI as a primary interface to the system. Instead of cross-compiling with a large meta-layer stack, the tool builds kernel, rootfs, and applications together using one engine, with a CLI, TUI, and AI assistant talking to…

>native builds This is the complete opposite way, actually. We need cross-compiling that is just as effortless as native compilation. You should be able to build complex software on a powerful computer and perform costly optimization, then run it on a low-powered device.

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 options you would have selected anyway.

Even if you don't have a beefy server of the same architecture, you can probably run it in qemu instead of docker to the same effect. And even if qemu is slow, you can run a build of the kernel and your in-house stuff in parallel on 64 cores and not really be affected by the qemu slowdown.

I'm interested to hear counterexamples, though.

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

#44

Post by [deleted] »

sollniss wrote: post #35
Palomides wrote: post #24

Earlier quoted context omitted.

I'm not very familiar with nix, how well does it do with cross compiling? is anyone actually using it for yocto sorts of domains?

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

[deleted]

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

#45

Post by russdill »

Oi, more AI slop. After dealing with things that have external package management and yocto, I understand the pain. But integrating that into yocto is very doable and is a far better path forward.

And "I've been experiment with" seems to just mean "I've been vibe coding"

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

#46

Post by [deleted] »

okanat wrote: post #7

The problems building with Linux and GNU environments exist because they were terribly designed with assumptions like - You're building on the same native system as GNU and Linux packages, you install them globally in the same places that servers and desktops use - Your C, C++ compiler and entire toolchain and other binary utilities with the kernel is a one single unit that you can only change one part at a time - Yo…

[deleted]

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

#48

Post by drdexebtjl »

nrdvana wrote: post #43
drdexebtjl wrote: post #25

Earlier quoted context omitted.

>native builds This is the complete opposite way, actually. We need cross-compiling that is just as effortless as native compilation. You should be able to build complex software on a powerful computer and perform costly optimization, then run it on a low-powered device.

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…

I don’t have counter examples, but hear me out.

What if this hegemony in ISAs is partially because of the high costs of porting software and toolchains?

Maybe the next generation of embedded devices will have ISAs that are, say, extremely optimized for real time industrial controllers, but terrible at compiling C++.

It seems a little silly to give up on cross-compilation just because _today_ everything runs on ARM.

Especially because cross-compilation is not a particularly hard problem, the problem is with decades of tooling assuming the build and target environments are the same.

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

#49

Post by rendaw »

Palomides wrote: post #24
KingMachiavelli wrote: post #17

I've been using Nix for "embedded" systems for few years now and it works fine. I don't quite understand why "embedded" has historically meant learning a completely separate tool. I've been building for x86 and ARM servers for 5+ years now, so why should targeting an ARM board be any different? Like the article points out, the software stacks people use for embedded devices are the same as people use non-embedded use…

I'm not very familiar with nix, how well does it do with cross compiling? is anyone actually using it for yocto sorts of domains?

Nixos can cross build os images for Le Potato with device tree stuff: https://hub.libre.computer/t/nixos-for-aml-s905x-cc-le-potat...
Post reply on HN