Здравствуйте, GarryIV, Вы писали:
ВП>>или мне надо заводить тестовый сервер для предварительных обновлений? GIV>Эмм. Это шутка да?
Постгрес при обновлениях не ломается. Апач не ломается. И так далее, и так далее. Копию всего прода для предварительных обновлений никто никогда не делал и не будет, а обновление на тестовом окружении с малым количеством данных может вести себя нормально, и вместе с тем — сломается на проде.
Здравствуйте, pagid, Вы писали:
S>>В /usr/bin ??? Ничего не попутали?! P>Недурственно кривизну линуксового подход пнул
У линупсов всё ок. Нет dll-hell'а, как в виндах когда каждое приложение всё с собой своё носит и обновление всего этого добра превращается в адскую боль, приводящую к "лучше меня путь накажут, но я это обновлять не полезу".
Ну да, ща вы мне начнете рассказывать про разные версии, про разные дистрибутивы... Я одно только спрошу: почему разработчики софта линупсячего осиливают тогда поддержку своего софта под кучу дистрибутивов? В чём разница? В усидчивости? В IQ? В руках?
Здравствуйте, Igore, Вы писали:
NB>>>+ -Wl,-rpath=. S>>За такое в порядочных семьях на горох в угол ставят на целый день, а вечером ещё за прохалявленый день подзатыльник дают. I>Лучше это, чем LD_LIBRARY_PATH, так что все свое ношу с собой в Linux-e очень даже применим и используется, только в отличие от Windows требует дополнительных телодвижений.
Горите в аду.
Здравствуйте, hi_octane, Вы писали:
ВП>>mssql это же не опенсурс _>А окружение — чистый незамутнённый опунсурс. В котором ухитирилсь сделать dll-hell, python version hell, config-hell, и ещё сотню хеллов у которых даже имен нет.
В GNU/Linux могу предложить очень тупой, но рабочий способ — просто запихивать сторонние динамические библиотеки алгоритмов в папку с исполняемым файлом проекта, тоже самое касается Windows. По большому счёту проблема зависимостей касается лишь разработчиков данного конкретного продукта, в текущем случае Microsoft с их MSSQL, а не операционных систем. Как они решат делать, так в итоге и будет работать.
Здравствуйте, Sheridan, Вы писали:
NB>>+ -Wl,-rpath=. S>За такое в порядочных семьях на горох в угол ставят на целый день, а вечером ещё за прохалявленый день подзатыльник дают.
Лучше это, чем LD_LIBRARY_PATH, так что все свое ношу с собой в Linux-e очень даже применим и используется, только в отличие от Windows требует дополнительных телодвижений.
Здравствуйте, pagid, Вы писали:
P>То есть не религиозные причины, а исторические — когда система задумывалась самой сложной программой в ей была утилитка по обработке текстового файла и в тех условиях выбранная схема выглядела красиво. P>А сейчас приходится городить костыль на костыле чтобы это работало, соорудить систему поддерживать которую может только пакетный менеджер, обложиться кучей правил и условий за выход за которые нужно грозить расстрелом и содержать этих самых специалистов чтобы разрешать и предвидеть возможные конфликты.
Это религиозным виндузятникам, ходящим везде со своим уставом, это всё требуется когда они в линупс приходят. А потом начинается "виноваты все кроме я". Повзрослей уже.
Здравствуйте, Мёртвый Даун, Вы писали:
МД>Здравствуйте, Ваня Первачев, Вы писали:
ВП>>Это ж каким надо быть раджи кумаром, чтобы такое сделать?
МД>Опен сорс! Или как ты хотел?
Здравствуйте, Слава, Вы писали:
С>Постгрес при обновлениях не ломается. Апач не ломается. И так далее, и так далее. Копию всего прода для предварительных обновлений никто никогда не делал и не будет, а обновление на тестовом окружении с малым количеством данных может вести себя нормально, и вместе с тем — сломается на проде.
Обсуждаемая проблема замечательно ловится на тестовом окружении.
Здравствуйте, AlexGin, Вы писали:
AG>Здесь успешно работают два варианта: AG>- через /usr/lib (просто копируя туда все вышеуказанные файлы под "рутом"); AG>- используя переменную окружения LD_LIBRARY_PATH (со значением '.' — точка) — то есть загружать библиотеки из текущего директория.
Здравствуйте, Sheridan, Вы писали:
S>Не вижу разницы между зависимостями и собственными либами.
Разница между плагинами и бинарными зависимостями принципиальна: плагины опциональны и приложение может их искать по любым путям.
S>rpath в любом случае грязный хак, делающий невозможным управление либами приложения
Глупость. rpath добавляет новое место для поиска зависимостей, но не отменяет остальные. Это именно что стандартное решение.
S>>>1. /var/lib/mysupersoft/plugins + LD_LIBRARY_PATH S>>1. Нет. LD_LIBRARY_PATH — это грязный хак. S>Нет, это стандартный метод указания софту где искать библиотеки, по каким путям. Есть PATH — для бинарников и LD_LIBRARY_PATH — для библиотек.
Нет, нет, нет. Это — не стандартный метод. Это хак для откладки.
1. Использование LD_LIBRARY_PATH при нормальной установке приложения — прямой путь к конфликтам и проблемам с безопасностью.
2. Для установки переменной надо либо глобально ее менять при установке приложения (ужос-ужос), либо использовать скрипт или для запуска (ужос).
S>>>2. /var/lib/libmysupersoftpluginsuperplugin.so S>>1. Нет гарантии отсутсвия конфликтов. S>Есть, если не называть либы именами типа libplugin.so или libextention.so
Нет гарантии отсутсвия конфликтов.
S>>>>>А для этого используйте LD_LIBRARY_PATH. S>>>>Это хак не особо рекоменнуемый для продакшена. Конфигурационные файлы правильный путь. S>Кем не рекомендован? Озвучте весь список пожалуйста
Здравый смысл и ну и например Оракл.
Ну или маны почитай и обрати внимание, когда LD_LIBRARY_PATH игнорируется.
S>>>Правильный путь — устанавливать в стандартные пути используя пакетный манагер. S>>Да хоть так, суть в том, что твой пакетный менеджер должен обновить /etc/ls.so.conf или что-то в этом духе. S>Это проблема?
В общем случае — нет, разговор про то, что менять глобальные переменные при установке приложения — очень плохая идея.
S>>Ну и проблема в пакетных менеджерах: кто будет заниматься их поддержкой? S>Их разработчики. S>А ты, как разработчик софта, выбери несколько дистрибутивов и автоматизируй сборку пакетов об тот же fpm
Да делать больше нечего. Нормально собранное приложение и так прекрасно работает на всех целевых линухах. Единственное действие которое надо сделать пользователю — добавить права на выполнение.
S>>Я, как разработчик, делаю AppImage, который работает везде без необходимости рутовых прав для установки. И совершенно пофиг на лишние мегабайты у пользователя из-за повторяющихся библиотек, зато количество головной боли во вселенной на порядки меньше. S>Вот сейчас у меня настолько подгорело что я даже не знаю какие слова тут написать. S>Бредовая идея. Бредовый софт. В линупсах так не делают.
Т.е. разработчики обязаны поддерживать все пакетные менеджеры?
S>Ты машешь флагом Спартака на трибунах Динамо.
Ну твой фанатизм известен
S>>Дальше мантейнеры пакетных мендежеров могут устанавливать как угодно. А можно и без них, Win-Win. S>нираспарсил...
Да вроде все просто: если тебе надо, то возьми мое приложение и сделай пакет, чтобы что-то вроде
sudo apt install super-pupper
работало. Но оно прекрасно работает и без этого. Скачал и запустил.
S>>И весь более-менее сложный софт использует собственные установщики (тот же QtCreator), S>Такого софта — единицы.
Такого софта вагон и маленькая тележка, для любого софт который активно развивается такой подход будет предпочтительнее.
Для утилит и программ которые "просто работают" и обновляются раз в 5 лет пакетные менеджеры лучше подходят.
S>>пакетные менеджеры отстают на пару лет обычно. S>Поправочка: официальные репозитории отстают в силу необходимости соблюдения стабильности дистрибутива. S>Тебе ничего не мешает иметь собственные репозитории для своих продуктов под популярные дистрибутивы, как это делает раббит, графана, прометей и так далее.
Это какой-то птичий язык. Я использую программы QtCreator/Chrome/Steam/etc, я их беру с офф. сайта разраотчиков и все работает.
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, Sheridan, Вы писали:
S>>Загляни в любой дистрибутив из популярных и посмотри как и куда устанавливается подавляющее большинство софта. S>Ну так посмотри: плагины всегда устанавлваются относительно исполняемого файла, т.к. он должен знать путь.
Ты думаешь что если путь установится абсолютны то чтото поменяется?
S>>>Это стандартное решение последние лет 20. Посмотри. S>>Не путай мягкое с тёплым. Это как раз явное указание стандартных путей. S>Нет. Сделай одолжение, посмотри код (и попытайся понять). S>Можешь установить и посмотреть где плагины будут.
Заканчивай уже выдумывать, короче.
S>>>Потому что это кривой костыль. Нормальное приложение работает и без него. S>>Если писать и линковать правильно — то работает и без него, конечно же. S>Конечно, для этого rpath и придумали. Или /etc/ld.so.conf, но не LD_LIBRARY_PATH.
Ты только чорное и белое различаешь?
S>>Ну у виндоюзеров привычка сваливать всё в одну папку а потом героически бороться с последствиями. А виноват в итоге, естественно, линупс. S>Смешались в кучу кони, люди...
Конечно же смешались, как же иначе.
S>>У виндоюзеров в линупсах и не такое случается. man "устав и монастырь", друже. S>Аргументы кончились, перешел на личности?
Я тебе характеристик не давал, я посоветовал только изучить систему, для которой пишешь софт и действовать согласно правилам этой системы, а не той, к которой ты привык.
S>Возьми любой нормальный софт под линух (vlc/Qtcreator/браузеры) и посмотри наконец.
Это ненормальный софт, вот в чём дело. Таким образом распространяются жалкие единицы пакетов.
S>>LD_LIBRARY_PATH там упоминается как переменная окружения, выставленная для конкретно твоего приложения. Это же очевидно. S>Ну тогда пользователь вынужден запускать не приложение, а скрипт. Вот это криво и так никто не делает.
И что? Пользователь запускает некий "ярлык" вообщето. Что в ярлыке будет прописано в качестве исполняемого файла — дело восемнадцатое.
S>>Не религия. Терпеть не могу когда приходят в чужой монастырь со своим уставом. S>Да нет никакого твоего монастыря, ты что-то себе навоображал. Посмотри исходники и преми реальность.
Посмотрел и вижу что рядом с бинарником никто не хранит плагины и путь относительно бинарника не вычисляет.
S>>И поэтому ты изобрёл свой пакетный манагер? S>Нет.
А что же там по ссылке которую ты приводил?
The AppImage format is a format for packaging applications
S>>Может стоит изучить как работают другие? S>Ну так посмотри, я ж тебе уже дал ссылку на самый что ни на есть популярный опенсорс который использует пакетные менеджеры. Посмотри куда он устанавливает плагины.
/usr/lib64/vlc
S>>Тебе надо. Но ты пошёл по более трудному пути: ты сразу начал писать свой пакетный манагер. Времени не жалко? S>Ты ничего не понял.
Конечно же я ничего не понял, да.
S>>В виндах — да. В линупсах такого софта единицы. S>Да факт-то простой: любой более-менее сложный и развивающийся софт будет все бинари таскать с собой. Пакетные менеджеры тут не причем.
Стоп. Какие такие бинари? Библиотеки, от которых он зависит? Так не делают в линухах. В линухах указывают зависимость и пакетный манагер дальше сам разбирается.
Здравствуйте, pagid, Вы писали:
S>>Тем не менее рядом с бинарником никто либы не укладывает P>И какие для этого причины, кроме религиозных соображений?
Это затрудняет работу специалистам, которые должны потом этот ваш мегасофт обкладывать подпорками чтобы оно работало. Деплоить мимо стандартных путей, обеспечивать правильный запуск из командной строки (как минимум править глобальный PATH), выставлять права и так далее.
Здравствуйте, Skorodum, Вы писали:
NB>>+ -Wl,-rpath=. S>Кстати, в официальной документации для этого рекомендуется $ORIGIN, но я не смог найти чем оно лучше просто точки...?
Тем что в linux-e можно даже точку переопределить
alias .='/home/mylibs'
Здравствуйте, AlexGin, Вы писали:
AG>Странно, но я пару месяцев назад, столкнулся на практике — с совершенно противоположной ситуацией AG>По ходу разбирания выяснилось, что по-умолчанию здесь поведение Windows и Linux — отличается кардинально...
Мне думается нужно к этому подходить с позиции, что если что-то не сработало как ожидалось, то как сделать так, чтобы сработало. Возьмём для примера более сложный случай, нужно чтобы программа загружала динамические библиотеки из папки ./lib, тогда как исполняемый файл лежит в ./. При этом программа должна быть переносимой. Очевидно, что по умолчанию такое условие не сработает ни в Windows, ни в GNU/Linux, но это ведь не значит, что такое невозможно.
По поводу этого:
Зависимость от библиотеки libqmapcontrol.so имеется, я эту библиотеку неоднократно пересобирал в том же самом Qt Creator.
В том же каталоге, где и файл MyApplication находится четыре файла:
libqmapcontrol.so
libqmapcontrol.so.0
libqmapcontrol.so.0.9
libqmapcontrol.so.0.9.7
То есть, нужный файл ЛЕЖИТ РЯДОМ!
Он откомпилирован с тем же самым GCC, что и мой исполнимый файл!
Хотелось бы обратить внимания на то, что libqmapcontrol.so может быть символической ссылкой. Это как если в Windows скопировать ярлыки вместо библиотек, но это я на всякий случай напоминаю, мало ли. Лучше всего копировать реальный файл и переименовать его соответствующим образом, то есть одна библиотека, один реальный файл, а не куча непонятно чего. Опять же убедиться, что всё находится в рабочем каталоге.
Вторым этапом я бы изучил подгрузку динамических библиотек, этим можно управлять, то есть нужно разбираться в компиляции и так далее. Сказал бы подробнее, но я знаю лишь куда копать, а вот изучать этот вопрос когда-то давно было лень. Qt ещё имеет класс QLibrary, опять же система плагинов, но лучше наверное сначала изучить универсальные методы работы с динамическими библиотеками вне зависимости от проекта.
Немного отвлекусь:
книга Программист-фанатик (Фаулер Чед)
Совет 8.
Будь специалистом
«Как бы вы написали на Java программу, которая уронит виртуальную машину Java?» А в ответ — тишина... «Эй, как вас там? Ау!» «Извините, я вас не понимаю. Вы не могли бы повторить вопрос?» В голосе послышалось отчаяние. По опыту я знал, что повторение вопроса вряд ли чему-то поможет. Поэтому я повторил вопрос медленно и громко. «Как бы вы написали на Java программу, которая
уронит виртуальную машину Java?»
«Э-э-э... прошу прощения. Я раньше никогда этого не делал». «Я уверен, что не делали. Но что там с вопросом: как бы вы написали на языке Java программу, которая НЕ будет приводить к падению JVM?»
Я искал по-настоящему квалифицированных Java-программистов. Перед началом собеседования я попросил этого человека (как и всех остальных, просмотренных за эту неделю) оценить себя по десятибалльной шкале. Он назвал цифру девять. Я ожидал увидеть перед собой звезду. Но если парень так высоко себя ценит, что мешает ему придумать трюк, выводящий виртуальную машину Java из строя?
Это недостаток технической подготовки.
Тем не менее он утверждал, что специализируется на языке Java. Спроси его на вечеринке, чем он зарабатывает, и он ответит: «Я Java-разработчик». Но при этом он оказался не в состоянии ответить на простой вопрос. Я не получил от него даже неправильного ответа. За две с половиной насыщенные собеседованиями недели вербовочной поездки по стране это было правило, а не исключение. На вакантные места претендовали тысячи специалистов по Java, и практически никто из них не мог объяснить, как работает загрузчик Java-классов, или рассказать, каким образом виртуальная машина Java обычно осуществляет управление памятью. Разумеется, все эти знания не нужны тем, кто собирается писать базовый код под чужим руководством. Но приходившие на собеседование люди позиционировали себя как специалисты.
Многие из нас считают, что термин «специализация» означает неумение разбираться в других вещах. Согласно такой трактовке я могу заявить, что моя мать специализируется в Windows, ведь она никогда не работала ни с Linux, ни с OS X. А мои родственники из арканзасской глубинки окажутся специалистами по кантри, потому что они никогда не слушали другой музыки.
В программировании важно досконально понимать детали, это в огромной мере определяют специализацию. Я могу сказать, что не специализируюсь на компиляции. Если человек заморочится, то в принципе он может стать специалистом в каком-нибудь вопросе. В данном вопросе мы пока общаемся не как специалист со специалистом и не как специалист с пользователем, а как пользователем с пользователем.
То как я когда-то компилировал и запускал программы может отличаться от того как их компилирует и запускает другой человек сейчас или даже я сам в настоящее время. Лично я по прежнему не думаю, что поведение Windows и GNU/Linux кардинально отличается. Что действительно часто отличается так это то, как люди привыкли работать в той или иной среде.
А окружение — чистый незамутнённый опунсурс. В котором ухитирилсь сделать dll-hell, python version hell, config-hell, и ещё сотню хеллов у которых даже имен нет. Судя по тому что написано в SO — в данном случае был openssl hell и/или python version hell одновременно или по очереди. Ничего выдающегося. У любого крупного проекта (читай с более чем 0 зависимостей) в опенсурс такие бывают.
Здравствуйте, velkin, Вы писали:
V>В GNU/Linux могу предложить очень тупой, но рабочий способ — просто запихивать сторонние динамические библиотеки алгоритмов в папку с исполняемым файлом проекта
S>Я одно только спрошу: почему разработчики софта линупсячего осиливают тогда поддержку своего софта под кучу дистрибутивов?
Не осиливают. Осиливают мейнтейнеры, которые занимаются неблагодарным и малооплачиваемым делом. Разработчики, которые действительно занимаются поддержкой разных дистрибутивов, сильно ограничивают и количество этих дистрибутивов и количество версий этих дистрибутивов, для всего остального — никаких гарантий.
Да и мейнтейнеры осиливают далеко не всегда. Стандартная ситуация, когда для дистрибутива двухлетней давности (например, LTS) нет пакетов полуторалетней или годовой давности.
Здравствуйте, night beast, Вы писали:
NB>+ -Wl,-rpath=.
За такое в порядочных семьях на горох в угол ставят на целый день, а вечером ещё за прохалявленый день подзатыльник дают.
Здравствуйте, Sheridan, Вы писали:
S>Как минимум пара вариантов
Это был намек на то, что фраза "софт ожидает библиотек" больше похожа на описание ситуации с подгрузкой плагинов, когда софт именно что использует относительный путь и контролирует загрузку. Разрешение остальных зависимостей обычно внешние дело, и испольняемым файлом мало контролируется (за исключением rpath или запуска через прокси и LD_LIBRARY_PATH).
S>1. /var/lib/mysupersoft/plugins + LD_LIBRARY_PATH
1. Нет. LD_LIBRARY_PATH — это грязный хак.
2. Нужны права.
S>2. /var/lib/libmysupersoftpluginsuperplugin.so
1. Нет гарантии отсутсвия конфликтов.
2. Нужны права для установки.
S>>>А для этого используйте LD_LIBRARY_PATH. S>>Это хак не особо рекоменнуемый для продакшена. Конфигурационные файлы правильный путь. S>Правильный путь — устанавливать в стандартные пути используя пакетный манагер.
Да хоть так, суть в том, что твой пакетный менеджер должен обновить /etc/ls.so.conf или что-то в этом духе.
Ну и проблема в пакетных менеджерах: кто будет заниматься их поддержкой?
Я, как разработчик, делаю AppImage, который работает везде без необходимости рутовых прав для установки. И совершенно пофиг на лишние мегабайты у пользователя из-за повторяющихся библиотек, зато количество головной боли во вселенной на порядки меньше.
Дальше мантейнеры пакетных мендежеров могут устанавливать как угодно. А можно и без них, Win-Win.
И весь более-менее сложный софт использует собственные установщики (тот же QtCreator), пакетные менеджеры отстают на пару лет обычно.
Здравствуйте, Sheridan, Вы писали:
S>Тем не менее рядом с бинарником никто либы не укладывает
И какие для этого причины, кроме религиозных соображений?
Здравствуйте, Ваня Первачев, Вы писали:
ВП>Это ж каким надо быть раджи кумаром, чтобы такое сделать?
Опен сорс! Или как ты хотел?
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, Mamut, Вы писали:
M>Не осиливают.
M>Разработчики, которые действительно занимаются поддержкой разных дистрибутивов, сильно ограничивают и количество этих дистрибутивов и количество версий этих дистрибутивов, для всего остального — никаких гарантий.
Так осиливают или не осиливают? Я чойто запутался...
Здравствуйте, velkin, Вы писали:
V>В GNU/Linux могу предложить очень тупой, но рабочий способ — просто запихивать сторонние динамические библиотеки алгоритмов в папку с исполняемым файлом проекта, тоже самое касается Windows.
Это не рабочий способ в линухе: по умолчанию загрузчик не смотрит на динамические библиотеки в одной папке с исполняемым файлом.
_>major_ver.minor_ver.fix_ver.build_data
_>major_ver — с каждой циферкой считай другой проект, api от между major версиями меняется как угодно _>minor_ver — с увеличением методы/объекты в api только добавляются, существующие методы не удаляются и не изменяются. т.е. все полагают что абсолютно безопасно заменять версию 3.1 на 3.2 _>fix_ver — фиксы которые накатили на конкретную версию, ничего вообще не меняется кроме исправления ошибок
Это называется semantic versioning и не работает нигде. Потому что версии от балды назначаются людьми, а автоматическую верификацию натянуть на это дело не получится.
_>Если админу прям очень надо чтобы ликовка была именно с 3.1 несмотря на то что уже есть 3.2 — надо указать в настройках (например в файле admin.config рядом с приложением). Само приложение ни при инсталляции ни как-то ещё создать этот файл не может, чтобы у разрабов не было шанса захардкодить конкретную зависимость для упрощения своей жизни.
1. Линковку должен решать не админ.
2. Есть ненулевое количество случаев, когда разработка зависит от конкретной версии библиотеки
_>Имхо, пару лет косорукие создатели библиотек будут отгребать от страдающих создателей программ, а потом длл-хелл отступит.
Не отступит. Semantic versioning уже скоро 10 лет существует в node.js и npm. Легче от этого не становится.
Здравствуйте, Skorodum, Вы писали:
S>>Значит /lib/mysupersoft/plugins например. Но не рядом с бинарником. S>Это кто сказал?
Загляни в любой дистрибутив из популярных и посмотри как и куда устанавливается подавляющее большинство софта.
S>>>Глупость. rpath добавляет новое место для поиска зависимостей, но не отменяет остальные. Это именно что стандартное решение. S>>В результате появляется приложение с нестандартным поведением, что плохо. S>Это стандартное решение последние лет 20. Посмотри.
Не путай мягкое с тёплым. Это как раз явное указание стандартных путей.
S>>>2. Для установки переменной надо либо глобально ее менять при установке приложения (ужос-ужос), либо использовать скрипт или для запуска (ужос). S>>Чем плох скрипт? Почему нет? S>Потому что это кривой костыль. Нормальное приложение работает и без него.
Если писать и линковать правильно — то работает и без него, конечно же. Ну у виндоюзеров привычка сваливать всё в одну папку а потом героически бороться с последствиями. А виноват в итоге, естественно, линупс.
S>>>Нет гарантии отсутсвия конфликтов. S>>История показывает что есть. S> да даже этот топик о конфликтах.
У виндоюзеров в линупсах и не такое случается. man "устав и монастырь", друже.
S>>>Ну или маны почитай и обрати внимание, когда LD_LIBRARY_PATH игнорируется. S>>Тем не менее рядом с бинарником никто либы не укладывает S>А мужики-то не знают. Sheridan, ты походу в каком-то альтернативном мире.
Та же ссылка, где ты путаешь мягкое с тёплым.
Добавлю еще, что естественно там будет ковнокод под линух, который ожидает либы рядом с бинарниками, это же гитхаб. И мне печально осознавать что есть люди, которые ориентируются на говнокод.
S>>Зачем менять глобальные? Я такого не предлагал. S>Ты предлагал
использовать пакетный менеджер для изменения LD_LIBRARY_PATH. Вот так никто не делает. Это плохо.
Там прямо так и написано: "используёте пакетный манагер и глобально меняйте LD_LIBRARY_PATH"?
Там прямо написано: устанавливайте всё в стандартные пути. То есть исполняемое в bin, либы в lib и так далее.
LD_LIBRARY_PATH там упоминается как переменная окружения, выставленная для конкретно твоего приложения. Это же очевидно.
S>>Нечего делать приложению на конпутере, установленному мимо манагера пакетов. S>Религия не позволяет? Ну ок
Не религия. Терпеть не могу когда приходят в чужой монастырь со своим уставом.
S>>>Т.е. разработчики обязаны поддерживать все пакетные менеджеры? S>>Не все, а два-три. S>Да мне нисколько не надо. И моим пользователям не надо.
И поэтому ты изобрёл свой пакетный манагер? Может стоит изучить как работают другие? Ни один луноход свой софт на пушечный выстрел не подпустит к конпутеру.
S>>fpm работает прекрасно. И как раз умеет в вышеописанные "два-три" пакетных манагера. S>Ну кому надо — тот и сделает. Это только у тебя религиозные ограничения на источники софта.
Тебе надо. Но ты пошёл по более трудному пути: ты сразу начал писать свой пакетный манагер. Времени не жалко?
S>>Вагон и маленькая тележка на фоне Фудзиямы, да. S>Да как угодно. В IDE и браузере я провожу большую часть времени. Они для меня Фудзияма. И любой более-менее сложный софт с зависимостями будет "все свое таскать с собой".
В виндах — да. В линупсах такого софта единицы.
Здравствуйте, Sheridan, Вы писали:
S>Загляни в любой дистрибутив из популярных и посмотри как и куда устанавливается подавляющее большинство софта.
Ну так посмотри: плагины всегда устанавлваются относительно исполняемого файла, т.к. он должен знать путь.
S>>Это стандартное решение последние лет 20. Посмотри. S>Не путай мягкое с тёплым. Это как раз явное указание стандартных путей.
Нет. Сделай одолжение, посмотри код (и попытайся понять).
Можешь установить и посмотреть где плагины будут.
S>>Потому что это кривой костыль. Нормальное приложение работает и без него. S>Если писать и линковать правильно — то работает и без него, конечно же.
Конечно, для этого rpath и придумали. Или /etc/ld.so.conf, но не LD_LIBRARY_PATH.
S>Ну у виндоюзеров привычка сваливать всё в одну папку а потом героически бороться с последствиями. А виноват в итоге, естественно, линупс.
Смешались в кучу кони, люди...
S>>>>Нет гарантии отсутсвия конфликтов. S>>>История показывает что есть. S>> да даже этот топик о конфликтах. S>У виндоюзеров в линупсах и не такое случается. man "устав и монастырь", друже.
Аргументы кончились, перешел на личности?
S>Та же ссылка, где ты путаешь мягкое с тёплым. S>Добавлю еще, что естественно там будет ковнокод под линух, который ожидает либы рядом с бинарниками, это же гитхаб. И мне печально осознавать что есть люди, которые ориентируются на говнокод.
Возьми любой нормальный софт под линух (vlc/Qtcreator/браузеры) и посмотри наконец.
S>Там прямо так и написано: "используёте пакетный манагер и глобально меняйте LD_LIBRARY_PATH"? S>Там прямо написано: устанавливайте всё в стандартные пути. То есть исполняемое в bin, либы в lib и так далее. S>LD_LIBRARY_PATH там упоминается как переменная окружения, выставленная для конкретно твоего приложения. Это же очевидно.
Ну тогда пользователь вынужден запускать не приложение, а скрипт. Вот это криво и так никто не делает.
S>Не религия. Терпеть не могу когда приходят в чужой монастырь со своим уставом.
Да нет никакого твоего монастыря, ты что-то себе навоображал. Посмотри исходники и преми реальность.
S>И поэтому ты изобрёл свой пакетный манагер?
Нет.
S>Может стоит изучить как работают другие?
Ну так посмотри, я ж тебе уже дал ссылку на самый что ни на есть популярный опенсорс который использует пакетные менеджеры. Посмотри куда он устанавливает плагины.
S>Тебе надо. Но ты пошёл по более трудному пути: ты сразу начал писать свой пакетный манагер. Времени не жалко?
Ты ничего не понял.
S>В виндах — да. В линупсах такого софта единицы.
Да факт-то простой: любой более-менее сложный и развивающийся софт будет все бинари таскать с собой. Пакетные менеджеры тут не причем.
Здравствуйте, Sheridan, Вы писали:
S>Это затрудняет работу специалистам, которые должны потом этот ваш мегасофт обкладывать подпорками чтобы оно работало.
То есть не религиозные причины, а исторические — когда система задумывалась самой сложной программой в ей была утилитка по обработке текстового файла и в тех условиях выбранная схема выглядела красиво.
S>Деплоить мимо стандартных путей, обеспечивать правильный запуск из командной строки (как минимум править глобальный PATH), выставлять права и так далее.
А сейчас приходится городить костыль на костыле чтобы это работало, соорудить систему поддерживать которую может только пакетный менеджер, обложиться кучей правил и условий за выход за которые нужно грозить расстрелом и содержать этих самых специалистов чтобы разрешать и предвидеть возможные конфликты.
Здравствуйте, pagid, Вы писали:
P>Здравствуйте, Sheridan, Вы писали:
S>>Это религиозным виндузятникам, ходящим везде со своим уставом, это всё требуется когда они в линупс приходят. А потом начинается "виноваты все кроме я". Повзрослей уже. P>То есть ответа на вопрос для чего в линуксе принято раскидывать какашки шедевральные части приложения по всему диску у тебя нет, ну кроме того, что это не так как принято у виндозятников значит хорошо и правильно.
Для того чтобы не было длл-хелла, для того чтобы не пришлось править глобальные переменные окружения и так далее.
Я же в свою очередь не понимаю — почему надо с собой тащить свои привычки. Я же не прихожу в винду и не говорю что надо всё делать по линуксячему. И ни один из линупсоидов такого не пишет и на это не обращает внимания. И лишь только виндузятники, приходя в линупс, начинают заниматься всякой ерундой вместо того чтобы почитать документацию и работать как там написано.
Почему только у виндузятников возникают такие проблемы, м? Не пробовал подумать?
хъ
S>Ну да, ща вы мне начнете рассказывать про разные версии, про разные дистрибутивы... Я одно только спрошу: почему разработчики софта линупсячего осиливают тогда поддержку своего софта под кучу дистрибутивов? В чём разница? В усидчивости? В IQ? В руках?
Здравствуйте, Sheridan, Вы писали:
I>>Лучше это, чем LD_LIBRARY_PATH, так что все свое ношу с собой в Linux-e очень даже применим и используется, только в отличие от Windows требует дополнительных телодвижений. S>Горите в аду.
В адe so-hell.
S>>> Что я должен тут увидеть? AB>>Всенепременно 9.2 жеж — только в этой версии есть минимально необходимый набор фитч при котором можно хоть как-то существовать. S>Как до этого жили и умудрились линупс напилить так, что микрософт стала его в себя встраивать — непонятно.
Sheridan: Я одно только спрошу: почему разработчики софта линупсячего осиливают тогда поддержку своего софта под кучу дистрибутивов?
B0FEE664: Нет, не осиливают. Если не верите — проверте какая у вас версия gcc.
<ровно одно сообщение спустя>
Sheridan: Как до этого жили и умудрились линупс напилить так, что микрософт стала его в себя встраивать?
Какое отношение майкрософт имеет к разговору о том, осиливают разрабочики линуксового софта поддержку разных дистрибутивов? А никакое.
Почему, Шеридан, ты удивляешься, что тебя никто всерьез не воспринимает?
На убунте крутится mssql
Думаю, дай обновлю его. Сегодня выходной, если что быстренько исправлю
И конечно же сломалось, причем даже локально не подключалось, хотя сам сервер работал
Танцы с бубном не помогли
И только тут нашел решение https://stackoverflow.com/a/57343207
Это ж каким надо быть раджи кумаром, чтобы такое сделать?
Здравствуйте, Ваня Первачев, Вы писали:
ВП>На убунте крутится mssql ВП>Думаю, дай обновлю его. Сегодня выходной, если что быстренько исправлю ВП>И конечно же сломалось, причем даже локально не подключалось, хотя сам сервер работал ВП>Танцы с бубном не помогли ВП>И только тут нашел решение https://stackoverflow.com/a/57343207 ВП>Это ж каким надо быть раджи кумаром, чтобы такое сделать?
Только что перепроверил. В докере последний стабильный билд под Линукс — 3098 (другое название — Comulative Update 13), а по ссылке на стековерфлоу билды 3223 и 3192.
Индус — это ты, потому что не тестиш
Хотя нет. Ты ещё хуже индусов. Потому что индусам простительно а тебе — нет. Шучю, но в каждой шутке
Здравствуйте, VladCore, Вы писали:
VC>Здравствуйте, Ваня Первачев, Вы писали:
ВП>>На убунте крутится mssql ВП>>Думаю, дай обновлю его. Сегодня выходной, если что быстренько исправлю ВП>>И конечно же сломалось, причем даже локально не подключалось, хотя сам сервер работал ВП>>Танцы с бубном не помогли ВП>>И только тут нашел решение https://stackoverflow.com/a/57343207 ВП>>Это ж каким надо быть раджи кумаром, чтобы такое сделать?
VC>Только что перепроверил. В докере последний стабильный билд под Линукс — 3098 (другое название — Comulative Update 13), а по ссылке на стековерфлоу билды 3223 и 3192.
VC>Индус — это ты, потому что не тестиш
VC>Хотя нет. Ты ещё хуже индусов. Потому что индусам простительно а тебе — нет. Шучю, но в каждой шутке
что не тестю?
убунта предложила обновить пакет, я согласился и получил сюрприз
или мне надо заводить тестовый сервер для предварительных обновлений?
Здравствуйте, Слава, Вы писали:
ВП>>>или мне надо заводить тестовый сервер для предварительных обновлений? GIV>>Эмм. Это шутка да?
С>Постгрес при обновлениях не ломается. Апач не ломается. И так далее, и так далее.
Читай внимательнее — это не mssql проблема а не той версии openssl в системе был. в убунте их две. все твои постгресы с апачами не ломаются пока админ не сломает зависимости.
С>Копию всего прода для предварительных обновлений никто никогда не делал и не будет, а обновление на тестовом окружении с малым количеством данных может вести себя нормально, и вместе с тем — сломается на проде.
Хахаха. Гуглить "докер" не пробовал? Ну и в облаках про слоты в ажуре например тоже не смотрел? 2019 год на дворе, йепта!
Здравствуйте, VladCore, Вы писали:
VC>Хахаха. Гуглить "докер" не пробовал? Ну и в облаках про слоты в ажуре например тоже не смотрел? 2019 год на дворе, йепта!
Телефонию в докер засунь. Кластер из Elasticsearch в докер засунь.
Здравствуйте, Слава, Вы писали:
VC>>Хахаха. Гуглить "докер" не пробовал? Ну и в облаках про слоты в ажуре например тоже не смотрел? 2019 год на дворе, йепта!
С>Телефонию в докер засунь.
Телефония это что софт такой?
С>Кластер из Elasticsearch в докер засунь.
Здравствуйте, VladCore, Вы писали:
VC>Хахаха. Гуглить "докер" не пробовал? Ну и в облаках про слоты в ажуре например тоже не смотрел? 2019 год на дворе, йепта!
Дерьмо эти ваши контейнеры. Решил попробовать недавно. Закинул прогу в контейнер. Не прошло и нескольких часов — сервер не пингуется. Захожу через терминал — отвечает, но сети нет. Ребутнул — работает. Лол. При том, что без контейнеров он месяцами работает как часы, а тут в первые же часы сломался. При том, что специально сервер переустановил для этого, там чистенький RHEL.
AB>А он в этом вашем 2019 уже научился полноценному IPv6 (/128 на контейнер например) или до сих пор его дальше локалхоста выпускать нельзя?
Самый большой косяк то что оно в nftables не умеет ((
Здравствуйте, vsb, Вы писали:
vsb>Не припомню такого в опен сорсе. Чтобы постгрес обновил и он сломался.
Я тоже не могу припомнить, чтобы у меня SQL Server ломался после апдейта.
Но гугл выдает результаты, что после обновления постгрес ломается.
Здравствуйте, 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 стоят/не-стоят и сравнить с после.
в 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
Здравствуйте, уважаемый velkin, Вы писали:
V>В GNU/Linux могу предложить очень тупой, но рабочий способ — просто запихивать сторонние динамические библиотеки алгоритмов в папку с исполняемым файлом проекта, тоже самое касается Windows. По большому счёту проблема зависимостей касается лишь разработчиков данного конкретного продукта, в текущем случае Microsoft с их MSSQL, а не операционных систем. Как они решат делать, так в итоге и будет работать.
Странно, но я пару месяцев назад, сталкнулся на практике — с совершенно противоположной ситуацией (речь об Ubuntu 16.04 LTS): http://rsdn.org/forum/unix/7464290
Здравствуйте, 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
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 и запускаем просмотр зависимостей.
Аналогично можно сделать для 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-файл).
Второе правило хорошо работает для разработчиков дистрибутива, но плохо для независимых разработчиков. Скорее всего понадобится какая-нибудь система непрерывной интеграции с ночными сборками под все операционки. Просто тупо скопировать приложение и забыть не получится.
Здравствуйте, vsb, Вы писали:
vsb>Не припомню такого в опен сорсе. Чтобы постгрес обновил и он сломался.
ну конечно, если vsb этого не помнит, этого не случается.
Здравствуйте, velkin, Вы писали:
V>Второе правило хорошо работает для разработчиков дистрибутива, но плохо для независимых разработчиков. Скорее всего понадобится какая-нибудь система
Да кто же вам разрабатывать то мешает? Хоть в докерах всё поднимайте.
Главное — убедитесь в том, что в результате ваш софт не ожидает библиотеки рядом с бинарником.
А для этого используйте LD_LIBRARY_PATH.
Здравствуйте, уважаемый velkin, Вы писали:
V>Мне думается нужно к этому подходить с позиции, что если что-то не сработало как ожидалось, то как сделать так, чтобы сработало. Возьмём для примера более сложный случай, нужно чтобы программа загружала динамические библиотеки из папки ./lib, тогда как исполняемый файл лежит в ./. При этом программа должна быть переносимой. Очевидно, что по умолчанию такое условие не сработает ни в Windows, ни в GNU/Linux, но это ведь не значит, что такое невозможно.
Установочный пакет (инсталлятор) программы будет различаться для Linux и Windows — вот очевидное решение.
Причём — совсем НЕ ОБЯЗАТЕЛЬНО делать различные инсталляторы!
Все отличия могут выглядеть как-то так:
V>Зависимость от библиотеки libqmapcontrol.so имеется, я эту библиотеку неоднократно пересобирал в том же самом Qt Creator.
V>В том же каталоге, где и файл MyApplication находится четыре файла:
V>libqmapcontrol.so
V>libqmapcontrol.so.0
V>libqmapcontrol.so.0.9
V>libqmapcontrol.so.0.9.7
V>То есть, нужный файл ЛЕЖИТ РЯДОМ!
V>Он откомпилирован с тем же самым GCC, что и мой исполнимый файл!
Эта проблема уже давно как решена, причём даже несколькими способами!
V>Хотелось бы обратить внимания на то, что libqmapcontrol.so может быть символической ссылкой. Это как если в Windows скопировать ярлыки вместо библиотек, но это я на всякий случай напоминаю, мало ли. Лучше всего копировать реальный файл и переименовать его соответствующим образом, то есть одна библиотека, один реальный файл, а не куча непонятно чего. Опять же убедиться, что всё находится в рабочем каталоге.
Здесь успешно работают два варианта:
— через /usr/lib (просто копируя туда все вышеуказанные файлы под "рутом");
— используя переменную окружения LD_LIBRARY_PATH (со значением '.' — точка) — то есть загружать библиотеки из текущего директория.
V>Вторым этапом я бы изучил подгрузку динамических библиотек, этим можно управлять, то есть нужно разбираться в компиляции и так далее. Сказал бы подробнее, но я знаю лишь куда копать, а вот изучать этот вопрос когда-то давно было лень. Qt ещё имеет класс QLibrary, опять же система плагинов, но лучше наверное сначала изучить универсальные методы работы с динамическими библиотеками вне зависимости от проекта.
Я в курсе насчёт плагинов Qt (QtPlugin).
Применял их пару лет назад. Сделал систему плагинов для проектов в моей прежней конторе.
Это решение хорошее, но оно скорее в стиле "кроссплатформенный_COM". Там много избыточных сущностей (неактуальных для повседневных задач).
В то же время, в описываемом мной проекте требовалось решение в стиле "дешево_и_сердито" — простая DLL (или *.so файл — в терминологии Linux).
V>>В GNU/Linux могу предложить очень тупой, но рабочий способ — просто запихивать сторонние динамические библиотеки алгоритмов в папку с исполняемым файлом проекта, тоже самое касается Windows. _>И когда найдут очередную уязвимость в библиотеке — система обновится сама, а тебе твой продукт надо будет обновлять отдельно. Так себе вариант.
Обратное тоже справедливо. См долгую историю про OpenSSL, например.
Здравствуйте, Sheridan, Вы писали:
S>Главное — убедитесь в том, что в результате ваш софт не ожидает библиотеки рядом с бинарником.
А плагины?
S>А для этого используйте LD_LIBRARY_PATH.
Это хак не особо рекоменнуемый для продакшена. Конфигурационные файлы правильный путь.
Здравствуйте, Skorodum, Вы писали:
S>>Главное — убедитесь в том, что в результате ваш софт не ожидает библиотеки рядом с бинарником. S>А плагины?
Как минимум пара вариантов
1. /var/lib/mysupersoft/plugins + LD_LIBRARY_PATH
2. /var/lib/libmysupersoftpluginsuperplugin.so
S>>А для этого используйте LD_LIBRARY_PATH. S>Это хак не особо рекоменнуемый для продакшена. Конфигурационные файлы правильный путь.
Правильный путь — устанавливать в стандартные пути используя пакетный манагер.
Здравствуйте, Skorodum, Вы писали:
V>>В GNU/Linux могу предложить очень тупой, но рабочий способ — просто запихивать сторонние динамические библиотеки алгоритмов в папку с исполняемым файлом проекта, тоже самое касается Windows. S>Это не рабочий способ в линухе: по умолчанию загрузчик не смотрит на динамические библиотеки в одной папке с исполняемым файлом.
Сам по себе это нормальный подход, особенно учитывая реалии российского использования линухи (военные и т.п.), просто фраза пользователя velkin не верная.
Кстати интересно, а вдруг есть. Например вот в такой схеме нумерации версий:
major_ver.minor_ver.fix_ver.build_data
major_ver — с каждой циферкой считай другой проект, api от между major версиями меняется как угодно
minor_ver — с увеличением методы/объекты в api только добавляются, существующие методы не удаляются и не изменяются. т.е. все полагают что абсолютно безопасно заменять версию 3.1 на 3.2
fix_ver — фиксы которые накатили на конкретную версию, ничего вообще не меняется кроме исправления ошибок
build_data — любой набор цифер который имеет смысл для разработчика, нет нужды даже быть упорядоченным, если в систему прилетает (например компилируется). По-умолчанию каждый новый билд затирает старый без проблем если не указано иное в каких-то настройках.
Единый репозиторий для всех библиотек, и ОС при запуске полагается только на эту структуру. То есть смело подставляет версию 3.2 вместо 3.1
Если админу прям очень надо чтобы ликовка была именно с 3.1 несмотря на то что уже есть 3.2 — надо указать в настройках (например в файле admin.config рядом с приложением). Само приложение ни при инсталляции ни как-то ещё создать этот файл не может, чтобы у разрабов не было шанса захардкодить конкретную зависимость для упрощения своей жизни.
Имхо, пару лет косорукие создатели библиотек будут отгребать от страдающих создателей программ, а потом длл-хелл отступит. Разработчики библиотек приспособятся соответствовать, а проекты в которых бардак и регулярно надо лазить в admin.config — будут нелюбимы и станут непопулярны. Или я ошибаюсь и в этой системе есть заметный изъян?
Здравствуйте, Skorodum, Вы писали:
S>>Как минимум пара вариантов S>Это был намек на то, что фраза "софт ожидает библиотек" больше похожа на описание ситуации с подгрузкой плагинов, когда софт именно что использует относительный путь и контролирует загрузку. Разрешение остальных зависимостей обычно внешние дело, и испольняемым файлом мало контролируется (за исключением rpath или запуска через прокси и LD_LIBRARY_PATH).
Не вижу разницы между зависимостями и собственными либами. rpath в любом случае грязный хак, делающий невозможным управление либами приложения
S>>1. /var/lib/mysupersoft/plugins + LD_LIBRARY_PATH S>1. Нет. LD_LIBRARY_PATH — это грязный хак.
Нет, это стандартный метод указания софту где искать библиотеки, по каким путям. Есть PATH — для бинарников и LD_LIBRARY_PATH — для библиотек.
S>2. Нужны права.
Это совершенно не проблема.
S>>2. /var/lib/libmysupersoftpluginsuperplugin.so S>1. Нет гарантии отсутсвия конфликтов.
Есть, если не называть либы именами типа libplugin.so или libextention.so
S>2. Нужны права для установки.
Это совершенно не проблема.
S>>>>А для этого используйте LD_LIBRARY_PATH. S>>>Это хак не особо рекоменнуемый для продакшена. Конфигурационные файлы правильный путь.
Кем не рекомендован? Озвучте весь список пожалуйста
S>>Правильный путь — устанавливать в стандартные пути используя пакетный манагер. S>Да хоть так, суть в том, что твой пакетный менеджер должен обновить /etc/ls.so.conf или что-то в этом духе.
Это проблема?
S>Ну и проблема в пакетных менеджерах: кто будет заниматься их поддержкой?
Их разработчики.
А ты, как разработчик софта, выбери несколько дистрибутивов и автоматизируй сборку пакетов об тот же fpm
S>Я, как разработчик, делаю AppImage, который работает везде без необходимости рутовых прав для установки. И совершенно пофиг на лишние мегабайты у пользователя из-за повторяющихся библиотек, зато количество головной боли во вселенной на порядки меньше.
Вот сейчас у меня настолько подгорело что я даже не знаю какие слова тут написать.
Бредовая идея. Бредовый софт. В линупсах так не делают. Ты машешь флагом Спартака на трибунах Динамо.
S>Дальше мантейнеры пакетных мендежеров могут устанавливать как угодно. А можно и без них, Win-Win.
нираспарсил...
S>И весь более-менее сложный софт использует собственные установщики (тот же QtCreator),
Такого софта — единицы.
S>пакетные менеджеры отстают на пару лет обычно.
Поправочка: официальные репозитории отстают в силу необходимости соблюдения стабильности дистрибутива.
Тебе ничего не мешает иметь собственные репозитории для своих продуктов под популярные дистрибутивы, как это делает раббит, графана, прометей и так далее.
Здравствуйте, Слава, Вы писали:
С>Да, это такой софт, который даже виртуалки не любит. Вроде freeswitch.
Я засунул. Даже свой докерфайл, из исходников собирается, на Alpine.
Хорошо работает на ~ 8 линий
В свою очередь, прошу конкретики. Что именно у тебя не запускается?
Чужие байки я и сам могу посмотреть, некоторые и шнурки завязать не могут. Но это же не значит, что они незавязываемы и это нужно переписывать как факт
Здравствуйте, Skorodum, Вы писали:
S>>Не вижу разницы между зависимостями и собственными либами. S>Разница между плагинами и бинарными зависимостями принципиальна: плагины опциональны и приложение может их искать по любым путям.
Значит /lib/mysupersoft/plugins например. Но не рядом с бинарником.
S>>rpath в любом случае грязный хак, делающий невозможным управление либами приложения S>Глупость. rpath добавляет новое место для поиска зависимостей, но не отменяет остальные. Это именно что стандартное решение.
В результате появляется приложение с нестандартным поведением, что плохо.
S>2. Для установки переменной надо либо глобально ее менять при установке приложения (ужос-ужос), либо использовать скрипт или для запуска (ужос).
Чем плох скрипт? Почему нет?
S>>>>2. /var/lib/libmysupersoftpluginsuperplugin.so S>>>1. Нет гарантии отсутсвия конфликтов. S>>Есть, если не называть либы именами типа libplugin.so или libextention.so S>Нет гарантии отсутсвия конфликтов.
История показывает что есть.
S>Ну или маны почитай и обрати внимание, когда LD_LIBRARY_PATH игнорируется.
Тем не менее рядом с бинарником никто либы не укладывает
S>>>Да хоть так, суть в том, что твой пакетный менеджер должен обновить /etc/ls.so.conf или что-то в этом духе. S>>Это проблема? S>В общем случае — нет, разговор про то, что менять глобальные переменные при установке приложения — очень плохая идея.
Зачем менять глобальные? Я такого не предлагал. В отдельных случаях можно конечно и поменять, особенно если сервант используется одним приложением, типа "сервер баз данных с ораклом на борту". Но в остальных случаях незачем.
S>>>Ну и проблема в пакетных менеджерах: кто будет заниматься их поддержкой? S>>Их разработчики. S>>А ты, как разработчик софта, выбери несколько дистрибутивов и автоматизируй сборку пакетов об тот же fpm S>Да делать больше нечего. Нормально собранное приложение и так прекрасно работает на всех целевых линухах. Единственное действие которое надо сделать пользователю — добавить права на выполнение.
Нечего делать приложению на конпутере, установленному мимо манагера пакетов.
S>>>Я, как разработчик, делаю AppImage, который работает везде без необходимости рутовых прав для установки. И совершенно пофиг на лишние мегабайты у пользователя из-за повторяющихся библиотек, зато количество головной боли во вселенной на порядки меньше. S>>Вот сейчас у меня настолько подгорело что я даже не знаю какие слова тут написать. S>>Бредовая идея. Бредовый софт. В линупсах так не делают. S>Т.е. разработчики обязаны поддерживать все пакетные менеджеры?
Не все, а два-три.
S>>>Дальше мантейнеры пакетных мендежеров могут устанавливать как угодно. А можно и без них, Win-Win. S>>нираспарсил... S>Да вроде все просто: если тебе надо, то возьми мое приложение и сделай пакет, чтобы что-то вроде S>
S>sudo apt install super-pupper
S>работало. Но оно прекрасно работает и без этого. Скачал и запустил.
fpm работает прекрасно. И как раз умеет в вышеописанные "два-три" пакетных манагера.
S>>>И весь более-менее сложный софт использует собственные установщики (тот же QtCreator), S>>Такого софта — единицы. S>Такого софта вагон и маленькая тележка, для любого софт который активно развивается такой подход будет предпочтительнее. S>Для утилит и программ которые "просто работают" и обновляются раз в 5 лет пакетные менеджеры лучше подходят.
Вагон и маленькая тележка на фоне Фудзиямы, да.
S>>>пакетные менеджеры отстают на пару лет обычно. S>>Поправочка: официальные репозитории отстают в силу необходимости соблюдения стабильности дистрибутива. S>>Тебе ничего не мешает иметь собственные репозитории для своих продуктов под популярные дистрибутивы, как это делает раббит, графана, прометей и так далее. S>Это какой-то птичий язык. Я использую программы QtCreator/Chrome/Steam/etc, я их беру с офф. сайта разраотчиков и все работает.
Всё это у меня прилетает об пакетный манагер. То что не-гентушники не осиливают содержать дистрибутив в чистоте — прямо говорит о радиусе кривизны их рук.
Здравствуйте, night beast, Вы писали:
NB>+ -Wl,-rpath=.
Кстати, в официальной документации для этого рекомендуется $ORIGIN, но я не смог найти чем оно лучше просто точки...?
Здравствуйте, Vetal_ca, Вы писали:
V_>В свою очередь, прошу конкретики. Что именно у тебя не запускается?
При достаточно большой нагрузке, в 50 линий и более, у людей иногда наблюдаются лаги и джиттер. Происходит это, видимо, от неравномерного распределения процессорного времени внутри виртуалки.
Здравствуйте, Sheridan, Вы писали:
S>Значит /lib/mysupersoft/plugins например. Но не рядом с бинарником.
Это кто сказал?
S>>Глупость. rpath добавляет новое место для поиска зависимостей, но не отменяет остальные. Это именно что стандартное решение. S>В результате появляется приложение с нестандартным поведением, что плохо.
Это стандартное решение последние лет 20. Посмотри.
S>>2. Для установки переменной надо либо глобально ее менять при установке приложения (ужос-ужос), либо использовать скрипт или для запуска (ужос). S>Чем плох скрипт? Почему нет?
Потому что это кривой костыль. Нормальное приложение работает и без него.
S>>Нет гарантии отсутсвия конфликтов. S>История показывает что есть.
да даже этот топик о конфликтах.
S>>Ну или маны почитай и обрати внимание, когда LD_LIBRARY_PATH игнорируется. S>Тем не менее рядом с бинарником никто либы не укладывает
А мужики-то не знают. Sheridan, ты походу в каком-то альтернативном мире.
S>Зачем менять глобальные? Я такого не предлагал.
Ты предлагал
использовать пакетный менеджер для изменения LD_LIBRARY_PATH. Вот так никто не делает. Это плохо.
S>Нечего делать приложению на конпутере, установленному мимо манагера пакетов.
Религия не позволяет? Ну ок
S>>Т.е. разработчики обязаны поддерживать все пакетные менеджеры? S>Не все, а два-три.
Да мне нисколько не надо. И моим пользователям не надо.
S>fpm работает прекрасно. И как раз умеет в вышеописанные "два-три" пакетных манагера.
Ну кому надо — тот и сделает. Это только у тебя религиозные ограничения на источники софта.
S>Вагон и маленькая тележка на фоне Фудзиямы, да.
Да как угодно. В IDE и браузере я провожу большую часть времени. Они для меня Фудзияма. И любой более-менее сложный софт с зависимостями будет "все свое таскать с собой".
Здравствуйте, Skorodum, Вы писали:
NB>>+ -Wl,-rpath=. S>Кстати, в официальной документации для этого рекомендуется $ORIGIN, но я не смог найти чем оно лучше просто точки...?
я точно не тот человек, который в этом сильно разбирается
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, Vetal_ca, Вы писали:
V_>>В свою очередь, прошу конкретики. Что именно у тебя не запускается?
С>При достаточно большой нагрузке, в 50 линий и более, у людей иногда наблюдаются лаги и джиттер. Происходит это, видимо, от неравномерного распределения процессорного времени внутри виртуалки.
Какая виртуалка, мы же о контейнерах говорим.
Далее, какая сеть (docker, host, ....)? Ядро? Clock resolution ядра? userland_proxy ? Используется ли jitter_buffer? Какие кодеки на обоих legs? Хватает ли ресурсов во время работы этих 50+ линий? Загружен ли сам хост где крутится виртуалка с докер-хостом (проблема "шумных" соседей)?
Я, когда отлаживался, использовал WiFi моего тогдашнего работодателя. Они там так "грамотно" сделали, 4 работодателя на один WiFi band свои сети посадили. Для VoIP это было потяжелее 2G
Там много компонентов. Лаги и джиттер у людей могут и без докера появиться, включая "последнюю милю", один из вариантов которой выше.
Здравствуйте, Sheridan, Вы писали:
S>Это религиозным виндузятникам, ходящим везде со своим уставом, это всё требуется когда они в линупс приходят. А потом начинается "виноваты все кроме я". Повзрослей уже.
То есть ответа на вопрос для чего в линуксе принято раскидывать какашки шедевральные части приложения по всему диску у тебя нет, ну кроме того, что это не так как принято у виндозятников значит хорошо и правильно.
Здравствуйте, Sheridan, Вы писали:
S> Для того чтобы не было длл-хелла, для того чтобы не пришлось править глобальные переменные окружения и так далее. S> Я же в свою очередь не понимаю — почему надо с собой тащить свои привычки. Я же не прихожу в винду и не говорю что надо всё делать по линуксячему. И ни один из линупсоидов такого не пишет и на это не обращает внимания. И лишь только виндузятники, приходя в линупс, начинают заниматься всякой ерундой вместо того чтобы почитать документацию и работать как там написано.
Здравствуйте, DenisCh, Вы писали:
S>> Для того чтобы не было длл-хелла, для того чтобы не пришлось править глобальные переменные окружения и так далее. S>> Я же в свою очередь не понимаю — почему надо с собой тащить свои привычки. Я же не прихожу в винду и не говорю что надо всё делать по линуксячему. И ни один из линупсоидов такого не пишет и на это не обращает внимания. И лишь только виндузятники, приходя в линупс, начинают заниматься всякой ерундой вместо того чтобы почитать документацию и работать как там написано. DC>Ага. Нифига не тянут.
Всё как вы любите — всё в одной папке. Не раскидано по всяким сисвов64. Что не так?
С>>Постгрес при обновлениях не ломается. Апач не ломается. И так далее, и так далее.
VC>Читай внимательнее — это не mssql проблема а не той версии openssl в системе был. в убунте их две. все твои постгресы с апачами не ломаются пока админ не сломает зависимости.
Проверка зависимостей — задача мейнтейнера, создающего пакет. Для apache, postgres и других пакетов мейнтейнеры пакетов это делают. Для mssql ты, похоже, предлагаешь сложить проверку зависимостей на пользователя...
Тогда уж и пакеты пусть пользователь сам создает...
Здравствуйте, Masterspline, Вы писали:
С>>>Постгрес при обновлениях не ломается. Апач не ломается. И так далее, и так далее.
VC>>Читай внимательнее — это не mssql проблема а не той версии openssl в системе был. в убунте их две. все твои постгресы с апачами не ломаются пока админ не сломает зависимости.
M>Проверка зависимостей — задача мейнтейнера, создающего пакет. Для apache, postgres и других пакетов мейнтейнеры пакетов это делают. Для mssql ты, похоже, предлагаешь сложить проверку зависимостей на пользователя...
M>Тогда уж и пакеты пусть пользователь сам создает...
Я написал про то что и дал официальную ссылку на поддержку только xenial — нехрен неродные репы подключать да еще и без тестирования, что бы потом не жаловаться на мейнтейнеров.
У тебя таже проблема что и у автора — невнимательно прочитал/написал.
Ну и тестировать надо перед обновлениями — на это тоже все указали.
С>>>>Постгрес при обновлениях не ломается. Апач не ломается. И так далее, и так далее.
VC>>>Читай внимательнее — это не mssql проблема а не той версии openssl в системе был. в убунте их две. все твои постгресы с апачами не ломаются пока админ не сломает зависимости.
M>>Проверка зависимостей — задача мейнтейнера, создающего пакет. Для apache, postgres и других пакетов мейнтейнеры пакетов это делают. Для mssql ты, похоже, предлагаешь сложить проверку зависимостей на пользователя...
M>>Тогда уж и пакеты пусть пользователь сам создает...
VC>Я написал про то что и дал официальную ссылку на поддержку только xenial — нехрен неродные репы подключать да еще и без тестирования, что бы потом не жаловаться на мейнтейнеров.
VC>У тебя таже проблема что и у автора — невнимательно прочитал/написал. VC>Ну и тестировать надо перед обновлениями — на это тоже все указали.
Во-первых, ты ничего не писал ни про xenial, ни про неродные репы, по-крайней мере до того сообщения, на которое я отвечал. Во-вторых, если в пакете правильно прописаны зависимости, то он с другим OpenSSL просто не установится (без флага "игнорировать зависимости" в apt). Так что проблема тут у тебя, как минимум в том, что твои объяснения ничего не объясняют. Но ты можешь продолжать считать, что я что-то не правильно прочитал...
Итого: либо автор отключил установку зависимостей при установке, либо пакет mssql мейнтейнерами собран с неправильно прописанными зависимостями.
Ну, а что касается тестирования, то я очень сомневаюсь, что в нормальном дистрибутиве при обновлении того же postgres при автоматическом обновлении базы не останется ее предыдущая копия (т.е. чтобы откатиться назад, нужно лишь вернуть предыдущую версию СУБД). Если мейнтейнеры mssql позволяют себе автоматически при обновлении угробить данные и переводить стрелки на то, что надо было тестировать и делать бакап — то опять же это больше говорит об их квалификации.
Здравствуйте, Sheridan, Вы писали:
S>Ну да, ща вы мне начнете рассказывать про разные версии, про разные дистрибутивы... Я одно только спрошу: почему разработчики софта линупсячего осиливают тогда поддержку своего софта под кучу дистрибутивов? В чём разница? В усидчивости? В IQ? В руках?
Нет, не осиливают. Если не верите — проверте какая у вас версия gcc.
Здравствуйте, B0FEE664, Вы писали:
S>>Ну да, ща вы мне начнете рассказывать про разные версии, про разные дистрибутивы... Я одно только спрошу: почему разработчики софта линупсячего осиливают тогда поддержку своего софта под кучу дистрибутивов? В чём разница? В усидчивости? В IQ? В руках? BFE>Нет, не осиливают. Если не верите — проверте какая у вас версия gcc.
Здравствуйте, Anton Batenev, Вы писали:
S>> Что я должен тут увидеть? AB>Всенепременно 9.2 жеж — только в этой версии есть минимально необходимый набор фитч при котором можно хоть как-то существовать.
Как до этого жили и умудрились линупс напилить так, что микрософт стала его в себя встраивать — непонятно.
Здравствуйте, Mamut, Вы писали:
M>Какое отношение майкрософт имеет к разговору о том, осиливают разрабочики линуксового софта поддержку разных дистрибутивов? А никакое.
Да я давно уже понял что ты категорически исключительно прямолинеен и неспособен думать над текстом.
Код, Мамут, в проектах. На форумах — разговор.
M>>Какое отношение майкрософт имеет к разговору о том, осиливают разрабочики линуксового софта поддержку разных дистрибутивов? А никакое. S>Да я давно уже понял что ты категорически исключительно прямолинеен и неспособен думать над текстом.
Тут не надо быть прямолинейным, чтобы увидеть, что ты, как всегда, увел разговор в сторону.