Тут варианты есть. Можно покопать smartd. Можно копать в сторону udev rules. Можно просто скрипт написать который правильно переименует устройства.
Тут главное, — знать о проблеме, т.к. с настройками по-умолчанию можно ошибиться по-незнанию.
Резервные копии конечно-же есть. Делаются автоматически, регулярно и на внешнее устройство. Но, тут обошлось даже без восстановления из резервных копий. Спасло то, что NVMe SSD заменяются на основе SMART атрибутов до фактического выхода из строя. Оставшийся в массиве «плохой» диск был способен проработать еще пару недель как минимум.
Проблему заметили вовремя и перенесли с него данные на новый рабочий носитель в штатном порядке.
Smartmontools мониторит NVMe устройства через их символьные устройства контроллеры. В отчетах которые присылаются по почте — тоже указывается именно символьное устройство: Device: /dev/nvme2, Temperature 59 Celsius reached critical limit of 59 Celsius (Min/Max 33/80)
Собственно да, отсюда и растут ноги у подставы. Особенность работы smartctl с NVMe. В сочетании с особенностью ядра, которое назначает имена контроллерам и нэймспейсам абы-как.
P.S. для тех кто захочет это написать в коде…
Хэш делить на две части. Ту часть которая используется для вычисления offset в таблице, — в саму таблицу не надо пихать. Это избыточная информация.
Проблема со случайным доступом к памяти у фильтра Блума — штука известная и довольно очевидная для тех, кто знает числа, которые должен знать каждый программист.
Замена фильтра Блума на подобную хэш таблицу работает хорошо, но там совсем не нужен linear probing при обработке коллизий. Он легко заменяется на bitwise OR. Проверка наличия строчки в таблице делается через bitwise AND. В этом случае потребление памяти получается практически равно таковому у фильтра Блума, и работает быстрее предложенной таблички, т.к. нет лишних условных переходов/циклов, которые процессору надо предсказывать. Работает еще быстрее.
Деятельность сия почетна и надо доводить дело до конца. Для этого есть суды. Однако, к пересмотру результатов выборов это не приведет.
Однако, если мы переходим на личности, поучаствовать в процессе не могу. Давно не живу в России. Так что, для меня, это не какая-то личная трагедия. Это, возможно, делает меня более объективным.
Автор предложил модель. Показал что она не соответствует реальности. И, попытался объяснить это подтасовками.
Если удалить из статьи объяснение, которое субъективно. В сухом остатке у нас просто модель которая не сходится с реальностью.
Пики широкие и не очень ярко выражены относительно их основания, да и после 70% кривая из Гаусса становится чем-то совсем незнакомым.
У нас явно композиция случайных величин, и, не все они имеют нормальное распределение. Там что-то другое. Например, из графиков очевидно, что на участках, где мало избирателей — гауссовым распределением и не пахло.
Однако, строить дальнейшие рассуждения не учитывая это опасно. Можно прийти к неверным выводам.
более простого объяснения образования пиков вроде тех, что видны на самых разнообразных графиках по выборам, нигде не предложено
Ну почему-же. Попытки предложить объяснения были по ссылкам в статье. Есть еще предположение, что это может быть объяснено количеством бюллетеней. Это все разумные доводы. Я уверен, что можно найти еще.
Мы всегда начинаем с создания статистической модели честных выборов. Показываем что модельные числа не сходятся с действительностью. Однако, из этого можно сделать два совершенно различных вывода:
1. Выборы были нечестными.
2. Модель не отражает реальность.
К сожалению, учитывая простоту рассмотренной в статье модели, второе субъективно кажется более вероятным. Так что, вопрос лежит скорее в плоскости факторов которые не учтены.
В итоге это всегда сводится к вопросу о том, кому мы больше верим — автору модели или избирательной комиссии. А, это всегда субъективно. Это политика. И ей тут не место.
нарисуйте гистограмму, где изображены остатки при делении на 10 от числа пришедших; или, ближе к рассматриваемому вопросу, распределение числа участков по явке, но с бином гистограммы в 10%. Результат будет гладким как при случайной симуляции, но это же ничего не говорит.
Это, действительно, совершенно бессмысленное занятие и результат ни о чем не будет говорить. Однако, ища отличия и не пытаясь найти этим отличиям более простое объяснение чем «теория заговора» мы впадаем в другую крайность, которая ничем не лучше.
Для полноты картины не стоит фильтровать по >500. И, еще стоит учесть количество бюллетеней доставленных на участки. Даже если на участке 500 избирателей, если туда доставлено только 400 бюллетеней, — то больше 400 голосов не будет. Если придет голосовать 401 человек — голосов будет всё равно 400. Вероятность этого исхода резко возрастает. На многих участках бюллетеней меньше чем избирателей.
Дополнительно скажу, что на графике видно видно очень большое количество пиков. И, мне кажется, что после учета количества бюллетеней они совпадут.
К сожалению, все графики в статье отражают количество голосов, а не избирателей. Проверить теорию можно следующим способом:
1. Берем количество избирателей на всех участках.
2. Для каждого участка предполагаем что любое количество проголосовавших избирателей равновероятно.
3. Для каждого возможного количества проголосовавших избирателей на каждом участке определяем в какой процент на шкале оно попадает и агрегируем по процентам и участкам.
На графике получатся пики в тех местах где наиболее вероятно появление пиков вызванных неслучайностью распределения избирателей по участкам.
Я прочитал. Мне просто показалось что в вашем исследовании вы считаете, что количество избирателей на избирательных участках — случайно. Однако же, когда избиратели распределяются по участкам, — процесс совершенно неслучаен. Там есть конкретные нормативы по пропускной способности одной кабинки для голосования. Я конечно могу быть не прав, но, например, 200 человек на кабинку. При распределении домов по участкам могут пытаться по максимуму нагрузить каждую кабинку для голосования. Отсюда и пики.
Я не вижу, или, может быть, не понимаю, как это учтено в вашем исследовании. Если можете пояснить или дополнить, буду рад продолжить дискуссию.
Чем больше у значения процента простых множителей — тем выше пик. Это, думаю, как-то связано с избирательными комиссиями у которых очень мало избирателей и округлением.
А вы тут заговор городите.
JavaScript does not provide access to the rdtscp instruction, and Chrome intentionally degrades the accuracy of its high-resolution timer to dissuade timing attacks using performance.now()[1]. However, the Web Workers feature of HTML5 makes it simple to create a separate thread that repeatedly decrements a value in a shared memory location [18, 32]. This approach yielded a high-resolution timer that provided sufficient resolution.
Кажется, отключение WebWorkers должно предотвратить/усложнить использование атаки через браузер.
Я взял на себя смелость изменить первоначальную процедуру обрезки SSSE3 Даниэля — на самом деле, я использовал свою версию для теста. Причина? Я не могу просто так взять 2 ^ 16 * 2 ^ 4 = 1 Мбайт таблицы поиска в моем коде — это был бы большой пожиратель кеша для любых сценариев, где мы не просто обрезаем потоки ascii, но вызов подпрограммы облегчает другую работу.
Если не использовать кеш на полную, то всё, что на самаом деле будет измеряться, — это скорость памяти. Так получилось исторически, что в армах и x86 память одинаково медленная. Так получилось, что тактовая частота у х86 больше. Поэтому, больше циклов расходуется впустую в ожидании ответа от памяти. Отсюда и результаты измерния в «тактах ЦП на символ».
Тут главное, — знать о проблеме, т.к. с настройками по-умолчанию можно ошибиться по-незнанию.
Проблему заметили вовремя и перенесли с него данные на новый рабочий носитель в штатном порядке.
Device: /dev/nvme2, Temperature 59 Celsius reached critical limit of 59 Celsius (Min/Max 33/80)
Собственно да, отсюда и растут ноги у подставы. Особенность работы smartctl с NVMe. В сочетании с особенностью ядра, которое назначает имена контроллерам и нэймспейсам абы-как.
Хэш делить на две части. Ту часть которая используется для вычисления offset в таблице, — в саму таблицу не надо пихать. Это избыточная информация.
Замена фильтра Блума на подобную хэш таблицу работает хорошо, но там совсем не нужен linear probing при обработке коллизий. Он легко заменяется на bitwise OR. Проверка наличия строчки в таблице делается через bitwise AND. В этом случае потребление памяти получается практически равно таковому у фильтра Блума, и работает быстрее предложенной таблички, т.к. нет лишних условных переходов/циклов, которые процессору надо предсказывать. Работает еще быстрее.
Однако, если мы переходим на личности, поучаствовать в процессе не могу. Давно не живу в России. Так что, для меня, это не какая-то личная трагедия. Это, возможно, делает меня более объективным.
Если удалить из статьи объяснение, которое субъективно. В сухом остатке у нас просто модель которая не сходится с реальностью.
У нас явно композиция случайных величин, и, не все они имеют нормальное распределение. Там что-то другое. Например, из графиков очевидно, что на участках, где мало избирателей — гауссовым распределением и не пахло.
Однако, строить дальнейшие рассуждения не учитывая это опасно. Можно прийти к неверным выводам.
Ну почему-же. Попытки предложить объяснения были по ссылкам в статье. Есть еще предположение, что это может быть объяснено количеством бюллетеней. Это все разумные доводы. Я уверен, что можно найти еще.
Мы всегда начинаем с создания статистической модели честных выборов. Показываем что модельные числа не сходятся с действительностью. Однако, из этого можно сделать два совершенно различных вывода:
1. Выборы были нечестными.
2. Модель не отражает реальность.
К сожалению, учитывая простоту рассмотренной в статье модели, второе субъективно кажется более вероятным. Так что, вопрос лежит скорее в плоскости факторов которые не учтены.
В итоге это всегда сводится к вопросу о том, кому мы больше верим — автору модели или избирательной комиссии. А, это всегда субъективно. Это политика. И ей тут не место.
Это, действительно, совершенно бессмысленное занятие и результат ни о чем не будет говорить. Однако, ища отличия и не пытаясь найти этим отличиям более простое объяснение чем «теория заговора» мы впадаем в другую крайность, которая ничем не лучше.
Просто оставлю это здесь:
График с фильтрацией может и более явно показывает отличие. Но, я ищу, как раз, совпадения.
Дополнительно скажу, что на графике видно видно очень большое количество пиков. И, мне кажется, что после учета количества бюллетеней они совпадут.
1. Берем количество избирателей на всех участках.
2. Для каждого участка предполагаем что любое количество проголосовавших избирателей равновероятно.
3. Для каждого возможного количества проголосовавших избирателей на каждом участке определяем в какой процент на шкале оно попадает и агрегируем по процентам и участкам.
На графике получатся пики в тех местах где наиболее вероятно появление пиков вызванных неслучайностью распределения избирателей по участкам.
Я не вижу, или, может быть, не понимаю, как это учтено в вашем исследовании. Если можете пояснить или дополнить, буду рад продолжить дискуссию.
А вы тут заговор городите.
Кажется, отключение WebWorkers должно предотвратить/усложнить использование атаки через браузер.
Если не использовать кеш на полную, то всё, что на самаом деле будет измеряться, — это скорость памяти. Так получилось исторически, что в армах и x86 память одинаково медленная. Так получилось, что тактовая частота у х86 больше. Поэтому, больше циклов расходуется впустую в ожидании ответа от памяти. Отсюда и результаты измерния в «тактах ЦП на символ».