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

Никаких заморочек с загрузочными секторами и множественными вариантами загрузки.

должен присутствовать системный EFI раздел, форматированный в FAT.

О да, никаких заморочек с бутсектором, зато требуется целый загрузочный раздел вместо него.

никаких заморочек с с:\boot.ini, зато требутся целый /usr вместо него

О да, никаких заморочек с бутсектором, зато требуется целый загрузочный раздел вместо него.

GRUB на GPT всегда требует дополнительный раздел, и что? А на MBR речь о костылях, поскольку загрузчик ставится фактически не только в эти жалкие 512 байтов, а в пустое место до первого раздела. Как там было в юникс-вэй — явное лучше неявного?

GRUB никуда гвоздями не прибит, ты можешь его патчить (на жёстком диске) как угодно или вообще выбрать другой загрузчик (например LILO, или вообще MBR от доса в 512 байтах, ведь линукс тоже никуда гвоздями не прибит). Собственно, таблица разделов (MBR/GPT/BSD/ещё какая) тоже опциональна, её парсит загрузчик (который ты можешь менять). Единственное, что прибито гвоздями - это необходимость наличия исполняемого кода в первом секторе диска.

А UEFI претендует на официальное апи прошивки материнки, требует сразу целый раздел безальтернативно с нужной ему фс (нативно-линуксовые не поддерживает например, хотя это уже мелкие придирки на фоне того, что он вообще хочет этот раздел), ну и таблицу разделов понятного ему формата.

А UEFI претендует на официальное апи прошивки материнки

И сравнительно успешно.

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

Линуксовые ФС никто не запрещает, нужен драйвер в прошивке. FAT32 — это требование, но не ограничение. Меня лично раздражает именно то, что кроме Apple никого не смущает использование FAT32 :/

и таблицу разделов понятного ему формата

Я не вижу ничего плохого в том, что хотя бы формат таблицы разделов стал общим. Какая-нибудь BSD disklabel не имеет достаточно веских технических преимуществ, чтобы плодить этот зоопарк.

нужен драйвер в прошивке

Это звучало бы хорошо, если бы драйвер надо было класть на жёсткий диск для ОС. Но тут для поддержки своей ОС надо патчить прошивку - это фейл апи. Апи прошивки должно быть максимально универсальным и не зависеть от ОС. Поскольку свести требования к нулю всё-таки невозможно, требовать от ОС один единственный сектор - нормальное решение.

Да и зачем дублировать функционал? Драйвер фс есть в ядре ОС. Раз уж мы сняли с прошивки её иммутабельность, стабильность и универсальность, допускаем её оперативный патчинг под задачи компа - давайте лучше сразу линукс-ядро (на серверных материнках - бсд-ядро) туда засунем, дописав в него код для инициализации железа (то что биос делал раньше). Ну и будем его обновлять через какой-нить update-system-firmware (вместо update-grub).

Я не вижу ничего плохого в том, что хотя бы формат таблицы разделов стал общим.

А мне вендорлоки не нравятся.

О да, никаких заморочек с бутсектором, зато требуется целый загрузочный раздел вместо него.

• Стоит заметить, что в этом «загрузочном» разделе, может лежать множество загрузчиков. А сколько загрузчиков непосредственно может располагаться в бутсекторе?
• Кроме загрузчиков, на системном EFI разделе может лежать ещё что угодно. Например файлы дополнительных модулей для загрузчиков, скины и другие ресурсы. Некоторые там к примеру ядра хранят. Системный EFI раздел ничем, кроме GUID, не отличается от любого другого раздела, форматированного в FAT. А можно ли в бутсектор пихнуть, кроме самого загрузчика, ещё и связанные с ним ресурсы, например те же модули, или для них придётся ещё один раздел создавать?
• С файлами загрузчиков гораздо удобней работать, чем с НЁХ из бутсектора. Как, к примеру, можно скопировать из бутсектора hdd на флешку загрузчик неизвестного размера и струтуры?
• FAT выбрана в качестве стандартной фс для системного EFI раздела не по «идеологическим» виндузятно-линуксячьим соображениям, а по той причине, что в эту фс умеет большинство существующих платформ. Даже современные игровые приставки. Могли конечно, чтоб никому не было обидно, запилить свою «универсальную» фс с маджонгом и гейшами, а потом попытаться пропихнуть её как одну из обязательных опций для систем с поддержкой UEFI, но зачем?

может располагаться в бутсекторе?

может лежать ещё что угодно.

В бутсекторе может лежать обёртка для любого формата загрузочных данных. В т.ч. для эмулятора UEFI. В этом вся суть: если биос требует только бутсектор, то ты свободен сам полностью выбирать формат хранения загрузочных данных, в т.ч. с отсутствием каких бы то ни было таблиц разделов и фс на диске вообще. От тебя требуют только один сектор, меньше - невозможно. Данные на диске - полностью сфера работы ОС. Если же от тебя требуют раздел, то тебе уже придётся делать и раздел, и делать таблицу разделов - отнимают свободу выбора.

Как, к примеру, можно скопировать из бутсектора hdd на флешку загрузчик неизвестного размера и струтуры?

Неизвестное - никак. И UEFI тут не поможет. Содержимое бут-раздела тоже может оказаться прибито гвоздями именно к этому HDD, и ты не знаешь где именно.

отнимают свободу выбора.

