Как стать автором
Обновить
282
0
Валентин Бартенев @VBart

Руководитель разработки ООО «Веб-Сервер»

Отправить сообщение

Потому, что это ближе по концепции к LTS. Т.е. каждый mainline релиз является стабильным, просто некоторые из них получают продленный на год срок поддержки и исправления критических ошибок.

А зачем для этого open-source делать?

И если у кого-то ещё остаются какие-то сомнения по поводу стабильности и позиционирования mainline ветки, то отдельно обращу внимание на то, как появляется очередная stable ветка: раз в год, обычно весной, текущая mainline ветка превращается в очередную stable ветку, при этом не имеет никакого значения, что какие-то функции и модули там уже почти год, а какие-то были добавлены за месяц до того. И ничего другого не происходит, никакой стабилизации кода, никаких дополнительных тестов - это просто ежегодное чисто формальное мероприятие от которого код не становится каким-то магическим образом более стабилен, чем был до того.

И "экспериментальность" отдельных модулей и функций - тут тоже совершенно ортогональная история. От переименования mainline ветки в очередную stable - "экспериментальные" модули и функции не перестают быть экспериментальными. Так, например, perl-модуль является экспериментальным с момента своего появления (в версии 0.3.21, выпущенной ещё в 2006 году) и по сей день. Т.е. этот "экспериментальный" модуль входит во все stable ветки за последние 18 лет.

Давайте заменим экспериментальный на нестабильный, что изменится? Вероятно ничего.

Как вы справедливо заметили ниже: нестабильный код не добавляют в стабильные релизы.

Тут у меня пожалуй вопрос лишь - зачем нестабильный модуль добавлять в стабильный релиз?

Это было бы очень странным и недальновидным решением с нашей стороны. Поэтому мы этого не делали. Может авторы nginx это сделали? Ниже попробуем разобраться.

Нестабильный - это тот код который не покрыт тестами, не поддерживает полностью rfc и имеет прочие недочеты.

Код HTTP/3 модуля достаточно неплохо покрыт тестами, а также неплохо соответствует RFC, благодаря чему даже согласно независимым тестам имеет хорошие характеристики по кросс-совместимости с другими реализациями (которые, кстати, не маркируются экспериментальными): https://interop.seemann.io/

Есть же ветка mainline для этих целей, не так ли?

Ветка mainline - это основная стабильная ветка, которую разработчик рекомендует использовать, а также на базе этой ветки выпускает коммерческую версию NGINX Plus.

Просто процитирую старшего продуктового директора nginx:

We generally recommend using the mainline branch. This is where we commit all new features, performance improvements, and enhancements. We actively test and QA the mainline branch, so it’s arguably more stable than the “stable” branch. The mainline branch is also the source of NGINX Plus builds for our commercial customers.

https://www.nginx.com/blog/nginx-1-12-1-13-released/

Да, название второй ветки не совсем точное, что может сбить с толку. Правильнее было бы назвать вторую ветку - legacy, т.к. stable в её названии прежде всего означает заморозку API, что более актуально, если у вас есть какие-то устаревшие модули, на поддержку совместимости и актуальности которых вы хотите тратить меньше сил.

Я также замечу, что разработчик, не только включил модуль HTTP/3 в ветку, которая позиционируется достаточно стабильной, но и собирает с ним пакеты, в чем не трудно убедиться, установив пакет из официального репозитория nginx. И само собой этот модуль входит в официальные стабильные сборки релизов коммерческой версии NGINX Plus.

Делаем ли мы в Angie что-то иначе? Нет. В сухом остатке, Angie от nginx отличается расширенным набором стабильной и востребованной функциональности, которую давно уже спрашивают и ждут от самого nginx.

Любопытно чем сейчас отличается freenginx от nginx. А отличается он только отсутствием релиза с исправлениями критических багов в HTTP/3. В чем не трудно убедиться сравнив репозитории на текущий момент:

image

Где, кто и кому тут свинью подложил? Просто мы, как и F5, не считаем, что пользователи HTTP/3 должны дожидаться очередного релиза, чтобы закрыть критические ошибки. И с учетом всего изложенного выше - есть веские основания так считать.

Отдельно отмечу, что оба бага, которые были расценены как критические, поскольку позволяют сделать DoS атаку на сервер - обнаружены благодаря тем самым пользователям HTTP/3, которые с ними столкнулись в продакшене и завели тикеты:

https://trac.nginx.org/nginx/ticket/2585
https://trac.nginx.org/nginx/ticket/2586

Цитирую: its on production machine and happened several times

