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