Разруливать dependency hell методом тыка так себе идея.
Если у вас ровно одна либа и ровно одно приложение - это разумно. если 100500 приложений требуют эту либу - как вы убедитесь, что глобальная замена версии не сломала ничего в 100499 приложениях? Если учить каждое приложение отдельно работать с указанной либой - это нужно придумывать очень хитрый загрузчик. Не то чтобы это выглядело невозможным.. Но appimage проще ;)
До сих пор продают металл, а покупают сделанные из него механизмы.
Какое то время это работает. Но механизмы дорогие, а металл не очень. Из металла на 100 баксов сделают бус и зеркал на 1000. На 100 баксов продадут - куда девать лишних изделий на 900?
две версии библиотеки из официальной репы, но к примеру, одну из текущей версии Дебиана, а другую из предыдущей версии.
Странное пожелание. Зачем это может пригодиться? И как указывать приложениям, где какую библиотеку искать? Запилить то можно. но как потом управлять этим?
Можно и так ;) Но функций str* много, и от nullptr они падают (strlen - падает). Если вдруг внутри этих функций появится код с дополнительными проверками - существующие программы этого не заметят, в них уже есть эти проверки. А новым программам придется учитывать, что функции из libc работают иначе, и наворачивать проверки после вызова функций.
На фото - не фото ;) Я chatgpt, я так вижу беспилотный автомобиль, правым колесом стремительно мчащий назад, а левым неподвижно стоящий в луже с нулевой глубиной ;)
Да, про стиралку и сварной бак. Бак в цеху сваривается за несколько секунд, соединение абсолютно герметичное. Герметик в разрезанном баке схватывается сутки. Ну и неплохо потом проконтроллировать герметичность шва. Вот и весь секрет неразьемных баков. Никто не будет строить конвеер длиной в сутки.
Ну то есть авторы либы приложили определенных усилий. И сделали свой менеджер зависимостей. И не позаботились подружить его с buildroot. А виноват Столман, Торвальдс и БГ.
Так значит source-based дистрибутивы всё таки подвержены такой проблеме?
/dev/hands
Для того, чтобы слинковать софтину с libfoo.1.0, а положить в архив libfoo_2.0 - нужно чтобы эти 2 либы существовали одновременно, для начала. clean build штоли.
Недавно с коллегой повеселились из-за того, что наше ПО собиралось, но в рантайме требовало версию одной библиотеки, сильно отличную от того, что попадало в target file system
Если кто-то вдруг сделает libc, в котором, например, станет возможно передавать nullptr в str* - нужно заодно переписать все API (strlen(null) - что должна вернуть? 0? -1 (нельзя, это же size_t)). И код, работающий с новым API, будет полностью несовместим со старым. Та еще бомба получится.
Разруливать dependency hell методом тыка так себе идея.
Если у вас ровно одна либа и ровно одно приложение - это разумно. если 100500 приложений требуют эту либу - как вы убедитесь, что глобальная замена версии не сломала ничего в 100499 приложениях? Если учить каждое приложение отдельно работать с указанной либой - это нужно придумывать очень хитрый загрузчик. Не то чтобы это выглядело невозможным.. Но appimage проще ;)
Какое то время это работает. Но механизмы дорогие, а металл не очень. Из металла на 100 баксов сделают бус и зеркал на 1000. На 100 баксов продадут - куда девать лишних изделий на 900?
Странное пожелание. Зачем это может пригодиться? И как указывать приложениям, где какую библиотеку искать?
Запилить то можно. но как потом управлять этим?
В мобильной связи нет жесткого регулирования? Правда?
Если у них денег мало - из них плохие покупатели.
Можно и так ;) Но функций str* много, и от nullptr они падают (strlen - падает). Если вдруг внутри этих функций появится код с дополнительными проверками - существующие программы этого не заметят, в них уже есть эти проверки. А новым программам придется учитывать, что функции из libc работают иначе, и наворачивать проверки после вызова функций.
Сбыт за деньги, да? А где менее прогрессивные страны берут деньги? Что они производят и куда продают? Ресурсы они не бесконечные.
Или за кредиты, которые потом можно обнулить? Так это тот самый БОД на межгосударственном уровне - заплатить, чтобы все осталось как и было.
На фото - не фото ;)
Я chatgpt, я так вижу беспилотный автомобиль, правым колесом стремительно мчащий назад, а левым неподвижно стоящий в луже с нулевой глубиной ;)
Автозапуск без обратной связи как то страшновато. А при наличии двусторонней связи чего угодно можно наворотить.
Да, про стиралку и сварной бак. Бак в цеху сваривается за несколько секунд, соединение абсолютно герметичное. Герметик в разрезанном баке схватывается сутки. Ну и неплохо потом проконтроллировать герметичность шва. Вот и весь секрет неразьемных баков. Никто не будет строить конвеер длиной в сутки.
А зачем для бесконтактного ключа такая дальность?
Диаметр Земли уже был измерен же?
Ну то есть авторы либы приложили определенных усилий. И сделали свой менеджер зависимостей. И не позаботились подружить его с buildroot. А виноват Столман, Торвальдс и БГ.
Сдаете в гарантийный ремонт.
Нет. Заливают герметиком. Через 5 лет, когда подшипники еще раз издохнут, можно разрезать ножом.
find /usr/lib -name libEGL.so
/usr/lib/slack/libEGL.so
/usr/lib/x86_64-linux-gnu/libEGL.so
find /usr/share/ -name libEGL.so
/usr/share/skypeforlinux/libEGL.so
/usr/share/discord/libEGL.so
/usr/share/discord/swiftshader/libEGL.so
/usr/share/code/libEGL.so
/usr/share/gitkraken/libEGL.so
/usr/share/gitkraken/swiftshader/libEGL.so
Ну да, ну да.. ;) Каждый притащил свою копию. Ну и ладно.
/dev/hands
Для того, чтобы слинковать софтину с libfoo.1.0, а положить в архив libfoo_2.0 - нужно чтобы эти 2 либы существовали одновременно, для начала. clean build штоли.
buildroot нужно уметь готовить.
В результате ни вариатора ни Москвича. Зато Ваз 2107 производился до 2012 года.
хочет поиметь с нас
бабоклайков и просмотров. Это почти как бабки, только лучше ;)Если кто-то вдруг сделает libc, в котором, например, станет возможно передавать nullptr в str* - нужно заодно переписать все API (strlen(null) - что должна вернуть? 0? -1 (нельзя, это же size_t)). И код, работающий с новым API, будет полностью несовместим со старым. Та еще бомба получится.