I have few queries related to BusyBox & embutils.
Can anyone brief me on the differences between BusyBox and embutils?
It would also be great if you can illustrate scenarios in which these respective tools are being used in embedded Linux environment?
An extract of Building embedded Linux Systems book :
embutils was written by the author of diet libc with very similar goals.
Though it supports many of the most common Unix commands, embutils is still far from being as exhaustive as BusyBox. For example, version 0.18 still lacks find, grep, ifconfig, ps and route.
In Contrast to BusyBox however, embutils must be statically linked with diet libc. It can't be linked to any other library. Because diet libc is already very small, This can make embutils a better choice than BusyBox when just a few binaries are needed, because the overall size is smaller.
Be aware that the embutils last version is about 6 years old, so not well maintained compared to BusyBox. As usual, choice depends of your needs, goals and contraints.
Related
What is the difference between alpine docker image and busybox docker image ?
When I check their dockfiles, alpine is like this (for Alpine v3.12 - 3.12.7)
FROM scratch
ADD alpine-minirootfs-3.12.7-x86_64.tar.gz /
CMD ["/bin/sh"]
busybox is like this
FROM scratch
ADD busybox.tar.xz /
CMD ["sh"]
But as https://alpinelinux.org/about/ says
Alpine Linux is built around musl libc and busybox.
So what is exactly the difference ?
I am also curious that many docker images, (nodejs/nginx/php just name a few) provide images based on alpine but not on busybox. Why is that ? What is use case for busybox image then ? I need to emphasize that I am not looking for an answer about why A is better than B or vise versa or software recommendation.
I have been experiencing intermittent DNS lookup failure for my alpine docker, as here musl-libc - Alpine's Greatest Weakness and here Does Alpine have known DNS issue within Kubernetes? said. That is one of reasons I asked my question.
PS, https://musl.libc.org/ says "musl is an implementation of the C standard library built on top of the Linux system call API" and https://en.wikipedia.org/wiki/Alpine_Linux mentioned
It previously used uClibc as its C standard library instead of the
traditional GNU C Library (glibc) most commonly used. Although it is
more lightweight, it does have the significant drawback of being
binary incompatible with glibc. Thus, all software must be compiled
for use with uClibc to work properly. As of 9 April 2014,[16] Alpine
Linux switched to musl, which is partially binary compatible with
glibc.
The key difference between these is that older versions of the busybox image statically linked busybox against glibc (current versions dynamically link busybox against glibc due to use of libnss even in static configuration), whereas the alpine image dynamically links against musl libc.
Going into the weighting factors used to choose between these in detail would be off-topic here (software recommendation requests), but some key points:
Comparing glibc against musl libc, a few salient points (though there are certainly many other factors as well):
glibc is built for performance and portability over size (often adding special-case performance optimizations that take a large amount of code).
musl libc is built for correctness and size over performance (it's willing to be somewhat slower to have a smaller code size and to run in less RAM); and it's much more aggressive about having correct error reporting (instead of just exiting immediately) in the face of resource exhaustion.
glibc is more widely used, so bugs that manifest against its implementation tend to be caught more quickly. Often, when one is the first person to build a given piece of software against musl, one will encounter bugs (typically in that software, not in musl) or places where the maintainer explicitly chose to use GNU extensions instead of sticking to the libc standard.
glibc is licensed under LGPL terms; only software under GPL-compatible terms can be statically linked against it; whereas musl is under a MIT license, and usable with fewer restrictions.
Comparing the advantages of a static build against a dynamic build:
If your system image will only have a single binary executable (written in C or otherwise using a libc), a static build is always better, as it discards any parts of your libraries that aren't actually used by that one executable.
If your system image is intended to have more binaries added that are written in C, using dynamic linking will keep the overall size down, since it allows those binaries to use the libc that's already there.
If your system image is intended to have more binaries added in a language that doesn't use libc (this can be the case for Go and Rust, f/e), then you don't benefit from dynamic linking; you don't need the unused parts of libc there because you won't be using them anyhow.
Honestly, these two images don't between themselves cover the whole matrix space of possibilities; there are situations where neither of them is optimal. There would be value to having an image with only busybox that statically links against musl libc (if everything you're going to add is in a non-C language), or an image with busybox that dynamically links against glibc (if you're going to add more binaries that need libc and aren't compatible with musl).
When I first asked the question I was not sure about the use case of busybox docker image and my link about busybox dockerfile was not entirely correct.
This was the correct dockerfile link and it explains many things. So busybox provides 3 different versions, build on glibc, musl, uclibc
A more appropriate question is what is the difference between alpine image and busybox image build based on musl? I still don't know the answer, except that alphine image is more actively maintained.
"Use Cases and Tips for Using the BusyBox Docker Official Image" was published Jul 14 2022 (so quite new) and it said "Maintaining the BusyBox image has also been an ongoing priority at Docker."
I still hope to see someone may provide answer about the use case of BusyBox image build on glibc or uclibc
--- update ---
As here discuss package manager for docker container running image busybox:uclibc "Anything based on Busybox doesn't have a package manager. It's a single binary with a bunch of symlinks into it, and the way to add software to it is to write C code and recompile." and here Package manager for Busybox also explained, busybox does NOT have package manager that is probably the reason why most poeple use alpine.
What is the difference between arm-none-eabi and arm-linux-gnueabi? I know the difference in how to use them (one for bare metal software, the other one for software meant to be run on linux). But what is the technical background?
I see there is a difference in the ABI which is, as far as I understood, something like an API but on binary level. It ensures interoperability of different applications.
But I don't really understand in which way having or not having an operating system affects my toolchain. The only thing that came to my mind is, that libraries maybe have to be statically linked (do they?) while compiling bare metal software, because there is no os dynamically providing them.
The most pages I found related to this toppic just answered how to use the toolchains but not the technical background. I'm a student of mechatronics and new to embedded systems, so my experience in this field is somewhat limited.
Maybe this link to a description will help.
Probably the biggest difference:
"The bare-metal ABI will assume a different C library (newlib for example, or even no C library) to the Linux ABI (which assumes glibc). Therefore, the compiler may make different function calls depending on what it believes is available above and beyond the Standard C library."
I have been looking for a linux distribution that is not for embedded systems and does not use many of the GNU utilities found in many popular distributions. I want to develop a (pet project) linux distribution that uses musl-libc, bsd userland, and Plan 9 from user space. Before I start and possibly waste time doing the impossible, is it feasible/practical to use the BSD userland as a replacement for GNU coreutils? If not, what is an alternative?
Your goal appears to be much close to stali project (the only difference is the BSD userland requirement).
http://sta.li/
I don't know much about the stage of this project, but you can get some help in the project mailing-list.
As far as I know, the BSD tools uses a lot of direct syscalls and little usage of the POSIX API. I don't believe that bsd guys had written code using a lot of #ifdefs to get fully compliant programs (but I can be wrong)...
The suckless site ported the plan9 userland to unix (based on plan9port too), it's called 9base (and is available on archlinux repo to install).
I think you'll have the same problem I had in the past trying to assembly a similar distro: Too much effort to get rid of GNU... The base system is easy, but for something useful you'll need a C compiler and then you're out of good alternatives. GCC is gnu and have dozens of gnu dependencies and the sane freebsd gcc port never will work on linux for obvious reasons.
My current try is help finish the ken-c (or 9-cc) port for linux.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to play around with some embedded linux. I want it to be able to run on an x86 processor (for start, it will be running on my regular PC). I have looked online, but the ones I have found seem hard to setup or lack proper documentation. So what are some good embedded x86 compatible linux distros that are easy to setup or have good documentation on how to get things setup?
Since the definition of "embedded" vary depending on who you talk to, what is considered an embedded Linux distribution will also vary.
As other have said, you can go with distribution building tool kit, like :
T2 SDE
OpenEmbedded
LinuxFromScratch
Buildroot
You can also use any "standard" Linux distribution, which can often be customized for an embedded environment. They have the advantage of being heavily tested in their normal environment. So you can choose any of :
Fedora (with Revisor, Instalinux)
OpenSuse (with SuseStudio, Instalinux)
Debian (with Reconstructor, Instalinux)
Ubuntu (with Reconstructor, Instalinux)
Gentoo
Slackware (with NimbleX)
CentOS (with Instalinux)
gNewSense (with Builder)
Finally, you can also build your own completely, from source. In that case, BusyBox will probably be helpful since it provide a lot of functionalities and common application. To help you with that, there is the nice 3 parts series : Building Tiny Linux Systems with Busybox (part 1, part 2, and part 3)
You may want to take a look at the OpenEmbedded project. It is a meta-distribution, meaning it's more of a distribution construction kit rather than ready distribution. But using it may take effort on your part. The same applies to all embedded solutions, though.
BusyBox
BusyBox is designed to be a small executable for use with the Linux kernel, which makes it ideal for use with embedded devices. It provides a fairly complete environment for any small or embedded system.
What do you actually mean by "Embedded Linux"? It depends what you want to run on that.
For example you can use OpenWRT, but there are surely others which might better fit your purpose.
If you want to build some multimedia thing, Moblin might be a solution as well.
You might want to look at the Beagle Board.
It's not x86, but decent community of developers, and it will give a good idea how to build and run embedded Linux.(i.e. flash file system, somewhat limited RAM...) and its real cheap!
I can also recommend these two books:
Building Embedded Linux Systems and
Embedded Linux Primer
I'd start by having a look at the output of the buildroot tool which comes with busybox.
You are suggesting that you want to make your own Linux distribution, this is fine but you really need to know how to use an existing one first. I am assuming you understand fully how Linux boots and works on a basic level. You'll need
Some kind of boot media (in some cases this CAN be a rom, but usually isn't) that the firmware can boot from (in most cases the firmware on x86 is some kind of bios, or bios-like - except on things like Macs)
A boot loader - I like to use syslinux because it's easy (and boots from a dos filesystem)
A kernel
A root filesystem of some kind - you can use an initramfs for this in which case, it's loaded by the bootloader and expanded at boot time. Initramfs is cool, it avoids the need for a "real" root fs or block device drivers etc (at the expense of some ram, but ram is easy).
A C library (unless all your exes are static linked)
Some userspace software
I'd strongly recommend using an emulator (such as vmware) to test this, it reduces turnaround time a lot. A development system will need to have rather a lot of disc space, as you'll probably need to compile everything in the above list, and possibly some other tools as well (such as gcc and C library) which aren't small. Your build box will probably need to be running a proper Linux distribution.
I have done this and it's good fun, but frustrating at times (debugging can be a mission in itself)
Happy hacking :)
Busybox + LFS, Gentoo, Arch all do the job well
First to you'd compile your stuff in a chroot jail on dev computer, last you don't need to compile but you need to mirror/keep your own repository because you can't get old packages from official arch repositories.
I suggest debian
Is a program shipped in assembler format portable between Linux distributions (modulo CPU architecture differences)?
Here's the background to my question: I'm working on a new programming language (named Aklo), whose modus operandi will be the classic compiling to .s and feeding the result to the GNU assembler.
Obviously it would be nice ultimately to have the implementation written in itself, but I had resigned myself to maintaining it in C++ to solve the chicken and egg problem: suppose you download the compiler for the first time and it is itself written in Aklo, how do you compile it? As I understand it, different Linux distributions and other UNIX like systems have different conventions for binary formats.
But it's just occurred to me, a solution might be to ship the .s file (well, one per CPU architecture): it's fair to assume you have or can install the GNU assembler. Of course I'd still need a bootstrap compiler, but that doesn't need to be fast; I can write it in Python.
Is assembler portable in the way that binaries are not? Are there any other stumbling blocks I haven't thought of?
Added in response to one answer:
I had looked wistfully at LLVM, there is certainly a lot of good stuff there and it would make my life easier -- except that it would incur a dependency on the correct version of LLVM being installed. It wouldn't be so bad having that dependency on development machines, but in a world where it's common to ship programs as source, the same dependency would be incurred for every user of every program ever written in Aklo, and I decided that was too high a price to pay.
But if the solution of shipping compiled programs as assembler works... then that solves that problem, and I can use LLVM after all, which would be a big win.
So the question about portability of assembler is even considerably more important than I had first realized.
Conclusion: from answers here and on the LLVM mailing list http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-January/028991.html it seems the bad news is the problem is unsolvable, but the good news is that means using LLVM makes it no worse, so I'm free to do so and obtain all the advantages thereof.
You might want to check out LLVM before going down this particular path. It might make your life a lot easier, as it provides a low level virtual machine that makes a lot of hard stuff just work and has been very popular.
At a very high level, the ABI consists of { instruction set, system calls, binary format, libraries }.
Distribution as .s may free you from the binary format. This is still rather pointless, because you are fixed to a particular ISA and still need to use libraries and/or make system calls. Libraries vary from distribution to distribution (although this isn't really that bad, especially if you just use libc) and syscalls vary from OS to OS.
It's basically 20 years since I last bootstrapped a C compiler. At the level of compilers, the differences between Linux distributions are minimal.
The much more important reason for going LLVM is cross-platform; if you're not writing some intermediate language, your compiler will be extremely difficult to retarget for different processors. And seeing as, on my laptop, I have compilers for x86, x86_64, two kinds of MIPS, PowerPC, ARM and AVR... you see where I'm going? I can compile multiple languages for most of those targets too (only C for AVR).