Автоматически это делать нельзя и вот почему: ширина колонок в виджете может настраиваться пользователем, и как только пользователь эту ширину настроил — менять ее уже не нужно, потому что это дико бесит. Особенно дико это будет бесить когда у вас не две колонки, а штук десять, и все элементы двигаются туда-сюда просто потому, что какую-то ветку свернули.
В некоторых областях нынче очень не хватает джуниоров просто потому, что порог входа высоковат. Та же разработка прошивок, тут тебе и ассемблер с чистым С, и голое железо, и EFI с Linux на миллион строк кода каждая, и прочее вот такое. При этом простых IDE и утилит из разряда «нажми на кнопку — получишь результат» там не было, нет и не будет, наверное, лет 50 еще.
В итоге джуниором туда идут только самые стойкие оловянные солдатики, с которыми потом и работаем. И это все при том, что тут достаточно обычного компьютера для старта.
Дело там не в версии МЕ, а в версии Intel Platform Support Code, вместе с которым поставляется и МЕ в том числе. Поддержка инженерных и квалификационных семплов обычно заканчивается значительно раньше, чем поддержка релейных процессоров, и потому код для них из PSC просто выкидывается. Можно, конечно, попробовать портировать его из старой прошивки в новую, но это масса работы ради непонятно чего, гораздо лучше будет либо оставаться на последней поддерживаемой версии, либо сменить процессор на нормальный. Замена МЕ\контрольной суммы\адреса\т.п. — точно не выход.
Вообще раз уж мы тут заговорили про ES и QS — читатель, я вас заклинаю, не покупайте их никогда, а если даром дают — отдайте назад. Вот эта проблема с PSC — это вершина айсберга, и там могут встречаться такие странные глюки в самых неожиданных местах, что лучше с ними не связываться вообще никогда.
За информацию спасибо, конечно, только заголовок надо исправить на «драйвер SPIFFS не совместим с чипами PUYA P25Qxxxx, обстоятельства выясняются», а то сейчас он читается так: «в новых ревизиях чипа ESP8266 найден баг, из за которого он перестал писать вообще на любые SPI flash», что, понятно, ложь и провокация.
Кстати, головки собраны от отличных производителей — Torx, Phillips, Spanner и др.
Автор жжот. Это не производители вовсе, это типы головок у винтов, для которых в наборе имеются биты.
Инструмент лучше выбирать самому, и брать надо сразу нормальный, а не очередной китайский набор 1000-в-1 известного качества и цен. От себя лично посоветую отвертки Wiha PicoFinish или Precision ESD, они хоть и дорогие, зато и работать с ними — одно удовольствие.
Для разного рода нестандартных винтов хороши наборы от iFixit, и хотя там качество похуже, чем у Wiha, но зато битов море разных.
Проблема тут мне видится вот в чем: доклады бывают, если совсем огрубить, двух видов. Первый — это когда в докладе представлены какие-то нетривиальные результаты исследований, которые кроме как из доклада этого взять просто неоткуда. В этом случае вообще по барабану качество презентации, слайдов, мимики, жестов и взглядов — ценность информации перекрывает все недостатки. Да, возможно некоторые доклады было бы слушать приятнее, если бы докладчик умел презентовать их лучше, но все прекрасно понимают, что требовать вершин ораторского мастерства от технарей — довольно странно.
Второй вид — это когда никакой толком информации в докладе нет, и там либо мнения какие-то чьи-то, либо банальности, либо другая какая-нибудь ерунда. Такие доклады не стоят потраченного на них времени независимо от ораторского уровня докладчика. Да, я понимаю, что на TED Talks люди на полном серьезе говорят о том, что «нас, оказывается, неправильно учили завязывать шнурки, я сейчас вам всем открою глаза на то, как правильно», но такие доклады, по моему мнению — мусор в любом случае, пусть там докладчиком хоть сам Цицерон.
Теперь про фору американских спикеров — ее нет. Да, тут людей учат в ораторскому искусству в школе, и потому тут практически нет людей, которые совсем не могут говорить со сцены, но мнение о том, что они тут все прямо на голову выше — ошибочное, и связано с тем, что они говорят на другом языке, который для вас является иностранным, и потому вы его слушаете и воспринимаете совершенно иначе, чем родной. Они тут и ошибаются тоже довольно много, и пауз ненужных в речи у них достаточно, а что руками машут задорнее — тут так принято. В общем, на мой взгляд, подавляющее превосходство американских докладчиков над российскими — это ошибка восприятия.
Почему на форумах выступают спикеры — это вопрос к устроителям форумов. Нравится ребятам слово — вот и используют. Мне не нравится, и я его использую в том смысле, в котором оно мне ближе.
Заменять русское слово иностранным, на мой взгляд, стоит тогда, когда подходящего слова либо не нашлось, либо оно слишком широкое по смыслу. Слово же «спикер» — оно по смыслу значительно шире, чем русское слово «докладчик», при этом доклад свой можно не только читать, но и выступать с ним, чего мы и хотим добиться. Вам не нравится налипший на это слово советский колорит («доклады членов 30 съезда КПСС вызвали бурные и продолжительные аплодисменты»), но он постепенно уходит в прошлое, а вот «спикер» в значении «докладчик» как было неприятным англицизмом, так и остается. Если через 10 лет с него уберут пометки жарг. и неол. в словаре — ну что ж, народ сказал свое слово, пусть будет.
Спорить о нюансах языка можно долго, и в спорах подобного рода редко рождается истина, т.к. язык — он у каждого свой, на самом деле, и то, что мы понимаем друг друга хоть как-то — уже большое достижение. Хотите спикера, пусть будет спикер, но найдутся люди, которые будут голосовать против употребления этого слова (особенно в смысле «это как докладчик, только лучше, на уровне американских») специально предназначенной для подобных случаев кнопкой.
За заголовок можно минусовать не читая, при этом статья довольно неплохая и советы дельные, только вот авторы зачем-то издеваются над русским языком.
Более того, подразумевается, что «докладчик» это чем-то хуже, чем «спикер», хотя на самом деле спикер — это вообще любая ерунда, которая относительно членораздельные звуки издает (PC speaker сразу на ум пришел), а докладчик — это человек, представляющий доклад. Получается в итоге смешно, превращаем то, что нужно, в ерунду какую-то, попутно надругавшись над языком. Не надо так.
Замечу, что подпись исполняемых файлов в Windows и UEFI — в формате PKCS#7 v1.5 (а точнее, его MS-модификации по имени Authenticode), и использует она упомянутую в статье X.509 v3 certificate chain, так что проверка такой подписи — это тоже работа с сертификатами X.509.
Если руки дойдут — напишу про это все статью как-нибудь, потому что там тоже, как оказалось, масса подводных граблей и темных углов.
МЕ работает от дежурного напряжения, и потому может исполнять свой код даже на «выключенном» компьютере. Ясно, что для взлома его все-таки потребуется включить, зато потом можно творить свои темные дела и на «выключенном». Согласен с тем, что заголовок несколько громче, чем следовало бы, но ради содержимого я готов это простить.
Статья — огонь, Хабр — торт, всем причастным — респект и уважуха.
Ждем статей про внутренее устройство железа и прошивки МЕ, уверен, что вам всем есть что рассказать о них.
Добавлю из своего прошивочного погреба: для проталкивания Rust в эту нишу нужно очень сильное давление со стороны производителей CPU, потому что именно они пишут львиную долю кода прошивок и пока они не захотят сменить C на более безопасный язык — ничего с места не сдвинется.
В Google товарищи, которые занимались coreboot, решили написать свою собственную реализацию фазы DXE (проект u-root) на Go, и у них оно может выстрелить, т.к. ресурсов достаточно, но пока индустрия вся это не поддержит — ничего не изменится, и пока даже намеков нет на какой-то прогресс в этой области.
Понятно, что любой путь начинается с первого шага, но пока даже на этот шаг (в случае с Rust таким шагом будет добавление драйверов на нем в сборочную систему EDK2, чтобы можно было начать их собирать там же, где собирается все остальное) времени ни у кого нет.
Модель своего ноутбука подскажите, потому что снимать дамп нужно утилитой Intel Flash Programming Tool, а она не запустится если ее версия не совпадает с мажорной версией ME.
Ребят, хоть кто-нибудь дамп прошивки в этом непонятном состоянии сделать догадался? Если тут есть кто-то с этой проблемой несохраняющихся настроек, способный загрузить Windows, напишите модель своего ноута, я расскажу как сделать дамп.
Без дампов это бесполезно расследовать, потому что гадание на кофейной гуще.
Если хотите гаданий, их есть у меня:
1. Линукс каким-то образом в очередной раз испортил прошивке NVRAM своей загрузочной записью, которую создал efibootmgr. Я про него устал уже проедупредждать, но похоже, надо делать это в каждом коментарии — авось кого-нибудь это остановит.
2. Драйвер spi_nor.c даже при простом поиске подключенных к нему чипов зачем-то пытается снять защиту от записи с некоторых из них, которую он не ставил и трогать не должен. Получается очень странная функция spi_nor_scan(), меняющяя состояние чипа. При этом чип, скорее всего, стартует с поставленным битом, а прошивка затем при записи пытается сбросить его через NEG, в результате только ставя его обратно. При этом для сброса на дефолты нужно полное обесточивание чипа (т.е. отсоединение батареи), либо установка этого бита вручную.
Короче, попробуйте для начала вынуть жесткий диск (чтобы не грузиться в этот линукс со странным драйвером) и батарею вынуть на минуту (не CMOS, а основную). Если после этого настройки начнут сохранятся — тут всяко второй вариант, а если не начнут — то может быть и первый, и что угодно еще.
Она не обязательна юридически, но включается в договоры аренды помещений повсеместно, и удалять ее оттуда ради вас никто не будет. Стоит такая страховка обычно совсем недорого, меньше 10 евро в месяц, поэтому она есть практически у всех.
которая всего лишь в течении десятка лет обеспечивала работу интеловского бэкдора IME.
Опять не в лотерею, а в карты, и не выиграл, а проиграл.
Minix используется только на МЕ10+, дебютировавший на платформе Skylake, так что десяток лет — это на самом деле два с небольшим, т.е. ее официальный анонс состоялся 5 августа 2015 года. До этого использовалась ОСРВ ThreadX.
Во-вторых, термин «бэкдор» для Management Engine — слишком сильный. Софт намного дешевле железа, поэтому на МЕ и повесили столько всего с момента его появления в сетевых картах. Да, теперь МЕ занимается чем попало от загрузки микрокода из FIT до эмуляции устройства TPM 2.0 и поддержки шифрованного А\В канала для HDMI, но это все исключительно потому, что в железе все эти вещи было бы сделать тупо вдесятеро дороже, а процессоры для ПК должны стоить дешево, иначе конкуренты сожрут. Думаете АМД себе в Ryzen добавили PSP от хорошей жизни, или просто потому, что софт дешев, а железо дорого? Вот то то и оно.
Фанатам открытости и свободы посоветую изначально открытые архитектуры вроде RISC-V и OpenPOWER, ибо на x86 и ARM ни того, ни другого уже давно нет.
Грубая оценка по опыту работы в другой большой компании похожего уровня.
Из всего вышеперечисленного только Chrome уже написан, и браться его переписывать на Go с нуля нет никакого смысла, все остальное — почему нет? Для хардкорной математики все равно будут использованы готовые библиотеки на С или Фортране (FFI у языка есть, сопряжение хоть и не без проблем, но работает), а для основной grunt work язык Go вполне подходит. Они на нем теперь даже initramfs пишут, так что я не удивлюсь, если напишут и что-нибудь из ML (AI все же слишком сильный термин, на мой взгляд).
Автор не понимает целей и задач Гугла при разработке этого языка, поэтому сетует на то, что Go — это такой «С для дураков», а надо было вместо него внедрять что другое, с нативным ООП, с шаблонами, с выводом типов. D, например, или Rust, или вообще ЯФП какой-нибудь.
Так вот, примерно 90% задач гугла вполне решается на этом самом «С для дураков» без использования кодогенерации, рефлексии, шаблонов, ООП и чего либо еще, и самое главное, что в итоге написанный разработчиками любого уровня код на Go смогут понять любые другие разработчики, даже если они в компании работают сутки и пришли сразу после ВУЗа.
Более того, при уходе всех оригинальных разработчиков из команды проект не придется выбрасывать весь, потому что в нем никто не может разобраться, а получится передать другой команде обычных программистов, и они смогут подхватить его в относительно короткие сроки.
Простота поддержки, простота отладки и поиска ошибок, доступность даже для новичков, и минимальные шансы выстрелить себе в ногу — вот что нужно компаниям уровня Гугла для большей части их кода. А оставшуюся меньшую часть можно писать на чем угодно, хоть на ассемблере, если есть такая необходимость.
Дима, Марк, Макс, спасибо вам огромное от всего сообщества и меня лично за эти таблицы, за бит HAP, и за то, что заставили Intel наконец заняться безопасностью своей прошивки, имеющей слишком много привилегий.
Это все очень гладко на бумаге, но позволить себе подобное могут только те, у кого проекты либо очень маленькие, либо очень дорогие, либо на них сидит сотня человек и можно бросить десяток на доводку предупреждений многочисленных компиляторов.
В реальности же абсолютное большинство проектов собирается для одной единственной ОС, одним единственным семейством компиляторов, без warnings-as-errors и прочего, и там от внедрения статического анализа (хоть какого-нибудь, не обязательно конкретно PVS-Studio) польза весьма существенная и доступна она практически сразу.
Про предупреждения компиляторов: ну вот пока еще не один не смог предупредить меня, что у меня две функции имеют одинаковое тело, хотя задумывались разными, что у меня результат вызова функции не влияет на проверяемое значение, что у меня в условии продолжения цикла for используется оператор, в смысле &&, а это так не работает на самом деле, что у меня оптимизатор может удалить цикл ожидания на MMIO-регистре, потому что он не помечен как volatile, и вызов memset для затирания данных на стеке тоже может удалить, потому что он не влияет на наблюдаемое поведение.
Понятно, что добрую половину всего вот этого можно получить, разобравшись с миллионом опций своего компилятора, но тут фишка в том, что сама по себе компиляция при этом с большой вероятностью сломается в стольких местах, что никто по доброй воле эти хитрые предупреждения больше никогда не включит.
Внедрение хорошего статического анализатора туда, где его никогда не было, а код при этом писали на обычном C/C++ (а не на MISRA C с последующей верификацией) обычные люди (не Boeing/Airbus/NASA), за обычные деньги и при постоянного горящих сроках — оно сразу позволяет найти кучу ошибок, просто потому что на танцы с опциями компилятора ни у кого времени нет и никогда не будет.
В итоге джуниором туда идут только самые стойкие оловянные солдатики, с которыми потом и работаем. И это все при том, что тут достаточно обычного компьютера для старта.
Дело там не в версии МЕ, а в версии Intel Platform Support Code, вместе с которым поставляется и МЕ в том числе. Поддержка инженерных и квалификационных семплов обычно заканчивается значительно раньше, чем поддержка релейных процессоров, и потому код для них из PSC просто выкидывается. Можно, конечно, попробовать портировать его из старой прошивки в новую, но это масса работы ради непонятно чего, гораздо лучше будет либо оставаться на последней поддерживаемой версии, либо сменить процессор на нормальный. Замена МЕ\контрольной суммы\адреса\т.п. — точно не выход.
Вообще раз уж мы тут заговорили про ES и QS — читатель, я вас заклинаю, не покупайте их никогда, а если даром дают — отдайте назад. Вот эта проблема с PSC — это вершина айсберга, и там могут встречаться такие странные глюки в самых неожиданных местах, что лучше с ними не связываться вообще никогда.
Инструмент лучше выбирать самому, и брать надо сразу нормальный, а не очередной китайский набор 1000-в-1 известного качества и цен. От себя лично посоветую отвертки Wiha PicoFinish или Precision ESD, они хоть и дорогие, зато и работать с ними — одно удовольствие.
Для разного рода нестандартных винтов хороши наборы от iFixit, и хотя там качество похуже, чем у Wiha, но зато битов море разных.
Второй вид — это когда никакой толком информации в докладе нет, и там либо мнения какие-то чьи-то, либо банальности, либо другая какая-нибудь ерунда. Такие доклады не стоят потраченного на них времени независимо от ораторского уровня докладчика. Да, я понимаю, что на TED Talks люди на полном серьезе говорят о том, что «нас, оказывается, неправильно учили завязывать шнурки, я сейчас вам всем открою глаза на то, как правильно», но такие доклады, по моему мнению — мусор в любом случае, пусть там докладчиком хоть сам Цицерон.
Теперь про фору американских спикеров — ее нет. Да, тут людей учат в ораторскому искусству в школе, и потому тут практически нет людей, которые совсем не могут говорить со сцены, но мнение о том, что они тут все прямо на голову выше — ошибочное, и связано с тем, что они говорят на другом языке, который для вас является иностранным, и потому вы его слушаете и воспринимаете совершенно иначе, чем родной. Они тут и ошибаются тоже довольно много, и пауз ненужных в речи у них достаточно, а что руками машут задорнее — тут так принято. В общем, на мой взгляд, подавляющее превосходство американских докладчиков над российскими — это ошибка восприятия.
Почему на форумах выступают спикеры — это вопрос к устроителям форумов. Нравится ребятам слово — вот и используют. Мне не нравится, и я его использую в том смысле, в котором оно мне ближе.
Заменять русское слово иностранным, на мой взгляд, стоит тогда, когда подходящего слова либо не нашлось, либо оно слишком широкое по смыслу. Слово же «спикер» — оно по смыслу значительно шире, чем русское слово «докладчик», при этом доклад свой можно не только читать, но и выступать с ним, чего мы и хотим добиться. Вам не нравится налипший на это слово советский колорит («доклады членов 30 съезда КПСС вызвали бурные и продолжительные аплодисменты»), но он постепенно уходит в прошлое, а вот «спикер» в значении «докладчик» как было неприятным англицизмом, так и остается. Если через 10 лет с него уберут пометки жарг. и неол. в словаре — ну что ж, народ сказал свое слово, пусть будет.
Спорить о нюансах языка можно долго, и в спорах подобного рода редко рождается истина, т.к. язык — он у каждого свой, на самом деле, и то, что мы понимаем друг друга хоть как-то — уже большое достижение. Хотите спикера, пусть будет спикер, но найдутся люди, которые будут голосовать против употребления этого слова (особенно в смысле «это как докладчик, только лучше, на уровне американских») специально предназначенной для подобных случаев кнопкой.
Более того, подразумевается, что «докладчик» это чем-то хуже, чем «спикер», хотя на самом деле спикер — это вообще любая ерунда, которая относительно членораздельные звуки издает (PC speaker сразу на ум пришел), а докладчик — это человек, представляющий доклад. Получается в итоге смешно, превращаем то, что нужно, в ерунду какую-то, попутно надругавшись над языком. Не надо так.
Если руки дойдут — напишу про это все статью как-нибудь, потому что там тоже, как оказалось, масса подводных граблей и темных углов.
Ждем статей про внутренее устройство железа и прошивки МЕ, уверен, что вам всем есть что рассказать о них.
В Google товарищи, которые занимались coreboot, решили написать свою собственную реализацию фазы DXE (проект u-root) на Go, и у них оно может выстрелить, т.к. ресурсов достаточно, но пока индустрия вся это не поддержит — ничего не изменится, и пока даже намеков нет на какой-то прогресс в этой области.
Понятно, что любой путь начинается с первого шага, но пока даже на этот шаг (в случае с Rust таким шагом будет добавление драйверов на нем в сборочную систему EDK2, чтобы можно было начать их собирать там же, где собирается все остальное) времени ни у кого нет.
Без дампов это бесполезно расследовать, потому что гадание на кофейной гуще.
Если хотите гаданий, их есть у меня:
1. Линукс каким-то образом в очередной раз испортил прошивке NVRAM своей загрузочной записью, которую создал efibootmgr. Я про него устал уже проедупредждать, но похоже, надо делать это в каждом коментарии — авось кого-нибудь это остановит.
2. Драйвер spi_nor.c даже при простом поиске подключенных к нему чипов зачем-то пытается снять защиту от записи с некоторых из них, которую он не ставил и трогать не должен. Получается очень странная функция spi_nor_scan(), меняющяя состояние чипа. При этом чип, скорее всего, стартует с поставленным битом, а прошивка затем при записи пытается сбросить его через NEG, в результате только ставя его обратно. При этом для сброса на дефолты нужно полное обесточивание чипа (т.е. отсоединение батареи), либо установка этого бита вручную.
Короче, попробуйте для начала вынуть жесткий диск (чтобы не грузиться в этот линукс со странным драйвером) и батарею вынуть на минуту (не CMOS, а основную). Если после этого настройки начнут сохранятся — тут всяко второй вариант, а если не начнут — то может быть и первый, и что угодно еще.
Опять не в лотерею, а в карты, и не выиграл, а проиграл.
Minix используется только на МЕ10+, дебютировавший на платформе Skylake, так что десяток лет — это на самом деле два с небольшим, т.е. ее официальный анонс состоялся 5 августа 2015 года. До этого использовалась ОСРВ ThreadX.
Во-вторых, термин «бэкдор» для Management Engine — слишком сильный. Софт намного дешевле железа, поэтому на МЕ и повесили столько всего с момента его появления в сетевых картах. Да, теперь МЕ занимается чем попало от загрузки микрокода из FIT до эмуляции устройства TPM 2.0 и поддержки шифрованного А\В канала для HDMI, но это все исключительно потому, что в железе все эти вещи было бы сделать тупо вдесятеро дороже, а процессоры для ПК должны стоить дешево, иначе конкуренты сожрут. Думаете АМД себе в Ryzen добавили PSP от хорошей жизни, или просто потому, что софт дешев, а железо дорого? Вот то то и оно.
Фанатам открытости и свободы посоветую изначально открытые архитектуры вроде RISC-V и OpenPOWER, ибо на x86 и ARM ни того, ни другого уже давно нет.
Из всего вышеперечисленного только Chrome уже написан, и браться его переписывать на Go с нуля нет никакого смысла, все остальное — почему нет? Для хардкорной математики все равно будут использованы готовые библиотеки на С или Фортране (FFI у языка есть, сопряжение хоть и не без проблем, но работает), а для основной grunt work язык Go вполне подходит. Они на нем теперь даже initramfs пишут, так что я не удивлюсь, если напишут и что-нибудь из ML (AI все же слишком сильный термин, на мой взгляд).
Так вот, примерно 90% задач гугла вполне решается на этом самом «С для дураков» без использования кодогенерации, рефлексии, шаблонов, ООП и чего либо еще, и самое главное, что в итоге написанный разработчиками любого уровня код на Go смогут понять любые другие разработчики, даже если они в компании работают сутки и пришли сразу после ВУЗа.
Более того, при уходе всех оригинальных разработчиков из команды проект не придется выбрасывать весь, потому что в нем никто не может разобраться, а получится передать другой команде обычных программистов, и они смогут подхватить его в относительно короткие сроки.
Простота поддержки, простота отладки и поиска ошибок, доступность даже для новичков, и минимальные шансы выстрелить себе в ногу — вот что нужно компаниям уровня Гугла для большей части их кода. А оставшуюся меньшую часть можно писать на чем угодно, хоть на ассемблере, если есть такая необходимость.
В реальности же абсолютное большинство проектов собирается для одной единственной ОС, одним единственным семейством компиляторов, без warnings-as-errors и прочего, и там от внедрения статического анализа (хоть какого-нибудь, не обязательно конкретно PVS-Studio) польза весьма существенная и доступна она практически сразу.
Про предупреждения компиляторов: ну вот пока еще не один не смог предупредить меня, что у меня две функции имеют одинаковое тело, хотя задумывались разными, что у меня результат вызова функции не влияет на проверяемое значение, что у меня в условии продолжения цикла for используется оператор, в смысле &&, а это так не работает на самом деле, что у меня оптимизатор может удалить цикл ожидания на MMIO-регистре, потому что он не помечен как volatile, и вызов memset для затирания данных на стеке тоже может удалить, потому что он не влияет на наблюдаемое поведение.
Понятно, что добрую половину всего вот этого можно получить, разобравшись с миллионом опций своего компилятора, но тут фишка в том, что сама по себе компиляция при этом с большой вероятностью сломается в стольких местах, что никто по доброй воле эти хитрые предупреждения больше никогда не включит.
Внедрение хорошего статического анализатора туда, где его никогда не было, а код при этом писали на обычном C/C++ (а не на MISRA C с последующей верификацией) обычные люди (не Boeing/Airbus/NASA), за обычные деньги и при постоянного горящих сроках — оно сразу позволяет найти кучу ошибок, просто потому что на танцы с опциями компилятора ни у кого времени нет и никогда не будет.
Мужики, у вас версия для MacOS планируется хоть когда-нибудь? Там не должно быть слишком уж больших отличий от версии для Linux, по идее.