В Fedora планируется прекращение поддержки Legacy BIOS

Не всем нужна поддержка Legacy BIOS.

Ну офигеть теперь

Ну, в принципе, передовой дистрибутив - поддержка передовых технологий. Это нормально.

Думаю, не так долго придётся ждать и перехода многих других дистрибутивов на UEFI Only установку.

Но энтузиасты найдут выход и из этого ;)

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

Правда эта возможность предоставляется не coreboot а SeaBIOS, который является самым популярным payload-ом коребута (сам коребут лишь инициализирует железо, после чего передаёт управление payload-у

По-моему главная задача биоса как раз и есть инициализировть железо. А потом передать управление ОС. Т.е. настоящий биос это coreboot, а в чём суть прослойки с названием SeaBIOS на аж целых 50к строк я из твоего сообщения не понял.

Не знаю, а что ты понимаешь под проблемами?

Для меня вот необходимости танцев с бубном с EFI для заведения какинтоша в виртуалке — проблема. Так и не заведён в итоге, уже 10 лет страдаю (10.3 для PPC можно не считать, оно чисто на потыкать).

не осталось в живых пациентов кому она нужна

Это как, интересно, почему новых пациентов с тем же диагнозом не появляется?

Гм, а диагноз здесь причем?

Несмотря на то, что какинтош - сам по себе одни сплошные танцы с бубном, достаточно просто закинуть .efi файл Clover/OpenCore/что там ещё придумали на раздел рядом с другими .efi. А пердолинг с какинтошем - это пердолинг с какинтошем, тут уже ничего не поделаешь, увы. Он требует подмены всяких там переменных, поэтому ему нужен кастомный загрузчик.

Но это про реальное железо. Про виртуалку - https://github.com/kholia/OSX-KVM . Скачивание, установка и запуск какинтоша в пару кликов. Подменённый загрузчик в комплекте, пердолиться не нужно.

А что, вообще новых пациентов нету?

достаточно просто закинуть .efi файл Clover/OpenCore/что там ещё придумали на раздел рядом с другими .efi

И чем это делать без макоси и соответствующего инструментария? Классический PKUNZIP.ZIP. Даже .webarchive-сохранёнки из Safari вон под онтопиком смотреть нечем, всё собираюсь плагин к DC запилить или FUSE-прослойку.

https://github.com/kholia/OSX-KVM

Ух какой прогресс. А под амуди оно уже пропатчено и кекстами на все случаи обмазано а-ля ZverDVD, или как всегда?

А под амуди оно уже пропатчено и кекстами на все случаи обмазано а-ля ZverDVD, или как всегда?

На амуде работает без всякого пердолинга, лично проверял на кукурайзене.

И чем это делать без макоси и соответствующего инструментария?

Ну EFI раздел и из-под линуксов можно открыть. Всякие там Clover И OpenCore - сторонние разработки, качаются отдельно.

лично проверял на кукурайзене

А теперь проверь на всратом огрызке, где даже Android виртуализированный не работает, потому что SSSE4.2 нет :P По ходу, я для него вообще ничего готового не найду, так что затея изначально провальная ещё с того самого 2012-го года от тогдашних какинтошев до современных.

Ну EFI раздел и из-под линуксов можно открыть

Но образ-то цельный.

потому что SSSE4.2 нет

Эм, я на амуде 2008 года виртуалки запускал. В т.ч. и андроид. Даже SSSE3 не было.

А какинтошам, вроде, с Mojave требуются новые наборы инструкций. Не помню.

В т.ч. и андроид

Каких версий? Он где-то с 5-й или 6-й версии такой наглый.

А какинтошам, вроде, с Mojave требуются новые наборы инструкций

Хех, ну тогда шансы есть. Тем более, новые всё равно слишком жирные, они на два DVD ещё влезают хоть? xD

Каких версий? Он где-то с 5-й или 6-й версии такой наглый.

Не помню, лет 5 назад было. Как минимум 6 точно. Но я в Genymotion запускал (это такая запускалка андроида, основанная на VirtualBox).

Помимо инициализации железа (что coreboot успешно делает), нужно как минимум предоставить какой-то пользовательский интерфейс для выбора загрузочного устройства. Для этого, coreboot после инициализации железа передаёт управление «полезной нагрузке» - которая может быть или простой и минималистичной как SeaBIOS, или пожирнее как Tianocore / GRUB / Linux и обладать какими-то ещё доп.фичами. Для меня вполне достаточно показа бутменю и поддержки виртуальных дискет, поэтому в качестве «полезной нагрузки» я выбираю SeaBIOS.

Вот мне и непонятно: 1) Чего там на 50к строк понаписали для бут меню. Даже на ассемблере это должно быть короче. 2) С чего это бут лоадер они биосом назвали.

