Нууу эээ. Не могу возразить, да в общем и не очень хотелось.
Я сам, как луддит и ретроград, вообще отношусь к докеру исключительно как к средству быстрой доставки демок, да еще где-то в параллельной мне вселенной есть всякие хостерские потребности типа «поднять одним махом миллиард одинаковых вордпрессов»- там своя богадельня, об этом ничего не знаю (но оттуда регулярно доносится мнение о том, что докер-не-готов). А в остальном - есть статическая линковка, есть LD_PRELOAD, и вообще, 640кб хватит каждому.

Все равно бюрократию нужно регулировать, иногда дело не в прямой зависимости на библиотеку, а о ее версии или зависимостях. Вон пишут люди допустим фронтенд на JS. Берут такие npm install и из одной библиотеки, допустим React, прилетело еще 200 зависимостей. Там же в коммьюнити на каждую фунцию пакет фигачат. Как провести аудит? Через время ощущение безопасности из-за наличия аудита пропадает и появляется чуство опасности от знания существующих багов. Например завтра вот нашли баг в основной библиотеке, надо обновиться. Обновились - зависимости обновились тоже в количестве 60 библиотек. В таких случая сильная бюрократия о добавлении библиотек мешает и работает плохо (знаю о реальных случаях). Надо искать компромисс.

И кстати докер в таком случае позволяет проверять качество строго того, что пойдет в production, а не какого-то сферического билда, который потом на проде будет собран чуть-чуть не так.

о каком стандарте ты говоришь? типа «используйте только этот язык, только этот завизированный набор библиотек, а теперь быстро разошлись по рабочим местам и принесите компании денег»? такое работает?

Почти так. Всегда должна быть рекомендация. ЯП, code style. Библиотеки должны быть или ваши или сторонние, но если стороние, то нужно понимать что они будут жить своей жизнью. И вы не будете знать что принесет следующая версия. Докер - способ герметично создать билд, чтобы протестировать blackbox собраный из твоего кода и чего-то неизвестного таким образом, чтобы проверить в тестах соответсвие требованиям. А потом быть уверенным что строго то же самое будет на проде. Понятное дело что можно присобачить не тот сервис как бекенд и что баг будет например проявляться при большем или меньшем количестве памяти, но это решается другими методами.

Все равно бюрократию нужно регулировать

Естественно.

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

Никакой разницы, по сути.

Обновились - зависимости обновились тоже в количестве 60 библиотек.

Ага. А еще может быть, что какой-то софт работает только с обновлениями, а какой-то - только без. И?

И сражаться с отделом разработки ради каждой библиотеки которую та или иная проектная команда хочет притащить в зависимости.

Это административная проблема.

Насчёт административной согласен, но я вижу несколько проблем:
1) нах нужна фича, которую впилили/выпилили? А как получается, что остальные без неё живут? А точно эта версия не заработает с другим кодом? А это точно не упирается в коррекцию вызова библиотеки?
2) (опционально) если выпилили, то, может, не зря?
3) если контейнер всраться как нужен, какие конкретные плюсы у контейнеризации перед виртуализацией? Ну не отсутствие в природе средств автоматизации развёртинга точно.Оверхеда там смешно сколько, сложности близко к никакой, а плюсов дохрениллион, пихай в свою прикладу хоть чорта с рогами.
Я так и не нашёл ни одной проблемы, решением которой был бы очевидно докер.
P. S. Заранее прошу прощения, если гоню пургу, нетрезв.

Выбор языка для следующего проекта - это решение уровня компании. Люди приходят и уходят, меняют проекты, а написанный ими код остается. И это компания будет решать проблему где искать экспертизу по языку X и фреймворку Y, и сколько за нее платить. И например по лицензионным и патентным искам тоже отвечает компания.

Чтобы не решать эту проблему каждый раз индивидуально у компании есть гайдлайны, внутренний стандарт на технологию. Он не обязательно должен быть точным списком. Можно например сказать: наш стандарт - centos 7 epel.

А вот для языков типа python или js лучше списки global reqirements и constraints.

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

если контейнер всраться как нужен, какие конкретные плюсы у контейнеризации перед виртуализацией?

Меньший оверхед, большая, хм, доступность (в Docker можно упаковать хоть утилиту командной строки).

Оверхеда там смешно сколько

Оверхеда там немало - даже virtio является эмулируемым PCI-устройством. А вот у контейнера оверхеда нет.

Предположим, я устанавливаю один из нескольких десятков тысяч пакетов для Debian. Он зависит от конфигурации и взаимных конфликтов. Но при этом после установки - работает.

Или не работает в той конфигурации которая нужна именно вам. Такое тоже сплошь и рядом. Темы вида «работало в версии x обновил до y» не только школота пишет. Работоспособность проверяют с базовыми зависимости и с базовыми конфигами, несколько шагов в сторону и тут начинается, здесь подправили, зато в другом месте отвалилось, это я конечно уже сгущаю краски, но бывает.

и прочим подобным бредом ленивых людей, которые не удосуживаются прочитать документацию...

Сколько приложений вы доставили под весь зоопарк линя?

ну сам же выше пишешь про React, где рекомендация означает просто «top level dependency», а дальше там полная жопа.
моё непонимание такого подхода вытекает из того, что если появилась нужда, а бизнес имеет хорошую конкуренцию, то срочное расширение стека технологий может принести контракт сейчас, а пиление велосипеда на ограниченном стеке может означать, что фичу доставить просто не успеете и просрёте полимеры.
все эти административные фашизмы и визирование библиотек полная дичь для меня. например проект на дотнете и перле. ну запилите мне на этом стеке копию ELK через неделю? очень будет смешно.

Д

Во-первых, не зря вы упоминаете docker и тесты рядом - да, именно для тестов это оптимальная технология, тут не поспоришь.

Во-вторых, глобальные библиотеки общего пользования типа openssl и boost меняют свой ABI крайне редко - и надо быть весьма странным разработчиком, чтобы словить проблемы из-за обновления этих библиотек.

В-третьих существует такая простая вещь, как LD_LIBRARY_PATH: таскайте все библиотеки вместе с приложением, в чём проблема-то? Ну да, вас засмеют скорее всего, потому-то вы и любите столь горячо docker: его кишки снаружи не видно. Но можете вспомнить пример той же Zimbra: ну таскает она фактически целый дистрибутив Linux под видом просто ПО для корпоративной работы с почтой, но ведь никто же не обвиняет разработчиков в головотяпстве. Правда, Zimbra обновляет поставляемые библиотеки вовремя, чего не скажешь о 99% разработчиков «контейнерного» ПО. Кстати, зачем эти поставщики вообще что-то там беспокоятся о беезопасности в коде своего ПО, если библиотеки, объём кода которых зачастую в разы больше и сложнее - могут содержать какие угодно уязвимости, а разработчики даже бюллетени по безопасности не читают, потому ччто не их это царское дело?