Здравствуйте, 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>Зачем менять глобальные? Я такого не предлагал.
Ты предлагал

Автор: Sheridan
Дата: 13.08.19

использовать пакетный менеджер для изменения LD_LIBRARY_PATH. Вот так никто не делает. Это плохо.

S>Нечего делать приложению на конпутере, установленному мимо манагера пакетов.
Религия не позволяет? Ну ок

S>>Т.е. разработчики обязаны поддерживать все пакетные менеджеры?
S>Не все, а два-три.
Да мне нисколько не надо. И моим пользователям не надо.

S>fpm работает прекрасно. И как раз умеет в вышеописанные "два-три" пакетных манагера.
Ну кому надо — тот и сделает. Это только у тебя религиозные ограничения на источники софта.

S>Вагон и маленькая тележка на фоне Фудзиямы, да.
Да как угодно. В IDE и браузере я провожу большую часть времени. Они для меня Фудзияма. И любой более-менее сложный софт с зависимостями будет "все свое таскать с собой".

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

NB>>+ -Wl,-rpath=.
S>Кстати, в официальной документации для этого рекомендуется $ORIGIN, но я не смог найти чем оно лучше просто точки...?

я точно не тот человек, который в этом сильно разбирается

Здравствуйте, 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>Ты предлагал

Автор: Sheridan
Дата: 13.08.19

использовать пакетный менеджер для изменения LD_LIBRARY_PATH. Вот так никто не делает. Это плохо.
Там прямо так и написано: "используёте пакетный манагер и глобально меняйте LD_LIBRARY_PATH"?
Там прямо написано: устанавливайте всё в стандартные пути. То есть исполняемое в bin, либы в lib и так далее.
LD_LIBRARY_PATH там упоминается как переменная окружения, выставленная для конкретно твоего приложения. Это же очевидно.

S>>Нечего делать приложению на конпутере, установленному мимо манагера пакетов.
S>Религия не позволяет? Ну ок
Не религия. Терпеть не могу когда приходят в чужой монастырь со своим уставом.


S>>>Т.е. разработчики обязаны поддерживать все пакетные менеджеры?
S>>Не все, а два-три.
S>Да мне нисколько не надо. И моим пользователям не надо.
И поэтому ты изобрёл свой пакетный манагер? Может стоит изучить как работают другие? Ни один луноход свой софт на пушечный выстрел не подпустит к конпутеру.

S>>fpm работает прекрасно. И как раз умеет в вышеописанные "два-три" пакетных манагера.
S>Ну кому надо — тот и сделает. Это только у тебя религиозные ограничения на источники софта.
Тебе надо. Но ты пошёл по более трудному пути: ты сразу начал писать свой пакетный манагер. Времени не жалко?

S>>Вагон и маленькая тележка на фоне Фудзиямы, да.
S>Да как угодно. В IDE и браузере я провожу большую часть времени. Они для меня Фудзияма. И любой более-менее сложный софт с зависимостями будет "все свое таскать с собой".
В виндах — да. В линупсах такого софта единицы.

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

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

V_>>В свою очередь, прошу конкретики. Что именно у тебя не запускается?

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

Какая виртуалка, мы же о контейнерах говорим.

Далее, какая сеть (docker, host, ....)? Ядро? Clock resolution ядра? userland_proxy ? Используется ли jitter_buffer? Какие кодеки на обоих legs? Хватает ли ресурсов во время работы этих 50+ линий? Загружен ли сам хост где крутится виртуалка с докер-хостом (проблема "шумных" соседей)?

Я, когда отлаживался, использовал WiFi моего тогдашнего работодателя. Они там так "грамотно" сделали, 4 работодателя на один WiFi band свои сети посадили. Для VoIP это было потяжелее 2G

Там много компонентов. Лаги и джиттер у людей могут и без докера появиться, включая "последнюю милю", один из вариантов которой выше.

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

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


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

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

там чувак в ответе написал, что заново устанавливал на 18

добавлю-все крутится на убунте 16

решил пойти до конца, и получил новый сюрприз
поставил mssql на чистую убунту 16, использовал эту репу https://packages.microsoft.com/config/ubuntu/16.04/mssql-server-2017.list
при этом установилась версия 2019, и нормально заработало, sqlcmd подключилась

на убунту 18 предсказуемо не заработало-сиквел работает, но нельзя подключиться

Здравствуйте, 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>В виндах — да. В линупсах такого софта единицы.
Да факт-то простой: любой более-менее сложный и развивающийся софт будет все бинари таскать с собой. Пакетные менеджеры тут не причем.

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

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

S>>Загляни в любой дистрибутив из популярных и посмотри как и куда устанавливается подавляющее большинство софта.
S>Ну так посмотри: плагины всегда устанавлваются относительно исполняемого файла, т.к. он должен знать путь.
Ты думаешь что если путь установится абсолютны то чтото поменяется?

S>>>Это стандартное решение последние лет 20. Посмотри.
S>>Не путай мягкое с тёплым. Это как раз явное указание стандартных путей.
S>Нет. Сделай одолжение, посмотри код (и попытайся понять).
S>Можешь установить и посмотреть где плагины будут.

pkglibdir=${libdir}/@PACKAGE@
pluginsdir=${pkglibdir}/plugins
...
codecdir = $(pluginsdir)/codec
...
... -rpath '$(codecdir)'

О чём я и говорил. Модули-плагины не рядом с бинарником, а в /usr/lib/mysupersoft

