LK>Даже если разработчики либы нашли и исправили серьёзный баг — и поэтому обновили библиотеку?
LK>Хороший программист — он всё-таки смотрит по сторонам и держит в уме зависимости.
Хороший — да. И тут полный форум таких разработчиков. В отличие от Шеридана, они не собираются фанатично «актуализировать библиотеки» только «патамушта гавно мамонта».
Здравствуйте, Sheridan, Вы писали:
S>Если софт — коробка, то это просто обязан быть пакет. (deb, rpm итд), который должен ставиться штатными средствами.
Ты не объяснил с какой луны возникнут задачи по обновлению версий в результате слежки за дистрибутивами. Да еще начал с девопсов которые должны следить за ними, а закончил примером коробки которая в идеале ни от чего не зависит и работой целой группы саппорта/внедрению ПО, но в их работе, — хватает иных нюансов.
Под основаниями на обновления, я, разумеется, спрашивал, что конкретно должно произойти для того, что бы надо было обновить зависимость, а не должных обязанностей.
Единственно разумное, что от тебя услышал — что это нужно планировать (аля сначала думать, потом делать). С этим согласен.
Здравствуйте, Явь-Истъ, Вы писали:
ЯИ>Как ты собираешься без докера устанавливать и обновлять сотни сервисов в каком-нибудь микросервисном проекте?
Первое что в голову пришло: опакетить с выставлением зависимостей, поставлять репозиторий с пакетами, деплоить оттуда.
Здравствуйте, Mystic Artifact, Вы писали:
S>>Если софт — коробка, то это просто обязан быть пакет. (deb, rpm итд), который должен ставиться штатными средствами. MA> Ты не объяснил с какой луны возникнут задачи по обновлению версий в результате слежки за дистрибутивами.
Используемая в проекте библиотека Х в свежем (можно даже LTS) рекомендуемом дистрибутиве обновилась. -> Таск на выяснение что изменилось и зацепило ли прект. Если да -> таск на фикс. Первый таск тоже может девапс выполнить.
Здравствуйте, Sheridan, Вы писали:
S>Надо ложить на актуализацию используемых в проекте либ -> глупость. Либы в проекта должны быть свежими. Их актуализацию надо планировать. Даже в проектах, ушедших с разработки в саппорт.
Разработка коммерческая отличается от разработки "сферической в вакууме" тем, что всё стоит денег. И когда дешевле поддерживать старую версию продукта, а не актуализировать либы — так и делают.
Здравствуйте, Mystic Artifact, Вы писали:
MA>Здравствуйте, Sheridan, Вы писали:
S>>Фанатизм плох всегда. В абсолют возводить не надо. Надо следить хотя бы за LTS дистрибутивами и актуализировать либы в соответствии с ними. MA> Разработчикам делать нехер как следить за всякими дистрибутивами. Нормальному приложению должно быть пофигу на либы в дистрибутиве, настолько, насколько это возможно. Именно так достигается переносимость между пачками дистрибутивов да еще в одном бинарнике.
С одной стороны да, с другой все же если делается Продукт, неплохо бы и последить за хотя бы самыми популярными, вроде Ubuntu, Debian, Fedora, CentOS/RHEL. Обычно, если под ними работает, то и под другими дистрами пользователь сможет более-менее легко запустить. Косвенно, переносимость вообще улучшает качество кода.
Потому что иначе возникают ситуации, когда разработанный софт (новая версия) работает почти исключительно на машине разработчика и более нигде, после чего он свое окружение пакует в докере и распространяет. Ну в принципе да, решение проблемы, но в итоге можно прийти к тому, что каждая программа будет в своем снапшоте сидеть.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>На любое обращение к ИТ отделу ему отвечают, что "корпоративные полиси запрещают что-либо менять на машине".
Вот это, знаете ли, придурь в духе "у нас бухгалтерский отдел не умеет с этим работать". Так бухгалтерия служит предприятию, или предприятие бухгалтерии?
Здравствуйте, chaotic-kotik, Вы писали:
CK>>>а разве докер мешает тебе это делать? S>>Мне — нет. CK>ok, будем считать что ты слился
Ты сам то диалог понял?
Мне ничего не мешает актуализировать либы. А вот многие местные найдут 1000 и 1 причину этого не делать.
Здравствуйте, sambl74, Вы писали:
S>Разработка коммерческая отличается от разработки "сферической в вакууме" тем, что всё стоит денег. И когда дешевле поддерживать старую версию продукта, а не актуализировать либы — так и делают.
тссс, автор похоже не знает, что у популярных зависимостей обычно бывает больше одной актуальной версии
Здравствуйте, Sheridan, Вы писали:
S>>>Если софт — коробка, то это просто обязан быть пакет. (deb, rpm итд), который должен ставиться штатными средствами. MA>> Ты не объяснил с какой луны возникнут задачи по обновлению версий в результате слежки за дистрибутивами. S>Используемая в проекте библиотека Х в свежем (можно даже LTS) рекомендуемом дистрибутиве обновилась. -> Таск на выяснение что изменилось и зацепило ли прект. Если да -> таск на фикс. Первый таск тоже может девапс выполнить.
Это применимо, но очень ограниченно.
Основная проблема в том, что выяснение всех деталей занимает слишком много времени, а оценка "зацепило ли" требует слишком глубоких знаний о всем проекте сразу (т.е. один девопс с этим не справится). И что самое главное — все эти телодвижения никак не помогут гарантировать что-либо клиенту. Там где учавствуют внешние не контроллируемые тобою зависимости — вообще от тебя ничего не зависит. Если контракт будет нарушен, то приложение упадет уже на существующих инсталляциях у реальных пользователей. А ты, как компания/разработчик/девопс наоборот, крайне заинтересован не делать лишней работы, не строить новые билды без необходимости.
В итоге — нужно получить ответ на вопрос — работает ли ПО, как ожидается, на конфигурации по вкусу. Но, как ты понимаешь, ответ на этот вопрос можно получить и без этих ковыряний в носу.
Если посмотреть на зависимости по жирнее, то можно офигеть просто лог читать. Ну, например взять llvm. Я по логу никогда не пойму все ли будет работать правильно. Думаю понятно, к чему я клоню.
Здравствуйте, Mystic Artifact, Вы писали:
S>>Если софт — коробка, то это просто обязан быть пакет. (deb, rpm итд), который должен ставиться штатными средствами. MA> Ты не объяснил с какой луны возникнут задачи по обновлению версий в результате слежки за дистрибутивами.
Хоть я Шеридана и не люблю, но тут он в чём-то прав. А задачи возникнут с того, что это часть той культуры, в рамках которой работают все бесплатные линуксы. Извольте соответствовать этой культуре.
Здравствуйте, Sheridan, Вы писали:
ЯИ>>Как ты собираешься без докера устанавливать и обновлять сотни сервисов в каком-нибудь микросервисном проекте? S>Первое что в голову пришло: опакетить с выставлением зависимостей, поставлять репозиторий с пакетами, деплоить оттуда.
Шеридан, вот ты нашёл с кем разговаривать. Сотни микросервисов ему, ага. Каждое мелкое земноводное вообразило себя Убером.
M>Потому что иначе возникают ситуации, когда разработанный софт (новая версия) работает почти исключительно на машине разработчика и более нигде, после чего он свое окружение пакует в докере и распространяет. Ну в принципе да, решение проблемы, но в итоге можно прийти к тому, что каждая программа будет в своем снапшоте сидеть.
В идеале так и нужно. Жалко, unikernels так до вменяемого состояния и не допилились, они бы в теории были бы неплохой альтернативной докеру.
Здравствуйте, Sheridan, Вы писали:
S>Ты сам то диалог понял? S>Мне ничего не мешает актуализировать либы. А вот многие местные найдут 1000 и 1 причину этого не делать.
я спросил, как докер мешает актуализировать либы, ты написал что тебе лично никак, хотя вопрос был не в этом = слился с темы
мало ли что за причины местные найдут, вопрос не о том был
MA> Основная проблема в том, что выяснение всех деталей занимает слишком много времени, а оценка "зацепило ли" требует слишком глубоких знаний о всем проекте сразу (т.е. один девопс с этим не справится).
Рилли? Запустить приложение в свежем окружении и прогнать уже готовые тесты — непосильная операция? Да с этим даже обезьяна справится.
MA>И что самое главное — все эти телодвижения никак не помогут гарантировать что-либо клиенту. Там где учавствуют внешние не контроллируемые тобою зависимости — вообще от тебя ничего не зависит.
А знаешь причины этого? Подсказать? Или догадаешься из контекста всего этого срача?
MA> Если посмотреть на зависимости по жирнее, то можно офигеть просто лог читать. Ну, например взять llvm. Я по логу никогда не пойму все ли будет работать правильно. Думаю понятно, к чему я клоню.
Ченжлоги не всегда есть необходимость читать. Я читаю только тогда, когда приложение не заработало с свежей либой а понимания с первого взгляда почему — нет.
Здравствуйте, Слава, Вы писали:
ЯИ>>>Как ты собираешься без докера устанавливать и обновлять сотни сервисов в каком-нибудь микросервисном проекте? S>>Первое что в голову пришло: опакетить с выставлением зависимостей, поставлять репозиторий с пакетами, деплоить оттуда. С>Шеридан, вот ты нашёл с кем разговаривать. Сотни микросервисов ему, ага. Каждое мелкое земноводное вообразило себя Убером.
В чём проблема?
Здравствуйте, chaotic-kotik, Вы писали:
S>>Ты сам то диалог понял? S>>Мне ничего не мешает актуализировать либы. А вот многие местные найдут 1000 и 1 причину этого не делать. CK>я спросил, как докер мешает актуализировать либы, ты написал что тебе лично никак, хотя вопрос был не в этом = слился с темы CK>мало ли что за причины местные найдут, вопрос не о том был
Здравствуйте, chaotic-kotik, Вы писали:
CK>тссс, автор похоже не знает, что у популярных зависимостей обычно бывает больше одной актуальной версии
Знает и не видит проблем.
Здравствуйте, Sheridan, Вы писали:
С>>Шеридан, вот ты нашёл с кем разговаривать. Сотни микросервисов ему, ага. Каждое мелкое земноводное вообразило себя Убером. S>В чём проблема?
В том, до такого количества микросервисов ещё дорасти надо. И для этого нужно быть кем-то вроде Убера или хотя бы БКС. А пока это так, сферовакуумные обсуждения в духе "а если к нам придёт мильон клиентов?". Да не придут, не беспокойтесь.
