Методы установки приложений, компиляция приложений и ядра, библиотеки

• Через средство управления пакетами ОС (Ubuntu: apt-get, CentOS: yum, Gentoo: emerge). Пакет чаще всего имеет не последнюю версия приложения/компилятора (ruby, phantomjs), но она почти гарантированно stable и легко ставится.

Для установки приложений в среде операционной системы GNU/Linux лучше всего пользоваться средствами управления пакетами вашего дистрибутива.
Например, в Ubuntu Linux для установки клиента и сервера MySQL достаточно выполнить в терминале команду:
sudo apt-get install mysql-client mysql-server
В Fedora/RHEL
yum install mysql mysql-server

• Через готовый бинарный файл приложения для вашей версии ОС/ядра ОС. Тут мы зачастую получаем последнюю версию, но с запуском/установкой возможны проблемы из-за разных зависимостей.

Если же вы по каким-то причинам не хотите устанавливать MySQL средствами дистрибутива, можно воспользоваться готовыми бинарными пакетами для Linux, доступными на странице http://dev.mysql.com/downloads/mysql/

• Через исходник собираем/компилируем используя утилиты configure (логи обычно пишуться в config.log), make, make install. Есть так же врапперы, которые объединяют все три (напр. autotools).
  • Желательно (не более чем рекомендация) собирать тут: /usr/src

(Опция) скрипт ./install_prereq install - установка зависимостей отдельным скриптом, есть далеко не во всех пакетах (есть например в asterisk, но и там нет автоподключения нужных репозиториев для библиотек для установки для rocky linux, при этом на debian это подключение не потребовалось), называется по разному, может иметь разные опции

(Иногда опция) Скрипт ./configure - Prepare(setup) environment for building ((подготовка к компилированию - проверка необходимых для компилирования зависимостей (компилятора/библиотек/утилит, включая make), подготовка make файла с параметрами системы для компиляции)). This script has lots of options that you should change. Like --prefix or --with-dir=/foo. That means every system has a different configuration. Also ./configure checks for missing libraries that should be installed. Anything wrong here causes not to build your application. configure may fail if it finds that dependencies are missing.

Утилита make / ninja - Building the system 
((компилирование на основе подготовленного make файла
- для ускорения make в несколько потоков можно воспользоваться указанием количества ядер -j$(nproc))
- для ускорения ninja ничего указывать не нужно т.к. он по умолчанию собирает на всех ядрах, но можно указать количество ядер для замедления/уменьшения потребляемых ресурсов при сборке через -j$(nproc))
This is actually make all by default. And every make has different actions to do. Some do building, some do tests after building, some do checkout from external SCM repositories. Usually you don't have to give any parameters, but again some packages execute them differently.

Утилита make с флагом install - Install to the system ((переносит бинарные файлы и файлы конфигураций в системные или указанные при configure директории))
This installs the package in the place specified with configure. If you want you can specify ./configure to point to your home directory. However, lots of configure options are pointing to /usr or /usr/local. That means then you have to use actually sudo make installbecause only root can copy files to /usr and /usr/local.

Here one can use autotools, that means ./configure, make and make install.


(Опция) Утилита make с флагами отличными от install - иногда позволяют создать примеры файл конфигураций (make samples) или предложить развернуть типовые сценарии деплоя (make basic-pbx) или развернуть документацию (make progdocs) очистить систему от промежуточных файлов/настроек (make clean , make mrproper), к примеру asterisk:

Процесс в целом не сложный – ищем архив с исходным кодом и компилируем его в ручную. Может потребоваться много времени (30 минут это норма) и сил (dependency hell) для установки. Так же сборка может требовать большое количество ОП и прерываться oom kill если в системе недостаточно памяти.

Там же можно найти и архив с исходным кодом MySQL для самостоятельной компиляции СУБД. Но такой подход к инсталляции пакетов популярного и общедоступного (присутствующего в репозиториях многочисленных Linux-дистрибутивов) программного обеспечения строго не рекомендуется.

'build' finished successfully (35m45.129s)

[1739/1907] Compiling ../src/core.cpp
gcc: fatal error: Killed signal terminated program cc1
compilation terminated.

