VR
сарказм это сложно 😄
а, оке :(
Size: a a a
2021 February 26
A🍊
на айфонах там вообще куча ботов с пиратским контентом не доступна
Вроде же с порнухой, а не с пиратским))
VR
Вроде же с порнухой, а не с пиратским))
книги/музыку
in
С другой стороны сейчас как раз эра всяких океанских островов, которые могут задекларировать что они никогда и не по какому поводу не будут блокировать трафик.
Пусть будет бухта как для пиратов и нарушителей, так и тех кто просто хочет уменьшить риски от различных аттак.
В том числе пусть будет git который никого и никогда не будет банить..
Пусть будет бухта как для пиратов и нарушителей, так и тех кто просто хочет уменьшить риски от различных аттак.
В том числе пусть будет git который никого и никогда не будет банить..
так какая им выгода с этого? хомячки им платить будут за сервис?
БС
хм, я смотрю тут специалисты по порнухе и пиратам.. Друг интересуется, кроме флибусты что еще пиратят в телеге? И что за порнуха? Есть же порнохабы? Зачем в телеге это иметь?
A🍊
С другой стороны сейчас как раз эра всяких океанских островов, которые могут задекларировать что они никогда и не по какому поводу не будут блокировать трафик.
Пусть будет бухта как для пиратов и нарушителей, так и тех кто просто хочет уменьшить риски от различных аттак.
В том числе пусть будет git который никого и никогда не будет банить..
Пусть будет бухта как для пиратов и нарушителей, так и тех кто просто хочет уменьшить риски от различных аттак.
В том числе пусть будет git который никого и никогда не будет банить..
Они не будут, а магистралы будут, делов-то
БС
если там будут хоститься банки или какой то монстр, то магистралы уже не будут банить.. Но это конечно мячты..
SB
Эх, вот бы была возможность децентрализовать git репозитории...
VR
хм, я смотрю тут специалисты по порнухе и пиратам.. Друг интересуется, кроме флибусты что еще пиратят в телеге? И что за порнуха? Есть же порнохабы? Зачем в телеге это иметь?
БС
благодарствую.. Но через бота в телеге искать что то на рутрекере, не очень удобно.
VR
благодарствую.. Но через бота в телеге искать что то на рутрекере, не очень удобно.
если в гостях и vpn там не настроен
VR
по блокировкам, у моего знакомого забанили @DeepNudeChat_Bot на айфонах, при этом сам бот порно не шлет, а только "пририсовывает" всякое на фотках
VR
при том забанили, когда про его бот написали в амер новостях, типа русские хакеры сделают с вами все что угодно, а вы и не узнаете
VB
при том забанили, когда про его бот написали в амер новостях, типа русские хакеры сделают с вами все что угодно, а вы и не узнаете
VR
VR
Переслано от P
Для пояснения , три дня общался с этим корреспондентом , доказывая что наш бот делает такие фото , что за реальное фото их не выдать , но они там на своей волне .
SA
У тебя должно быть ровно одно место для декларации конфига, его типа и дефолтного значения. И это место может быть ямл файл, а не код. Получается что ямл это аналог dsl и является частью кода.
devops'у не надо лезть в код искать какой то параметр, его дефолтное значение и прочее. Ему достаточно открыть один конфиг файл. В этом же yamlе могут быть и комментарии.
Если нужно сделать параметр, для которого нет универсального значения, и которое нужно обязательно определять, то можешь его поменить строкой определенной.
И во время сборки (всмысле кнопки в CI, а не docker build) проверять (ну да, надо чекер написать из пяти строк) конфиг. И если девосп забудет (или ему забудут сказать) определить этот параметр, то об этом девопс узнает до момента начала деплоя.
А еще, иногда, конфиги меняют QAщики. Напримрер через конфиг можно включать/выключать какие то фичи. И для QAщики поменять конфиг, а не код, это меньший стресс и вероятность ошибок меньше (но тут надо не забыть объяснить QAщику разницу между табами и пробелами и выключить автоматическую конверсию).
А если учесть, что благодаря куберу и не только ему, конфиги так и так лежать в yamlе, то вообще нет ни одного резона использовать переменные окружения.
Хранить секреты в волте и передавать их только через переменные окружения (чтобы враг их не узнал), это прям секрет полишинеля. Получить доступ к переменным окружения не сложнее, чем к файлу..
devops'у не надо лезть в код искать какой то параметр, его дефолтное значение и прочее. Ему достаточно открыть один конфиг файл. В этом же yamlе могут быть и комментарии.
Если нужно сделать параметр, для которого нет универсального значения, и которое нужно обязательно определять, то можешь его поменить строкой определенной.
И во время сборки (всмысле кнопки в CI, а не docker build) проверять (ну да, надо чекер написать из пяти строк) конфиг. И если девосп забудет (или ему забудут сказать) определить этот параметр, то об этом девопс узнает до момента начала деплоя.
А еще, иногда, конфиги меняют QAщики. Напримрер через конфиг можно включать/выключать какие то фичи. И для QAщики поменять конфиг, а не код, это меньший стресс и вероятность ошибок меньше (но тут надо не забыть объяснить QAщику разницу между табами и пробелами и выключить автоматическую конверсию).
А если учесть, что благодаря куберу и не только ему, конфиги так и так лежать в yamlе, то вообще нет ни одного резона использовать переменные окружения.
Хранить секреты в волте и передавать их только через переменные окружения (чтобы враг их не узнал), это прям секрет полишинеля. Получить доступ к переменным окружения не сложнее, чем к файлу..
Антон, я тебя не понимаю:
> У тебя должно быть ровно одно место для декларации конфига, его типа и дефолтного значения. И это место может быть ямл файл, а не код. Получается что ямл это аналог dsl и является частью кода.
Каким образом в ямле ты можешь определить значение по умолчанию. А переопределять ты где и как будешь? Это текстовый файл же, а не нечто исполняемое.
А про ровно одно место никто и не спорит.
> devops'у не надо лезть в код искать какой то параметр, его дефолтное значение и прочее. Ему достаточно открыть один конфиг файл. В этом же yamlе могут быть и комментарии.
Ровно это же я могу сказать про settings.py 🤷
> Если нужно сделать параметр, для которого нет универсального значения, и которое нужно обязательно определять, то можешь его поменить строкой определенной.
И как это сделать в ямле? В текстовом файле.
> И во время сборки (всмысле кнопки в CI, а не docker build) проверять (ну да, надо чекер написать из пяти строк) конфиг. И если девосп забудет (или ему забудут сказать) определить этот параметр, то об этом девопс узнает до момента начала деплоя.
Ну да, вместо
> А еще, иногда, конфиги меняют QAщики. Напримрер через конфиг можно включать/выключать какие то фичи. И для QAщики поменять конфиг, а не код, это меньший стресс и вероятность ошибок меньше (но тут надо не забыть объяснить QAщику разницу между табами и пробелами и выключить автоматическую конверсию).
Чем это лучше, чем передать переменную окружения-то? Универсальное средство же
> Хранить секреты в волте и передавать их только через переменные окружения (чтобы враг их не узнал), это прям секрет полишинеля. Получить доступ к переменным окружения не сложнее, чем к файлу.
Эти секреты нужны, чтобы разделить приложение, общую конфигурацию (открытую) и секретные значения, к которым доступ контроллируется. Если ты из этих секретов через шаблон генерируешь конфиг и кладешь его куда-то, то по безопасности это да, примерно то же самое, что и передавать через переменные окружения.
Мой поинт в том, что не нужно смешивать разные консерны. Хранение секретов != хранению конфигурации. Вполне допустимо хранить конфиги, куда секреты прокидываются извне. Вполне допустимо хранить в том же репозитории секреты, которые менеджатся через тот же sops.
> У тебя должно быть ровно одно место для декларации конфига, его типа и дефолтного значения. И это место может быть ямл файл, а не код. Получается что ямл это аналог dsl и является частью кода.
Каким образом в ямле ты можешь определить значение по умолчанию. А переопределять ты где и как будешь? Это текстовый файл же, а не нечто исполняемое.
А про ровно одно место никто и не спорит.
> devops'у не надо лезть в код искать какой то параметр, его дефолтное значение и прочее. Ему достаточно открыть один конфиг файл. В этом же yamlе могут быть и комментарии.
Ровно это же я могу сказать про settings.py 🤷
> Если нужно сделать параметр, для которого нет универсального значения, и которое нужно обязательно определять, то можешь его поменить строкой определенной.
И как это сделать в ямле? В текстовом файле.
> И во время сборки (всмысле кнопки в CI, а не docker build) проверять (ну да, надо чекер написать из пяти строк) конфиг. И если девосп забудет (или ему забудут сказать) определить этот параметр, то об этом девопс узнает до момента начала деплоя.
Ну да, вместо
os.getenv("ENV", default_value) надо просто использовать os.environ["ENV"]> А еще, иногда, конфиги меняют QAщики. Напримрер через конфиг можно включать/выключать какие то фичи. И для QAщики поменять конфиг, а не код, это меньший стресс и вероятность ошибок меньше (но тут надо не забыть объяснить QAщику разницу между табами и пробелами и выключить автоматическую конверсию).
Чем это лучше, чем передать переменную окружения-то? Универсальное средство же
> Хранить секреты в волте и передавать их только через переменные окружения (чтобы враг их не узнал), это прям секрет полишинеля. Получить доступ к переменным окружения не сложнее, чем к файлу.
Эти секреты нужны, чтобы разделить приложение, общую конфигурацию (открытую) и секретные значения, к которым доступ контроллируется. Если ты из этих секретов через шаблон генерируешь конфиг и кладешь его куда-то, то по безопасности это да, примерно то же самое, что и передавать через переменные окружения.
Мой поинт в том, что не нужно смешивать разные консерны. Хранение секретов != хранению конфигурации. Вполне допустимо хранить конфиги, куда секреты прокидываются извне. Вполне допустимо хранить в том же репозитории секреты, которые менеджатся через тот же sops.