21–30 of 92 posts
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
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…
Because historically, and I would argue should still, refer to very limited hardware, in terms of memory, processing power, and energy.
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’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…
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.
Earlier quoted context omitted.
Are you proposing compiling on the target? For a vast number of embedded systems that is not only impossible (insufficient disk and memory) but also incredibly slow. At the end of the day you need some cross compilation just for board bring up. If you're playing with some platform for which this has already been done, then sure, but that's not really the "normal" way of doing embedded.
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.
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’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.
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 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.