[ 3478.001521] Out of memory: Kill process 6092 (cc1) score 429 or sacrifice child
[ 3478.001557] Killed process 6092 (cc1) total-vm:1901712kB, anon-rss:279800kB, file-rss:0kB, shmem-rss:0kB

Пример сборки Python3.7 из исходника на Debian 9. Причем сборка с кучей самотестов и анализом load avg.

running build_scripts
creating build/scripts-3.7
Run tests sequentially

0:00:00 load avg: 1.53 [  1/416] test_grammar
0:00:00 load avg: 1.53 [  2/416] test_opcodes
0:00:00 load avg: 1.53 [  3/416] test_dict
0:00:00 load avg: 1.53 [  4/416] test_builtin
0:00:01 load avg: 1.53 [  5/416] test_exceptions

Пример сборки netmap (подробнее о нем и других примерах ниже в отдельных статьях).

https://github.com/luigirizzo/netmap
cd netmap-master
chmod -R 777 *
./configure
# alternate actual Intel X710 Drivers 
./configure --select-version=i40e:2.17.4
make
sudo make install

Пример ручной сборки ntttcp.

sudo apt-get update
sudo apt install git
sudo apt install gcc 
git clone https://github.com/Microsoft/ntttcp-for-linux cd ntttcp-for-linux/src 
make && make install

Пример сборки TRex.

# TREX 
mkdir -p /opt/trex cd /opt/trex 
#LATEST-VER 
git clone https://github.com/cisco-system-traffic-generator/trex-core.git #SPECIFIC-VER 
git clone https://github.com/cisco-system-traffic-generator/trex-core.git -b v2.89 cd trex-core/linux_dpdk/ 
./b configure 
./b build

Пример сборки hex инструментов

git clone https://github.com/ZerBea/hcxdumptool.git
cd hcxdumptool
make
sudo make install

git clone https://github.com/ZerBea/hcxtools.git
cd hcxtools
make
sudo make install

Owamp

$ git clone https://github.com/perfsonar/owamp.git
$ cd owamp/
$ git submodule update --init
$ apt install automake
$ ./bootstrap
$ ./configure --prefix=/usr/local
$ make ## no errors here
$ make install

 

Разделяемые библиотеки на уровне системы Библиотеки / library

• • В Linux так много системных библиотек, одних директорий только в которых могут быть библиотеки не мало (от одной директории lib как самой главной до как минимум 4 в актуальных системах; библиотеки находятся в /usr/, но линки на них сделаны в / и могут быть и в других местах)
  • Расширение .so,
  • Следит/собирает их в каталог library daemon – ld с конфигом в /etc/ld.so.conf.d)
  • Обычно внутри директории с библиотеками содержится короткое имя библиотеки и одна или несколько версий этой библиотеки, на одну из которых ссылается короткое имя.
  • Есть так же очень полезная команда ldd (library daemon dependencies), которая показывает какие библиотеки использует приложение.
  • Для установки библиотек не рекомендуется просто копировать их в системные директории через cp, рекомендуется копировать их в локальную для  пользователя директорию lib (точно так же как и бинарные файлы в локальную bin) и указывать новую директорию для поиска ldconfig (командой ldconfig -n /home/user/lib или созданием конфига с путем к новой директории в /etc/ld.so.conf.d).
    • особенно это относится к таким библиотекам как libc, которые зачастую скрываются под одной версией (по названию файла)
      • libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb26ce1f000)
      • libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f375581f000)
    • и могут поломать ВСЕ приложения системы – если удалить/подменить файл библиотеки libc.so.6 может поломаться полностью система.

# ls /
bin lib mnt sys
boot lib32 opt tmp
dev lib64 proc usr
etc libx32 root var
home log.conf run vmlinuz
initrd.img lost+found sbin vmlinuz.old
initrd.img.old media srv

# ls /usr/lib/libdiscover.so.2* 
/usr/lib/libdiscover.so.2 
/usr/lib/libdiscover.so.2.0.1 

# ldconfig - v 
/usr/local/lib: /lib/x86_64-linux-gnu: librte_latencystats.so.18.11 -> librte_latencystats.so.18.11 librte_pdump.so.18.11 -> librte_pdump.so.18.11 libapparmor.so.1 -> libapparmor.so.1.6.0 libfastjson.so.4 -> libfastjson.so.4.2.0 libncursesw.so.6 -> libncursesw.so.6.1 libgcc_s.so.1 -> libgcc_s.so.1 … 

# cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf 
# Multiarch support 
/usr/local/lib/x86_64-linux-gnu 
/lib/x86_64-linux-gnu 
/usr/lib/x86_64-linux-gnu 

# type ping 
ping является /usr/bin/ping 

# ldd /usr/bin/ping 
linux-vdso.so.1 (0x00007fffdd497000) 
libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007f0935322000) 
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0935162000) /lib64/ld-linux-x86-64.so.2 (0x00007f093557b000) 

Хорошее описание, зачем используется LD_LIBRARY_PATH – переопределение библиотек.

- LD_LIBRARY_PATH contains a colon separated list of paths and the linker gives priority to these paths over the standard library paths /lib and /usr/lib. The standard paths will still be searched, but only after the list of paths in
- LD_LIBRARY_PATH has been exhausted. The best way to use LD_LIBRARY_PATH is to set it on the command line or script immediately before executing the program. This way the new LD_LIBRARY_PATH isolated from the rest of your system.
- LD_LIBRARY_PATH is the predefined environmental variable in Linux/Unix which sets the path which the linker should look in to while linking dynamic libraries/shared libraries.

 

Статическая линковка

Статическая линковка (static linking) — это процесс, при котором все необходимые код и библиотеки для программы объединяются в один исполняемый файл во время компиляции. Код внешних библиотек (статических библиотек) напрямую встраивается в итоговый исполняемый файл.

• Позволяет в одном бинарном файле иметь все (по факту почти все) зависимости
  • Почему “все” – чаще всего включенных библиотек в бинарный файл достаточно для работы в другой системе.
  • Почему почти все – подробнее ниже (проблемы при статической линковке)

 

Простая статическая линковка

В целом для статической линковки обычно нужно

• • установить библиотеки для статической линковки (прежде всего libc и libpthread).

apt-get install build-essential git libc6-dev

• • указать флаг STATIC, но вот где его указывать может отличаться:
    • для configure – при подготовке к компиляции
    • для make – на входе в компиляцию
    • для gcс (т.е. напрямую в комилятор) – в том числе глобальная сборка может игнорировать флаг static и для конкретного файла который вам нужен статическим придется запускать gcc

Указываем только при make:

git clone https://github.com/ColinIanKing/stress-ng.git
cd stress-ng
make STATIC=1 -j$(nproc)

Указываем только при config/configure:

wget https://github.com/openssl/openssl/releases/download/openssl-3.4.0/openssl-3.4.0.tar.gz
tar -xzvf openssl-3.4.0.tar.gz
cd openssl-3.4.0
./config --prefix=/usr/local/openssl-static --openssldir=/usr/local/openssl-static no-shared -static
make -j$(nproc)

Указываем и при configure и при make:

git clone https://github.com/axboe/fio.git
cd fio
./configure --build-static
make LDFLAGS="-static" -j$(nproc)  # собрать все утилиты со статической линковкой
make fio LDFLAGS="-static" -j$(nproc) # собрать только fio со статической линковкой

В исключительных случаях указываем напрямую gcc:

gcc -O3 -static test/speedtest1.c sqlite3.c -o speedtest1 -lpthread -ldl -lm

Проверка линковки

# ldd ./fio
not a dynamic executable
# file ./fio
fio: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=0e42b6794b198df2fe01014e4244317afa4fc885, for GNU/Linux 3.2.0, with debug_info, not stripped

Можно уменьшить размер файла удалив информацию по отладке с использованием strip утилиты/strip library.

# strip ./fio

strip is a shell command for removing information from binary executable programs and object files that is not required for execution – typically including debugging data, symbol tables, relocation information, and other metadata. The resulting file will have a smaller size. This is also known as a stripped binary.

Проблемы при статической линковке

• • При статической линковке порядок библиотек в команде сборки имеет решающее значение. Библиотеки, от которых зависят другие (в данном случае pthread и dl), должны стоять в самом конце списка. Сталкивался с этим при компиляции ab.

  • по факту при дефектный статической линковке собрать файл со всеми полностью библиотеками может не получилось из-за отсутствия статической библиотеки libudev.a , от которой зависит libhwloc , но почти полностью статические бинарные файлы при этом могут работают на разных системах (сталкивался с подобным при сборке will-it-scale – собрал со всеми статическими библиотеками кроме libudev) 

