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

V>В GNU/Linux могу предложить очень тупой, но рабочий способ — просто запихивать сторонние динамические библиотеки алгоритмов в папку с исполняемым файлом проекта

В /usr/bin ??? Ничего не попутали?!

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

S>В /usr/bin ??? Ничего не попутали?!
Недурственно кривизну линуксового подхода пнул

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

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

ВП>>>>или мне надо заводить тестовый сервер для предварительных обновлений?
GIV>>>Эмм. Это шутка да?

С>>Постгрес при обновлениях не ломается. Апач не ломается. И так далее, и так далее.

VC>Читай внимательнее — это не mssql проблема а не той версии openssl в системе был. в убунте их две. все твои постгресы с апачами не ломаются пока админ не сломает зависимости.

openssl вроде тоже обновился
но тогда почему mssql предыдущей версии не конфликтует с новым openssl?

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

GIV>Здравствуйте, Ваня Первачев, Вы писали:

ВП>>или мне надо заводить тестовый сервер для предварительных обновлений?

GIV>Эмм. Это шутка да?

шутки можешь почитать в разделе политика

Здравствуйте, Ваня Первачев, Вы писали:

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

ВП>>>>>или мне надо заводить тестовый сервер для предварительных обновлений?
GIV>>>>Эмм. Это шутка да?

С>>>Постгрес при обновлениях не ломается. Апач не ломается. И так далее, и так далее.

VC>>Читай внимательнее — это не mssql проблема а не той версии openssl в системе был. в убунте их две. все твои постгресы с апачами не ломаются пока админ не сломает зависимости.

ВП>openssl вроде тоже обновился
ВП>но тогда почему mssql предыдущей версии не конфликтует с новым openssl?

хз. в профильном форуме надо спрашивать. Но я сомневаюсь что тебе ответят. До обновления надо было смотреть какие версии openssl 1.0 и 1.1 стоят/не-стоят и сравнить с после.

Здравствуйте, Ваня Первачев, Вы писали:

ВП>mssql это же не опенсурс

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

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

vsb>Не припомню такого в опен сорсе. Чтобы постгрес обновил и он сломался.

А я вот разок натыкался.

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

S>>В /usr/bin ??? Ничего не попутали?!
P>Недурственно кривизну линуксового подход пнул

У линупсов всё ок. Нет dll-hell'а, как в виндах когда каждое приложение всё с собой своё носит и обновление всего этого добра превращается в адскую боль, приводящую к "лучше меня путь накажут, но я это обновлять не полезу".

Ну да, ща вы мне начнете рассказывать про разные версии, про разные дистрибутивы... Я одно только спрошу: почему разработчики софта линупсячего осиливают тогда поддержку своего софта под кучу дистрибутивов? В чём разница? В усидчивости? В IQ? В руках?

S>Я одно только спрошу: почему разработчики софта линупсячего осиливают тогда поддержку своего софта под кучу дистрибутивов?

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

Да и мейнтейнеры осиливают далеко не всегда. Стандартная ситуация, когда для дистрибутива двухлетней давности (например, LTS) нет пакетов полуторалетней или годовой давности.

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

M>Не осиливают.

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

Так осиливают или не осиливают? Я чойто запутался...

S>Я чойто запутался...

Ну удивительно.

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


S>>Я чойто запутался...
M>Ну удивительно.
Удивительно видеть в одном посте от одного человека противоречащие другдругу утверждения.

Здравствуйте, Ваня Первачев, Вы писали:

ВП>openssl вроде тоже обновился
ВП>но тогда почему mssql предыдущей версии не конфликтует с новым openssl?

Если посмотриш сюда https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-change-repo?view=sql-server-2017&pivots=ld2-ubuntu, то там все для 16й убунты только.

в 16й убунте openssl 1.0.2 называется openssl, а openssl 1.1 нет
в 18й убунте южноафриканские товарищи сделали openssl 1.1 покет под старым именем openssl, а openssl 1.0 переоименовали в пакет openssl1.0

Потому когда ты ставиш на 18й убунте mssql для 16й убунты через apt, то она ставит openssl пакет с фактической версией 1.1, который с sql сервер-ом не работает

где написано что репо для 16й убунты будет работать на 18й?

P.S.
Кто не в курсе все что собрано на core 2.* Требует openssl 1.0
а все что собрано на core 3.0 требует openssl 1.1

С>Да, это такой софт, который даже виртуалки не любит.
Докер это не совсем виртуалка.

С>Вроде freeswitch.
https://hub.docker.com/r/bettervoice/freeswitch-container/

S>>>Я чойто запутался...
M>>Ну удивительно.
S>Удивительно видеть в одном посте от одного человека противоречащие другдругу утверждения.

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

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

V>В GNU/Linux могу предложить очень тупой, но рабочий способ — просто запихивать сторонние динамические библиотеки алгоритмов в папку с исполняемым файлом проекта, тоже самое касается Windows. По большому счёту проблема зависимостей касается лишь разработчиков данного конкретного продукта, в текущем случае Microsoft с их MSSQL, а не операционных систем. Как они решат делать, так в итоге и будет работать.

