Два или три комплекта разделов, и ватчдог аппаратный. Сломался один линукс весь — ничего страшного, у нас тут рядом таких же еще два, грузим один из них, восстанавливаем сломанный из работающего. От резкой потери питания (внезапной смерти батареи) спасет только резервирование, от плавного высасывания до нуля — микроконтроллер, который нужен только для того, чтобы за питанием этим следить (SMC/EC), и который же сможет аккуратно остановить все остальное до того, как питание пропадет совсем.
Отдельное спасибо за программатор SPI/I2C, про который вы упоминали в твиттере. Понятно, что его можно сделать из чего угодно теперь, хоть из RPi, хоть из ардуины, хоть из старого роутера, но тут можно сделать простой мост между ПК (тем более у вас есть карта памяти уже, и можно читать файлы с прошивкой прямо с нее) и целевым устройством, на который прошивка записывается. Дальше там простой переходник на SOIC-клипсу (купите Pomona или 3M, не пожалейте денег), и получится замечательная железка для аварийного восстановления прошивок практически всего окружающего железа от дверных звонков до материнских плат ПК и роутеров. Пусть даже не быстро, пусть не основная функция, но если сделать нормально и позволять прошивать это все без драйверов, специального софта, и прочих народных танцев в килтах на босу жопу — я куплю два.
Проблема в том, что как только Intel и AMD откажутся поддерживать CSM на своем новом железе, эту поддержку придется взять на себя IBV, OEM или еще каким-то участникам рынка, и очень далеко не факт, что в результате получится что-то нормальное, а не кусок известно чего, ломающий ради совместимости с древними 16-битными загрузчиками половину прошивки.
UEFI использует Microsoft x64 calling convention для 64-битного режима, поэтому указатели там все-таки 64-битные. Можно попробовать использовать x32 ABI для PEI (принципиально почти ничего не мешает), но настолько я знаю, у формата Portable Executable, в котором хранятся компоненты UEFI (а точнее, UEFI Platform Interface, стандарта на внутренние представления, файловую систему прошивки и т.п.) нет стандартных средств выразить факт «вот этот файл использует x32 ABI».
PEI на реальном железе до сих пор 32-битный, потому что в 64-битном режиме все указатели ровно вдвое длиннее, а место в кэше L2 совсем не резиновое. Переход из 32-битного в 64-битный режим выполняется драйвером DxeIplPei, последним из PEI-драйверов, в функции HandOffToDxeCore.
Как Вы думаете, как скоро получится полностью уйти от Legacy?
Ответ сильно зависит от текущей ниши. В промышленности — лет через 15-20, на серверах — лет через 5, на десктопах — через 1-3 (Intel обещала перестать поддерживать CSM уже в этом году, но видимо передумает), на всяких нишевых устройствах вроде планшетов\смартфонов — давно уже избавились. Apple избавилась от CSM на своих x86-системах еще в 2015 году.
Очень рад за проект, но несколько переживаю за слово Tamagochi в промо-материалах, потому что оно может быть зарегистрированной торговой маркой Bandai, а судиться с крупной корпорацией в чужой юрисдикции — такое себе удовольствие. Лучше заменить на multitool for hackers или что-нибудь подобное нейтральное.
Странные условия. Что мешает продать полученные акции сразу же на момент вестинга и перенастроить форму W-4 в тот же день так, чтобы дополнительный налог удержали через нее? Получится то же самое по сути.
У публичных компаний налог с RSU платится удерживанием части этих RSU в момент vesting'а. Причем там можно самому из личного кабинета настроить, какой именно процент удерживать (22-37% в пользу федеральных налогов при сумме до миллиона долларов в год, ровно 37 после миллиона, плюс налог штата, для Калифорнии это 10-15%), а потом в следующем апреле при оплате налогов придется доплатить разницу (если удержали мало) или получить вычет (если наоборот).
Более того, exchange-traded fund необязательно индексный, и отслеживать может любые акции, которые управляющим в голову взбредут. Там автор скорее всего имел в виду mutual fund (как противопоставление exchange-traded fund), но и они тоже торгуются на бирже, просто цена на них определяется после закрытия торгов раз в день, а не в каждый конкретный момент времени, как у ETF.
Ну вот у Windows свой бинарный формат, у macOS натурально XML, у разных загрузчиков Linux/*BSD свои текстовые форматы.
В общем, всем сока в этом чате, но в реальности это все никаких эмоций уже не вызывает, настолько типичная картина. О, и этот загрузчик от неправильного конфига падает? Неожиданно то как…
Плюс 50 центов к BoM cost, плюс три месяца на написание и тестирование софта, плюс поддержка этого механизма до EoL, минус тысяча возвратов по RMA за всю историю продуктовой линейки. В итоге ставить дополнительную микросхему с прошивкой в потребительскую (про промышленную другой разговор) электронику практически не окупается, и потому все давно на это забили.
Сделаю несколько замечаний по коду, если позволите:
1. Есть такой TianoCore C style guide, и если писать что-то с расчетом на дальнейшее включение в EDK2, то лучше следовать ему, иначе есть неслабый шанс, что PR не примут. Более того, работать с кодом, который похож на «обычный» — приятнее.
2. Если используете goto FINALIZE;, лучше завернуть его в макрос вроде require(condition, label) или require_noerr(status_variable, label), это снизит нагрузку при чтении кода.
3. Не используйте ASSERT_EFI_ERROR() для проверки ошибок, особенно если у вас следующая операция — разыменование указателя, полученного от предыдущей. Из релизных конфигураций такие ассерты удаляются препроцессором, и потому вот эта операция — потенциальный источник бесконечного числа багов и потенциальная же дыра в безопасности.
Тоже однажды пришлось заводить подобную камеру, только на значительно более мощном процессоре Intel Atom BayTrail и с интерфейсом MIPI CSI. Как вспомню эту прекрасную 32х-битную Fedora с патченным Intel ядром, эти отличные драйверы для v4l2, этот замечательный процессор и не менее восхитительную прошивку для него от AMI… Слава яйцам, больше этим заниматься не надо, потрахались — и хватит!
Описываю своими словами решение: при загрузке держите Option, и затем загружаетесь в recoveryOS уже из BootPicker. Сейчас эта проблема уже починена (начиная, ЕМНИП, с 10.15.3), и при загрузке в «недостаточно правильную» recoveryOS утилита Startup Security Utility выдает предупреждение, что запись в данной ОС недоступна, и предлагает перезагрузиться в «правильную» recoveryOS вышеуказанным способом.
Сетевые драйверы давно уже не загружаются на дефолтном пути (с 2015 года, ЕМНИП), не надо грязи. Если у вас есть PoC атак на прошивки Маков — пишите нам на security@apple.com, поговорим о них предметно.
Менять условия выдачи новых виз и продления старых в сторону ужесточения. Кроме бодишопов есть еще и FAANG, которые тоже привозят себе людей по H1B и L1, и при этом люди эти и не дешевые, и не бесправные, и не хуже местных (а некоторые и лучше). А такие ковровые баны — это лечение головной боли отрубанием головы и выплескивание ребенка вместе с водой.
Отдельное спасибо за программатор SPI/I2C, про который вы упоминали в твиттере. Понятно, что его можно сделать из чего угодно теперь, хоть из RPi, хоть из ардуины, хоть из старого роутера, но тут можно сделать простой мост между ПК (тем более у вас есть карта памяти уже, и можно читать файлы с прошивкой прямо с нее) и целевым устройством, на который прошивка записывается. Дальше там простой переходник на SOIC-клипсу (купите Pomona или 3M, не пожалейте денег), и получится замечательная железка для аварийного восстановления прошивок практически всего окружающего железа от дверных звонков до материнских плат ПК и роутеров. Пусть даже не быстро, пусть не основная функция, но если сделать нормально и позволять прошивать это все без драйверов, специального софта, и прочих народных танцев в килтах на босу жопу — я куплю два.
Ответ сильно зависит от текущей ниши. В промышленности — лет через 15-20, на серверах — лет через 5, на десктопах — через 1-3 (Intel обещала перестать поддерживать CSM уже в этом году, но видимо передумает), на всяких нишевых устройствах вроде планшетов\смартфонов — давно уже избавились. Apple избавилась от CSM на своих x86-системах еще в 2015 году.
В общем, всем сока в этом чате, но в реальности это все никаких эмоций уже не вызывает, настолько типичная картина. О, и этот загрузчик от неправильного конфига падает? Неожиданно то как…
Сделаю несколько замечаний по коду, если позволите:
1. Есть такой TianoCore C style guide, и если писать что-то с расчетом на дальнейшее включение в EDK2, то лучше следовать ему, иначе есть неслабый шанс, что PR не примут. Более того, работать с кодом, который похож на «обычный» — приятнее.
2. Если используете goto FINALIZE;, лучше завернуть его в макрос вроде require(condition, label) или require_noerr(status_variable, label), это снизит нагрузку при чтении кода.
3. Не используйте ASSERT_EFI_ERROR() для проверки ошибок, особенно если у вас следующая операция — разыменование указателя, полученного от предыдущей. Из релизных конфигураций такие ассерты удаляются препроцессором, и потому вот эта операция — потенциальный источник бесконечного числа багов и потенциальная же дыра в безопасности.