Здравствуйте, Sheridan, Вы писали:

I>>В любом случае конфигурация финишного деплоймента на момент разработки неизвестна. И в конце спокйно может оказаться мешанина вида "софтина-плагины-еще-софтина-еще-плагины" имее взаимоисключающие требования.
S>Всмысле неизвестна? Как софт должен установиться и как работать уже должно быть известно ещо до первой строки кода, на проектировании. Окружение по мере разработки да, может поменяться. Наприер, используемая БД или средства мониторинга. Но чем ближе к финишу, тем всё более точно известно и окружение.

Для небольшого класса приложений это так. А для остального софта финишная конфигурация принципиально неизвестна.

S>При этом деплой пишется сразу, параллельно разработке. И этим кодом деплоя выкатывается продукт на stage сервера.

Ну вот я взял alpina + node, понакидывал туда хрен знает чего — десятка два софтин. Каким образом команды alpine или node или команды тех софтин будут в курсе про эту мою конфигурацию?

I>>Заказчик платит не за софт в дистрибутиве, а за решение конкретной его проблемы. all-in-one это хороший вариант исключить проблемы с шаред/транзитивными зависимостями.
S>Определитесь уже. То заказчик не может на свои сервера поставить для вашего продукта нужную ОС (из списка популярных и заведомо стабильных), то ему побоку на ОС и ему надо решить некую проблему. Взаимоисключающие пункты.


I>>Снова тебе программисты мешают.
S>Я чтото не так сказал? Программисты умеют находить корни проблем и исправлять их? Если да, то к чему этот разговор? Срач ради срача?

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


I>>Здесь ровно наоборот- ты по пять раз на сообщении утверждашь, что с прграммистами чтото не то.
S>Конечно чтото не то. Вас послушать так программист умеет только код в студии набирать. Чуть чтото не так и сразу у него лапки.

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

I>>Совсем необязательно, что придется. Это всего лишь риск. Сработает ли он, и во что обойдутся последствия это отдельный разговор. И слишком часто заказчик принимает решение, что ему выгоднее всего игнорировать такие риски.
S>Ты по верхам прыгаешь. Спустись на землю. Этот риск при своевременном обновлении либ воообще не возникнут.

Ты попутал причину и следствие. Обновление — это одна из стратегий управления риском, т.е. минимизация вероятности небрагоприятного результата. И у тебя это единственно возможная, единственно правильная стратегия.
Есть и другая стратегия — игнорирование. А можно сказать — "дешевле заплатить когда случится фейл". Это тоже возможные стратегии. Тебя послушать, так они все оказываются неправильными.

I>>Да, бывают такие баги, которые трудно воспроизводятся, или их фикс ломает обратную совместимость. БОлее того — приоритеты в разработке никто не отменял. А в опен-сорсе тебе никто ничего не должен.
S>Это ты к чему? Да, такие баги бывают. Но как это относится к тому что автор забил на свой проект и несколько лет его вообще не сопровождает?

В том то и дело, что никак. Берешь ты либу А, думаешь, что всё хорошо, написал тесты, запаблишил. Другая команда через полгода собирает на основе твоего солюшна свой собственный, и выясняет, что у них баг, который автор либы А никак не может пофиксить.
Им что теперь, проплатить тебе переписывание с нуля, что бы ты построил солюшн на основе другой либы?

I>>Это только с детскими багами так, когда сразу ясно где он, и как его воспроизвести. А слишком часто баг в одном месте, а причина — в противоположном, и появляется не сразу, а время от времени, через пару дней и последствия
S>То у тебя тот же баг в другом месте. То у тебя баг вообще неуловимый. Сколько у тебя обуви то?

Баг это обычно наблюдаемое поведение. Т.е. именно то, что описывается в багтрекере. Причина на этот момент неизвестна. В какой части проекта находится причина — сказать невозможно. Для этого надо идентифицировать, локализовать проблему.
Соответсвенно, нормой является именно описаный мной случай.
Например — UI содержит мусор. А причина в наполнении БД на другом ресурсе.

I>>А это норма в опен-сорсе — игнорить баги. Заходишь зарепортать в популярный репозиторий, а там булькают вещи еще с нулевых.
S>Если брать к себе в проект либу которую когдато вася пуповкин написал для себя то так и будет. И часто у вас ошибки выбора используемых либ? Как часто вы хватаете первое попавшееся а потом "ойвей, а либа то мёртвая!"?.

Ты слово "популярный" правильно понимаешь?

I>>Так я не сужу по себе.
S>Вот только не надо говорить мне что если весь мир называет белое чорным то и я обязан это делать.

Так в том то и дело — весь мир живет не по твоим правилам

I>>Снова программисты виноваты.
S>Не все, а только те, которые тупы.

Обычно ты пишешь максимально обобщая "программисты некомпетентны".

I>>У тебя похоже риск и инцидент это одно и то же.
S>Нет. Но тебе же важно набросить на вентилятор.

Собственно смотри пример про обновление — там ты снова демонстрируешь эту самую особенность и у тебя всего она единственная стратегия.
Пример
есть риск уязвимости
— обновить, затратив 100 чаоов * 30$ в час + налоги — это твой вариант, с твоих слов это единственно правильный
А есть и другие
— игнорировать — бывает и так, для маловероятных или некритических рисков это наилучшая стратегия
— не обновлять, а закрыть файрволом-фильтром, стоимость 1 час * 30$ + налоги
— не обновлять, а застраховать риски и выплатить пенальти, когда сработает уязвимость, стоимость страховки/пенальти прилагается
— не обновлять, т.к. через год будет другая версия на другом движке
— передать другой команде, пусть они думают, надо им или нет
— открыть для опенсорса, пусть обновят те, кому это актуально
— обновить когда будет на это бюджет