Вы внимательно прочитали сообщение на которое отвечаете? Для новых пациентов есть ХРюша.

в бутлоадере GRUB'е больше миллиона строк кода, но это никого не удивляет) К тому же, SeaBIOS, помимо меню загрузки и поддержки виртуальных дискет, вот ещё чего умеет - https://ru.wikipedia.org/wiki/SeaBIOS#Сравнение , в том числе - поддержка PCI BIOS calls

SeaBIOS реализует (PC BIOS-подобный) интерфейс, использующийся загрузчиками, ExtROM’ами и legacy-системами (например DOS) для абстрагирования от железа - работу с дисками (поддерживает некоторые PATA, SATA, NVMe и SCSI-контроллеры) и дискетами, клавиатурой, последовательными портами, дисплеем (SeaVGABIOS), часами реального времени, таймером и TPM. Ещё в нём есть некоторая поддержка USB (работает с клавиатурами, мышами и дисками, скрывая факт существования USB).

Бутлоадером SeaBIOS назвать крайне сложно - он умеет показывать бутменю со списком устройств, откуда пользователь (или опция конфигурации) выбирает одно, после чего из него читается первый сектор, и ему передаётся управление.

А как насчёт Core/Libreboot?..

Там тоже можно реализовать UEFI, так что особая поддержка не требуется.

>90% из нас выбирают SeaBIOS судя по репортам из board-status! И это лучшее подтверждение реальной не-нужности UEFI

Смиритесь уже что 16 битный BIOS уже мёртв. В новых процессорах вполне могут убрать поддержку 16 битного режима. Да и давно пора.

У Apple вроде на всех компьютерах UEFI, включая ARM.

Нет.

Не до конца. V86 режим можно убрать только вместе с 32-битным. Но вообще да, нативно-16-битный режим на современных процах это скорее легаси чем что-то полезное. Но UEFI от этого нужнее не становится.

Real mode убрать вроде ничего не мешает. Да и 16 битный режим без GDT/LDT наверное тоже.

Смиритесь уже что 16 битный BIOS уже мёртв.

SeaBIOS (опенсорсный BIOS на Си) - по-прежнему активно развивается. И, если приспичит, переведём оставшиеся 16-битные части SeaBIOS на 32-бита (например, «32-bit PCI BIOS calls» уже поддерживаются). Лишь бы не переходить на UEFI-жир, который даже в опенсорсном виде вызывает отвращение! UEFI - это уродливый стандарт, навязанный нам свыше. И нет ничего такого, что мог бы UEFI но физически не мог бы BIOS. Если SeaBIOS ещё чего-то не умеет - возможно, это не так уж и нужно, поэтому с меньшим приоритетом разработки.

В новых процессорах вполне могут убрать поддержку 16-битного режима.

Разве что только чтобы насолить любителям самодельных ОС, т.к. практического выигрыша от этого - ноль. И вообще, x86 всё менее и менее свободен, и опенсорсный БИОС под матплаты посвежее - когда он возможен - всё сильнее напичкан блобами. Поэтому, если уж и есть деньги под мощный Workstation на новых процессорах, стоит посмотреть в сторону Talos II на архитектуре POWER.

UEFI-жир

В самом стандарте нет жира. Реализовывать все протоколы никто не заставляет. Можете взять компактную реализацию EFI из u-boot, если вам EDK 2 так не нравится.

BIOS совершенно уродливый, непортируемый и на него нет внятной целостной документации (для UEFI вся документация в одном PDF файле). Так что он должен умереть поскорее, включая на виртуальных серверах.

И, если приспичит, переведём оставшиеся 16-битные части SeaBIOS на 32-бита

