Hacker News Reader

Comment by candiddevmike | Hacker News Reader

> Since an embedded Linux system will likely require use of either Buildroot or Yocto,

I don't know if that's the case anymore. The kernel ships with a lot of drivers now, and Root FS for embedded devices aren't really space constrained anymore. The needs of an IoT device have also grown to include things like containers and telemetry. In my experience, forking off of an existing distribution like Debian is way easier than navigating Buildroot or Yocto's documentation and cruft, and results in faster builds.

I got so fed up with those tools I eventually built a custom tool (Etcha) to build my own meta distribution (EtchaOS) of immutable variants for Debian, Fedora, etc. It owns the entire provisioning pipeline and builds multi-arch images in less than 10 minutes:

https://etcha.dev/etchaos/explanations/build-process/

View on HN

For the projects I've done, we're not usually particularly space constrained, but we are usually at least one of:

* Cost constrained so RAM constrained * Need fast boot times * For a niche processor architecture

Starting with very little apart from an init system and busybox and then building up from there has been a good approach to get the performant (by whatever metric) platform that I need.

That said, I'm not a fan of Yocto at all. I find it painful and slow to work with. I experimented with using Nix (as in NixOS) as my build platform which had some great advantages (e.g. great caching of build steps), but also some pain.

> For a niche processor architecture

It's been ages since I've last seen something else than ARM and x86 - are people still bringing up new designs for MIPS CPUs?!

unrelated but curious - what do you think of OSTree-based embedded distros? Any future in it?

I see it as an overly complicated way of trying to apply containerization concepts to a base OS via transactions. It's really hard to use OSTree on new projects or get existing distros like Debian to work with OSTree. I think the update process, while in theory should be better, ends up being a black box of will it/won't it frustration for end users.

Finally, OSTree is mainly a Red Hat thing and is built for their needs (CoreOS). They could pull the rug on it in the sense that what you build today using it may not work tomorrow if Red Hat needs OSTree to function differently. Which is their perogrative, as they are the primary contributors to it.

What do you think about using btrfs snapshots instead of ostree similar to openSUSE MicroOS or SLE Micro?

Reply on news.ycombinator.com