Comments 71
...мне видится очень серьёзной проблемой сам тот факт, что кто-то имеет
возможность приказать разработчикам, что им делать, игнорируя мнение
разработчиков, и этой возможностью пользуется.
Что сказать, с подключением :) Бывает ещё хуже - когда приходит человек и говорит "как делать" и "в какой последовательности". Таких приходящих людей называют техлидами и РМами.
Хуже, когда приходят коммерсы и пытаются рулить техническими аспектами
Насколько я понял, в данном случае никто не пытался диктовать разработчику, что делать - просто поменяли приоритет задач. Мы, разумеется, не знаем, что там происходило "в течение двух лет", но один этот случай не выглядит как достаточный повод для разрыва отношений.
Как компания может "разорвать отношения с сотрудником", который по его же собственным словам перестал быть сотрудником уже два года назад и теперь занимается этим проектом в качестве волонтера?
Я поэтому и не написал "увольнение" или нечто подобное. Человек волонтёрил, возможно получал какие-то деньги (а может и нет). Два года терпел, а сейчас перестал - как ещё назвать произошедшее?
Или если человек что-то по своей воле делает для компании без оформления трудового договора, на него не должны распространяться процессы этой компании?
Бывает ещё хуже - когда приходит человек и говорит "как делать" и "в какой последовательности". Таких приходящих людей называют техлидами и РМами.
если техлид или пм технарь и знает что делает то это не хуже а лучше, а вот если он манагер то проще действительно "покинуть здание"..
Это была лёгкая ирония в сторону разработчиков, которые не привыкли к костлявому менеджерскому плечу. Да и "не-технарь", в общем-то, тоже может вполне объективно оценивать приоритет задач.
и "не-технарь", в общем-то, тоже может вполне объективно оценивать приоритет задач
расскажите это тиньку и альфе у которых НЕ технари добились того что в банковском приложении появились нафиг не нужные там "сториз" разработка которых велась в ущерб времени которое можно было бы потратить на исправление багов или появление полезного функционала, расскажите это сберу у которого в мобильном приложении чёрт ногу сломит.. я не спорю, бывают хорошие НЕтехнари в роли ПМ и тимлидов, но это зверь крайне редкий и почти вымерший (покрайней мере в разработке софта для потребителей, в разработке сурового софта который обычному пользователю неизвестен, который живёт где-то в недрах гудящих серверов и из интерфейса имеет только cli ситуация конечно получше, но опять же не везде)..
тож хейчу сторис, но грустная правда в том, что банки уже давно не банки, а сборщики биг-дата для впаривания всего сразу: поэтому Сбер стал озоном, билайном и пикпоинтом одновременно - чтобы всё про нас знать, а сторис нужны для впаривания того, что они думают, нам нужно
Это вам не нужные сториз. Мне не нужные сториз.
А кому-то очень для чего-то нужные. Зачем рассуждать о смысле строительства моста через реку с точки зрения рыбы.
Владельцев бизнеса устраивает же происходящее? Значит все правильно.
Ещё нужно уточнить, что в таких корпорациях принятие решений строится не от "хочу", а от метрик, над которыми работают штаты аналитиков
И, если что-то не нужно, чем-то не пользуются или нет business value - это выпиливают
О, метрики!
В 1961 году у нас в Вычислительном центре АН СССР проводились расчеты наиболее экономичных путей доставки стройматериалов строительным объектам в Москве. Математики рассуждали просто: вот имеются заявки строительных организаций, которые должны быть удовлетворены. Этот критерий нам казался совершенно очевидным. Ведь цель управления —обеспечить строительные организации стройматериалами.
Но выполнить заявки можно разными способами; и среди них надо выбрать наиболее экономичный. А для этого достаточно — и это тоже нам казалось вполне очевидным, — чтобы путь, проходимый каждым самосвалом, везущим груз, был самым коротким. Так рассуждали математики; и на основе этих рассуждений была составлена задача оптимизации. Она получилась громоздкой, но нетрудной; и мы предвкушали быстрое и эффективное внедрение наших методов расчета.
Для эксперимента нам выделили автобазу, в которой было 80 самосвалов. Каждую пятницу к нам в Вычислительный центр привозилась кипа заявок на неделю вперед; в воскресенье ЭВМ для каждого самосвала печатала документ. В нем было все: и что и откуда брать, и куда везти, и каким маршрутом следовать! Казалось, мы сделали все правильно. Но в жизни многое бывает гораздо сложнее, чем на бумаге, и основные трудности оказались все впереди.
Прошло три месяца. Автобаза подвела квартальные итоги и увидела, что попала в глубочайший прорыв. План был не просто не выполнен — он был сорван; показатели работы были столь плохи, что оказалась под угрозой выплата зарплаты рабочим, и руководители автобазы потребовали прекращения эксперимента и возвращения к старым методам работы.
Так что же, спрашивается, мы оптимизировали? Что в таких условиях стоят все наши математические методы?
Несколько позднее, чем это следовало бы, мы вместе с руководством автобазы начали анализировать структуру показателей автобазы и обсуждать причины, почему математики сумели за такой короткий промежуток времени развалить ее работу.
Прежде всего выяснилось, что задачу, подобную той, какую мы сформулировали, раньше никто из должностных лиц автобазы не решал; просто без ЭВМ ее нельзя было решить за два дня! Раньше сами шоферы выбирали маршруты и получали премию за сокращение холостого пробега и экономию бензина. Далее, оказалось, что работа автобазы оценивается целым набором различных параметров. Основным для нее было количество тонна-километров, а потом шли второстепенные: экономия бензина, холостой пробег и многое другое. Не было только главного среди этих показателей — степени удовлетворения потребностей строительных организаций, то есть того, ради чего существует сама автобаза.
Вот и получилось, что, несмотря на то, что все заявки оказались выполненными, что количество тонн, которые перевезла автобаза, было гораздо больше того, которое она перевозила раньше, километров она не доездила, и не доездила много — так много, что основной план не был выполнен! А как он мог быть выполнен, если каждому шоферу был точно задан маршрут и нельзя варьировать холостым пробегом и экономией бензина!
Наша попытка «выяснить отношения» была отягощена традициями и взаимным непониманием. Если строго следовать требованиям базы, то ЭВМ легко дала бы оптимальное решение, но оно было бы абсурдным. Согласно ему автомашина должна была бы взять стройматериал, выехать на окружную дорогу, крутиться целый день вокруг Москвы, а к концу рабочего дня свалить этот груз где-нибудь поближе к автобазе и вернуться в гараж. В этом случае и тонно-километров будет много, и холостой пробег будет минимальным, и план будет выполнен — чего еще желать! И потребовалось время, большие усилия обеих сторон и активность вышестоящих органов, которым пришлось менять систему показателей, чтобы избежать случившихся нелепостей и наконец сдвинуть дело с мертвой точки.
Это вам не нужные сториз. Мне не нужные сториз.
А кому-то очень для чего-то нужные.
на всё есть объективный и субъективный взгляд. субъективно я считаю что сториз в банковском приложении это глупо и неудобно, а секретарша субъективно считает что это самый удобный способ узнавать новости. объективно же это для всех НЕ информативно и НЕ удобно, а главное позволяет банкам в случае чего давать заднюю говоря "ну это же просто сторис а не официальный пресс релиз".
А мне нравятся истории. Висят себе, глаза особо не мозолят. Тыкнул, посмотрел - красивенько
Да, если именно тыкнул и посмотрел, а не когда ты запускаешь апп для того чтобы совершить какое-то действие (читать как оплатить что-то), а тебе вместо нужного тебе вот прям сейчас выползает куча лишнего дерьма, которое тебе совсем не нужно.
Причем повторюсь, это дерьмо выползает на передний план, сторисы автоматически разворачиваются на весь экран, а не висят себе где-то в шапке по которой нужно тыкать чтобы посмотреть.
Отчего же? Пользуясь Тиньком, ни единого раза не было, чтобы что-то само выскочило. Я, конечно, утверждать не буду, может AdGuard исправляет ситуацию, но факт остаётся фактом. А блок с исторьками занимает места чуть меньше ширины большого пальца и обзору не мешает.
Ну, да ладно. Кому-то мешает, кому-то не мешает, чего спорить?!)
Тыкнул, посмотрел
согласился отдать биометрию в ЕБС.
Поймал себя на том, что стал часто открывать сторис в тиньке, потому что там статистика трат за прошлый месяц + ссылки на их раздел Город. Я раньше и Город хейтил, когда он появился, но тоже осознал, что все эти кэшбеки меня туда знатно завлекли. Что со мной стало… как легко я попался на эту удочку и даже не заметил.
Зачем было нужно затевать всю эту историю, фактически разорвав отношения со мной на ровном месте, я, честно говоря, не совсем понимаю.
Я полагаю, это секрет Полишинеля: баг был в экспериментальном модуле, обрабатывающем HTTP/3-запросы.
Наиболее вероятная версия, что этот модуль уже продали какому-нибудь заказчику под видом готового решения, а потом заказчик возмутился, почему это найденная DoS-уязвимость в этом решении не получает CVE. Ну и, соответственно, менеджмент предпочёл поссориться с разработчиками, нежели с клиентом, вероятно, не ожидая такой вот реакции.
А может, всё куда проще, и менеджмент просто в курсе, что в 2024 году протокол http/3 используется людьми независимо от того, насколько "экспериментальной" объявлена его поддержка?
Никто не мешает пользоваться веб-серверами, где поддержка http/3 не объявлена экспериментальной, у них даже порты другие (:
Это на здоровье, пусть используют, но вот только CVE на экспериментальную ветку кода им никто заводить не обещал. И это обалдеть можно, писать CVE на эксперименты.
Ну, то что заводить CVE не обещали - это понятно, но в чём проблема-то с заведённым, блин?
И вообще, от экспериментальных фич лично я ожидаю следующего:
изменения форматов настроек, API и прочего без обратной совместимости и предупреждения в патчах;
отсутствия документации;
глупых багов вида "УМеняКривыеРукиException".
А вот умалчивание проблем с безопасностью в мой личный список ожиданий от экспериментальных фич как-то не входило...
Продолжаем разбираться в подробностях: указанная "уязвимость" заключалась в некорректном обращении по указателю, которое приводило к ошибке сегментации.
Это вот натурально ровно тот род ошибок, который и ожидается от экспериментальной фичи, когда в первую очередь прописывается и тестируется happy path, а обработка исключительных ситуаций оставляется "на потом".
Писать на каждую такую ошибку CVE — означает превратить разработку в итальянскую забастовку.
Случился выстрел в ногу указателями!
Иначе говоря, это уязвимость, позволяющая сломать сам сервер (и привести к DoS, например), но не позволяющая сломать что-то ещё через сервер, если я правильно понимаю суть?
Не согласен. Если кто-то считает, что эту ошибку нужно было бы поставить на учет = предать гласности, тогда это responsible (ответственно) так и поступить. Потому что мне из комментария кажется, что "CVE" в какой-то мере идолизируется. Напоминает холивар о номерах версий Firefox, а которой я был на стороне мелкив чисел (:
Если пройтись по описаниям, вики:
When investigating a vulnerability or potential vulnerability it helps to acquire a CVE number early on. [...] The benefit of early CVE candidacy is that all future correspondence can refer to the CVE number.
Изначальная проблема была с коммуникацией о возникших проблемах, см. статью 1999 г.
Assignment Rules > What Is a Vulnerability? и далее расписывают критерии настоящего CVE и того, что они ожидают в базах. Ну и после этого можно вообще не спорить :)
7.1.1 If a product owner considers an issue to be a vulnerability in its product, then the issue MUST be considered a vulnerability, regardless of whether other parties (e.g., other vendors whose products share the affected code) agree.
Not all vulnerabilities receive a CVE ID. CVE IDs are meant to help two or more parties communicate about a vulnerability.
Ну а это относится к, как я понимаю, публичной эксперементальной ветке:
7.4.7 CNAs SHOULD NOT assign CVE IDs to vulnerabilities in products that are not publicly available or licensable.
7.4.8 CNAs SHOULD NOT consider factors other than those listed in these rules (e.g., whether the vulnerability affects end-of-life products) when deciding whether to assign a CVE ID. If they do, and the issue gets escalated to the CNA’s parent CNA, then the parent CNA SHOULD assign a CVE ID.
Писать на каждую такую ошибку CVE
Оптимизируйте время написания и выставления номера. Поставьте на поток как и деплой.
указанная "уязвимость" заключалась в некорректном обращении по указателю, которое приводило к ошибке сегментации.
DoS - самое место среди CVE. Единственное в чем я могу понять - экспериментальность ветки. Но я согласен с документом - с этим к product owner. С другой стороны, пункт про доступность клиентам гласит, что можно внесение эскалировать выше (если кому-то захочется).
Надеюсь, расставил все точки над i. В целом, мысли@INSTEповторяют в комментарии ниже процитированные пассажи.
Единственное в чем я могу понять - экспериментальность ветки. Но я согласен с документом - с этим к product owner.
Ну. Это Дунин. Какие тогда ещё вопросы? :-)
С другой стороны, пункт про доступность клиентам гласит, что
Есть общепринятая практика разработки опенсорса, например - этот код тоже доступен клиентам. Но никто не назначает уязвимости в коде, который еще в HEAD, и не становился никаким релизом - сегодня он есть, завтра его нет. С экспериментальными то же самое.
Не досмотрел до конца, но вами описываемая практика похожа на Linux ядро: #comment_26509502
Просто Attentionwhore. Господин Дунин показал себя в омерзительном свете, поставив свою неосязаемую свободу (которая здесь по сути никаким боком - его не бекдор заставляли вмержить, а тег для релиза всего-лишь поставить) выше качества продукта и безопасности пользователей.
Если во всей цепочке разработки (в том числе и у менеджмента) хоть у кого-то есть ощущение, что нужно завести CVE и сделать security-релиз, то это должно быть сделано БЕЗУСЛОВНО.
Наоборот, это бы еще раз показало, что разработчики заботятся о пользователях даже СВЫШЕ меры и именно в самой нужной области, а не в "присрем-ка мы сторис в наше приложение".
Ну и F5 как владельцы продукта отвечают за его качество деньгами и репутацией, а Максим как волонтер - ничем. Потому вопросы PR и информирования пользователей о проблемах чисто на их совести.
Слово "омерзительный" всё же too much. Всё что вы пишете, справедливо в нормальной ситуации, когда есть компания, есть коллектив разработчиков, который в ней работает, все работают заодно. В данной ситуации были явные трения, возможно продиктованные by design ситуацией, когда один из главных людей в проекте - волонтер, фактически не имеющий к компании уже никакого отношения, но судя по всему продолжающий выполнять очень важные функции. Неизвестно, какие были договоренности - Максим пишет, что договоренности были о полном невмешательстве.
По поводу CVE - по мне стоило сделать исключение, я не понимаю, если честно, почему в обсуждении разработчики решили не делать релиз. По-моему вообще стоило относиться к HTTP/3 иначе, чем к остальным экспериментам. С другой стороны, когда заведение CVE у части ИБ-шников превратился в вид спорта, открыть ящик Пандоры - дать возможность писать CVE ещё и на эксперимент - вот это прям шаг скользкий.
У любого волонтера есть право уйти и делать что он хочет, даже форк в котором можно будет говнокодить и делать что угодно, вообще не реагируя на уязвимости, это ок.
Однако когда ты при этом еще и поливаешь налево и направо "вмешательством и неволей" того, кто тебе показал на баг и решил тебя по сути "прикрыть", опубликовав CVE и исправления от своего имени - это мерзко.
Насчет эксперимента - пока это было в отдельной ветке - сколько угодно. Когда это есть в релизе и его можно включить - это уже стало частью корабля, и тут CVE нужен.
Сами подумайте, сколько CVE создается на всякую мелочь типа TIPC-сокетов в ядре Linux, которые вообще у большей части не вкомпилированы в ядро (и, возможно, даже помечены как EXPERIMENTAL). Однако Торвальдс (или меинтейнер подсистемы) не плачет и не делает форк всего ядра из-за того, что ему назначают CVE.
По-моему, вы перебарщиваете, он особенно никого не поливает, но в его словах безусловно есть нотки обиды. Послушайте, я не знаю, что он делал для nginx последние 2 года, но для многих core-чуваков в open source их проект - это ребенок, особенно когда они над ним работают 10+ лет, нужно делать на это скидку, менеджмент должен был это понимать и постараться договориться.
Про ядро -
@ximaeraкоторый уже каментил выше, тут подметил крайне точно один факт, и это произошло именно 14-го февраля, в тот же день: "коллективный Торвальдс", который как раз плакал, получил таки возможность управлять процессом создания CVE:
https://openssf.org/blog/2024/02/14/linux-kernel-achieves-cve-numbering-authority-status/
но для многих core-чуваков в open source их проект - это ребенок,
особенно когда они над ним работают 10+ лет, нужно делать на это скидку
Не нужно торговать детьми.
для многих core-чуваков в open source их проект - это ребенок, особенно когда они над ним работают 10+ лет, нужно делать на это скидку, менеджмент должен был это понимать
Менеджмент, который двумя годами ранее выставил их на улицу? (вопрос риторический)
Сами подумайте, сколько CVE создается на всякую мелочь типа TIPC-сокетов
в ядре Linux, которые вообще у большей части не вкомпилированы в ядро
(и, возможно, даже помечены как EXPERIMENTAL). Однако Торвальдс (или
меинтейнер подсистемы) не плачет и не делает форк всего ядра из-за того,
что ему назначают CVE.
Ой, вы очень сильно не в теме :-)
Разговоры о том, что система Mitre CVE не подходит ядру Linux, ведутся как минимум с 2017 года. Грег Кроа-Хартман (я полагаю, вы знаете, кто это такой) в 2019 году даже сделал на этот счёт публичную и весьма разгромную презентацию.
А с 13 февраля 2024 года (прямо с этой недели) у команды разработки ядра появился статус CVE Numbering Authority (CNA). Описание, как Linux kernel CNA будет работать, уже можно найти в свежем файле документации. Краткая выжимка:
CVE в отношении ядра назначаются только тогда, когда для уязвимости уже есть патч. (Это несколько, мягко говоря, противоречит исходной философии CVE, потому что получается, что если уязвимости уже три года, но по ней всё равно нет патча, то она как бы и не уязвимость всё ещё).
В принципе, CVE в отношении ядра назначаются только через согласование с самой командой ядра. Не захотят, не назначат.
Tl;dr: форк ядра Торвальдс сотоварищи, конечно, делать не стали. Вместо этого они де-факто форкнули систему CVE :-)
Что-то по вашей ссылке не видно, собственно, презентации...
Хм, у вас включен Javascript?
А, вижу. У меня на этом месте заглушка со статус кодом 451 Unavailable For Legal Reasons, только его нигде кроме вкладки network не показывают.
Slideshare в 2017 заблокировали в России. Правда, в 2020 писали, что блокировку сняли. Похоже, что это уже сами SlideShare подстраховались и на все запросы из России до сих пор отдают 451.
Омерзительный коммент со словами типа "омерзительно", начисто игнорирующий самую суть вопроса. Если на любой нестабильный код будут назначаться CVE, отрасль просто встанет.
Повторюсь:
> Есть общепринятая практика разработки опенсорса, например - этот код
тоже доступен клиентам. Но никто не назначает уязвимости в коде, который
еще в HEAD, и не становился никаким релизом - сегодня он есть, завтра
его нет. С экспериментальными то же самое.
[МД] Не уверен, что у меня есть, что вот прям говорить про проект, он в целом не то чтобы очень нов.:)).
Да ладно, Макс! Зачитаешь еще раз "с выражением" release notes, ну и как addendum - манифест форка. Отличный доклад. Можно еще Linus Torvalds поцитировать в той части которая про NVIDIA
В твиттере под твитом Максиму ему вполне обоснованно указали на один большой нюанс - наличие буквенного сочетания "nginx", что вызывет определенные проблемы с возможным использованием форка в крупных компаниях.
Какая лицензия на это интервью?
Спасибо.
[МД] Сейчас я работаю один,
Напомнило
Причина выглядит надуманной - один спорный эпизод, который он везде приводит.
Вот ещё бы избавились от этого меркуриала и перевели бы разработку на привычные бОльшему количеству людей рельсы -- пулл-реквесты в каком-нибудь гитхабе, а не через мейллисты...
Зачем, если:
1) git объективно хуже,
2) для проектов такого уровня необходим порог входа, а не пулл-реквесты от кого попало?
1) Можно даже и hg оставить, можно и на битбакете том же пр принимать
2) Порог входа во что? В то, как там хитро оформить патч, отправить его куда-то в какой-то мейллист и потом трекать его состояние в почте? Или же всё же порог входа в разработку на C и четкое понимание как оно там внутри работает? Я может быть буду голословным, но я считаю что огромное количество людей сами реализуют то что им нужно, сохранят у себя патч и будут собирать с этим патчем, чем засылать его куда-то в мейллисты. Это касается не именно nginx, а в целом проектов которые таким образом разрабатываются.
Один большой вопрос на который надо будет ответить, это "а на какие деньги будет дальше развиваться freenginx?". Ну тоесть по пятно что какие-то деньги будут сейчас приходить с пожертвованиями, какие-то с поддержки.. но объём финансирования, как мне кажется в любом случае будет меньше, чем может позволить себе F5.
А Дунин последние два года что-то получал от F5?
Настаивать не буду, но опыт подсказывает, что мало кто может поддерживать проект такого масштаба на чистом альтруизме питаясь только подножным кормом.. а пожертвования никогда не были стабильным источником заработка, если только не иметь ввиду пожертвования от заинтересованных организаций.. но они сейчас скорее пойдут в F5
>Поэтому я создал отдельный проект, в котором позиция разработчиков гарантировано будет определяющей
Слова "позиция гарантированно будет определяющей", выстроенные в ряд, дают точно такое же доминирование чьего-то мнения над другим. Право слово, это не чудовищно сложный и передовой раздел наук, чтобы кто-то кому-то что-то диктовал. Кто не хотел идти на компромисс в этой ситуации, тот не прав, вот только взгляд "изнутри" в этой ситуации недоступен.
Самый интересный и логичный вопрос не был задан: почему не присоединиться к команде Angie? Зачем распылять силы? Лучше, когда все пилят один проект. Распыление усилий — одна из проблем open source. Тысячи форков только потому создаются, что отдельные разработчики не довольны какими-то мелочами. В результате все проекты страдают из-за недостаточной поддержки. Самые успешные open source — это те, которые поддерживаются большим сообществом. Один в поле не воин.
Могу предположить что Максим хочет развивать свободный продукт, а не импортозамещать его, чем собственно angie и занимается.
Не правда, насколько я понял, у Angie есть два продукта: собственно, свободный и открытый для всех Angie и выполняющий требования законодательства РФ для импортозамещения Angie Pro, который создаётся на основе открытого и распространяемого для всех по лицензии BSD основного проекта. Поэтому, не вижу реальных препонов, чтобы пойти в их команду, тем более, что и она состоит из бывших разработчиков Nginx.
И вот поэтому хотелось бы узнать ответ именно на этот вопрос.
freenginx: комментарии от Макса Дунина