Ага, спасибо им, что сообщили, но наплевать на них, пусть ждут следующего очередного релиза, ведь сами виноваты, что включили в конфигурационном файле экспериментальный модуль, который поставляется в официальной стабильной сборке сервера - так что ли?

  1. Мы не просто взяли у nginx, а мы его в том числе разрабатывали. Один из активных разработчиков HTTP/3 в nginx - работает у нас. Поэтому мы также добавили поддержку HTTP/3 клиента в сторону бэкенда и попробовали даже предложить эти патчи в nginx: https://mailman.nginx.org/pipermail/nginx-devel/2023-December/THMZAQ36SN5BICJSCLX6FLEUI45FHR4H.html - и в том числе отчасти из-за этого у нас оказалось на одну уязвимость меньше, наш код отличается.

  2. "Экспериментальный" - это не более, чем способ снять с себя ответственность. Надо заметить, довольно плохой способ. Пользователи же хотят видеть нормальную, полноценную поддержку современных протоколов, а не вот эти отмазки. Что им с этим делать? Эксперименты ставить? Переходить на конкурентов, где поддержка HTTP/3 ни чуть не лучше, но просто не содержит слова "экспериментальный"? Наша позиция заключается в том, что современный веб-сервер заслуживает иметь полноценную поддержку современных протоколов.

  3. Проработав в nginx одиннадцать лет и будучи, среди прочего, разработчиком аж 3-х "экспериментальных" модулей/механизмов: SPDY, HTTP/2, thread pools - я догадываюсь, что во многом "экспериментальность" HTTP/3 обусловлена негативным отношением одного человека к самому протоколу и тем, что он лично не принимал активного участия в разработке и ревью данного кода. И этот человек вовсе даже не Игорь Сысоев, написавший большую часть кода и заложивший основную архитектуру сервера.

Факт от этого не меняется, что заметная часть коллектива ушла делать Angie.

для многих core-чуваков в open source их проект - это ребенок, особенно когда они над ним работают 10+ лет, нужно делать на это скидку, менеджмент должен был это понимать

Менеджмент, который двумя годами ранее выставил их на улицу? (вопрос риторический)

Замечу также, что мы уже выпускали релиз с усилением безопасности на неделю раньше, чем это изменение попало в выпуск nginx. Именно потому, что мы придерживаемся более строгой политики в этом отношении.

CVE может запросить кто угодно, даже совершенно постороннее лицо. Реакцию вызвал факт выпуска внеочередного security-релиза с исправлением, о чем рассказано, как в последующих письмах в рассылку, так и недавнем интервью хабру. И, как можно заметить, форк freenginx уже отличается от nginx тем, что не содержит данного релиза.

Мы в Angie такую позицию не разделяем, не делим код на "экспериментальный" и "не экспериментальный" в этом отношении. Пользователи уже используют HTTP/3 на своих серверах и имеют право, как узнавать об уязвимостях как можно раньше, так и получать исправленную сборку.

Но что стоит собирать его еще и под несколько древних ОС - мне не очень понятно

Вы так пишете, будто nginx продолжает собираться под bionic. Но этот репозиторий давно объявлен устаревшим, последняя версия пакета nginx под bionic в данной репе датирована маем прошлого года - это уже достаточно старая 1.25.0 с известными уязвимостями.

То же самое касается большинства других репозиториев по ссылке, они просто лежат в качестве архива, как дистрибутивы, когда-то давно поддерживаемые. Но ставить из них какие-то пакеты - это, мягко говоря, плохая идея с точки зрения безопасности.

Angie скоро тоже будет автоматически получать сертификаты. Поддержка ACME уже на финальной стадии разработки.

Речь шла о сертификации и для этого уже разработчики дистрибутива проводят свои тесты и выдают сертификат совместимости.

А так, разумеется, у нас развернута огромная инфраструктура по сборке и тестированию для 13 различных дистрибутивов и 28 версий, 2-х архитектурах. Каждый коммит инициирует запуск нескольких десятков виртуалок, где происходит множество циклов сборок в различных конфигурациях и прогон функциональных тестов, в том числе с санитайзерами и статический анализ.

Поэтому разработчики библиотеки китайской криптографии рекомендуют Angie ;)
https://www.tongsuo.net/eco/

Большая часть вопросов должна отпасть, если учесть, что Angie разрабатывает та же команда, что до этого 10 лет разрабатывала nginx.

64 бита. Пойдет считать по второму кругу, с нуля.

Спокойно работаешь, занимаешься своим делом, никаких законов не нарушаешь.


... между тем помогаешь сфабриковать дело против Игоря Сысоева (просто погуглите).

"usable" не означает, что это правильно и удобно. Всё-таки писать на С++ в стиле С - довольно неблагодарное занятие, а если не в стиле С, то это означает сильно отличаться от кода стандартных библиотек Python, что также сомнительный выбор для задачи расширения возможностей Python (как и любой необоснованный зоопарк языков в проекте).

Исключение тут составляют библиотеки, которые изначально были написаны на другом языке, а далее уже был сделан биндинг для Python.

Вообще-то Numpy написан с использованием С, а не на С++. Большинство подобных библиотек написано на С, что логично, т.к. сам Python тоже написан на С.

А кто тогда будет разрабатывать? =)

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность