Хотя с другой стороны можно попробовать посчитать, что доступ к менеджеру паролей изначально является двухфакторным — фактор владения БД и фактор знания мастер-пароля от этой БД, но не уверен, верна ли такая интерпретация
Использование TOTP внутри менеджера паролей вырождает двухфакторную аутентификацию до однофакторной (доступ к этому самому менеджеру становится единственным фактором)
remote write по умолчанию выключен (а у флага, который его включает, второй раз написано, что он НЕ предназначен для сбора метрик с приложений, что он вообще неэффективен и должен использоваться с осторожностью)
В документации прометеуса я вижу только remote write, который даже не gRPC, и в описании remote write прямым текстом написано, что он НЕ предназначен для сбора метрик с приложений. Или вы считаете, что разработчики прометеуса дурачки и пишут чушь в своей собственной документации?
Если таймвеб в своих виртуалках специально настраивает не-статику по умолчанию, то откуда мы можем быть уверены, что вручную настроенная статика не сломается через какое-то время из-за изменений на стороне таймвеба?
То, что этот пункт является третьим по списку (в английском оригинале) и не предлагается по умолчанию в Installation guide, вы тактично проигнорировали
Ну вот и надо было переводить, а не побуквенно переписывать оригинал https://dictionary.cambridge.org/ru/словарь/англо-русский/dramatic
Ну блин, а я зашёл в пост в надежде почитать, каким чудом вин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, вы тактично проигнорировали