Хотя с другой стороны можно попробовать посчитать, что доступ к менеджеру паролей изначально является двухфакторным — фактор владения БД и фактор знания мастер-пароля от этой БД, но не уверен, верна ли такая интерпретация
Использование TOTP внутри менеджера паролей вырождает двухфакторную аутентификацию до однофакторной (доступ к этому самому менеджеру становится единственным фактором)
remote write по умолчанию выключен (а у флага, который его включает, второй раз написано, что он НЕ предназначен для сбора метрик с приложений, что он вообще неэффективен и должен использоваться с осторожностью)
В документации прометеуса я вижу только remote write, который даже не gRPC, и в описании remote write прямым текстом написано, что он НЕ предназначен для сбора метрик с приложений. Или вы считаете, что разработчики прометеуса дурачки и пишут чушь в своей собственной документации?
Если таймвеб в своих виртуалках специально настраивает не-статику по умолчанию, то откуда мы можем быть уверены, что вручную настроенная статика не сломается через какое-то время из-за изменений на стороне таймвеба?
То, что этот пункт является третьим по списку (в английском оригинале) и не предлагается по умолчанию в Installation guide, вы тактично проигнорировали
Когда ядро само по себе является загрузчиком (EFI boot stub, UKI), то очень даже место
Плюс ещё бывают, например, шифрование, файловые системы, не поддерживаемые загрузчиком (некоторые даже ext4 не умеют), и прочие странные конфигурации, поэтому ArchWiki предлагает монтировать uefi-раздел не /boot/efi, а прямо в /boot
Ну блин, а я зашёл в пост в надежде почитать, каким чудом вин11 запускают на Pentium III
Хотя с другой стороны можно попробовать посчитать, что доступ к менеджеру паролей изначально является двухфакторным — фактор владения БД и фактор знания мастер-пароля от этой БД, но не уверен, верна ли такая интерпретация
Использование TOTP внутри менеджера паролей вырождает двухфакторную аутентификацию до однофакторной (доступ к этому самому менеджеру становится единственным фактором)
import thisИ это сломает совместимость со всеми программами, которые ожидают немедленное выполнение импортированного кода
А как только случаются какие-нибудь проблемы с аппаратным ускорением, фпс падает на дно
remote write по умолчанию выключен (а у флага, который его включает, второй раз написано, что он НЕ предназначен для сбора метрик с приложений, что он вообще неэффективен и должен использоваться с осторожностью)
А о каком ещё rpc вы говорите, я всё ещё не знаю
В документации прометеуса я вижу только remote write, который даже не gRPC, и в описании remote write прямым текстом написано, что он НЕ предназначен для сбора метрик с приложений. Или вы считаете, что разработчики прометеуса дурачки и пишут чушь в своей собственной документации?
Но ведь документация прометеуса прямым текстом нескольких местах говорит, что он использует pull-модель, а push реализуется через сторонние костыли
А называть официальную библиотеку от разработчиков прометеуса «странными приседаниями» само по себе очень странно
Если таймвеб в своих виртуалках специально настраивает не-статику по умолчанию, то откуда мы можем быть уверены, что вручную настроенная статика не сломается через какое-то время из-за изменений на стороне таймвеба?
Не учите плохому, в systemd для изменения системных юнитов есть drop-in файлы
У таймвеба пинг из Qupra DC2 до Qupra DC2 40мс ¯\_(ツ)_/¯
У другого хостинга в том же Qupra DC2 такой фигни нет, только у таймвеба
OVH отправляет данные клиентов в облако
Всё на месте, это у вас что-то глюкнуло
То, что Qupra падал в январе из-за той же самой системы охлаждения, вспоминать тактично не будем)
Как минимум логи-то почитайте, это вполне может виснуть какой-нибудь ваш собственный процесс
Другой хостинг пишет, что других вариантов в общем-то и нет, с РФ готовы сотрудничать не только лишь все
На 3 часа больше, чем трачу я, работая без докера
То, что этот пункт является третьим по списку (в английском оригинале) и не предлагается по умолчанию в Installation guide, вы тактично проигнорировали
Когда ядро само по себе является загрузчиком (EFI boot stub, UKI), то очень даже место
Плюс ещё бывают, например, шифрование, файловые системы, не поддерживаемые загрузчиком (некоторые даже ext4 не умеют), и прочие странные конфигурации, поэтому ArchWiki предлагает монтировать uefi-раздел не /boot/efi, а прямо в /boot