Могу сам ответить) Дело в том, что как таковых обновлений безопасности не существует отдельно от пакетов. В приведенной мной ссылке yum ищет пакеты, у которых в ченджлоге указаны исправления безопасности. Соответственно, он просто подтянет новую версию пакета с этими исправлениями. Так что если в пакет или зависимости закрался баг, то вы его получите.
У меня пока нет опыта работы с CentOS Stream за пределами домашних проектов, но я бы не стал так сильно переживать в организациях, где парк машин и количество сервисов довольно маленькие. Мне кажется, многие излишне драматизируют, дистрибутив все еще сравнительно стабильный, а основные баги будет собирать Fedora, как и прежде.
Наверно, если ставить только обновления безопасности, то политика rolling release не будет так сказываться на стабильности.
Безусловно, с голым Линуксом тоже всё это есть, но там и продукты более зрелые, собравшие все очевидные грабли, и айтишники на уровне рефлексов впитали некоторые вещи
На голом линуксе абсолютно те же ошибки, без всяких кубернетисов наружу торчит кучу сервисов. Дело не в сырости кубера, а в подготовке специалистов, от сервиса общие правила подхода к безопасности не зависят. В данном случае банально доступ к вебморде не был ограничен на уровне сети, точно так же могла в интернет смотреть админка любого другого сервиса.
Да ещё и делать это в рамках Open Source-проекта, инвестиции в который больше
Не совсем. На долгой дистанции open source может обойтись дешевле проприетарного решения. Выкатывание проекта уровня enterprise в открытый доступ - это возможность привлечь "инвестиции" в виде труда сотрудников других компаний. Чем популярнее продукт, тем больше в него вкладываются другие.
А вы не боитесь, что у вас доступы утекут? Начиная с банальной недоработки со стороны Гугла, заканчивая утечкой самой ссылки? Декомпилировать .Net приложение и посмотреть откуда тянутся данные не составит труда, не говоря уже о распространении скрипта в чистом виде
То есть исправлять явные ошибки, лежащие в основе статьи, которые к тому же вводят читателя в заблуждение, за вас должны другие? Да, предлагаю переписать, на вашем месте я бы сделал именно так
В результате оптимизации код стал не только быстрее отрабатывать, но и быть проще для восприятия, а значит более поддерживаемым и расширяемым
Не согласен. Неоптимизированный код легче читается, т.к. логически более структурирован, сразу видно что за чем идет. Для понимания оптимизированного варианта нужно уже разбираться в связи между двумя циклами. В варианте, где функции вынесены, добавляется еще избыточность кода. Теперь для понимания связи между двумя циклами я должен просмотреть отдельно функции и при внесении изменений редактировать их отдельно друг от друга.
Но почему-то оставили в основной части статьи, что у вас «оптимизация» превращает сложность из квадратической в линейную. Наверно потому что иначе неоткуда взяться 13%? Вам уже несколько раз доходчиво объяснили почему сложность не изменилась. Еще большие вопросы к вашей методике измерения, по статье выглядит так, будто вы сделали по одному прогону, в таком случае совсем неудивительно получить неправильные результаты. Причем тут уже доказали ошибочность измерений
Есть подходы, которые уже являются де-факто стандартом и их игнорирование, как минимум, плохой тон, как максимум, указывает на некомпетентность. Шифрование паролей как раз относится к таким подходам, и для «крупнейшего EdTech в школьном образовании» это позор, за такое надо как раз ругать, а не хвалить. Давайте тогда также похвалим ребят из госуслуг, например, что они прикрыли дыру, которую по недосмотру сами же оставили, ведь ошибку признали и исправили. Такой подход деструктивен, т.к. понижает стоимость ошибки.
а) фундаментальной научной базы относительно воздействия ЭМИ на живые организмы, накопленной за полтора столетия
Ну так если все хорошо, зачем новые исследования? А их ведь проводят снова и снова. Условия меняются, надо перепроверять. Лет 50 назад никто еще не рассчитывал, что мы будем так плотно облучаться микроволнами, поэтому такие сценарии никто не рассматривал.
б) подопытной группы из нескольких миллиардов человек, постоянно подвергающихся ЭМИ-воздействию в течении десятилетий
ЭМИ много разных, длина волны очень сильно влияет на характер воздействия, микроволновое ЭМИ плотно вошло в нашу жизнь лет 30 назад, а сидеть с ним «в обнимку» мы начали вообще недавно.
В свете того, что негативные последствия от радиации выявили в течении нескольких лет после открытия явления радиации, ваш контраргумент так себе :)
Я что-то не смог найти данных когда была открыта лучевая болезнь, но вообще тема опасности активно начала обсуждаться только после 1945, а уже после ЧАЭС появились дополнительные данные по влиянию нелетальных доз радиации на человека.
Так в инструкции все действия происходят в консоли. Какая разница в чьей консоли команды писать?
Могу сам ответить) Дело в том, что как таковых обновлений безопасности не существует отдельно от пакетов. В приведенной мной ссылке yum ищет пакеты, у которых в ченджлоге указаны исправления безопасности. Соответственно, он просто подтянет новую версию пакета с этими исправлениями. Так что если в пакет или зависимости закрался баг, то вы его получите.
У меня пока нет опыта работы с CentOS Stream за пределами домашних проектов, но я бы не стал так сильно переживать в организациях, где парк машин и количество сервисов довольно маленькие. Мне кажется, многие излишне драматизируют, дистрибутив все еще сравнительно стабильный, а основные баги будет собирать Fedora, как и прежде.
Наверно, если ставить только обновления безопасности, то политика rolling release не будет так сказываться на стабильности.
Я думаю минусы за то, что хабр - это не место для памяток
На голом линуксе абсолютно те же ошибки, без всяких кубернетисов наружу торчит кучу сервисов. Дело не в сырости кубера, а в подготовке специалистов, от сервиса общие правила подхода к безопасности не зависят. В данном случае банально доступ к вебморде не был ограничен на уровне сети, точно так же могла в интернет смотреть админка любого другого сервиса.
Почему бы таким организациям не перейти на Centos Stream и ставить обновления безопасности этим способом?
А корпоративные клиентские устройства, работающие во внутренней сети, не проходят предварительную настройку? Речь же не про публичный сервис
Не совсем. На долгой дистанции open source может обойтись дешевле проприетарного решения. Выкатывание проекта уровня enterprise в открытый доступ - это возможность привлечь "инвестиции" в виде труда сотрудников других компаний. Чем популярнее продукт, тем больше в него вкладываются другие.
Так непонятно какую задачу решает Lets Encrypt, чтобы под это искать альтернативу
Не согласен. Неоптимизированный код легче читается, т.к. логически более структурирован, сразу видно что за чем идет. Для понимания оптимизированного варианта нужно уже разбираться в связи между двумя циклами. В варианте, где функции вынесены, добавляется еще избыточность кода. Теперь для понимания связи между двумя циклами я должен просмотреть отдельно функции и при внесении изменений редактировать их отдельно друг от друга.
А что гугл потеряет без них? Таких людей единицы и вряд ли они являются активными пользователями его продуктов
Так привязка к номеру телефона или к смартфону?
Ну так если все хорошо, зачем новые исследования? А их ведь проводят снова и снова. Условия меняются, надо перепроверять. Лет 50 назад никто еще не рассчитывал, что мы будем так плотно облучаться микроволнами, поэтому такие сценарии никто не рассматривал.
ЭМИ много разных, длина волны очень сильно влияет на характер воздействия, микроволновое ЭМИ плотно вошло в нашу жизнь лет 30 назад, а сидеть с ним «в обнимку» мы начали вообще недавно.
Я что-то не смог найти данных когда была открыта лучевая болезнь, но вообще тема опасности активно начала обсуждаться только после 1945, а уже после ЧАЭС появились дополнительные данные по влиянию нелетальных доз радиации на человека.