Именно из-за этой свободы выбора и возникла ситуация, когда каждый загрузчик (а в некоторых случаях и разные версии одного загрузчика) имели свой, несовместимый с другими формат загрузочных секторов, и дополнительных данных. И именно от этой свободы отказались в UEFI, в пользу унифицированного стандарта.

Обратная сторона свободы - множество несовместимых, часто кустарных реализаций. Обратная сторона стандартизации - отсутствие свободы выбора…

Неизвестное - никак. И UEFI тут не поможет. Содержимое бут-раздела тоже может оказаться прибито гвоздями именно к этому HDD, и ты не знаешь где именно.

В UEFI такая ситуация как раз и становится маловероятной. Загрузчик - простой файл. Сопутствующие данные - тоже. Копирование на другой накопитель - тривиально. Степень привязки к конкретному накопителю - прямо пропорциональна кривизне рук разраба.

Именно из-за этой свободы выбора и возникла ситуация, когда каждый загрузчик (а в некоторых случаях и разные версии одного загрузчика) имели свой, несовместимый с другими формат загрузочных секторов, и дополнительных данных. И именно от этой свободы отказались в UEFI, в пользу унифицированного стандарта.

Ясно, идиоты не могут сами решить что им нужно и просят сверху издать указ о том как им жить.

У меня таких проблем ни разу не возникало.

Обратная сторона свободы - множество несовместимых, часто кустарных реализаций.

Это не обратная сторона. Это не минус. Загрузчик линукса должен быть совместим с линуксом, больше от него ничего не требуется.

Степень привязки к конкретному накопителю - прямо пропорциональна кривизне рук разраба.

Степень привязки к конкретному накопителю зависит от поставленных задач. Кому-то она нужна, кому-то нет. А вот от формата загрузчика она не зависит. Что файл, что бутсектор, привязку можно делать а можно и не делать.

Ясно, идиоты не могут сами решить что им нужно

Дебил-регистрант, не знающий зачем существуют стандарты в естественной среде обитания.

У меня таких проблем ни разу не возникало.

Фраза-детектор дебила регистранта.

должен быть совместим с линуксом

Раньше на лоре за вендорлок обоссывали на месте. Куда всё скатилось.

Дебил-регистрант тут ты, увидевший фейковый вендорлок.

Ясно, идиоты не могут сами решить что им нужно и просят сверху издать указ о том как им жить.

Вы когда-нибудь слышали об унификации, стандартизации и конструкторской дисциплине?

Позвольте привести здесь фрагмент очень интересной книги «Цифровая схемотехника и архитектура компьютера»:

Конструкторская Дисциплина – это преднамеренное ограничение самим конструктором выбора возможных вариантов разработки, что позволяет работать продуктивнее на более высоком уровне абстракции. Использование взаимозаменяемых частей – это, вероятно, самый хорошо знакомый всем нам пример практического применения конструкторской дисциплины. Одним из первых примеров использования взаимозаменяемых деталей и узлов стала унификация при производстве кремнёвых ружей. До начала 19-го века такие ружья производились вручную и в штучном порядке. Высококвалифицированный оружейный мастер тщательно подтачивал и подгонял комплектующие, произведенные несколькими не связанными друг с другом ремесленниками. Конструкторская дисциплина для обеспечения взаимозаменяемости деталей и узлов произвела революцию в оружейной промышленности. Ограничение ассортимента комплектующих деталей до стандартного набора с жестко установленными допусками для каждой детали позволило собирать и ремонтировать ружья гораздо быстрее и использовать при этом менее квалифицированный персонал. Оружейный мастер перестал тратить свое время на разрешение проблем, связанных с нижними уровнями абстракции, такими как доводка какого-то конкретного ствола или исправление формы отдельного взятого приклада.

Вот научишься не только зубрить методички и потом применять их методом карго-культа - поймёшь в чём проблема.

Конструкторская дисциплина для обеспечения взаимозаменяемости деталей

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

Допуск - это стандартное апи, и оно уже есть - «первый сектор с исполняемым кодом». Апи вида «формат таблицы разделов + формат файловой системы + uefi-файл для загрузки с всё тем же исполняемым кодом но в усложнённом формате» ничем в этом плане не лучше, оно просто СЛОЖНЕЕ. А сложность апи - это плохо. Сложные апи любят проектировать графоманы, которые свою продуктивность измеряют количеством написанных букв.

У лоровских карго-регистрантов всё просто, а на практике в этом говнище был бесконечный анал-карнавал с загрузкой с флэшек и прочих нестандартных носителей, пока не начали переходить на efi.

Вот научишься не только зубрить методички и потом применять их методом карго-культа - поймёшь в чём проблема.

Я был бы Вам признателен, если бы Вы попытались сэкономить моё время, и объяснили бы с примерами, в чём именно заключается упомянутая Вами проблема.

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

А текст вообще не об этом. Текст о том, что нужны стандартные интерфейсы между узлами. Они были и раньше, тут ничего не поменялось. Но были простые - стали сложные. Была ярко выраженная модульность (материнка с прошивкой -> максимально тривиальный интерфейс -> жёсткий диск с ОС), теперь каша, прошивка лезет на жёсткий диск а ОС, если хочет везде свою фс, должна лезть в прошивку и внедрять туда драйвер ext4.

давайте лучше сразу линукс-ядро (на серверных материнках - бсд-ядро) туда засунем

да

давай

засовывай

начинай прям щас

и про хуитабельность незабуть