Usually, when you are using Linux on a desktop, you are actually working with a specific Linux distribution like Ubuntu, Debian, Suse, Fedora, or similar. There are more than 100 distributions available, most of them with a specific purpose, for example, best hardware support, easiest installation, most stable software, and so on. Distribution means that someone has assembled a large collection of software, has subdivided all the software into small packages and makes these packages available as a software repository. You can decide what packages to use and you can download and install additional packages later at any time and you can also uninstall unused packages. The distribution also provides updates, such as fixing security issues or having newer versions with additional features available.

This results in a very flexible and universal system that is suited for nearly every purpose. However, if you want to use an embedded system, you most probably have a specific application in mind. And in such a case a full-blown distribution also has a few disadvantages. 

● A distribution is mainly targeted for desktops. This means installation, configuration and usage often imply some kind of display and many components imply that they can show their output on a Graphical User Interface (GUI).

● This also means that all components use a very comprehensive configuration. For example, a web browser will support 3D, Web Assembly, multimedia, and similar stuff, resulting in a rather large binary. And this binary will pull in a lot of libraries and thus a lot of additional packages. So even if you know that you will never need 3D, you can not uninstall the 3D library package alone because you could not start the browser without this library. Therefore, the package manager of the distribution will automatically uninstall the browser package, too, if you uninstall the 3D library. This means a distribution can not easily be stripped down to a small system that is specifically targeted for your application. You have to carry a lot of extra ballast around that can also cause additional security issues, even if you never use it.

● Distributions often start a lot of background services that are not required on an embedded system. This slows down the boot process and increases the RAM footprint unnecessarily.

● A generic distribution for ARM often does not support specific hardware features of specific SoC variants. Then you probably can not use hardware-accelerated video decoding or similar things.

An Embedded Linux System basically does not differ from a regular Desktop Linux System. It uses the same source code, it uses the same compilers and software tools and it even uses the same Userland packages. However, there are often some constraints that need attendance.

● Embedded Systems usually have less RAM. It is counted in megabytes, not gigabytes. This requires to keep the system small, only start those background services that are really necessary, sometimes software is even optimized for size instead of speed. Also, leave out unnecessary parts of software. For example, if you know that your application will never need 3D features or web assembly, you can compile a smaller version of the web browser without these elements.

● Embedded Systems usually do not have a hard disc drive, only small flash media. So a full-blown distribution that needs several gigabytes of storage is most probably not appropriate. Even the hundreds of common command-line tools take too much space and are often replaced by a compact single tool called Busybox.

● Embedded Systems are often battery-powered. So it is important that all power-saving functions actually work. Sleeping modes like Suspend-to-RAM are essential and fast wake-up features need to be implemented. On the desktop, this is often not a priority topic.

● Embedded Systems are often connected to industrial buses like serial ports, SPI, I²C, CAN, and similar, but do not have many PCI lanes, if any at all. So common hardware extensions known from PCs can not be used. On the other hand, the SoCs in Embedded devices have lots of built-in periphery, so that additional external hardware is often not necessary at all. This means different device drivers are needed compared to a regular desktop PC.

Linux is an Open Source Operating System. This means the source code of the Linux kernel itself and also of thousands of userspace applications, the so-called Userland, is available for free. Linux is running on most CPU architectures, including x86 and ARM, but also on many other architectures from small CPUs for IoT devices (Internet-of-Things) to large Main Frames and High-Performance Computers (HPC). Linux is feature-rich and fully scalable. The number of applications is correspondingly diverse.

● Set-top boxes, media players, DVD/Blu-ray players, TVs
● Network devices, routers
● Storage devices (NAS)
● Home automation
● Industrial and medical applications

The Linux kernel including the device drivers also forms the basis for Android, so in principle, all Android devices, i.e. smartphones, tablets, etc., are also Linux devices. In fact, most people already use Linux devices, perhaps without knowing it.

All these applications ensure that Linux continues to evolve at a rapid pace. Video and audio codecs are often available for Linux first, also WLAN and Bluetooth drivers. In fact, nowadays even Linux itself is the first OS available for most Systems on Chip (SoC), because the SoC manufacturers use Linux to test and verify their hardware. So when the chip is released to the public, there is also immediately the first version of all necessary Linux device drivers available. Linux development is done by the “Community”. On one hand, the Community consists of professional software developers who are employed by companies and earn their money by developing software for Linux. On the other hand, there are many private enthusiasts who contribute code to Linux that they developed in their spare time. In this way, about every nine to ten weeks a new version of the Linux kernel is released. This is the so-called Mainline Kernel.

Despite this variety of people working on the kernel, the quality is at a very high standard. If you want to contribute a change to the kernel, you must first post it to a mailing list. There the code is checked by many people for bugs, shortcomings, and even coding style. In most cases, there are still complaints and the code has to be revised again. Often several iterations of these revisions have to be performed until the code satisfies the requirements of the kernel maintainers and is then actually integrated into the next kernel release.