Паникующим людям нужен психотерапевт, и они ждут этих услуг от врача
А как это определяется врачом? Мне не однократно выписывали всякую гомеопатию и прочий арбидол (причем при короновирусе). На мой взгляд, я не выглядел паникующим ни разу, во всех случаях когда мне прописывали гомеопатию. Более того, спокойно менял на врача, который в итоге при простуде, просто рекомендовал пастельный режим, обильное питье и жаропонижающие при высокой температуре, и я без паники соблюдал такие рекомендации, вообще не был против.
Меня больше всего расстраивает, что приходится теперь разбиратся в лекартсвах, в рекомендациях ВОЗ по лечению конкретных болезней. Нельзя просто прийти к профессионалу, который назначит тебе анализы, сделает выводы, и выпишет рекомендованный курс лечения. Надо самому тратить время, проверять назначения, лекартсва и т.д. А ведь и своей работы полно. Грустно это. Неужели все это из-за того, что меня врачи считают паникующим, которму надо выписать гомеопатию, а на самом деле они профессионалы, и зря сразу таких меняю?
Угу, я понял. То есть корректней все таки утверждать, что хеши md5 небезопасно использовать в случае слабых и легко подбираемых паролей. Конечно, если вы не контролируете то, каким будет пароль, то лучше md5 не использовать. Это логично. В общем случае конечно лучше использовать PBKDF, scrypt, bcrypt, argon2.
Причина очень простая - например, RTX 3090 дает 9.5 GH/s на SHA-256 (и 95 GH/s на MD5, для сравнения)
Простите за глупый вопрос, но мне все же не очень понятно. Если пароль нормальный, допустим 16 символов в нижнем и верхнем регистре + цифры. Условный YmLUa8BBZDp9SvPS
Это по идее (2*26 + 10)^16 = 47672401706823533450263330816 комбинаций 95GH/s это как я понимаю 95 * 10^9 хешей в секунду = 95000000000
47672401706823533450263330816 / 95000000000 ~= 47672401706823533450 секунд ~= 1511681941489 годов подбора на указанной вами скорости. Звучит не очень впечатляюще если честно.
Я скорее всего ошибаюсь, но как я понимаю, если у вас нормальный пароль, то вполне безопасно хранить его и в md5. Возможно стоит упоминать это. Просто когда говорят "md5 небезопасный", то как будто имеется в виду, какой бы у вас пароль не был захеширован этим алгоритм, злоумышленник его узнает легко и просто.
Как я понимаю у алгоритма md5 есть уязвимости и проблемы с коллизиями. Но он разве вот прям легко взламывается? И это легко мне докажут, я полагаю? Предлагаю написать варианты паролей, md5 от которых будет равен 0a592abfeb0bd49c4179c999b7f00043 (я спрашиваю потому что не один из сервисов, предложенные в статье, не подобрали пароль на этот хеш)
Необходим какой-либо edge узел, способный принять трафик, но дальше он должен все же прийти на узел кластера (желательно на любой) и попасть на ingress-контроллер. Получаем двойное проксирование, чего можно избежать например с подобным решением как в статье
Делаете такие узлы воркерами кластера. Шедулите туда pod'ы ingress-controller'а с hostNentwork: true, и никаких двойных проксирований не будет. pod'у будет досупна как сеть внутри кластера, так и сеть хоста (то есть сеть edge узла).
Эта схема ничем принципиально не отличается от того что вы сделали. Только ingress-controller будет у вас в кластере, и деплоить вы его будете с помощью абстракций k8s. Любой pod k8s может иметь доступ в сеть хоста. На мой взгляд нет никаких причин выносить ingress-controller из куба. Вы сделали тоже самое решение что и с hostNetwork: true, только деплой реализовали сами (вместо того чтобы деплоить с помощью k8s).
В случае self hosted Kubernetes обычно используют NodePort и затем вручную устанавливают балансировщик нагрузки. Так что практически в каждом случае балансировщик нагрузки размещается перед вашим Ingress Controller, что означает наличие двойного проксирования, через которые должен пройти трафик для достижения приложений.
Вы же можете публиковать pod'ы ingress controller'а с помощью опции hostNetwork: true, получать трафик напрямую без лишних проксирований. Нет никакой необходимости иметь внешний балансировщик или вытаскивать ingress controller из кластера.
А что мешает глобально для всех агентов CI выставить переменную среды HELM_MAX_HISTORY? Или же сделать степ "helm", внутри которого эта переменная определяется, а потом вызывается обычная команда "helm"? В jenkins например это делается просто.
Ваше утверждение, что CI выполняет команды, никак не опровергает мое предложение, вы прост озвучили факт. Ну да, CI умеет выполнять команды, кто же спорит с этим?
Ну вот банальный кейс который я приводил выше. Вот сейчас я смотрю на детализацию и вижу что у меня только за трафик выходит 4000$. У меня на bare-metal вся инфра стоила столько =).
А это не статика, а именно бэкенд трафик. Статику у нас CDN отдельно раздает. Отдельно за это платим.
Кого нам уволить, чтобы окупить цену за трафик? На bare-metal нам этот трафик бесплатно обходился и никакие люди его отдельно не обслуживали. А цена только за этот трафик равна цене всей нашей инфраструктуре которая была на bare-metal.
Как бы цынично это не звучало, манажед сервисы уменьшают потребность в персонале. По сути вы перемещаете стоимость персонала в шареный сервис, частично. И "девопсы" становятся не нужны в таком количестве.
Но в моем кейсе это ведь не так. managed решение покрывает всего 1% задач. Возьмем для примера тот же куб, managed решает проблему обслуживания control-plain и обновления, но это ведь мизерная часть того, что обычно надо делать. Есть еще уйма задач связанных с кубом, которые вообще никак managed решением не покрывается. И как же "девопсы" будут не нужны, а кто node-local-dns развернет? Кто напишет gatekeeper политики на rego? Логирование, мониторинг, ingress-controller, istio, cert-manager, т.д. Кто будет это обслуживать, исправлять проблемы, дорабатывать? P.S. На самом деле мы используем managed куб, поскольку он считай бесплатный. Но это никак не избавляет от того, что нужны компетентные люди, которые будут обслуживать его.
С managed mysql мы покрываем задачи настройки отказоустойчивого кластера и бэкапов. Но на обслуживание этого, сейчас у нас уходит максимум 8 часов в месяц. Каждый managed mysql сейчас нам обойдется в лучшем случае на 1170$ дороже, таких кластеров у нас 6 (6*1170 = 7020). 7K$ чтобы покрыть 8 часов работы в месяц.
Ну то есть окей мы возьмем managed решение, и закроем какой-то мелкий пласт задач по обслуживанию, но есть же большое количество задач для "девопсов", банально даже поддерживать terreaform код для развертки всего этого в облаке. Не совсем понятно, как это избавит от надобности в у словных "девопсах" и сократит персонал. В нашем кейсе работы например меньше не стало, местами стало даже больше. Как было два девопса так и осталось.
Про серверлесс тоже непонятно, ну вот у нас есть 20-30 приложений, от 100 до 10000 rps, обычные бэкендики, что-то пишут в базу. Как серверлесс поможет сэкономить?
И далеко не во всех случая совокупная стоимость владения bare metal ниже cloud и ни о каких "кратно дороже" и речи быть не может, просто вы не умеете в FinOps.
Из практики:
Переехали в yandex cloud из hetzner. Теперь платим в 4 раза дороже (вместо 4K евро, платим 16-18K долларов)
Прерываемая виртуалка в яндекс облаке, стоит больше обычной вирталки в hetzner. Обычная виртуалка в яндекс облаке естественно еще дороже. С bare-metal даже сравнивать нет смысла.
Надежность никак не поменялась. Возможно даже в облаке сеть моргает чаще чем моргала в hetzner. Не говоря уже о других проблемах, недавно например лег DNS на ощутимое время.
Ценник в основном за инстансы с кластерами БД, managed БД стоят еще дороже, и не факт, что дадут какие-то плюшки, которые это окупят.
Как было два девопса на той же зарплате, так и осталось. Только теперь в облаке требуется тратить дополнительные ресурсы на оптимизацию затрат и экономию. И в виду сложности, для экономии в облаке нужно потратить больше ресурсов чем в hetzner.
Как научиться в FinOps чтобы платить меньше? Прерываемые/spot машины не станут чудесно дешевле, обычные инстансы тоже. На чем тогда экономить? На готовых сервисах? Ну у нас автоматизация для настройки пару типов кластеров бд и кластеров kubernetes не супер дорого вышла и вполне устраивает. Особенно учитывая, что один кластер managed БД по стоймости равен 50% зп одного девопса, а таких кластеров несколько. Да и managed решение далеко не идеальны, особенно по гибкости конфигурации. Например многие вещи в managed кубе яндекса, мы хотели бы сделать по другому (не использовать kube-proxy, вместо iptables для сервисов использовали бы ipvs, а в cilium хотели бы использовать native routing вместо тунелинга, хотели бы иметь возможность включить pod security policy и так далее и тому подобное). У меня если честно нет идей, но если вы что-то посоветуете, то я буду вам сильно благодарен. С облаками опыта имею не много.
1) Ваши утверждения мне кажутся не убедительны их бы подкрепить какими-то данными.
2) это на мой взгляд пример почему есть такое неравенство. Общество навязывает женщинам что эти задачи должны делать именно они, и это навязывается с самого детства (конечно же не специально, просто социальные конструкты, и это впечатывается довольно глубоко)
3) Это тоже крайне сомнительно, вовлеченность не зависит ни от пола, ни от того когда ты пришел в индустрию. Я например до 2015 года, чем больше работаю тем меньше хочется в свободное время что-то ковырять (максимум что-то интересное и связанное с работой). А от всего железа и домашнего сервера избавился уже после 3 лет работы в индустрии. У всех всё по разному. Конкретные примеры ничего не доказывают и не опровергают.
Дальше вести дискуссию не буду, потому что слишком много минусов хватаю.
gender gap по РФ равен 0.7 то есть женщины на 30% имеют меньше возможностей. Когда я говорил про 30% я имел в виду РФ.
> Потому что, скажем, если о западных странах, то gender gap - методологическая ошибка статистики, возникающая из-за того, что все эти исследования, ставящие целью доказать существование gender gap, сбрасывают со счетов два главных фактора - количество сверхурочных и склонность мужчин к большему риску, выражающуюся в том, что они просят больше денег на собеседованиях и annual review.
Это ваше личное мнение, или есть какое-то исследование про ошибочность подсчета gender gap?
> что все эти исследования, ставящие целью доказать существование gender gap
Вроде исследование про неравенство, и существует ли это неравенство, а не про доказательство того что существует неравенство. В принципе считать статистику чтобы доказать какое-то утверждение как-то глупо. Смотрим стат данные а уже потом делаем выводы. Я может неправильно понял суть исследований, но вроде там не ставят целью доказать существование gender gap.
> это абсолютная демагогия > Во-вторых, когда вы хотите сказать о "потраченных усилиях", лучше ничего не говорить, потому что это неизмеримая объективно величина.
Я не устраиваю демагогию, я стараюсь объективно смотреть на ситуацию. Поэтому и смотрю gender gap и другие стат данные. Где вообще в моих словах вы нашли про "давление общества и так далее".
Объективно по стат данным видно, что женщины получают худшие рабочие места и зарабатывают меньше мужчин с такими же бэкграундом и навыками. В исследованиях о "потраченных усилиях" конкретных людей ничего не сказано. Можно конечно сказать что женщины стараются меньше и тратят меньше усилий чем мужчины, поэтому на 30% имеют меньше возможностей в РФ. Но мне в это слабо верится, также как и слабо верится в идеи что одна нация умнее и лучше другой. Если есть какие-то исследования, которые объясняют такое различие какими-то другими причинами, а не неравенством полов, то укажите их, я бы почитал.
> Если бы все было действительно очевидно, понадобился бы весь этот грязный арсенал аргументации?
Проблема в том что эта дискриминация не очевидна как я понимаю. Я например был не в курсе про это, пока не посмотрел статистику ради интереса. Насчет грязного арсенала аргументации не понял, исследования ошибочны и неправильно проводятся? Данные по зарплатам неверны? - я об этом если честно вообще не в курсе.
Не понимаю почему набросились на статью и на gudvinr.
Дискриминация женщин до сих пор существует, это видно по статистике разницы зарплат между женщинами и мужчинами (и не только зарплат). Почитайте global gender gap report. Да что тут говорить женщинам буквально в этом году разрешили работать водителем метро. Или например возьмем министерства иностранных дел РФ. У нас 242 посольства, только в одном из них посол женщина.
В IT , тоже самое, хотя казалось бы разницы не должно быть, физическая сила не нужна в работе. Но женщинам в среднем с одинаковыми навыками, уровнем образования, опытом, бэкграундом что и кандидаты мужчины, нужно прикладывать гораздо больше усилий чтобы добиться такой же работы с идентичной зарплатой. Это и показывает характеристика Gender Gap из отчета который я упомянул выше.
Не понимаю аргументов в стиле: "ну у меня женщина начальник, или вот у меня женщина коллега, они же добились почему другие не могут?" Но неравенство же состоит в том, когда твоей коллеге пришлось приложить гораздо больше усилий чтобы попасть на аналогичную должность. А другим женщинам с такими же навыками как у тебя платят меньшую зарплату. Аргумент "моей коллеге платят столько же" тоже не принимается, поскольку это статистика, если у вас так, не значит что в среднем точно также. А судя по подсчетам в среднем как раз не так, в среднем женщины на 30% имеют меньше возможностей чем мужчины с аналогичными характеристиками.
По поводу "начальница женщина" кстати в РФ действительно неплохо, но это касается менеджмента среднего звена, а вот на самых высоких должностях женщин считай совсем нет.
А чем собственно это отличается от создания проекта для всех переиспользуемых CI шаблонов и подгрузкой их через include?
Тем что это совсем про другое. В jenkins и github actions вы реализуете библиотеку методов на groovy и javascript соотвественно, которые потом используйте в своих пайплайнах как обычные стандартные методы. А в gitlab по сути нет ничего кроме script.
Нечто подобное и пытался сделать автор поста в gitlab. Но поскольку gitlab не имеет никакого способа расширять и добавлять новые методы к его стандартным https://docs.gitlab.com/ee/ci/yaml/#job-keywords, поэтому так все печально и выглядит. И все на баше естественно, так как иначе придется таскать в раннеры зависимости для своего "библиотечного кода".
В Jenkins есть shared lib, где ты можешь хранить переиспользуемый код любого уровня. В Github actions есть action'ы. В Gitlab почему-то до сих пор нет ничего подобного =(.
как по мне это типичный кейс для иммутбл инфры. SCM обычно нужен, когда надо менеджить приложения со стейтом. Но в облаках и правда непонятно зачем ansible.
Запекаешь образы packer'ом, разворачиваешь их через terraform, pulimi на виртуалках. Все как с контейнерами. Приложеньки со стейтом, обычно есть как готовые сервисы в облаке, их также готовишь через pulimi/terraform.
А как это определяется врачом? Мне не однократно выписывали всякую гомеопатию и прочий арбидол (причем при короновирусе). На мой взгляд, я не выглядел паникующим ни разу, во всех случаях когда мне прописывали гомеопатию. Более того, спокойно менял на врача, который в итоге при простуде, просто рекомендовал пастельный режим, обильное питье и жаропонижающие при высокой температуре, и я без паники соблюдал такие рекомендации, вообще не был против.
Меня больше всего расстраивает, что приходится теперь разбиратся в лекартсвах, в рекомендациях ВОЗ по лечению конкретных болезней. Нельзя просто прийти к профессионалу, который назначит тебе анализы, сделает выводы, и выпишет рекомендованный курс лечения. Надо самому тратить время, проверять назначения, лекартсва и т.д. А ведь и своей работы полно. Грустно это. Неужели все это из-за того, что меня врачи считают паникующим, которму надо выписать гомеопатию, а на самом деле они профессионалы, и зря сразу таких меняю?
Угу, я понял. То есть корректней все таки утверждать, что хеши md5 небезопасно использовать в случае слабых и легко подбираемых паролей. Конечно, если вы не контролируете то, каким будет пароль, то лучше md5 не использовать. Это логично. В общем случае конечно лучше использовать PBKDF, scrypt, bcrypt, argon2.
Простите за глупый вопрос, но мне все же не очень понятно.
Если пароль нормальный, допустим 16 символов в нижнем и верхнем регистре + цифры.
Условный
YmLUa8BBZDp9SvPSЭто по идее (2*26 + 10)^16 = 47672401706823533450263330816 комбинаций
95GH/s это как я понимаю 95 * 10^9 хешей в секунду = 95000000000
47672401706823533450263330816 / 95000000000 ~= 47672401706823533450 секунд ~= 1511681941489 годов подбора на указанной вами скорости. Звучит не очень впечатляюще если честно.
Я скорее всего ошибаюсь, но как я понимаю, если у вас нормальный пароль, то вполне безопасно хранить его и в md5. Возможно стоит упоминать это. Просто когда говорят "md5 небезопасный", то как будто имеется в виду, какой бы у вас пароль не был захеширован этим алгоритм, злоумышленник его узнает легко и просто.
Как я понимаю у алгоритма md5 есть уязвимости и проблемы с коллизиями. Но он разве вот прям легко взламывается? И это легко мне докажут, я полагаю? Предлагаю написать варианты паролей, md5 от которых будет равен
0a592abfeb0bd49c4179c999b7f00043(я спрашиваю потому что не один из сервисов, предложенные в статье, не подобрали пароль на этот хеш)Делаете такие узлы воркерами кластера. Шедулите туда pod'ы ingress-controller'а с hostNentwork: true, и никаких двойных проксирований не будет. pod'у будет досупна как сеть внутри кластера, так и сеть хоста (то есть сеть edge узла).
Эта схема ничем принципиально не отличается от того что вы сделали. Только ingress-controller будет у вас в кластере, и деплоить вы его будете с помощью абстракций k8s. Любой pod k8s может иметь доступ в сеть хоста. На мой взгляд нет никаких причин выносить ingress-controller из куба. Вы сделали тоже самое решение что и с hostNetwork: true, только деплой реализовали сами (вместо того чтобы деплоить с помощью k8s).
Вы же можете публиковать pod'ы ingress controller'а с помощью опции hostNetwork: true, получать трафик напрямую без лишних проксирований. Нет никакой необходимости иметь внешний балансировщик или вытаскивать ingress controller из кластера.
А что мешает глобально для всех агентов CI выставить переменную среды HELM_MAX_HISTORY? Или же сделать степ "helm", внутри которого эта переменная определяется, а потом вызывается обычная команда "helm"? В jenkins например это делается просто.
Ваше утверждение, что CI выполняет команды, никак не опровергает мое предложение, вы прост озвучили факт. Ну да, CI умеет выполнять команды, кто же спорит с этим?
Да вроде норм, в других языках похожие вещи есть.
В ruby например примерно такое-же называется блоками:
def example
yield 101
end
example do |i|
# any code
# i будет равен 101
puts i * 10
end
example {|i| puts i * 100}
Результат:
1010
10100
P.S. не могу понять как нормально оформить код в новом редакторе хабра, сори =(
Но можно попросить использовать некий степ в пайплайне, который создает нужные переменные среды, и добавляет переменную среды
HELM_MAX_HISTORY.Если у вас один CI. Это не сложно сделать. Ну или пойти с другой стороны, и эту переменную среды устанавливать на стороне раннеров/билд-агентов.
Ну вот банальный кейс который я приводил выше.
Вот сейчас я смотрю на детализацию и вижу что у меня только за трафик выходит 4000$. У меня на bare-metal вся инфра стоила столько =).
А это не статика, а именно бэкенд трафик. Статику у нас CDN отдельно раздает. Отдельно за это платим.
@eosfor
Кого нам уволить, чтобы окупить цену за трафик? На bare-metal нам этот трафик бесплатно обходился и никакие люди его отдельно не обслуживали. А цена только за этот трафик равна цене всей нашей инфраструктуре которая была на bare-metal.
Но в моем кейсе это ведь не так. managed решение покрывает всего 1% задач. Возьмем для примера тот же куб, managed решает проблему обслуживания control-plain и обновления, но это ведь мизерная часть того, что обычно надо делать. Есть еще уйма задач связанных с кубом, которые вообще никак managed решением не покрывается. И как же "девопсы" будут не нужны, а кто node-local-dns развернет? Кто напишет gatekeeper политики на rego? Логирование, мониторинг, ingress-controller, istio, cert-manager, т.д. Кто будет это обслуживать, исправлять проблемы, дорабатывать?
P.S. На самом деле мы используем managed куб, поскольку он считай бесплатный. Но это никак не избавляет от того, что нужны компетентные люди, которые будут обслуживать его.
С managed mysql мы покрываем задачи настройки отказоустойчивого кластера и бэкапов. Но на обслуживание этого, сейчас у нас уходит максимум 8 часов в месяц. Каждый managed mysql сейчас нам обойдется в лучшем случае на 1170$ дороже, таких кластеров у нас 6 (6*1170 = 7020). 7K$ чтобы покрыть 8 часов работы в месяц.
Ну то есть окей мы возьмем managed решение, и закроем какой-то мелкий пласт задач по обслуживанию, но есть же большое количество задач для "девопсов", банально даже поддерживать terreaform код для развертки всего этого в облаке. Не совсем понятно, как это избавит от надобности в у словных "девопсах" и сократит персонал. В нашем кейсе работы например меньше не стало, местами стало даже больше. Как было два девопса так и осталось.
Про серверлесс тоже непонятно, ну вот у нас есть 20-30 приложений, от 100 до 10000 rps, обычные бэкендики, что-то пишут в базу. Как серверлесс поможет сэкономить?
Из практики:
Переехали в yandex cloud из hetzner. Теперь платим в 4 раза дороже (вместо 4K евро, платим 16-18K долларов)
Прерываемая виртуалка в яндекс облаке, стоит больше обычной вирталки в hetzner. Обычная виртуалка в яндекс облаке естественно еще дороже. С bare-metal даже сравнивать нет смысла.
Надежность никак не поменялась. Возможно даже в облаке сеть моргает чаще чем моргала в hetzner. Не говоря уже о других проблемах, недавно например лег DNS на ощутимое время.
Ценник в основном за инстансы с кластерами БД, managed БД стоят еще дороже, и не факт, что дадут какие-то плюшки, которые это окупят.
Как было два девопса на той же зарплате, так и осталось. Только теперь в облаке требуется тратить дополнительные ресурсы на оптимизацию затрат и экономию. И в виду сложности, для экономии в облаке нужно потратить больше ресурсов чем в hetzner.
Как научиться в FinOps чтобы платить меньше? Прерываемые/spot машины не станут чудесно дешевле, обычные инстансы тоже. На чем тогда экономить? На готовых сервисах? Ну у нас автоматизация для настройки пару типов кластеров бд и кластеров kubernetes не супер дорого вышла и вполне устраивает. Особенно учитывая, что один кластер managed БД по стоймости равен 50% зп одного девопса, а таких кластеров несколько. Да и managed решение далеко не идеальны, особенно по гибкости конфигурации. Например многие вещи в managed кубе яндекса, мы хотели бы сделать по другому (не использовать kube-proxy, вместо iptables для сервисов использовали бы ipvs, а в cilium хотели бы использовать native routing вместо тунелинга, хотели бы иметь возможность включить pod security policy и так далее и тому подобное). У меня если честно нет идей, но если вы что-то посоветуете, то я буду вам сильно благодарен. С облаками опыта имею не много.
P.S. Переезд был обусловлен 152-ФЗ
1) Ваши утверждения мне кажутся не убедительны их бы подкрепить какими-то данными.
2) это на мой взгляд пример почему есть такое неравенство. Общество навязывает женщинам что эти задачи должны делать именно они, и это навязывается с самого детства (конечно же не специально, просто социальные конструкты, и это впечатывается довольно глубоко)
3) Это тоже крайне сомнительно, вовлеченность не зависит ни от пола, ни от того когда ты пришел в индустрию. Я например до 2015 года, чем больше работаю тем меньше хочется в свободное время что-то ковырять (максимум что-то интересное и связанное с работой). А от всего железа и домашнего сервера избавился уже после 3 лет работы в индустрии. У всех всё по разному. Конкретные примеры ничего не доказывают и не опровергают.
Дальше вести дискуссию не буду, потому что слишком много минусов хватаю.
Понятно что сама корреляция ничего не доказывает, но как минимум меня заставляет задуматься.
gender gap по РФ равен 0.7 то есть женщины на 30% имеют меньше возможностей. Когда я говорил про 30% я имел в виду РФ.
> Потому что, скажем, если о западных странах, то gender gap - методологическая ошибка статистики, возникающая из-за того, что все эти исследования, ставящие целью доказать существование gender gap, сбрасывают со счетов два главных фактора - количество сверхурочных и склонность мужчин к большему риску, выражающуюся в том, что они просят больше денег на собеседованиях и annual review.
Это ваше личное мнение, или есть какое-то исследование про ошибочность подсчета gender gap?
> что все эти исследования, ставящие целью доказать существование gender gap
Вроде исследование про неравенство, и существует ли это неравенство, а не про доказательство того что существует неравенство. В принципе считать статистику чтобы доказать какое-то утверждение как-то глупо. Смотрим стат данные а уже потом делаем выводы. Я может неправильно понял суть исследований, но вроде там не ставят целью доказать существование gender gap.
> это абсолютная демагогия
> Во-вторых, когда вы хотите сказать о "потраченных усилиях", лучше ничего не говорить, потому что это неизмеримая объективно величина.
Я не устраиваю демагогию, я стараюсь объективно смотреть на ситуацию. Поэтому и смотрю gender gap и другие стат данные. Где вообще в моих словах вы нашли про "давление общества и так далее".
Объективно по стат данным видно, что женщины получают худшие рабочие места и зарабатывают меньше мужчин с такими же бэкграундом и навыками. В исследованиях о "потраченных усилиях" конкретных людей ничего не сказано.
Можно конечно сказать что женщины стараются меньше и тратят меньше усилий чем мужчины, поэтому на 30% имеют меньше возможностей в РФ. Но мне в это слабо верится, также как и слабо верится в идеи что одна нация умнее и лучше другой. Если есть какие-то исследования, которые объясняют такое различие какими-то другими причинами, а не неравенством полов, то укажите их, я бы почитал.
> Если бы все было действительно очевидно, понадобился бы весь этот грязный арсенал аргументации?
Проблема в том что эта дискриминация не очевидна как я понимаю. Я например был не в курсе про это, пока не посмотрел статистику ради интереса.
Насчет грязного арсенала аргументации не понял, исследования ошибочны и неправильно проводятся? Данные по зарплатам неверны? - я об этом если честно вообще не в курсе.
Не понимаю почему набросились на статью и на gudvinr.
Дискриминация женщин до сих пор существует, это видно по статистике разницы зарплат между женщинами и мужчинами (и не только зарплат). Почитайте global gender gap report. Да что тут говорить женщинам буквально в этом году разрешили работать водителем метро. Или например возьмем министерства иностранных дел РФ. У нас 242 посольства, только в одном из них посол женщина.
В IT , тоже самое, хотя казалось бы разницы не должно быть, физическая сила не нужна в работе. Но женщинам в среднем с одинаковыми навыками, уровнем образования, опытом, бэкграундом что и кандидаты мужчины, нужно прикладывать гораздо больше усилий чтобы добиться такой же работы с идентичной зарплатой. Это и показывает характеристика Gender Gap из отчета который я упомянул выше.
Не понимаю аргументов в стиле: "ну у меня женщина начальник, или вот у меня женщина коллега, они же добились почему другие не могут?"
Но неравенство же состоит в том, когда твоей коллеге пришлось приложить гораздо больше усилий чтобы попасть на аналогичную должность. А другим женщинам с такими же навыками как у тебя платят меньшую зарплату. Аргумент "моей коллеге платят столько же" тоже не принимается, поскольку это статистика, если у вас так, не значит что в среднем точно также. А судя по подсчетам в среднем как раз не так, в среднем женщины на 30% имеют меньше возможностей чем мужчины с аналогичными характеристиками.
По поводу "начальница женщина" кстати в РФ действительно неплохо, но это касается менеджмента среднего звена, а вот на самых высоких должностях женщин считай совсем нет.
Тем что это совсем про другое. В jenkins и github actions вы реализуете библиотеку методов на groovy и javascript соотвественно, которые потом используйте в своих пайплайнах как обычные стандартные методы. А в gitlab по сути нет ничего кроме
script.Нечто подобное и пытался сделать автор поста в gitlab. Но поскольку gitlab не имеет никакого способа расширять и добавлять новые методы к его стандартным https://docs.gitlab.com/ee/ci/yaml/#job-keywords, поэтому так все печально и выглядит. И все на баше естественно, так как иначе придется таскать в раннеры зависимости для своего "библиотечного кода".
В Jenkins есть shared lib, где ты можешь хранить переиспользуемый код любого уровня. В Github actions есть action'ы. В Gitlab почему-то до сих пор нет ничего подобного =(.
в среде puppet, используют bolt для таких вещей.
как по мне это типичный кейс для иммутбл инфры. SCM обычно нужен, когда надо менеджить приложения со стейтом. Но в облаках и правда непонятно зачем ansible.
Запекаешь образы packer'ом, разворачиваешь их через terraform, pulimi на виртуалках. Все как с контейнерами. Приложеньки со стейтом, обычно есть как готовые сервисы в облаке, их также готовишь через pulimi/terraform.
werf так делает https://ru.werf.io/documentation/v1.2/advanced/building_images_with_stapel/assembly_instructions.html#ansible