VoidVolker

Да, возможно. Вот только скорость удаления данных с диска зависит от скорости работы накопителя. Для полного удаления данных необходимо полностью обнулить каждую ячейку памяти в накопителе. По умолчанию ОС удаляет только запись о файле в ФС, а вот содержимое файла остаётся и будет перезаписано когда-нибудь в будущем, когда дойдёт очередь до данного сектора/ячейки памяти. Кроме того, для более надёжного удаления данных с HDD используется многократная запись, чтобы не осталось даже остаточного заряда, который теоретически можно считать. Есть даже специальные приложения для удаления данных с дисков с многократной записью в каждую ячейку. Аналогично и для шифрования — надо сначала считать данные с диска, зашифровать их, записать на диск и только потом удалить оригинальные данные.

Единственное, что может очень быстро удалить данные с диска — устройства для физического уничтожения дисков. Для HDD используются мощные электромагниты. С SSD несколько сложнее, т.к. там используется флеш-память: тут уже требуется физическое разрушение микросхем — измельчить в специальном шредере очень мелко, разогреть больше сотни-полутора градусов, сжечь электромагнитным импульсом (из разряда экзотики конечно же - ибо куда сложнее и есть риск сжечь чего лишнего). Так же существуют специальные SSD со встроенным механизмом уничтожения.

RTFM:
https://www.boost.org/doc/libs/latest/doc/html/boo...

Supported Platforms

• Win32 using Visual C++ 11.0 (Visual Studio 2012) or later
  
• Win64 using Visual C++ 11.0 (Visual Studio 2012) or later
  

The following platforms may also work:

• Win32 using MinGW.
  
• Win32 using Cygwin. (__USE_W32_SOCKETS must be defined.)
  

Как именно это работает и как именно распределяются ресурсы — вам следует смотреть в исходниках конкретного гипервизора. В гипервизорах с закрытым исходным кодом вы сможете узнать только сделав запрос разработчикам и если они захотят/им разрешат сверху — они расскажут.
Да, на своём сервер тоже вполне возможно использовать: заходите в настройки вашего гипервизора и точно так же указываете нужное вам значение.

Вполне обычное явление, когда несколько идентичных устройств выходят из строя примерно в одно и то же время. В вашем случае вам только один путь: проверять работоспособность каждого устройства отдельно. Тут может быть проблема в чём угодно. В первую очередь проверьте память, SSD (т.к. ноунейм - там может быть что угодно внутри), БП, процессор, видеокарту и далее остальные устройства (при наличии). Так же рекомендую на всякий случай проверить напряжение в розетке. А в идеале — получить данные из мониторинга по скачкам напряжения, если такой мониторинг есть.

LibreOffice

Для виртуализации — только х86 и винда/линукс. На арме виртуализация х86 стоит примерно 90% производительности (UTM/qemu). Касательно арм-винды под маком: лично не тестил, но пишут, что в целом нормально работает. Виндовый транслятор инструкций х86 в arm в целом работает. Но в таком случае всегда есть достаточно высокий шанс поймать какую-нибудь ошибку в каком-нибудь приложении.
Докер с арм контейнерами на маке работает отлично — 10-20 штук легко переваривает. Вот х86 да, медленно работают, но работают.

Доброе пожаловать в реальный мир, где очень часто все кладут болт на полноценное соблюдение стандартов! Если правильно помню — по стандарту USB максимальное число устройств 256, но в большинстве случаев на практике это количество значительно меньше и сильно зависит от USB контроллёров, материнской платы и ОС. Ну и конечно же используйте хабы с дополнительным питанием. Так что пробуйте другие контроллёры, материнские платы, драйверы и ОС. Часто на материнских платах есть несколько контроллёров — попробуйте подключать хабы в разные. Если не заработает — ну, значит не повезло с материнской платой и надо использовать другую. В сети даже есть исследования на эту тему, вроде даже на хабре была статья.

UPD: Судя по топику про рутокен — ограничения могут быть так же и в драйверах КриптоПро. Если сами токены определяются в системе нормально, то имеет смысл попробовать виртуализацию с пробросом USB концентраторов в виртуалку и уже в виртуалке работать с токенами. Для настольной виртуализации топ - VirtualBox.