git clone https://github.com/antonblanchard/will-it-scale.git
cd will-it-scale
make LDFLAGS="-Wl,-Bstatic -lhwloc -lxml2 -lz -Wl,-Bdynamic /lib/x86_64-linux-gnu/libudev.so.1 -lpthread -ldl -lm" 

• • • по факту при дефолтной статической линковке с использованием glibc можно столкнуться с ситуацией когда в бинарный файл не включаются все зависимости и она падает,
      • в таком случае может помочь сборка с использованием musl (с glibc/gcc падает с segmentation fault статически слинкованный netperf на Debian 13, а с musl/musl-gcc работает),
      • но это сработает не всегда – к примеру собрать nginx не получилось через musl (не собирается openssl с разными ошибками), возможно будет достаточно сборки со всеми статическими библиотеками кроме динамической glibc (т.е. не используем –with-ld-opt=”-static”)

# NETPERF
git clone https://github.com/HewlettPackard/netperf
cd netperf/
./autogen.sh
# glibc
./configure LDFLAGS="-static"
make
# musl
apt install musl-tools -y
CC=musl-gcc ./configure LDFLAGS="-static"
make


# NGINX
- проблема с конфигурациями указанными в бинарном файле - решается указанием путей для configure
- проблема с segmentation fault на debian 12 при полностью статических библиотеках glibc (--with-ld-opt="-static") - сборкой с динамической glibc (т.е. не используем --with-ld-opt="-static”); вариант собрать через musl не сработал т.к. с musl не собирается openssl с разными ошибками
Ошибка Segmentation fault при запуске полностью статического бинарника на Debian 12 (при сборке на Debian 11) чаще всего вызвана тем, как статический glibc обрабатывает функции сетевого имени (DNS) и пользователя (nsswitch). В современных дистрибутивах статическая линковка glibc (через -static) считается «условно-статической», так как функции getpwnam или getaddrinfo все равно пытаются загрузить библиотеки libnss_* из системы в рантайме, что приводит к краху при несовпадении версий или окружения.
mkdir ~/nginx-build && cd ~/nginx-build
tar -xzvf nginx-1.24.0.tar.gz
tar -xzvf openssl-3.0.8.tar.gz
tar -xzvf pcre-8.45.tar.gz
tar -xzvf zlib-1.2.13.tar.gz
cd nginx-1.24.0
mkdir -p /root/nginx-portable/logs
mkdir -p /root/nginx-portable/temp
./configure --prefix=/root/nginx-portable \
--sbin-path=/root/nginx-portable/nginx \
--conf-path=/root/nginx-portable/nginx.conf \
--with-pcre=../pcre-8.45 \
--with-zlib=../zlib-1.2.13 \
--with-openssl=../openssl-3.0.8 \
--with-http_ssl_module \
--with-http_v2_module \
--with-http_gzip_static_module \
--with-cc-opt="-static-libgcc"
make -j 4
sudo make install
file objs/nginx

ldd objs/nginx
linux-vdso.so.1 (0x00007f158df21000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f158df13000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f158df0e000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f158ded2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f158d61f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f158df23000)

• • (методы установки приложений, DPDK) полностью статический бинарный файл dpdk-testpmd собрать получилось с большим трудом (проблемы с зависимостями отличными от DPDK – libnuma.so и libatomic.so , а так же библиотекой bpf и с драйверами crypto/nic), но по итогу получилось (STATICALLY LINKED) и как альтернатива частично статичный бинарный файл (PARTIAL STATICALLY LINKED) корректно работает на Deb11 и Deb12 при указании сохраненных с исходной системы libnuma.so.1 и libatomic.so.1 в LD_LIBRARY_PATH

# установка DPDK через компиляцию
apt install build-essential python3-pip ninja-build libnuma-dev python3-pyelftools
pip3 install meson
wget http://fast.dpdk.org/rel/dpdk-23.11.1.tar.xz
tar xf dpdk-23.11.1.tar.xz
cd dpdk-stable-23.11.1/
# PARTIAL STATIC LINKED! 
meson setup build -Ddefault_library=static -Dcpu_instruction_set=generic
ninja -C build
# STATICALLY LINKED (without problem bpf lib and crypto/nic drivers)
rm -rf build
meson setup build \
--default-library=static \
-Dbuildtype=release \
-Dcpu_instruction_set=generic \
-Ddisable_libs=bpf \
-Ddisable_drivers=crypto/*,net/bnx2x,net/sfc
ninja -C build
# дальнейшая сборка только конкретного файла включая проблемные lnuma и libatomic прямым вызовом gcc
gcc -static -o dpdk-testpmd-static \
-Wl,--whole-archive \
build/app/dpdk-testpmd.p/*.o \
build/drivers/librte_*.a \
build/lib/librte_*.a \
-Wl,--no-whole-archive \
-Wl,--start-group \
-lnuma -ldl -lrt -lm -lpthread -latomic -lz \
-Wl,--end-group \
-Wl,--allow-multiple-definition

# создание hugepages без скриптов
echo 1024 | tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

# Запуск dpdk-testpmd
# (1) Запуск теста AF_PACKET PMD: DPDK через стандартные драйверы ядра (медленный путь)
ip link set ens32 up
ip link set ens33 up
dpdk-testpmd -l 0-1 --vdev 'eth_af_packet0,iface=ens32' --vdev 'eth_af_packet1,iface=ens33'
# (2) Запуск теста VIRTIO_USER PMD. Согласно логике DPDK, первое ядро в списке (1) становится сервисным (master core), а второе (2) — рабочим (forwarding core).--nb-cores=1: Явное указание использовать ровно одно рабочее ядро для генерации трафика. -l 1-2: Мы выделили только два ядра. т.е. нулевое ядро не задействуется и оставлено под систему.
modprobe tun
modprobe vhost-net
{ sleep 5; echo "stop"; sleep 1; echo "quit"; } | ./dpdk-testpmd-static -l 1-2 -n 4 \
--vdev 'net_virtio_user0,path=/dev/vhost-net' \
--vdev 'net_virtio_user1,path=/dev/vhost-net' \
-- \
-i --forward-mode=txonly \
--nb-cores=1 \
--auto-start
# (3) Запуск теста virtio-pci PMD не долучилась в VM, это потенциально наиболее интересный драйвер (приближен к реальному железу), но решить проблему с запуском в виртуализированной среде не получилось - проблема с lockdown в VM (dmesg | grep -i "lockdown") , который блокирует работу драйверов прямого доступа к железу (UIO и VFIO No-IOMMU)

 

 

musl vs glibc

• при сборке если задать переменную CC=musl, а потом забыть ее убрать, можно долго траблшутить проблемы “Почему не собирается приложение” т.к. по умолчанию будет использоваться musl-gcc для сборки вместо gcc

- Для широкого применения, с glibc меньше шансов, что что-то сломается. Для конкретного случая использования это может быть не так важно. Если сильно обобщать (и это опасно), musl обычно потребляет меньше ресурсов, но glibc быстрее. Если используется ARM или очень ограниченное железо, musl может быть на самом деле быстрее, но с большим количеством доступных ресурсов glibc обычно выигрывает, часто за счёт нестандартных оптимизаций (жульничества).

- Musl = норм, но ещё сыроват, много проблем с сетью / 
- Glibc = ну такое, зато стабилен как скала

- Все преимущества (немного меньший размер, немного быстрее на слабом железе, лучшая безопасность, возможность тестировать ваши приложения на musl (если вы разработчик) и немного более организованная структура (полезно для разработчиков, если вы не понимаете, что ваше приложение не будет работать на 99% дистрибутивов, если вы решите написать его с учётом musl)) меркнут по сравнению с тем, что большинство приложений сломаны.
musl может быть отличным, если вы реанимируете ноутбук вашей бабушки с 2010 года и вернете его к жизни. Но все, что связано с рендерингом, будет зависеть от glibc. Приложения, такие как игровые движки AAA (UE5, GODOT, UNITY), зависят от glibc. То же самое с Proton и другими видеоиграми. 

 

сборка ядра linux

• Ускорение сборки (запуск на всех ядрах) через -j “$(nproc)” полезно при сборке ядра Linux, даже с учетом этого сборка занимает ~2-3 часа (Debian 11 – 2, Debian 13 – 3)

  # make -j "$(nproc)"
  # top
     %Cpu0  : 94.1 us,  5.9 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
     %Cpu1  : 92.2 us,  7.8 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
     %Cpu2  : 92.1 us,  7.9 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
     %Cpu3  : 92.1 us,  7.9 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

• Переходим в директорию /usr/src/kernels , качаем с kernel.org архив с исходниками ядра в tgz , распаковываем

• В целом компиляцией ядра из исходников на kernel.org или из других мест занимаются редко, но есть сообщества-исключения (gentoo)
  
  • чаще ставится какой то дистрибутив, а к нему при необходимости доустанавливаются необходимые модули/драйвера (RAID/сетевые/другие) через патч производителя к определенному дистрибутиву (или наиболее близкому к рекомендуемому, как я в случае с TRex взял что-то близкое и в конфиге TRex подменил ядро на поддерживаемое)
  • для разработчиков есть develop версия (исходники), которая позволяет после работы с исходниками сформировать patch
• При сборке ядра нужно понять откуда взять конфигурацию ядра  (.config)
  • Если установлена Debian ОС (аналогичная компилируемой), то для конфигурации ядра можно воспользоваться конфигурацией, поставляемой с ОС на которой осуществляется сборка. Для этого можно
    • выполнить команду make menuconfig. При ее выполнении сборочная система ядра инициализирует конфигурацию (файл .config), используя конфигурацию ядра установленной системы (файл /boot/config-$(uname -r))
    • либо можно скопировать конфигурацию ядра от вашей ОС в текущую директорию как файл с именем .config : $ cp /boot/config-$(uname -r) ./.config
    • Чтобы при сборке ядра не получать вопросы о не инициализированных опциях ядра, можно выполнить следующую команду, которая проинициализирует не выставленные опции значениями по умолчанию: $ make olddefconfig
  • Для создания конфигурации ядра удобно так же использовать графическую версию make (make xconfig) или псевдографическую версию (make menuconfig) утилиту в сравнению с классическим make config (можно выбрать только интересующееся, не отвечая на все вопросы/возвращаться и проч)

  • 

    

    

• Если при сборке ядра появляются ошибки ssl/ругается на сертификаты то можно попробовать занулить в make файле указание на pem ключ
• При успешной сборке ядра используя стандартные инструменты они прописывают его в grub
• После сборке ядра есть возможность те модули, которые можно поставить как модули, дособрать (включая зависимые для них модули) путем приписывания в конфиг и прописать make modules, make modules install
• Сборка ядра в deb пакет (пакеты будут в корневой директории от текущей), последующие deb пакеты можно установить через dpkg (вместо * указать конкретные файлы):

make -j "$(nproc)" bindeb-pkg

dpkg -i linux-headers-*
dpkg -i linux-image-*

• (препод LPIC) На старых ядрах зачастую была проблема с тем, что определенным сетевым пакетом или еще каким то действием на систему можно было выгрузить модуль (напр. модуль firewall) с последующей работой без этого модуля, поэтому рекомендовалось компилировать функционал в ядро, а не ставить как модуль

Из чего состоит компиляция

• Выбор глобальных для системы настроек, таких как
  • разрядность – 32-ух битные ядра по факту еще нужны, бывают очень жесткое legacy (препод LPIC)
    • кофейный аппарат на базе linux (старый, американский, но очень крутой), для изменения количества подаваемого кофе (поменяли чашки кофе на чуть-меньше) пришлось провалится по telnet на linux, через vi отредактировать файл конфигурации с режимом варки/размеров кружки
    • ткацкие фабрики (в целом промышленность) – перфокарты с возможностью апгрейда в 200х на дискеты (мы стали, немцы не стали); заменить производственную линию с таким оборудованием – огромные бюджеты
    • чтобы отказаться от настройки поездов в Токийском метро через дискет требуется огромный бюджет
  • настроки NUMA
  • initramfs
  • SWAP
• Возможность выбора по дополнительному функционалу/драйверам (Bluetooth, CD/DVD-ROM, RAID, NIC разных вендоров и прочие драйвера), которые устанавливаются в Linux ядро:
  • скомпилировать в ядро
  • установить как модуль
  • не устанавливать вообще