Странно, но я пару месяцев назад, сталкнулся на практике — с совершенно противоположной ситуацией (речь об Ubuntu 16.04 LTS):
http://rsdn.org/forum/unix/7464290

Автор: AlexGin
Дата: 07.06.19

По ходу разбирания выяснилось, что по-умолчанию здесь поведение Windows и Linux — отличается кардинально...

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

VC>Здравствуйте, Ваня Первачев, Вы писали:

ВП>>openssl вроде тоже обновился
ВП>>но тогда почему mssql предыдущей версии не конфликтует с новым openssl?

VC>Если посмотриш сюда https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-change-repo?view=sql-server-2017&pivots=ld2-ubuntu, то там все для 16й убунты только.

VC>в 16й убунте openssl 1.0.2 называется openssl, а openssl 1.1 нет
VC>в 18й убунте южноафриканские товарищи сделали openssl 1.1 покет под старым именем openssl, а openssl 1.0 переоименовали в пакет openssl1.0

VC>Потому когда ты ставиш на 18й убунте mssql для 16й убунты через apt, то она ставит openssl пакет с фактической версией 1.1, который с sql сервер-ом не работает

VC>где написано что репо для 16й убунты будет работать на 18й?

VC>P.S.
VC>Кто не в курсе все что собрано на core 2.* Требует openssl 1.0
VC>а все что собрано на core 3.0 требует openssl 1.1

у меня 16 убунта

Здравствуйте, Ваня Первачев, Вы писали:


ВП>у меня 16 убунта

а в твоей ссылке 18я

V>В GNU/Linux могу предложить очень тупой, но рабочий способ — просто запихивать сторонние динамические библиотеки алгоритмов в папку с исполняемым файлом проекта, тоже самое касается Windows.
И когда найдут очередную уязвимость в библиотеке — система обновится сама, а тебе твой продукт надо будет обновлять отдельно. Так себе вариант.

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

V>>В GNU/Linux могу предложить очень тупой, но рабочий способ — просто запихивать сторонние динамические библиотеки алгоритмов в папку с исполняемым файлом проекта
S>В /usr/bin ??? Ничего не попутали?!

В GNU/Linux часто используют вторичную иерархию /usr/* и третичную /usr/local/*, но речь не о них. Как крайний случай того о чём говорю это:

Переносимое приложение (также портативное, автономное, и — неточно, в качестве кальки — портированное; англ. portable application, portable app) — программное обеспечение, которое для своего запуска не требует процедуры установки и может полностью храниться на съёмных носителях информации, что позволяет использовать данное ПО на многих компьютерах.

То есть в общем случае приложение отправится в /opt/*, но по сути может быть где угодно, например, в /home/*, /media/*, /mnt/*.

Чисто для примера, берём исполняемый файл скомпилированной мною программы memories-console и запускаем просмотр зависимостей.

ldd /mnt/data_00/archive/files/work/memories-console

Результат.

linux-vdso.so.1 (0x00007ffe28fc4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f26dab1b000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f26da799000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f26da495000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f26da27e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f26d9edf000)
/lib64/ld-linux-x86-64.so.2 (0x00007f26daf3f000)

Аналогично можно сделать для Windows, именно о таком копировании и говорилось в предыдущем комментарии. Дело в том, что лично я использую Windows и GNU/Linux в мультизагрузке. Я и там и там проводил опыты по статической линковке, по динамической с переносом динамических библиотек в одну папку или настройку окружения и так далее. У меня нет предубеждений, что подходы Windows работают только в Windows, а подходы GNU/Linux только в GNU/Linux. Если в Windows существует возможность засрать системный реестр, то это не значит, что надо делать именно так. Если в каком-то дистрибутиве GNU/Linux есть порядок установки приложений из репозитория, то это не значит, что обязательно нужно к этому привязываться. С одной стороны вроде бы удобно, а с другой Ubuntu насколько помню обновляется раз в пол года, Debian раз в 2 года и так далее.
Меры против DLL hell

1. подсчитать контрольную сумму кода функции, вызываемой из DLL — сравнить с контрольной суммой функции, используемой при написании программы.
2. Операционная система должна поставляться совместно с менеджером пакетов, чтобы иметь возможность прослеживать все взаимозависимости DLL, при этом использование менеджера пакетов должно поощряться, а индивидуальная инсталляция DLL — по возможности отвергаться.
3. Централизованное распространение библиотек.
4. Допустить возможность параллельного использования нескольких версий одной и той же DLL.
5. При модификации программного обеспечения для частного использования поставлять также модифицированные версии DLL.
6. Во время проектирования DLL должна тщательно продумываться концепция функций и версий.
7. DLL не должны использоваться без необходимости, а библиотеки, связанные только с одним приложением, должны подключаться статически (в EXE-файл).

Второе правило хорошо работает для разработчиков дистрибутива, но плохо для независимых разработчиков. Скорее всего понадобится какая-нибудь система непрерывной интеграции с ночными сборками под все операционки. Просто тупо скопировать приложение и забыть не получится.