Проще всего добавить какой-нибудь конвертер между ними на JS или питоне, который будет проксировать все запросы и конвертировать даты во всех API ответах/запросах. И не надо никуда погружаться ни в свой проект ни в редмайн.
Например: https://github.com/chimurai/http-proxy-middleware/...

const proxy = createProxyMiddleware({
    target: 'http://redmine-url-or-ip',
    changeOrigin: true, // for vhosted sites

    selfHandleResponse: true, // res.end() will be called internally by responseInterceptor()

    on: {
        proxyRes: responseInterceptor(async (responseBuffer, proxyRes, req, res) => {
            // detect json responses
            if (proxyRes.headers['content-type'] === 'application/json') {
                let data = JSON.parse(responseBuffer.toString('utf8'));

                // manipulate JSON data here
                if (Object.hasOwnProperty.call(data, 'created_on')) {
                    data['created_on'] = new Date(data['created_on']).toISOString()
                }

                // return manipulated JSON
                return JSON.stringify(data);
            }

            // return other content-types as-is
            return responseBuffer;
        }),
    },
});

Решать проблему выключения стенда. Если у вас там проблемы с электроснабжением — решить их. Можно подключить стенд к ИБП. Можно перенести стенд в другое помещение/здание/корпус. Если сетевые проблемы — решать их. Кинуть новый линк или даже два, заменить устаревшее оборудование.
Писать какие-то собственные скрипты для автоматизации деплоя на стенд вам всё равно придётся. Какой гит сервис вы используете? А CI/CD? В Гитлабе, например, всё достаточно легко настраивается и скриптуется. В вашем случае алгоритм стандартный и почти ничем не отличается для деплоя на сервер: при появлении PR в тестовой ветке залить прошивку на стенд. Структура тоже вполне стандартная:

• Гит сервер
  
• CI/CD сервер
  
• Стенд для прошивки и тестирования
  

Вообще, стенд можно настроить на автоматический забор прошивки с файлового сервера: т.е. CI/CD сервер публикует прошивку, а стенд её самостоятельно забирает. Сам же стенд в идеале настроить на автоматическую заливку прошивки и проверку устройства. Т.е., воткнул устройство в стенд — загорается, условно, жёлтая ламчока или надпись "устройство проверяется". Если устройство работает — зелёная лапочка, если нет — красная.

Увы, но вероятность восстановления данных с SSD диска очень низкая. Особенно, когда сдох контроллёр — если диск с полноценным шифрованием, то без ключей ничего не сделать. Каждое включение диска эту вероятность уменьшает ещё меньше. У нормальных топовых производителей шансы выше на восстановление — там обычно если что не так, диск переходит в режим только для чтения, а вот у обычной китайщины гораздо меньше шансов.

а во-вторых трехпиновый, так что обороты будут на максимуме в любом случае

Ну, во-первых, тут есть как минимум два варианта: поставить стандартный резистор Noctua, которых с каждым вентилятором по две штуки разных номиналов поставляется. А второй вариант — можно запитать вентилятор снаружи через реобас и настроить нужные обороты. Лучше запитать с родного разъёма внутри БП — современные БП обычно сами управляет скоростью вращение кулера в зависимости от температуры.

Если всё равно хотите поменять БП — берите FSP. Например FSP Vita 550. Они достаточно надёжные и там обычно кулеры полноразмерные и с разъёмом — меняются без проблем на ноктуа. Вот в компактных моделях разъёма может не быть. Кулеры там обычно достаточно тихие, но в целом обычные китайские. Так что лучше сразу ставить ноктуа.

Просто поставьте Zabbix и настройте шаблоны для ваших ПЛК и других железок. Он как раз и создан для мониторинга.

Конечно, OpenVPN например: https://openvpn.net/connect-docs/command-line-func...
Или WireGuard: https://www.wireguard.com/quickstart/#command-line...

В чём угодно. От кривых драйверов звуковой карты или работающего на фоне антивируса до спящего кота на выхлопе горячего воздуха из системного блока.