Там уродливые соглашения вызовов с номерами функций/подфункций и неконсистентная передача параметров через регистры. Некоторые BIOS портят регистры после вызова которые по идее не должны.

Разве что только чтобы насолить любителям самодельных ОС

Для самодельных ОС использовать UEFI намного проще. Не надо страдать с переключением режимов, 16 битным кодом и вмещать его в 512 байт. Можно сразу писать загрузчик на C/C++/Oberon/Pascal/Rust или что вам больше нравится. Можно собирать под разные платформы.

выпускались с поддержкой UEFI.

Пока что всё железо, что я вижу, может быть переключено в режим загрузки legacy. Это тот случай, когда «может» означает «уже сделано», тут даже раздумия неуместны. Придумавшие «новую» схему загрузки, используемую [u]efi, должны быть люто казнены.

Да, есличо, я ещё и lilo использую. Создатели grub/* тоже должны быть люто казнены.

Держи в курсе

В самом стандарте нет жира

Если все существующие практические воплощения стандарта UEFI - жирные (по сравнению с 50к строк минималистичного кода SeaBIOS), возможно - жир проистекает из самого стандарта?

Можете взять компактную реализацию EFI из u-boot

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

Там уродливые соглашения вызовов с номерами функций/подфункций и неконсистентная передача параметров через регистры. Некоторые BIOS портят регистры после вызова которые по идее не должны.

По всей видимости, вы говорите о проприетарных БИОСах, которые на ассемблере писаны и костыль на костыле. Разумеется, любая проприетарщина - уродлива! Но к опенсорсному SeaBIOS это не относится: всё гениальное - просто, и простота и минималистичность в размере 50к строк Сишного кода (из которых реально задействовано в два раза меньше если отключить всякие TPM) - достойны уважения в наш век жирноты.

Для самодельных ОС использовать UEFI намного проще.

Даже если так, самодельщикам придётся всё переписывать чтобы подстроиться под эти новые стандарты, навязанные сообществу. По своей воле UEFI практически никто себе не ставит! Когда у технически грамотных людей есть выбор, они выбирают БИОС - судя по отчётам board_status, >90% процентов коребутчиков используют SeaBIOS. И это - пожалуй, самое яркое свидетельство реальной ненужности UEFI. Типичному юзеру он достаётся в довесок с матплатой, не поддерживающей опенсорсные БИОСы - а к проприетарщине уважения не может быть априори.

Вообще не понятно, чем им этот самый Legacy BIOS так мешает? Он ведь простой как три копейки.

Всё очень просто: новомодный systemd-bootd (кстати, когда там systemd-kerneld? ;-) ) не поддерживает Legacy BIOS, а напрогать эту поддержку тамошние хипстеры не могут - у них лапки, да и религия не позволяет. Вот и хотят прекратить поддержку Legacy BIOS, чтобы пропихнуть systemd-bootd. и Fedora, и SystemD идут от RedHat'а - а рука руку моет.

Если все существующие практические воплощения стандарта UEFI - жирные (по сравнению с 50к строк минималистичного кода SeaBIOS), возможно - жир проистекает из самого стандарта?

Железная логика. Подсказка: нет.

На данный момент судя по гуглу

Вы всё по гуглу судите и делаете выводы не разобравшись в теме? Я занимался сборкой u-boot и адаптацией его под специфичные эмуляторы в рамках проекта портирования Haiku на RISC-V.

она не является полнофункциональной, благодаря этому и относительная компактность по отношению к ещё более жирным воплощениям стандарта.

Для запуска Haiku/Linux/FreeBSD на RISC-V и ARM достаточно (на x86 оно вроде тоже работает, но я не пробовал, может можно и Windows запустить). Haiku использует UEFI для запуска на RISC-V железе и используется существующий код загрузчика без значительных изменений. Никаких страданий с ассемблером, регистрами и режимами. Один и тот же образ системы запускается на реальном железе и нескольких независимых эмуляторах. Встроенная переферия автоматически распознаётся.

По всей видимости, вы говорите о проприетарных БИОСах, которые на ассемблере писаны и костыль на костыле.

У любого BIOS 16 битный API с передачей параметров через непойми какие регистры. От реализации это не зависит.

достойны уважения в наш век жирноты.

Достойны на выставке демосцены, не более.

Даже если так, самодельщикам придётся всё переписывать чтобы подстроиться под эти новые стандарты, навязанные сообществу.

Самодельщики уже не слышали про BIOS и пишут сразу под UEFI. А если писали давно, то это либо уже не самодельщики и стало большим серьёзным проектом, либо давно загнулось.

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

Я ставлю на RISC-V железо, с ним проще и гибче. Загрузчик можно скопировать как обычный файл, не надо страдать с FDT образами, запускается с любого носителя.

На x86_64 железе я использую UEFI загрузку. Линуксы имеют тенденцию перезаписывать MBR и ломать другие ОС в случае BIOS загрузки, с UEFI такой проблемы в принципе нет.

Советую вам попробовать хоть немного разобраться с UEFI вместо слепого хейтерства. Это не сложно. Программу для UEFI можно за 5 минут написать используя clang/lld.

Так как любая лишняя строка кода является потенциальным источником багов и уязвимостей, возникает естественное желание к минимизации размера исходного кода, особенно когда дело касается прошивок - критически важного компонента системы с максимально привилегированным доступом к железу. Учитывая, что постоянно всплывают новости вроде этой про дыры UEFI - у человека, желающего обеспечить максимальную безопасность системы вместо погони за фичами, возникает закономерное стремление бойкотировать UEFI как класс. Так что моё «хейтерство» вполне обоснованно. По аналогичным причинам я «хейчу» и SystemD, и многое другое «фичастое но дырявое».

В случае x86, u-boot может быть использован лишь поверх coreboot, а схема «coreboot --> дополнение u-boot --> его реализация EFI» - если и не невозможна, то выглядит крайне неоптимально, и я пока ещё не встречал человека который бы так делал. Даже Tianocore, который накатить на coreboot намного проще, и то мало кто использует - все на SeaBIOS.

На альтернативных архитектурах вроде RISC-V и ARM, с которыми вы работает, у u-boot дела обстоят намного лучше т.к. он может быть использован нативно. Но там и дополнительный функционал EFI выглядит излишним, т.к. u-boot может грузить и без этого. Да, придётся иногда немного «страдать с FDT образами» - но дополнительная безопасность стоит того, чтобы пожертвовать некоторыми удобствами.

Самодельщики уже не слышали про BIOS и пишут сразу под UEFI

Если пройтись по OSDev Projects, даже среди активных проектов в UEFI там умеют считанные единицы.

Программу для UEFI можно за 5 минут написать используя clang/lld.

Но зачем, если она будет работать только с UEFI, которого по крайней мере на x86 следует избегать.

Линуксы имеют тенденцию перезаписывать MBR и ломать другие ОС в случае BIOS загрузки

Нормальные дистрибутивы так не делают, + нет необходимости держать дурацкий /boot/efi . Да и какие «другие ОС» вы здесь имеете ввиду - винду, что ли? Если важна безопасность, то винде есть место лишь в максимально изолированной виртуалке, а лучше вообще от неё отказаться. Иначе «ломать» будут уже вас - во все дыры Windows/UEFI/SystemD и прочего ныне модного непотребства.

и многое другое «фичастое но дырявое».

В т. ч. ядро Linux? Или это другое™?

Это действительно другое, если посмотреть на плотность фич на число разработчиков и тестеров.

Что такое «плотность фич»?

Отношение числа фич на число разработчиков и числа фич на число тестеров. Весь важный код просматривает большее число людей, а тестирует ещё больше, если сравнивать с SeaBIOS, GRUB и реализациями UEFI.

числа фич

Что есть «фича» и как их количество измерить?

Отношение числа фич на число разработчиков и числа фич на число тестеров.

Численные значения в студию.

Весь важный код просматривает большее число людей, а тестирует ещё больше, если сравнивать с SeaBIOS, GRUB и реализациями UEFI.

Сравнивать что?

systemd-bootd

Гораздо лучше чем говнограб, в котором без пол литры не разберешься. И да, если топишь за минимализм, линукс не для тебя. В ядре линукса больше 20 миллионов строк кода. А ядро openBSD пересобирается за несколько минут на i5 7500.

Скорее всего, не будут ничего удалять, просто кровати передвинут немного.