Да, по обоим пунктам. Мелкое дрожание ещё худо-бедно полечилось настройкой перехода объекта в неподвижное состояние (~засыпание при отсутствии внешних воздействий, не помню сейчас, как именно это называется в ODE), а вот где вылезал NaN дебажить уже лень было.
ODE вообще довольно заброшенный движок, по ощущениям. Как-то написал с его использованием машинку, которая ездила по ландшафту, потом долго удивлялся мелко дрожащим колёсам (а я их сделал "честными" цилиндрами, а не просто вектором-сенсором) и иногда ловил проблему на резком повороте, когда вся система улетала в небеса (где-то в процессе вычислений вылезал NaN, который потом разваливал всю симуляцию). В общем, физический сыроватый в лучшие годы и околозаброшенный к текущему времени.
Фактически, как я понимаю, лазер тут выполняет роль печки принтера. А не пробовали для обеспечения долговечности сначала выгравировать небольшое углубление, в которое потом ляжет тонер?
В общем-то, да. С современными технологиями управления частотой иногда выгоднее понизить немного напряжение (undervolting), чтобы процессор смог сам добавить чуть больше турбо и держать его дольше!
На самом деле, текущее состояние (остановка) можно тоже считать оптимальным в том смысле, что, если движение кольца ничего не даёт (например, предметы однородны), то мы не тратим ресурсы на лишнюю анимацию.
В принципе, да, хотя я не знаю, что будет по скорости износа.
В качестве самодельного печатного варианта попробовал сделать вот такую штуку, корпус из PLA с каналами, куда закладываются кусочки прутка 1,75мм. Пока попробовал нейлон (полиамид-12), работает неплохо, но нужно оценить долговечность. В принципе, аналогично можно заложить и фторопласт, и PEEK.
Вообще из моего опыта даже на хороших направляющих и с приличными LM8UU стол на валках получается довольно громким. В итоге взял себе для Prusa MK3s втулки скольжения Drylin RJ4JP (оригинальные, а не с Али). Теперь при печати с обдувом поток воздуха шумит громче, чем механика.
Сам по себе механизм reparse point используется отнюдь не только Data Deduplication, но и, например, для монтирования или симлинков, это есть в документации Microsoft (отдельно стоит заглянуть в перечень задекларированных тэгов). В документации к профессиональной версии Paragon есть только одно упоминание reparse point: они предлагают свою утилиту junction, чтобы искать и читать точки монтирования. Так что, скорее всего, считать содержимое reparse point их драйвер NTFS позволит, но вот интерпретировать его он сам не пытается.
А разве это является функцией NTFS? Насколько я знаю, Data Deduplication в винде является отдельным сервисом. Разве что его реализация опирается на механизм reparse point, но без самого компонента корректно интерпретировать данные не получится.
Замечу, что даже в Москве в квартире столкнулся с не очень хорошей стабильностью напряжения, из-за которой один ИБП регулярно щёлкал реле (видимо, переключал ступени трансформатора), а второй и вовсе периодически «истерил», уходя на батарею. Так что да, тихая работа для домашнего ИБП очень актуальна.
В рамках данной аналогии, скорее, если подозреваемый ездит на машине марки N, то, внезапно, проезд машин данного производителя по дорогам России становится недоступен (кроме как транзитом и в контейнере).
Насколько я помню, в Windows система часовых поясов попросту изначально не предполагала возможности иметь несколько исторических вариантов для одной географической зоны и, соответственно, если время указано в RTZ2, то никаких его коррекций в случае, если дата до введения этой зоны, не производится. В отличие от Linux, да.
P.S. и да, в системных жураналах событий Windows эта проблема «в полный рост».
Ну и ещё совет: при настройке фильтров в procmon настоятельно рекомендую выставить настройку Filter->Drop Filtered Events, иначе отфильтрованное не отображается, но забивает память или файл лога.
Замечу, что procmon всё-таки утилита полезная, ибо она может в трейсе сохранить даже стек потока и указать точно на модуль и место в нём, откуда пришла бяка. Не знаю, возможно ли это в утилите Nirsoft.
Ну почему же без тестов. В статье ясно написано, что тесты были, но они не выявили аномального роста потребления ресурсов. Вероятно, это недостаток теста, но идеальных тестов не бывает. Вот насчёт ревью ничего не увидел, но, строго говоря, не уверен, что это сильно помогло бы в подобном, но немного менее очевидном случае. Всё-таки regex в голове прокручивать достаточно затруднительно.
У вас есть проблема. Вы решили использовать регулярные выражения чтобы её решить. Теперь у вас две проблемы.
первоначальный источник мне не известен
На самом деле, проблема с реализацией регулярных выражений и бэктрэкингом есть много где. Вот тут мне встречался неплохой разбор этой проблемы, в том числе со ссылкой на исходную работу Томпсона.
Насчёт автоматизации PIN, вот решение для SafeNet токенов, может поможет и для Вашего случая. Или, хотя бы, даст направление поисков.
https://stackoverflow.com/a/46032947/4177563
Да, по обоим пунктам. Мелкое дрожание ещё худо-бедно полечилось настройкой перехода объекта в неподвижное состояние (~засыпание при отсутствии внешних воздействий, не помню сейчас, как именно это называется в ODE), а вот где вылезал NaN дебажить уже лень было.
ODE вообще довольно заброшенный движок, по ощущениям. Как-то написал с его использованием машинку, которая ездила по ландшафту, потом долго удивлялся мелко дрожащим колёсам (а я их сделал "честными" цилиндрами, а не просто вектором-сенсором) и иногда ловил проблему на резком повороте, когда вся система улетала в небеса (где-то в процессе вычислений вылезал NaN, который потом разваливал всю симуляцию). В общем, физический сыроватый в лучшие годы и околозаброшенный к текущему времени.
Ну а чиплеты это несколько кристаллов на одной подложке. Те же Intel 8809g имели вполне приличный объём HBM2 оперативы вместе с остальными кристаллами
Фактически, как я понимаю, лазер тут выполняет роль печки принтера. А не пробовали для обеспечения долговечности сначала выгравировать небольшое углубление, в которое потом ляжет тонер?
В общем-то, да. С современными технологиями управления частотой иногда выгоднее понизить немного напряжение (undervolting), чтобы процессор смог сам добавить чуть больше турбо и держать его дольше!
На самом деле, текущее состояние (остановка) можно тоже считать оптимальным в том смысле, что, если движение кольца ничего не даёт (например, предметы однородны), то мы не тратим ресурсы на лишнюю анимацию.
В принципе, да, хотя я не знаю, что будет по скорости износа.
В качестве самодельного печатного варианта попробовал сделать вот такую штуку, корпус из PLA с каналами, куда закладываются кусочки прутка 1,75мм. Пока попробовал нейлон (полиамид-12), работает неплохо, но нужно оценить долговечность. В принципе, аналогично можно заложить и фторопласт, и PEEK.
Вообще из моего опыта даже на хороших направляющих и с приличными LM8UU стол на валках получается довольно громким. В итоге взял себе для Prusa MK3s втулки скольжения Drylin RJ4JP (оригинальные, а не с Али). Теперь при печати с обдувом поток воздуха шумит громче, чем механика.
Сам по себе механизм reparse point используется отнюдь не только Data Deduplication, но и, например, для монтирования или симлинков, это есть в документации Microsoft (отдельно стоит заглянуть в перечень задекларированных тэгов).
В документации к профессиональной версии Paragon есть только одно упоминание reparse point: они предлагают свою утилиту junction, чтобы искать и читать точки монтирования. Так что, скорее всего, считать содержимое reparse point их драйвер NTFS позволит, но вот интерпретировать его он сам не пытается.
А разве это является функцией NTFS? Насколько я знаю, Data Deduplication в винде является отдельным сервисом. Разве что его реализация опирается на механизм reparse point, но без самого компонента корректно интерпретировать данные не получится.
P.S. и да, в системных жураналах событий Windows эта проблема «в полный рост».
UPD: чтобы открыть стек, двойной клик по строке в procmon
P.S. в 10-ке вроде уже не обязательно ставить Debugging Tools, но адрес сервера символов нужно указать
Замечу, что procmon всё-таки утилита полезная, ибо она может в трейсе сохранить даже стек потока и указать точно на модуль и место в нём, откуда пришла бяка. Не знаю, возможно ли это в утилите Nirsoft.
первоначальный источник мне не известен
На самом деле, проблема с реализацией регулярных выражений и бэктрэкингом есть много где. Вот тут мне встречался неплохой разбор этой проблемы, в том числе со ссылкой на исходную работу Томпсона.