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

31–40 of 92 posts

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

#31

Post by drdexebtjl »

joezydeco wrote: post #29
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.

Yocto and Buildroot will compile, from scratch, an entire gcc crosstool chain with standard library suite and headers to build fast and then deploy to your target. This exists.

I wouldn’t call either of those effortless, though. I’m thinking of something similar to Zig’s DX for cross-compilation.

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

#32

Post by alright2565 »

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?

[dead]

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

#33

Post by kbaker »

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…

(For the unaware, OP above is the article author.)

As a long time user of Bitbake and Yocto, and watcher of Yoe Linux... I kind of have to respectfully disagree with the approach.

One look at the Python or Node packaging ecosystem, and you can see how difficult trying to integrate those in a 'sane' way in embedded, with repeatability and security in mind, nevertheless wrangling something like C/C++ dependencies and native packages in a qemu-cross (or binfmt emulation) environment.

I feel like Bitbake and the wider Yocto ecosystem has essentially 'solved' cross compiling. Sure there are the incredibly complex codebases like Chromium that require lots and lots of study and patience, or esoteric compilers, etc. but for most applications I feel that especially AI tooling can write up a good basic recipe for integration with Yocto.

The unfortunate thing about AI tooling is Kernighan's law (where debugging is twice as hard as writing it the first time.) Especially in Embedded Linux, where 99.99% of the product code is written by others, trying to figure out where the AI didn't quite get it right or missed something can break things unexpectedly and impossibly for the unaware developer to fix, even breaking at runtime. So the build environment has to be simple and predictable. I think Yocto/Bitbake already strikes a good balance here, with other nice things like offline builds, repeatable builds, sstate caching across machines, PRbuild servers... things useful for big teams, so consider those as well.

Although, if someone does a 'uv'-like rewrite of Bitbake into Rust with the same feature set but faster, I am all for it...

Maybe, having Yoe or some other centralized distro make specific opinionated choices and then provide an open sstate feed, working inside Bitbake, could get a lot of the speed and customizability gains back without a big rewrite effort.

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

#34

Post by dima55 »

Gigachad wrote: post #21
dima55 wrote: post #13

Modern SBCs are just normal computers and not "embedded" in the traditional sense. You can generally just use Debian, and spend time on the actual project, instead of wrestling with the system

They aren't normal computers in the same way x86 is. They usually need proprietary drivers in custom boot processes, forked kernels with patches, etc. I'm yet to see a single SBC I can just download the iso from the debian website and get going. You always need some custom build.

ARM boards need a custom kernel and bootloader. These aren't things managed by the distro. The userspace IS managed by the distro and IS standard. Using yocto to manage userspace maybe made sense 15 years ago, but it has long since become far more trouble than its worth. Debian supports most architectures out of the box, has good cross-building infrastructure, many thousands of ready-to-use packages, and is non-weird.

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

#35

Post by sollniss »

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?

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

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

#36

Post by cozzyd »

dima55 wrote: post #34
Gigachad wrote: post #21

Earlier quoted context omitted.

They aren't normal computers in the same way x86 is. They usually need proprietary drivers in custom boot processes, forked kernels with patches, etc. I'm yet to see a single SBC I can just download the iso from the debian website and get going. You always need some custom build.

ARM boards need a custom kernel and bootloader. These aren't things managed by the distro. The userspace IS managed by the distro and IS standard. Using yocto to manage userspace maybe made sense 15 years ago, but it has long since become far more trouble than its worth. Debian supports most architectures out of the box, has good cross-building infrastructure, many thousands of ready-to-use packages, and is non-weird…

Debian handles userspace fine but there is a lot of image customization needed a lot of the time. I have experience with developing images for a beaglebone black, where I forked the bespoke image builder (to create user accounts, mount points, set up udev rules, device tree overlays, ssh keys, etc) and that was a pain to maintain. I suppose I could have create debian packages for some of those things, but I would still have needed to set up repositories. Now I'm using an SoM with Yocto and while the learning curve is quite a bit steeper, it is much easier to customize for our experiment's needs. Also, AI assistants are really good at spitting out yocto recipes (that usually don't work immediately, but gets you 90% of the way there).

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

#37

Post by jdub »

drdexebtjl wrote: post #31
joezydeco wrote: post #29

Earlier quoted context omitted.

Yocto and Buildroot will compile, from scratch, an entire gcc crosstool chain with standard library suite and headers to build fast and then deploy to your target. This exists.

I wouldn’t call either of those effortless, though. I’m thinking of something similar to Zig’s DX for cross-compilation.

zig makes cross-compiling easy for a single project - but not everything is zig (or supported by zig cc)

the various embedded build systems make cross-compiling easy at scale, which means you often don't need to think about it when adding a new package

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

#38

Post by nine_k »

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?

We do Nix-based cross-compiling for non-embedded software (ARM vs x64). I'd say it works mostly transparently.

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

#40

Post by shevy-java »

> Fast, reasonably priced prototyping (PCB assembly, mechanical 3D printing, etc.).

RAM is expensive now. Reasonably priced seems to be counter to that fact.

The whole article feels like a promo-tour.

> The catch is that nobody handed us the tools to keep the place running.

Software such as homebrew exists. Why is the article ignoring this? Not only does it feel like promo, it now feels like propaganda. Homebrew is also just one example; LFS/BLFS also exists for embedded linux. Perhaps the quality is less than for desktop computer systems but it exists.

> Edge devices have started behaving like cloud systems. They run increasingly complex stacks, are frequently updated, and are managed remotely over their entire life.

Companies want to become dependent on others? Because that is what cloud is all about. Top-down control. A mafia for later blackmail rack-up-the-price strategies.

> That puts the cross-compile burden squarely on embedded developers, and maintaining recipes for thousands of packages has been a steady drain on the Yocto community

Seems untrue. If you have a compiler that works, you can compile. Thousands of packages? I am tracking 3888 right now. That covers really most software by far, including python pypi addons. If a single person can do that, a team has an even easier time. The whole article seems to narrate a story that is just made up.

> Building everything from source in Yocto means long builds, heavy memory use, and powerful workstations.

No it does not. I do so every day. You need a reasonably fast computer and RAM, which is now driven up by the existing hardware mafia that must be put in jail, but it is easily possible for solo persons too. Now imagine a team.

The whole article is really really crap. Absolute garbage. The claims it makes are for the most part simply not correct. It narrates a story as if all linux developers are incompetent. I highly doubt that. It also never mentions any existing software here that would change the rhetoric such as homebrew, LFS/BLFS and so forth. It feels as if that article is just engineered to tell a "we thus need xyz". That's not good writing. I mean just look at this:

"We can leverage these change agents and rethink the world of connected products."

What does that even mean? Did AI write this? Because humans are usually smarter when it comes to opinion pieces. "connected products" - everything is now connected?

Post reply on HN