Предлагаю вашему вниманию небольшую ретроспективу эволюции загрузчиков. Текст носит обзорный характер и не претендует на исчерпывающее описание всех исторических и технических деталей, так как я познакомился с Linux только в 2010-х, а понимание его работы пришло сильно позже. Если у вас есть интересные дополнения — добро пожаловать!

Загрузчик — это программный компонент, который запускается после инициализации BIOS в legacy системах. Он отвечает за передачу параметров и загрузку ядра ОС, решает проблемы совместимости с железом (например, с дисками, файловыми системами), обеспечивает безопасность (шифрование, верификацию) и гибкость (поддержку нескольких ОС). В контексте Linux, где дистрибутивы часто кастомизируются, загрузчик — ключевой компонент для стабильности и удобства.

В 1992 Вернер Альмесбергер начал разработку первой версии загрузчика для Linux — LILO (LInux LOader), поддержка которого прекратилась в 2015 году, был хорошим загрузчиком для своего времени и отличался простотой настройки, но имел несколько недостатков. Один из них – он не мог читать файловую систему. Следовательно, ему было необходимо знать точные физические адреса (сектора на диске) ядра. Это накладывало определенные ограничения. Например, после обновления ядра требовалось переконфигурировать и сам загрузчик, иначе можно было “сломать” процесс загрузки. Также LILO устанавливался в MBR, что препятствовало его использование на дисках объёмом >2TB.

LILO был стандартом в дистрибутивах вроде Slackware, ранних Red Hat и Debian. По мере усложнения Linux-систем и увеличения количества поддерживаемых конфигураций ограничения LILO становились всё более критичными. Это привело к появлению и последующему распространению загрузчика GRUB.

GRUB поддерживал жесткие диски бОльших объёмов, упрощал настройку мультибута и позволял загружать ядро без жёсткой привязки к секторам, благодаря чему изменения в /boot не ломали загрузку операционной системы. Также в GRUB появился интерактивный командный интерфейс для ручного восстановления (rescue shell) и поддержка загрузки по сети. 

Широкое распространение GRUB объясняется сочетанием универсальности, гибкости и активной поддержки со стороны сообщества. Загрузчик оказался способен адаптироваться к быстро меняющемуся окружению Linux и новым файловым системами. Большинство дистрибутивов приняли GRUB в качестве загрузчика по умолчанию, что укрепило его позиции и обеспечило фактический статус отраслевого стандарта.

Таким образом, GRUB стал логичным этапом эволюции загрузки Linux, заменив простые, но ограниченные решения предыдущего поколения более сложным, но значительно более функциональным механизмом. Однако у него были и минусы.

GRUB часто критиковали за то, что архитектура загрузчика была значительно усложнена а объём кода был большим, из-за чего усложнялась поддержка, анализ и сопровождение. Для компонента, работающего на раннем этапе загрузки системы, это считалось нежелательным. Также возросла сложность конфигурации, что требовало более глубокого понимания процесса загрузки.

Развитие GRUB в рамках первоначальной архитектуры оказалось затруднительным, что привело к поискам альтернатив и появлению новой версии загрузчика — GRUB 2. 

Появление GRUB 2 стало попыткой переосмыслить архитектуру и устранить ограничения, накопившиеся в классической версии. GRUB 2 не является прямым продолжением первой версии, а представляет собой фактически полностью переписанный загрузчик с иной внутренней структурой.

Главным отличием стала модульная архитектура. Вместо одного бинарного файла новая версия использует набор модулей, которые загружаются только по необходимости. Это позволяет легче расширять функциональность и упрощает поддержку новых файловых систем и железа. Дополнительно  была изменена система конфигурации. Основной конфиг в новой версии генерируется автоматически на основе скриптов и шаблонов, что, в свою очередь, снижает риск ошибок, но делает ручное редактирование менее очевидным. 

Во второй версии была добавлена поддержка UEFI, GPT, сложных систем хранения данных, например, RAID, а также шифрование и сжатие.

В итоге GRUB 2 стал универсальным загрузчиком, способным работать в самых разных средах — от домашних ПК до серверов с нестандартными конфигурациями дисков. Все эти качества сделали GRUB 2 логичным выбором для большинства дистрибутивов Linux в эпоху UEFI и крупных дисков.

Но при всех своих преимуществах GRUB 2 унаследовал и некоторые проблемы своего предшественника. Пожалуй, самая главная из них — это сложность. Кодовая база стала еще больше, она насчитывает более полумиллиона строк. Это означает, что GRUB 2 предлагает значительно больше функциональности, чем действительно необходимо большинству пользователей. К тому же в последние годы в нём было обнаружено множество уязвимостей среднего и высокого уровня, что вызывает растущую критику загрузчика. Возможно, это говорит о том, что проверенный временем загрузчик уже исчерпал себя. Но есть ли альтернативы?

Конечно, есть. Распространение UEFI и постепенный отказ от legacy BIOS позволили пересмотреть саму роль загрузчика, сместив фокус с универсальности на минимализм и безопасность.

Одним из таких решений стал systemd-boot — простой UEFI-загрузчик, изначально развивавшийся под именем Gummiboot. В отличие от GRUB, systemd-boot не пытается быть универсальным и не содержит собственной логики работы с файловыми системами. Он использует возможности UEFI для загрузки заранее подготовленных EFI-приложений, а конфигурация сводится к набору текстовых файлов в стандартном каталоге. Такой подход значительно снижает сложность, уменьшает объём исполняемого кода и делает процесс загрузки более предсказуемым.

Другим популярным решением является rEFInd, ориентированный прежде всего на удобство и визуальную навигацию. rEFInd автоматически обнаруживает установленные операционные системы и ядра, предоставляя пользователю графическое меню выбора. Хотя он не столь минималистичен, как systemd-boot, rEFInd демонстрирует альтернативный подход, в котором упор делается на простоту использования, а не на сложную конфигурацию.

Более того, есть ещё более радикальный вариант — EFI stub. В этом случае ядро Linux само компилируется как EFI-приложение и может быть загружено напрямую прошивкой UEFI, без промежуточного загрузчика. Логическим развитием этой идеи стали Unified Kernel Images (UKI) — единые образы, объединяющие ядро, initramfs и параметры загрузки в один подписанный EFI-файл.

Для стандартизации этих подходов была предложена Boot Loader Specification (BLS), определяющая единый формат описания загрузочных записей. BLS позволяет отделить управление ядрами от конкретного загрузчика, упрощает обновления и снижает необходимость сложной генерации конфигураций. В результате загрузчик превращается в минимальный механизм выбора и запуска заранее подготовленных образов.

Таким образом, эволюция загрузки Linux прошла полный цикл: от простых и жёстко ограниченных механизмов к сложным и универсальным решениям, а затем — к осознанному упрощению и минимализму. Современный тренд — переход от одного «всезнающего» загрузчика к набору разделённых компонентов, где каждый отвечает за свой узкий круг задач. Этот сдвиг отражает общее направление развития Linux-экосистемы: от функциональности любой ценой через эпоху максимальной гибкости к приоритетам безопасности, предсказуемости и лёгкого сопровождения. Вероятно, в будущем роль традиционных загрузчиков будет только уменьшаться, уступая место интегрированным и минималистичным образам.