spc ~ # ls -la /usr/lib64/vlc/plugins/codec
итого 1164
drwxr-xr-x  2 root root  4096 авг  2 17:06 .
drwxr-xr-x 30 root root  4096 авг  2 17:06 ..
-rwxr-xr-x  1 root root 18344 авг  2 17:06 libadpcm_plugin.so
-rwxr-xr-x  1 root root 14232 авг  2 17:06 libaes3_plugin.so

Заканчивай уже выдумывать, короче.

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>Да факт-то простой: любой более-менее сложный и развивающийся софт будет все бинари таскать с собой. Пакетные менеджеры тут не причем.
Стоп. Какие такие бинари? Библиотеки, от которых он зависит? Так не делают в линухах. В линухах указывают зависимость и пакетный манагер дальше сам разбирается.

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

S>Тем не менее рядом с бинарником никто либы не укладывает
И какие для этого причины, кроме религиозных соображений?

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

S>>Тем не менее рядом с бинарником никто либы не укладывает
P>И какие для этого причины, кроме религиозных соображений?

Это затрудняет работу специалистам, которые должны потом этот ваш мегасофт обкладывать подпорками чтобы оно работало. Деплоить мимо стандартных путей, обеспечивать правильный запуск из командной строки (как минимум править глобальный PATH), выставлять права и так далее.

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

S>Это затрудняет работу специалистам, которые должны потом этот ваш мегасофт обкладывать подпорками чтобы оно работало.
То есть не религиозные причины, а исторические — когда система задумывалась самой сложной программой в ей была утилитка по обработке текстового файла и в тех условиях выбранная схема выглядела красиво.

S>Деплоить мимо стандартных путей, обеспечивать правильный запуск из командной строки (как минимум править глобальный PATH), выставлять права и так далее.
А сейчас приходится городить костыль на костыле чтобы это работало, соорудить систему поддерживать которую может только пакетный менеджер, обложиться кучей правил и условий за выход за которые нужно грозить расстрелом и содержать этих самых специалистов чтобы разрешать и предвидеть возможные конфликты.

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

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

Это религиозным виндузятникам, ходящим везде со своим уставом, это всё требуется когда они в линупс приходят. А потом начинается "виноваты все кроме я". Повзрослей уже.

S>А потом начинается "виноваты все кроме я". Повзрослей уже.

Говорит нам человек, у которого «виноваты все кроме я» является единственным modus operandi уже больше 15 лет.

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

S>Это религиозным виндузятникам, ходящим везде со своим уставом, это всё требуется когда они в линупс приходят. А потом начинается "виноваты все кроме я". Повзрослей уже.
То есть ответа на вопрос для чего в линуксе принято раскидывать какашки шедевральные части приложения по всему диску у тебя нет, ну кроме того, что это не так как принято у виндозятников значит хорошо и правильно.

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

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

Предпочитаю собирать из исходников в двухстадийном docker image.

Все, до это собранные images доступны по первому требованию безо всяких зависимостей и безотносительно к версии Линукс. Главное, tags правильные.

И безо всякой предыстории типа "Это работало на моей машине"

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

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

S>>Это религиозным виндузятникам, ходящим везде со своим уставом, это всё требуется когда они в линупс приходят. А потом начинается "виноваты все кроме я". Повзрослей уже.
P>То есть ответа на вопрос для чего в линуксе принято раскидывать какашки шедевральные части приложения по всему диску у тебя нет, ну кроме того, что это не так как принято у виндозятников значит хорошо и правильно.
Для того чтобы не было длл-хелла, для того чтобы не пришлось править глобальные переменные окружения и так далее.
Я же в свою очередь не понимаю — почему надо с собой тащить свои привычки. Я же не прихожу в винду и не говорю что надо всё делать по линуксячему. И ни один из линупсоидов такого не пишет и на это не обращает внимания. И лишь только виндузятники, приходя в линупс, начинают заниматься всякой ерундой вместо того чтобы почитать документацию и работать как там написано.
Почему только у виндузятников возникают такие проблемы, м? Не пробовал подумать?

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

S> Для того чтобы не было длл-хелла, для того чтобы не пришлось править глобальные переменные окружения и так далее.
S> Я же в свою очередь не понимаю — почему надо с собой тащить свои привычки. Я же не прихожу в винду и не говорю что надо всё делать по линуксячему. И ни один из линупсоидов такого не пишет и на это не обращает внимания. И лишь только виндузятники, приходя в линупс, начинают заниматься всякой ерундой вместо того чтобы почитать документацию и работать как там написано.

Ага. Нифига не тянут.

Содержимое папки D:\Git

25.01.2019 17:47 <DIR> .
25.01.2019 17:47 <DIR> ..
25.01.2019 16:23 <DIR> bin
25.01.2019 16:23 <DIR> cmd
25.01.2019 16:23 <DIR> dev
25.01.2019 16:23 <DIR> etc
15.12.2018 09:52 149 272 git-bash.exe
15.12.2018 09:52 148 760 git-cmd.exe
12.03.2018 17:58 18 765 LICENSE.txt
25.01.2019 16:23 <DIR> mingw64
15.12.2018 10:14 141 866 ReleaseNotes.html
25.01.2019 16:23 <DIR> tmp
25.01.2019 16:23 960 002 unins000.dat
25.01.2019 16:16 1 297 048 unins000.exe
25.01.2019 16:23 22 795 unins000.msg
25.01.2019 16:23 <DIR> usr