4 ms·

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

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 https://www.openbsd.org/arm64.html

PragmaticPulp 5y ago
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.
- synergy20 5y ago
  RPI also sells modules for commercial products, so anything you play with RPI can be used on products too.
johnklos 5y ago
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?
- yjftsjthsd-h 5y ago
  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.
- 1vuio0pswjnm7 5y ago
  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.
moondev 5y ago
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
- iJohnDoe 5y ago
  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.
spyremeown 5y ago
>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.
- foxfluff 5y ago
  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.

PragmaticPulp 5y ago

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.

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

johnklos 5y ago

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?

yjftsjthsd-h 5y ago
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.
1vuio0pswjnm7 5y ago
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.

moondev 5y ago

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

iJohnDoe 5y ago
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.

spyremeown 5y ago

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

foxfluff 5y ago
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.