Проблема в пилотной группе - никто там быть не хочет, а тестировать обнову в боевых условиях как-то надо. Результат - обычно пилотную группу и не делают, а проверяют только на "виртуалке на серваке", на случай если ломается что-то такое, что вообще работать нельзя. А потом хоба и пол-офиса потеряли расшаренные принтеры...
Формулировка комментария такая, что читается как "AMD обещает исправить отсутствие ошибки при генерации 64-битного числа" вместо ошибок для 16- и 32-битных результатов. :)
iptables-nftables существует неспроста. Эквивалент всегда можно найти, мало того, там где nft стоит и работает, и есть iptables-nftables, команда всё равно сделает что надо поверх настроенной системы цепочек и правил nft.
https://what-if.xkcd.com/29/ Похоже, что водоём есть, но больше технический, доп.уровень защиты для оболочки под давлением, а также для перехвата высокоэнергетичных нейтронов, пролетающих эту оболочку насквозь. То есть обычный ВВЭР(PWR) спрятан под ещё одним слоем воды. Работник же, как я понимаю, упал в хранилище топлива перед/после работы в реакторе, там вода служит для защиты от перегрева помимо захвата нейтронов. Насчет "потянет радиацию в воздух" - а что может с испарением вылететь при штатной нагрузке? Там даже тритию взяться неоткуда - вода в защитном контуре обычная H2O, нейтрон из неё может сделать тяжелую HDO либо "проапгрейдить" кислород до O(17), затем до О(18) который распадается по альфа-каналу до С(14) - ну его и так в атмосфере хватает, да, вроде бы повышенные выбросы от иррадиации присутствуют, и даже некоторые АЭС фильтруют воду, убирая "тяжелую по кислороду" из контура (вместе с тритием, но на вики написано не совсем понятно, из какой именно воды убирают тритий, логика подсказывает, что из внутреннего контура, где поток нейтронов достаточно большой, чтобы трития образовывалось влияющее количество), но разница от иррадиации внешнего контура должна быть в пределах погрешности.
Клон переименован? Если нет, то да, сразу ломается, если переименовать, живут неплохо - сиспреп заведомо нужен только при установке нового DC, вот там ломается, и ломался ещё в 2000м. Домен слегка подкручен в "плюс". Ну и да, клонируется ПК/ВМ без членства в домене, потом вводится в домен стандартным способом - если клонировать комп уже в домене, будет тоже ломаться.
то это баг, и надо (разработчикам AMD) разобраться, откуда он взялся и что к нему приводит. Кстати, я в той статье не видел, сколько процентов запросов RDSEED вернуло val=0 CF=0, может и впрямь там 99% ошибок. Но всё равно, возврат val=0 CF=1 в таком количестве в общем случае некорректен. По поводу некорректности тестовой программы - вообще говоря, это возможно, но в таком случае под подозрение подпадает не только тестовая программа, но и планировщик ОС, и код переключения потоков, и ещё много что, так как реально имеется "два потока на ядро" - мало ли из-за чего внезапно устанавливается CF, когда не должен.
Это не странная вещь, это описание эксперимента на работающей системе, при котором RDSEED выдает некорректные результаты. Я думаю, влияет постоянная инвалидация кэша, другое дело, как именно. "Hammering on RAM" это постоянные попытки чтения (а может и записи), предназначенные для того, чтобы кэш L1/L2 постоянно не играл роли, так как следующее чтение или запись выполняются к адресу, который отсутствует в кэше. Конкретная реализация скрыта за коммерческой тайной AMD, но скорее всего, если в каких-то условиях оказывается, что RDSEED выдает некорректные результаты, значит, где-то в микрокоде есть состояние гонки, или сопоставимый с ним баг, и это уже предмет для разбирательств внутри AMD. Может ещё быть, что де-факто исчерпывается источник энтропии внутри процессора, но тогда RDSEED должен возвращать 0 в CF, но он этого не делает - всё равно баг.
Что неверно, так как при CF=0 никакого значения вообще нет.
Выше же цитаты из мануала по RDSEED, где сказано, что если CF=0, то в регистре должен быть ноль. Значения нет, но команда не может вернуть вообще ничего, так как у неё строго один регистр в списке выходных. Вот его решили занулять. Поэтому он и пишет, что 0 в регистре "обычно" появляется, если операция провалилась (хотя и может появиться при CF=1 с тем же шансом, как любое другое значение в нём - рандом же). Поэтому куча нулей при CF=1 - баг.
Я его так понял, что в ~10% случаев возврат RDSEED был 0 при CF=1, то есть верно первое предположение. Цитата, кстати, явно указывает на первый случай в стартовом коменте ветки:
Under unknown architectural conditions, Zen5 chips running rdseed can produce (val=0,CF=1) as a "random" result over 10% of the time (when rdseed is successful).
bus factor==1 - вина начальника. нечего завязывать весь проект на один фэйс, в конце концов он мог и не свалить, а тупо сдохнуть от передоза от внешних причин, и вы бы точно так же обфакапились.
TL;DR химики собрали и протестировали молекулу, которая реагирует в полости рта на вещество, выделяющееся в слюну при инфекции гриппом, но не чем-то ещё ("сенсор"), выделяя остроту (тимол), и планируют запихать его в жвачку. Дополнительные данные: один из путей сборки "сенсора" оказался пригодным для промышленных масштабов, вместо остроты можно использовать другие вещества (ограничения неясны, но теоретически возможность есть), но время диагностики довольно длительное (30 минут). Остальной текст нейрошушера или детальные выкладки научным языком. Вообще говоря, полезная и довольно прорывная штука.
Не подов, а их данных, и изначально все поды были эфемерные - хранилище выделялось на нодах без какой-либо персистентности. А потом какие-то умные головы начали пихать в куб СУБД, которые затребовали постоянное хранение, кубу пришлось городить PVC/PV инфраструктуру - и вы спрашиваете коркретно про неё, а она вообще говоря кубо-независимая, и под её капотом может сидеть и NFS, и локальные рейды, и какой-нибудь Ceph, и ХЗ что ещё, вплоть до физического NAS'a, который научили выделять пространство мелкими кусочками по запросу. Остальные ваши запросы уже третий уровень, из-за этого и порождаемой сложности управления (а куб непрозрачно работает с statefulset'ами БД) я лично предпочитаю держать БД вне куба.
Вот по одним названиям в самом деле сложно понять, кто где живет. А внутриигровая стилистика у них как раз на высоте. Замок это рыцари - крепостные здания (белого камня, что круче), бастион это ушастики и всякая лесная живность, башня это маги и их порождения, крепость - вопрос к переводу, это stronghold или fortress, пустыня или болота с тамошними жителями, подземелья это те, кто без глаз может дорогу найти (а то и пролететь). А вот не назвали вы некрополь, инферно и конфлюкс (точнее Elemental Conflux), о которых всё прекрасно понятно сразу.
"углеродный след тотального SSL"? дык защита данных при передаче от подслушивающих детей стоит куда больше.
Проблема в пилотной группе - никто там быть не хочет, а тестировать обнову в боевых условиях как-то надо. Результат - обычно пилотную группу и не делают, а проверяют только на "виртуалке на серваке", на случай если ломается что-то такое, что вообще работать нельзя. А потом хоба и пол-офиса потеряли расшаренные принтеры...
Формулировка комментария такая, что читается как "AMD обещает исправить отсутствие ошибки при генерации 64-битного числа" вместо ошибок для 16- и 32-битных результатов. :)
iptables-nftables существует неспроста. Эквивалент всегда можно найти, мало того, там где nft стоит и работает, и есть iptables-nftables, команда всё равно сделает что надо поверх настроенной системы цепочек и правил nft.
https://what-if.xkcd.com/29/
Похоже, что водоём есть, но больше технический, доп.уровень защиты для оболочки под давлением, а также для перехвата высокоэнергетичных нейтронов, пролетающих эту оболочку насквозь. То есть обычный ВВЭР(PWR) спрятан под ещё одним слоем воды. Работник же, как я понимаю, упал в хранилище топлива перед/после работы в реакторе, там вода служит для защиты от перегрева помимо захвата нейтронов.
Насчет "потянет радиацию в воздух" - а что может с испарением вылететь при штатной нагрузке? Там даже тритию взяться неоткуда - вода в защитном контуре обычная H2O, нейтрон из неё может сделать тяжелую HDO либо "проапгрейдить" кислород до O(17), затем до О(18) который распадается по альфа-каналу до С(14) - ну его и так в атмосфере хватает, да, вроде бы повышенные выбросы от иррадиации присутствуют, и даже некоторые АЭС фильтруют воду, убирая "тяжелую по кислороду" из контура (вместе с тритием, но на вики написано не совсем понятно, из какой именно воды убирают тритий, логика подсказывает, что из внутреннего контура, где поток нейтронов достаточно большой, чтобы трития образовывалось влияющее количество), но разница от иррадиации внешнего контура должна быть в пределах погрешности.
iptables -P OUTPUT DROP, и читать логи, кто пытается в интернет вылезти. И потом их точечно вышибать.
потом winget начнет их молча же регать в магазине...
Клон переименован? Если нет, то да, сразу ломается, если переименовать, живут неплохо - сиспреп заведомо нужен только при установке нового DC, вот там ломается, и ломался ещё в 2000м. Домен слегка подкручен в "плюс". Ну и да, клонируется ПК/ВМ без членства в домене, потом вводится в домен стандартным способом - если клонировать комп уже в домене, будет тоже ломаться.
Если есть
то это баг, и надо (разработчикам AMD) разобраться, откуда он взялся и что к нему приводит. Кстати, я в той статье не видел, сколько процентов запросов RDSEED вернуло val=0 CF=0, может и впрямь там 99% ошибок. Но всё равно, возврат val=0 CF=1 в таком количестве в общем случае некорректен.
По поводу некорректности тестовой программы - вообще говоря, это возможно, но в таком случае под подозрение подпадает не только тестовая программа, но и планировщик ОС, и код переключения потоков, и ещё много что, так как реально имеется "два потока на ядро" - мало ли из-за чего внезапно устанавливается CF, когда не должен.
Это не странная вещь, это описание эксперимента на работающей системе, при котором RDSEED выдает некорректные результаты. Я думаю, влияет постоянная инвалидация кэша, другое дело, как именно. "Hammering on RAM" это постоянные попытки чтения (а может и записи), предназначенные для того, чтобы кэш L1/L2 постоянно не играл роли, так как следующее чтение или запись выполняются к адресу, который отсутствует в кэше. Конкретная реализация скрыта за коммерческой тайной AMD, но скорее всего, если в каких-то условиях оказывается, что RDSEED выдает некорректные результаты, значит, где-то в микрокоде есть состояние гонки, или сопоставимый с ним баг, и это уже предмет для разбирательств внутри AMD. Может ещё быть, что де-факто исчерпывается источник энтропии внутри процессора, но тогда RDSEED должен возвращать 0 в CF, но он этого не делает - всё равно баг.
Выше же цитаты из мануала по RDSEED, где сказано, что если CF=0, то в регистре должен быть ноль. Значения нет, но команда не может вернуть вообще ничего, так как у неё строго один регистр в списке выходных. Вот его решили занулять. Поэтому он и пишет, что 0 в регистре "обычно" появляется, если операция провалилась (хотя и может появиться при CF=1 с тем же шансом, как любое другое значение в нём - рандом же). Поэтому куча нулей при CF=1 - баг.
Я его так понял, что в ~10% случаев возврат RDSEED был 0 при CF=1, то есть верно первое предположение. Цитата, кстати, явно указывает на первый случай в стартовом коменте ветки:
bus factor==1 - вина начальника. нечего завязывать весь проект на один фэйс, в конце концов он мог и не свалить, а тупо сдохнуть
от передозаот внешних причин, и вы бы точно так же обфакапились.TL;DR химики собрали и протестировали молекулу, которая реагирует в полости рта на вещество, выделяющееся в слюну при инфекции гриппом, но не чем-то ещё ("сенсор"), выделяя остроту (тимол), и планируют запихать его в жвачку.
Дополнительные данные: один из путей сборки "сенсора" оказался пригодным для промышленных масштабов, вместо остроты можно использовать другие вещества (ограничения неясны, но теоретически возможность есть), но время диагностики довольно длительное (30 минут). Остальной текст нейрошушера или детальные выкладки научным языком.
Вообще говоря, полезная и довольно прорывная штука.
Не подов, а их данных, и изначально все поды были эфемерные - хранилище выделялось на нодах без какой-либо персистентности. А потом какие-то умные головы начали пихать в куб СУБД, которые затребовали постоянное хранение, кубу пришлось городить PVC/PV инфраструктуру - и вы спрашиваете коркретно про неё, а она вообще говоря кубо-независимая, и под её капотом может сидеть и NFS, и локальные рейды, и какой-нибудь Ceph, и ХЗ что ещё, вплоть до физического NAS'a, который научили выделять пространство мелкими кусочками по запросу. Остальные ваши запросы уже третий уровень, из-за этого и порождаемой сложности управления (а куб непрозрачно работает с statefulset'ами БД) я лично предпочитаю держать БД вне куба.
Вот по одним названиям в самом деле сложно понять, кто где живет. А внутриигровая стилистика у них как раз на высоте. Замок это рыцари - крепостные здания (белого камня, что круче), бастион это ушастики и всякая лесная живность, башня это маги и их порождения, крепость - вопрос к переводу, это stronghold или fortress, пустыня или болота с тамошними жителями, подземелья это те, кто без глаз может дорогу найти (а то и пролететь). А вот не назвали вы некрополь, инферно и конфлюкс (точнее Elemental Conflux), о которых всё прекрасно понятно сразу.
Они сломали барьеры со словами, что ли?
А оно там есть, в заголовке: "Возможные..."
Обычно в операционной набор инструментов пошире, чем в медпункте.
...в идеальном мире. Когда от идеала хоть немного отступают, хоть кто хоть где, бывает и вот такое.