Hacker News Reader

Comment by traceroute66 | Hacker News Reader

Rolling your own minimal embedded Linux is all cute fun. But what about maintaining it ?

Assuming you're not going to be rebuilding the whole lot manually each time, you're also going to have to go through the rather cute experience of building (and maintaining) your own automation tooling around maintaining your minimal embedded Linux.

If I were developing an embedded project, I don't know about you, but I would suggest focusing on the project itself might be a nice idea, not wasting time on things like a custom OS.

Custom OS is fine if you've got a large team working along side you. But if its a one-man-band (or small team) then all the cuteness will soon evaporate.

If you think all Linux distros are too bloated, why not go BSD instead ?

For example, OpenBSD is famous for a minimal default install, and guess what, they maintain ready-to-go builds for Pine 64/64+, Raspberry Pi 3 and Raspberry Pi 4.[1]

[1] https://www.openbsd.org/arm64.html

View on HN

The Raspberry Pi is a learning platform, first and foremost. This is actually a great learning project for someone to understand what goes into a Linux system.

> If I were developing an embedded project, I don't know about you, but I would suggest focusing on the project itself might be a nice idea, not wasting time on things like a custom OS

Using an off the shelf distribution is ideal your goal is rapid prototyping, but most real-world embedded projects end up requiring custom distributions sooner or later. Distributions tailored to interactive use tend not to be so great for distributing and upgrading predictable firmware. You really want all of your devices in a known state, not a random mix of package versions depending on when they last ran ‘apt-get upgrade’, for example.

In production-grade products, the OS is often built with tools like Buildroot or OpenEmbedded (Yocto), not from scratch. However, doing a tutorial like this once is a good learning exercise.

RPI also sells modules for commercial products, so anything you play with RPI can be used on products too.

>If I were developing an embedded project, I don't know about you, but I would suggest focusing on the project itself might be a nice idea, not wasting time on things like a custom OS.

And that's why you're probably not working on embedded. Minimal environments with almost zero footprint is a must in almost all cases. If you're rolling a custom board, you simply have to go custom, which is where OpenBSD will fall short on you. Check Variscite's or Toradex websites and see if you find any BSD in there.

The other thing is that existing distros are rarely good for anything truly autonomous. Too many moving parts. There's always the expectation that someone with a display and a keyboard, or a sysadmin at the console, is ready to pick up the pieces when it falls apart.

I've asked people how to easily download the sources for any given Linux distro to compile locally, and I've gotten links to sites with pages of instructions.

To build NetBSD/aarch64 on most Unix / Linux OSes (replace -j 8 with a suitable number for however many processor cores / threads you have):

  curl "https://cdn.netbsd.org/pub/NetBSD/NetBSD-current/tar_files/src.tar.gz" -o src.tar.gz
  curl "https://cdn.netbsd.org/pub/NetBSD/NetBSD-current/tar_files/xsrc.tar.gz" -o xsrc.tar.gz
  tar xzf src.tar.gz ; tar xzf xsrc.tar.gz
  cd src
  ./build.sh -m evbarm -a aarch64 -x -U -j 8 -D ../dest -O ../obj -T ../tools -R ../sets tools release

Is there really nothing this simple for Linux distros?

Maybe nix/guix, but most distros are going to have difficulty because they aren't a single thing to build, they're a collection of separate packages that you'd have to build individually.

Cannot offer any advice to the parent^1 however the build.sh instructions he provides bring to mind a general observation: By comparison, running buildroot's script will initiate downloads of files. This is a key distinction I see with Linux/GNU distributions (cf. the Linux kernel) in general (there are exceptions). Linux distribution maintainers try to automate everything. The idea of the user downloading the source tree for the entire distribution manually is not contemplated. Another example: When NetBSD is first installed, generally no networking programs are enabled by default. Its expected the user will turn things on, if she wants them on. By contrast, when a popular Linux distribution is installed, there are usually networking programs enabled by default to listen on the network. I use both Linux and NetBSD. I am not invoking a Linux v BSD debate nor arguing for one's approach over the other's, I am just pointing out how they are philosophically different.

1 The "NetBSD way" would be to study the NetBSD source tree and then modify certain files to suit one's needs. For example, I like to create custom crunched binaries; this requires editing a list. By comparsion, with Linux, I have never read any advice to study the Debian source tree and then modify files to suit one's needs. Rather, the advice one finds directs readers to Yocto, buildroot, etc.

I understand and appreciate that. But the distinction between manually downloading or automatically downloading isn't important to me.

Perhaps buildroot does the closest thing. I'll have to give it a go.

Maybe Gentoo is the closest thing.

You should really try out Yocto. There is a lot to learn but you can configure it from super-minimal tiny distros to mega kitchen-sink-included distros.

Everything is customizable, every file, every compiler flag and option of every package, with easy overrides in your own layer which only 'appends' to the original instructions, or adding and removing packages as you see fit in the base install.

What I dont underatand (yet) is in the example you provided you gave "qemuarm64" as the BSP. But the NetBSD example johnklos gave is not just for QEMU. I dont see an option for the RPi in poky's local.conf. NetBSD of already has configs for bootable RPi in its tree. This illustrates my point about automated downloads. Yocto requires, among other things, wget. For building images. This implies there is more to be downloaded before we can begin. With NetBSD, network access is not required to build images.

Uh, with Yocto at least, it's also pretty simple for a basic bootable disk image/packages... downloading all the source and compiling the cross toolchain along the way...

    git clone git://git.yoctoproject.org/poky
    cd poky
    git checkout -b hardknott -t origin/hardknott
    source oe-init-build-env
    MACHINE=qemuarm64 bitbake core-image-sato

But after the first build you may want more - bringing in other functional layers for different features (maybe you want docker?), support for different boards (same OS distro for x86_64 and ARM, or your own custom board... plus it can build a whole SDK for you for local development/debugging?), customization of target files, pulling from updated upstreams, support in deployment and throughout the device lifecycle, custom package feeds, etc.

There's a lot going for Yocto, it has a deep learning curve but does a pretty good job of taming the complexity of managing an entire OS distro.

I would use buildroot for that. It's very convenient even to just build random kernels for random targets

esxi for arm edition runs on the rpi 4 and 8 gb models. This way you can use the vsphere tooling and api to make it pretty painless, including the use of snapshots and cloning

Wow! Had no idea that VMware would run on a rpi. Thanks.

It’s interesting to think about the different markets for the rpi. I would never consider the rpi for learning. I only look at it as an inexpensive system to run my favorite distro. I want it to run CentOS or NetBSD, etc. rpi OS is meaningless to me. I want it to run the stuff I use every day.

Reply on news.ycombinator.com