Comments 47
Так почему новый быстрый накопитель даёт сбой и «не едет» после апгрейда? Может быть брак?
Ребят, у вас весь рассказ про EFI получился из серии «слышал звон, нагуглил новостей, теперь мнение имею»:
— никакой мастер-ключ у МС не утекал, иначе его давно уже заменили бы (утек подписаный кусок загрузчика, который позволял загрузить по цепочке что угодно только на ARM, и был затем успешно забанен добавлением хешей в переменную dbx).
— проблемы с Windows 7 у ASUS возникли потому, что ASUS до сих пор грубо нарушает спецификацию, позволяя включать SecureBoot вместе с CSM, что не имеет никакого смысла.
— чтобы бы там в MS не говорили, пока жив CSM, на десктопных системах всегда будет возможность отключения SecureBoot, потому что иначе CSM нормально не реализовать.
Если вам интересно, как работал SecureBoot во времена UEFI 2.4 - вот моя практическая статья о нем. С тех пор внесли немного изменений, добавив режим аудита для того, чтобы не мучатся с подписыванием ОРОМов доверенных устройств, но суть осталась та же.
В этой же статье вот это «введение в EFI» не нужно совершенно, потому что режим AHCI (вместо устаревшего native IDE и еще более древнего legacy IDE) появился раньше UEFI и не имеет к нему отношения, а GPT для EFI не является обязательным типом разметки. Написали бы лучше про необходимость драйвера NvmExpressDxe для загрузки с NVMe-накопителей и про опыт добавления этого драйвера в прошивку / загрузки его с ESP в случае, если прошивка старая и об NVMe еще ничего не знает.
— никакой мастер-ключ у МС не утекал, иначе его давно уже заменили бы (утек подписаный кусок загрузчика, который позволял загрузить по цепочке что угодно только на ARM, и был затем успешно забанен добавлением хешей в переменную dbx).
— проблемы с Windows 7 у ASUS возникли потому, что ASUS до сих пор грубо нарушает спецификацию, позволяя включать SecureBoot вместе с CSM, что не имеет никакого смысла.
— чтобы бы там в MS не говорили, пока жив CSM, на десктопных системах всегда будет возможность отключения SecureBoot, потому что иначе CSM нормально не реализовать.
Если вам интересно, как работал SecureBoot во времена UEFI 2.4 - вот моя практическая статья о нем. С тех пор внесли немного изменений, добавив режим аудита для того, чтобы не мучатся с подписыванием ОРОМов доверенных устройств, но суть осталась та же.
В этой же статье вот это «введение в EFI» не нужно совершенно, потому что режим AHCI (вместо устаревшего native IDE и еще более древнего legacy IDE) появился раньше UEFI и не имеет к нему отношения, а GPT для EFI не является обязательным типом разметки. Написали бы лучше про необходимость драйвера NvmExpressDxe для загрузки с NVMe-накопителей и про опыт добавления этого драйвера в прошивку / загрузки его с ESP в случае, если прошивка старая и об NVMe еще ничего не знает.
Столкнулись в проблемой на Lenovo G770. При включенном SecureBoot снесли Ubunty и поставили Ubunty Unity. После перезагрузки в BIOS/UEFI пропало меню SecureBoot, диск при загрузке пытается определиться, но через пару минут отключается от интерфейса SATA. Перепрошить BIOS можно только через Windows (написано на сайте Lenovo).
насколько мне помнится, был косяк с разметкой дисков под mbr.и gpt. они не бились в один сектор на 512б. через это контроллер лог запись 4к читал дважды в 2секторах. вендоры делали утилиты, к выравнивали разделы (начало раздела) на на физический 4к. как то так, навскидку).
я с 2009 г пользуюсь symon (разраб называет его монитор ос, как по мне, так точнее было бы монитор разделов) так вот он позволяет под mbr бить диск в скока) хошь разделов (primary)и грузица с них на выбор в любом сочетании, это первое, и второе — физически правильно бить разделы на 64/255/0 сек, дорожка, цилиндр.
насколько мне помнится, был косяк с разметкой дисков под mbr.и gpt. они не бились в один сектор на 512б. через это контроллер лог запись 4к читал дважды в 2секторах.Это вы перепутали с дисками в Advanced Format. К MBR/GPT отношения не имеет. Просто физический сектор у современных дисков 4 Кб, а программы за долгое время успели завязаться на сектор в 512 б, плюс древняя схема выравнивания разделов по цилиндрам (давно не актуальная, но соблюдающаяся «по привычке»), плюс то, что число цилиндров не является степенью двойки. В итоге выравнивание раздела по цилиндру приводило к тому, что он не был выровнен по физическим секторам.
вот старые диски, не af, и не бились в 512б под gpt, когда первый раздел начинается с lba 34, т.е перед ним 33
Сама GPT занимает 34 сектора (точнее, 1 сектор — protective MBR + 33 сектора на GPT), поэтому перед первым разделом не может быть менее 34 секторов. А за этими пределами создавать можно что угодно и как угодно, формат GPT просто содержит LBA-номер сектора (512-байтного). Можно создать по границе 4-килобайтного блока, а можно создать со смещением. Всё точно так же, как и в MBR (при использовании LBA-адресации). Это уже вопрос не к формату таблицы разделов, а к конкретным инструментам разбиения диска. Ну и к тому пользователю, который это разбиение выполняет, разумеется.
еще раз — первый раздел начинается на lba34
https://ru.m.wikipedia.org/wiki/%D0%A2%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D0%B0_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB%D0%BE%D0%B2_GUID
https://ru.m.wikipedia.org/wiki/%D0%A2%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D0%B0_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB%D0%BE%D0%B2_GUID
Нумерация с нуля. LBA 34 означает, что перед этим сектором находятся не 33, а 34 сектора (с номерами от 0 до 33).
И никто не заставляет создавать первый раздел прямо вот строго сразу за таблицей разделов. Современные разбивальщики вообще выравнивают по мегабайтам, что даёт почти мегабайтную дыру перед первым разделом, и ничего. Так что выровнять раздел просто, было бы желание.
И никто не заставляет создавать первый раздел прямо вот строго сразу за таблицей разделов. Современные разбивальщики вообще выравнивают по мегабайтам, что даёт почти мегабайтную дыру перед первым разделом, и ничего. Так что выровнять раздел просто, было бы желание.
«не бились», это в смысле не попадали в кратно 8х512
GPT работает гораздо более гибко и присваивает каждому разделу глобальный идентификатор, поэтому разделов может быть неограниченное количество…Использование глобального идентификатора никак не связано с неограниченностью числа разделов. MBR тоже спокойно может хранить бесконечное число логических разделов без всяких там идентификаторов — тупой односвязный список, с чего бы ему ограничиваться. Но во многих программах зашит лимит на 128 разделов (что для MBR, что для GPT), поэтому, несмотря на неограниченность по спецификации, я бы не рекомендовал превышать этот лимит. Впрочем, большинству пользователей так много и не нужно.
GPT хранит множество копий этой информации в разных секторах диска и восстанавливает информацию, если она повреждена.Вообще-то, не «множество», а две. Одна в начале диска, одна в конце.
Устаревший и более медленный интерфейс по соображениям «кабы чего не вышло»не очень удачный пример: на картинках в данном паттерне разница скорости IDE vs ACHI менее 10%…
Могу сейчас ляпнуть чушь, но насколько мне известно сами диски про AHCI ничего как не знали так и не знают. У них своя система команд. А AHCI уже реализовано на отдельном контроллере/материнской плате и является прослойкой между командами диску и OS. И эти 10% он и добавляет благодаря всяким ускоряющим аппаратным штукам.
Да, всё так и есть. Если быть чуточку точнее, режим IDE эти «штучки» просто не позволяет использовать, а AHCI наоборот, раскрывает. Как в программах — есть устаревший ограниченный API, с которым нужно поддерживать совместимость, и более полный современный интерфейс, хотя в обоих случаях по сути выполняется один и тот же код.
А тесты на картинке просто неправильно сделаны. Если бы взяли тесты на IOPS-ы, сразу бы стало видно, кто есть кто. У меня есть диски, которые подключены по USB 2.0, и там тоже не поддерживается очередь команд. Стоит хотя бы к двум файлам одновременно обратиться, и начинаются дикие тормоза :(
А тесты на картинке просто неправильно сделаны. Если бы взяли тесты на IOPS-ы, сразу бы стало видно, кто есть кто. У меня есть диски, которые подключены по USB 2.0, и там тоже не поддерживается очередь команд. Стоит хотя бы к двум файлам одновременно обратиться, и начинаются дикие тормоза :(
Скидки на 16гб DDR4 нет, ждал именно на них…
32768 символов в пути NTFS прекрасно поддерживает, ограничение на стороне Windows (уже можно отключить в Win10\Server2016). Впрочем можно обратиться к таким файлам через \?\\.
Про скорость накопителя ровно один абзац, относящийся к IDE\AHCI.
Остальное — про безопасность и надежность.
Так почему накопитель не едет то? )
Про скорость накопителя ровно один абзац, относящийся к IDE\AHCI.
Остальное — про безопасность и надежность.
Так почему накопитель не едет то? )
Избыточность хранения данных для большего ресурса накопителя.
Ой ли?
Также не раскрыт вопрос драйверов msahci vs intel RST, и на каких драйверах интересно тестирует сам производитель и что рекомендует?
А режим расширенного хост-контроллера (AHCI) даже в самых современных чипсетах отключен «до востребования».Не знаю какого года у вас «современные», но все последние материнские платы которые видел — у всех по умолчанию AHCI включен.
В таком режиме накопители SATA 3.0 работают с быстродействием уровня своих PATA-предшественников.
И скриншот из которого видно что разница всего 13.5 мегабайт. Что конечно не 0, и на более новых носителях может быть больше, но крайне далеко от ваших страшилок.
GPT хранит копии этой информации в разных секторах диска и восстанавливает информацию, если она повреждена.
А это где-то действительно так работает? Прямо сейчас попробовал на W10 — стёр копию GTP в начале диска и всё, диск пустой, никакого автовосстановления.
Вручную восстановить конечно можно, несколько легче чем с MBR. Но и с MBR совсем не сложно.
Не то чтобы GPT плох, но и смысла конвертировать из MBR уже имеющийся диск никакого.
И скриншот из которого видно что разница всего 13.5 мегабайт. Что конечно не 0, и на более новых носителях может быть больше, но крайне далеко от ваших страшилок.
Я не так давно замерял на SSD скорость в
AHCI:
root@xubuntu:/home/xubuntu# dd if=/dev/sdb of=/dev/zero bs=1M count=11024
11024+0 records in
11024+0 records out
11559501824 bytes (12 GB, 11 GiB) copied, 32.311 s, 358 MB/s
root@xubuntu:/home/xubuntu# dd if=/dev/sdb of=/dev/zero bs=1M count=11024
11024+0 records in
11024+0 records out
11559501824 bytes (12 GB, 11 GiB) copied, 32.3014 s, 358 MB/s
root@xubuntu:/home/xubuntu# dd if=/dev/sdb of=/dev/zero bs=1M count=11024
11024+0 records in
11024+0 records out
11559501824 bytes (12 GB, 11 GiB) copied, 32.3107 s, 358 MB/
IDE:
root@xubuntu:/home/xubuntu# dd if=/dev/sdb of=/dev/zero bs=1M count=11024
11024+0 records in
11024+0 records out
11559501824 bytes (12 GB, 11 GiB) copied, 33.3194 s, 347 MB/s
root@xubuntu:/home/xubuntu# dd if=/dev/sdb of=/dev/zero bs=1M count=11024
11024+0 records in
11024+0 records out
11559501824 bytes (12 GB, 11 GiB) copied, 33.3228 s, 347 MB/s
root@xubuntu:/home/xubuntu# dd if=/dev/sdb of=/dev/zero bs=1M count=11024
11024+0 records in
11024+0 records out
11559501824 bytes (12 GB, 11 GiB) copied, 33.3727 s, 346 MB/s
В общем то с увлечением скорости диска видимо не сильно меняется разница между ACHI и IDE тебе 11-12 мегабайт.
Ну с 1-мегабайтным блоком любой сможет. Было бы интересно посмотреть на скорость при работе с блоками меньшего размера, а лучше вообще со случайным доступом.
dd if=/dev/sdb of=/dev/zero bs=512 count=11024 dd if=/dev/zero of=/dev/zero bs=512 count=11024
Лучше используя fio.
По скорости разницы никакой.
# dd … of=/dev/zero …Может имелось в виду
dd … of=/dev/null …% dd if=/dev/zero bs=512 count=22M of=/dev/null
23068672+0 записей получено
23068672+0 записей отправлено
11811160064 байт (12 GB, 11 GiB) скопирован, 6,22619 s, 1,9 GB/s
# Конечно не SSD, но AHCI включен
% dd if=/dev/sda bs=512 count=22M of=/dev/null
23068672+0 записей получено
23068672+0 записей отправлено
11811160064 байт (12 GB, 11 GiB) скопирован, 133,262 s, 88,6 MB/s
Ну при записи в /dev/zero ничего не происходит, также как и при записи в /dev/null
Хотя правильней наверно всё же будет /dev/null но на практике отсутствие разницы.
в данном примере тоже обычный HDD:
Хотя правильней наверно всё же будет /dev/null но на практике отсутствие разницы.
в данном примере тоже обычный HDD:
dd if=/dev/sda of=/dev/null bs=512 count=20000000
20000000+0 records in
20000000+0 records out
10240000000 bytes (10 GB) copied, 46,0533 s, 222 MB/s
dd if=/dev/sda of=/dev/zero bs=512 count=20000000
20000000+0 records in
20000000+0 records out
10240000000 bytes (10 GB) copied, 45,8982 s, 223 MB/s
Поддержка длинных имен. До 32768 символов в пути вместо 255, как это было в NTFS
NTFS поддерживает длинные имена если не с рождения, то очень-очень давно, как минимум со времён NT4sp6. Ограничение на 255 символов — это ограничение древнего винапи, которое обходится либо использованием новых функций и интерфейсов, либо костылём "\\?\C:\путь_любой_длины".
Хм, действительно.
Но это, имхо, полная фигня. Делать имя файла такой длины — очень сомнительная затея. А вот старое ограничение в MAX_PATH символов на полный путь с именем файла — вот это истинный маразм, который до сих пор живее всех живых.
Но это, имхо, полная фигня. Делать имя файла такой длины — очень сомнительная затея. А вот старое ограничение в MAX_PATH символов на полный путь с именем файла — вот это истинный маразм, который до сих пор живее всех живых.
Проблема-то не в системе, а в программах. Если убрать ограничение в API, то куча программ порушатся из-за того, что используют фиксированный буфер и не проверяют длину полученной строки.
Впрочем, в десятке что-то там такое, вроде, собирались уже делать в этом направлении. Ключом реестра что ли включается…
Впрочем, в десятке что-то там такое, вроде, собирались уже делать в этом направлении. Ключом реестра что ли включается…
А если ограничение не убрать, то программисты так и будут лепить фиксированный буфер.
Кстати, раньше программы работали только с именами в формате 8.3, но это не помешало ввести длинные имена, сделав временный костыль (короткий алиас для длинных имён).
Короткие имена — это всё же наследие 16-битной эры. Первая 32-битная винда (95) шла уже с длинными именами, так что всё, что под неё писалось, должно было это учитывать. Сейчас такого крупного архитектурного изменения не планируется, чтобы туда можно было под шумок MAX_PATH=32768 пропихнуть. Вместо этого сделали манифестом — что ж, посмотрим, к чему это приведёт.
IDE (Integrated Development Environment)
Наверное, должно быть так — IDE (англ. Integrated Drive Electronics — «электроника, встроенная в привод»)
Как-то у вас всё поверхностно описано, хотя темы сложные и неоднозначные. А вы их только с одного угла рассматриваете, да и то половина предмета в кадр не попадает.
BIOS и UEFI. Вы говорите UEFI лучше, но забыли сказать чем. Вообще, всё новое лучше старого, иначе его бы не придумывали — это само собой подразумевается. Но интересно в чём точно заключается преимущество. UEFI решает одну проблемку в загрузке компьютера — двойную инициализацию. Сначала биос загружался и инициализировал железо (в режиме совместимости), потом передавал управления операционной системе, и она начала инициализировало всё железо наново (уже в безопасном режиме — с разнесением полномочий ring0-ring3 и т.п.)
В теории ускорение загрузки, упомянутое вами, достигается за счёт отказа от двойной инициализации. UEFI передаёт железо готовой к использованию в ОС. На практике, это работает только если UEFI заточен для работы с этой ОС. Догадайтесь для какой именно ОС заточен UEFI? Кто протащил его через монопольный сговор? Так вот — для линукса быстрее загружаться через традиционный BIOS, просто потому что он проще и быстрее стартует сам по себе, а двойной инициализации не избежать. Для линукса есть свой UEFI, называется coreboot, но совместимого с ним железа очень мало, и оно дико устаревшее. Так что для линуксоидов от UEFI один вред, и они ваших восторгов не разделяют.
По поводу Secure Boot — у меня он никогда не заведётся, потому что я использую gentoo, систему собираю сам, и мне никто не подпишет. Линукс, конечно, гибкая система — никто не мешает мне загрузить подписанное ядро и сделать из него kexec — но зачем мне такой геморрой? Если бы производитель железа действительно заботился о пользователе, он бы дал ему возможность подписывать образа для своей системы. А он заботится только о том, чтобы ярмо покрепче нацепить на покупателя.
NCQ — полезная примочка, но не обязательная. Все средства для разметки дисков как раз для этого и задают архитектуру — бьют диски на сектора и дорожки вместо цельной адресации, чтобы операционная система могла сама оптимально упорядочивать запросы к диску. Но с тех пор как появились жёсткие диски, которые и не диски вовсе, а штабеля флеш памяти, разложенные каждым производителем в свой уникальный пасьянс, NCQ стал более актуален.
Преимущества GPT перед MBR очевидны, но в некоторых ситуациях достаточно и MBR, и нечего лишнюю память занимать. Если 4 разделов и 2х терабайтов вам за глаза — возьмите MBR, она работает, подтверждено годами. Восстановить данные можно, если вы помните размер разделов. А ещё можно и по характерным заголовкам файловых систем поискать. Надёжно от битых дисков спасает только бекап — всё прочее относительно.
А если вы ещё сами не знаете, сколько разделов вам понадобится — то тут и GPT не поможет. Надо сразу ставить LVM или какую-нибудь BTRFS, которая в себя включает функциональность управления разделами, в виде сабвольюмов. Прям поверх диска, без MBR или GPT — они уже морально устарели, если вам действительно нужна гибкая работа с разделами.
BIOS и UEFI. Вы говорите UEFI лучше, но забыли сказать чем. Вообще, всё новое лучше старого, иначе его бы не придумывали — это само собой подразумевается. Но интересно в чём точно заключается преимущество. UEFI решает одну проблемку в загрузке компьютера — двойную инициализацию. Сначала биос загружался и инициализировал железо (в режиме совместимости), потом передавал управления операционной системе, и она начала инициализировало всё железо наново (уже в безопасном режиме — с разнесением полномочий ring0-ring3 и т.п.)
В теории ускорение загрузки, упомянутое вами, достигается за счёт отказа от двойной инициализации. UEFI передаёт железо готовой к использованию в ОС. На практике, это работает только если UEFI заточен для работы с этой ОС. Догадайтесь для какой именно ОС заточен UEFI? Кто протащил его через монопольный сговор? Так вот — для линукса быстрее загружаться через традиционный BIOS, просто потому что он проще и быстрее стартует сам по себе, а двойной инициализации не избежать. Для линукса есть свой UEFI, называется coreboot, но совместимого с ним железа очень мало, и оно дико устаревшее. Так что для линуксоидов от UEFI один вред, и они ваших восторгов не разделяют.
По поводу Secure Boot — у меня он никогда не заведётся, потому что я использую gentoo, систему собираю сам, и мне никто не подпишет. Линукс, конечно, гибкая система — никто не мешает мне загрузить подписанное ядро и сделать из него kexec — но зачем мне такой геморрой? Если бы производитель железа действительно заботился о пользователе, он бы дал ему возможность подписывать образа для своей системы. А он заботится только о том, чтобы ярмо покрепче нацепить на покупателя.
NCQ — полезная примочка, но не обязательная. Все средства для разметки дисков как раз для этого и задают архитектуру — бьют диски на сектора и дорожки вместо цельной адресации, чтобы операционная система могла сама оптимально упорядочивать запросы к диску. Но с тех пор как появились жёсткие диски, которые и не диски вовсе, а штабеля флеш памяти, разложенные каждым производителем в свой уникальный пасьянс, NCQ стал более актуален.
Преимущества GPT перед MBR очевидны, но в некоторых ситуациях достаточно и MBR, и нечего лишнюю память занимать. Если 4 разделов и 2х терабайтов вам за глаза — возьмите MBR, она работает, подтверждено годами. Восстановить данные можно, если вы помните размер разделов. А ещё можно и по характерным заголовкам файловых систем поискать. Надёжно от битых дисков спасает только бекап — всё прочее относительно.
А если вы ещё сами не знаете, сколько разделов вам понадобится — то тут и GPT не поможет. Надо сразу ставить LVM или какую-нибудь BTRFS, которая в себя включает функциональность управления разделами, в виде сабвольюмов. Прям поверх диска, без MBR или GPT — они уже морально устарели, если вам действительно нужна гибкая работа с разделами.
Да, забыл сказать. GPT и MBR могут работать одновременно. Это не рекомендуется, но никто не мешает с помощью небольшого извращения создать диск, который будет размечен одновременно и MBR и GPT. Очень помогало в начальный этап внедрения GPT, когда его поддерживала только половина софта, а вторая ничего про него не слышала.
Отличный пост, почти все мифы об UEFI, в которые верят апологеты Linux, точно также начитавшиеся новостей, как и автор этой статьи.
Давайте по порядку: UEFI не решает проблему двойной инициализации ни на одной платформе, потому что создан был вовсе не для этого. EFI, вообще говоря — это просто интерфейс между прошивкой и ОС, и он не имеет никакого отношения к инициализации оборудования вообще, а пришел на смену интерфейса BIOS interrupt call, потому что для той платформы, для которой EFI изначально разрабатывался Intel с 1998 года (назывался он тогда Intel Boot Initiative) — IA64/Itanium совместимость с legacy BIOS реализовывать не стали из за отсутсвия поддержки 16-битного режима исполнения.
Еще раз: UEFI — это всего лишь интерфейс между ОС и прошивкой, избавленый от костылей вроде ресета через IO-порт клавиатуры и управления адресной линией A20.
То, что вы называете UEFI на деле представляет из себя комбинацию из двух относительно независимых компонентов: кода инициализации оборудования и кода, реализующего интерфейс с ОС. На большинстве современных ПК инициализацией оборудования теперь занимается либо Intel PI, либо AMD AGESA, либо вышеупомянутый coreboot, а на ARMах — uboot.
Еще раз: coreboot занимается только инициализацией оборудования, а для предоставления интерфейса с ОС ему нужен т.н. payload, который может реализовать как старый интерфейс BIOS int (SeaBIOS), так и более новый интерфейс UEFI (TianoCore), а может вообще никакого не реализовавывать и запускать ядро Linux напрямую.
Для какой ОС заточен UEFI — ни для какой, активно используется MacOS и Windows. Кто протащил его через монопольный сговор — Intel, начав предоставлять MRC в виде 32-битного блоба (который с 16-битным BIOS нужно было женить через жертвоприношения и танцы с бубном и барабанами), а потом вынудив IBV перейти на UEFI с релизом Sandy Bridge. Apple же использует EFI с 2007 года, потому что на момент перехода на x86 никаких альтернатив EFI на x86 не было уже тогда.
Про SecureBoot — вы можете подписывать все свое своими собственными ключами, и никто вам не мешает этой возможностью пользоваться, а не рассказывать очередной раз про ярмо, которое на пользователя якобы кто-то нацепил.
Линуксоиды, если вы хотите хоть немного разобраться прежде чем начинать в очередной раз обвинять производителей железа и ОС во всех смертных грехах, прочтите Beyond BIOS, авторы которой этот самый UEFI придумали и поддерживают уже почти 20 лет.
Давайте по порядку: UEFI не решает проблему двойной инициализации ни на одной платформе, потому что создан был вовсе не для этого. EFI, вообще говоря — это просто интерфейс между прошивкой и ОС, и он не имеет никакого отношения к инициализации оборудования вообще, а пришел на смену интерфейса BIOS interrupt call, потому что для той платформы, для которой EFI изначально разрабатывался Intel с 1998 года (назывался он тогда Intel Boot Initiative) — IA64/Itanium совместимость с legacy BIOS реализовывать не стали из за отсутсвия поддержки 16-битного режима исполнения.
Еще раз: UEFI — это всего лишь интерфейс между ОС и прошивкой, избавленый от костылей вроде ресета через IO-порт клавиатуры и управления адресной линией A20.
То, что вы называете UEFI на деле представляет из себя комбинацию из двух относительно независимых компонентов: кода инициализации оборудования и кода, реализующего интерфейс с ОС. На большинстве современных ПК инициализацией оборудования теперь занимается либо Intel PI, либо AMD AGESA, либо вышеупомянутый coreboot, а на ARMах — uboot.
Еще раз: coreboot занимается только инициализацией оборудования, а для предоставления интерфейса с ОС ему нужен т.н. payload, который может реализовать как старый интерфейс BIOS int (SeaBIOS), так и более новый интерфейс UEFI (TianoCore), а может вообще никакого не реализовавывать и запускать ядро Linux напрямую.
Для какой ОС заточен UEFI — ни для какой, активно используется MacOS и Windows. Кто протащил его через монопольный сговор — Intel, начав предоставлять MRC в виде 32-битного блоба (который с 16-битным BIOS нужно было женить через жертвоприношения и танцы с бубном и барабанами), а потом вынудив IBV перейти на UEFI с релизом Sandy Bridge. Apple же использует EFI с 2007 года, потому что на момент перехода на x86 никаких альтернатив EFI на x86 не было уже тогда.
Про SecureBoot — вы можете подписывать все свое своими собственными ключами, и никто вам не мешает этой возможностью пользоваться, а не рассказывать очередной раз про ярмо, которое на пользователя якобы кто-то нацепил.
Линуксоиды, если вы хотите хоть немного разобраться прежде чем начинать в очередной раз обвинять производителей железа и ОС во всех смертных грехах, прочтите Beyond BIOS, авторы которой этот самый UEFI придумали и поддерживают уже почти 20 лет.
Я действительно не сильно разбирался в технологии, зачем читать документацию, если ты всё равно не собираешься ей пользоваться. Всё что я знаю — это сумма статей вендоров, в которых они объясняют, зачем мне надо поставить себе UEFI и быть довольным.
Вот например, в этой статье сказано, что UEFI ускоряет загрузку. А вы утверждаете, что UEFI вовсе этого не делает. Что всё его предназначение — это замена специальных вызовов биоса, которым современные ОС всё равно никогда не пользовались, предпочитая отдавать работу с железом своим собственным драйверам.
За ссылку на SecureBoot спасибо — добавил себе в закладки. До сих пор думал, что без джейлбрейка ты не заставишь его кушать другие ключи.
Вот например, в этой статье сказано, что UEFI ускоряет загрузку. А вы утверждаете, что UEFI вовсе этого не делает. Что всё его предназначение — это замена специальных вызовов биоса, которым современные ОС всё равно никогда не пользовались, предпочитая отдавать работу с железом своим собственным драйверам.
За ссылку на SecureBoot спасибо — добавил себе в закладки. До сих пор думал, что без джейлбрейка ты не заставишь его кушать другие ключи.
Уважаемые при всё уважение, у вас акции очень короткие и попадают в промежуток между получками(ЗП), у вас менеджеры этот вариант рассматривали при рассмотрение рамок продаж, по моему ( частное мнение), актуальные даты это 5-15 и 20-30 числа. А так же хорошая практика предупреждать о грядущих акциях, может у кого-то другие временные рамки получки ( те кто работают сами на себя или выполняют работу на заказ)
Sign up to leave a comment.
Стандартные настройки — самые бестолковые. Почему новый быстрый накопитель даёт сбой и «не едет» после апгрейда?