Еще одно самое окончательное решение проблемы Dependency hell/Dependecy Convergence

где ответ на мой вопрос насчёт хэшей? А?

Еще раз, проблема возникает только если у тебя кусок данных, произведенный C1 протекает в приложение и из него через B - в C2. Такую проблему мой подход не решит сам по себе - но он не решается и при текущем состоянии дел.

Еще раз, речь идет о КОДЕ, а не о структурах данных. Я предлагаю решение проблемы конвергенции КОДА.

Хэш подставляется при СВЯЗЫВАНИИ программы X с библиотекой Y, указывается в точке вызова F.

Как я уже сказал - нужны изменения в компиляторе (или постпроцессор), нужно особое уличное системное апи и загрузчик на смену dlopen и текущим загрузчикам.

WinSxS изобретаешь?

не уверен, что я быстро найду, я с Erlang достаточно поверхностно знакомился и как раз в момент этого знакомства шум по поводу такого решения был. Если найду - то скину ссылку, но не обещаю.

Еще раз, нет. WinSxS - это половинчатое решение. И я про него упоминал.

Также отмечу, что для той же жабы даже аналогов SxS нет.

значит, чтобы скачать и запустить у себя программу X, я должен буду ещё скачать сборку библиотеки Y с подходящим хэшем, самостоятельно собрать Y у меня не выйдет, ибо хэш от F получится другой

у жабы нет такого понятия как библиотека и связывание идет на уровне .class файлов

и будет у меня для каждой из 100500 установленных программ 100500 сборок функций F, каждая со своим хэшем

мне лень задумываться, но не приведет ли это к аналогу версий?

Да. Поэтому - коммунизм и репозитории а-ля мавен. Например, у поставщика программы. Также никто не отменяет возможности предоставить все зависимости вместе с программой в виде толстого пакета.

ну и чем это всё тогда лучше обычной статической линковки?

Ой, и чё? А в POMке ты тоже классы указываешь?

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

Также не забываем про яву и конвергенцию зависимостей в ней.

Да, и это единственный способ не напороться на конвергенцию.

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

но при этом все преимущества динамического связывания теряются, а оверхед возрастает. В чём профит?

Экономии места на харде нет, независимого обновления библиотек нет. Если в функции F нашли уязвимость, юзер должен ждать, пока автор каждой из 100500 программ, дергающих F, скомпилирует новую версию F c исправлением и перекомпилирует программу, чтобы обновить хэш

В разных jar'никах могут лежать одинаковые классы с чуть-чуть разным API вот это hell похлеще чем dll-hell :) Я так как-то полдня убил, разбираясь почему в playframework логгирование не работает. Оказалось, что с какой-то из зависимых библиотек прилетает другой класс логгера с чуть-чуть другим API и play не мог его заюзать :)

Это и называется «конвергенция», мать твою. И я предлагаю ее решение.

В текущей ситуации у тебя все то же самое, т.к. половина софта связана статически, а еще 40% держат зависимости рядом с собой.

Профит - в том, что этот подход лишен некоторых недостатков динамического связывания и сам по себе не привносит новых. За исключением оверхеда. Зато, например, можно организовать инкрементальную дистрибуцию ПО.

Экономии места на харде нет,

Очевидно есть. Т.к. каждая шляпа не будет тащить с собой libQt4*.so, коэффициент переиспользования возрастет - и существенно.

в моей генточке libQt4.so вполне себе в единственном экземпляре лежит :)

А в моей генточке - в нескольких, поскольку у меня есть скайп, p4merge и еще кучка проприетарного софта.

Я у себя на бложике набросал пост на эту тему.

вместо хеша лучше использовать подпись.

Например есть XYZ, и всё хорошо. Когда выходит новая версия (именно ВЕРСИЯ, а не тоже самое но не то, вроде питона3), ты просто подписываешь её. И потому твой пакетный менеджер принимает без проблем новую XYZ.

Это не решение «dependency hell». Твоё решение просто позволяет сделать так, чтобы вся эта свалка из разных версий работала, а сам по себе «dependency hell» никуда не пропадает.

Ну, да, именно. Хотя бы чтобы работало.

Понимаешь, такое возможно только в идеальном мире. Только не всегда автор библиотеки понимает, что небольшим фиксом сломал нахрен половину зависимого кода.

Понимаешь, такое возможно только в идеальном мире.

понимаешь, твоё решение вообще _в_ _принципе_ не работоспособно. Если у меня Over9000 программ, и каждая тянет Over9000 зависимостей, то очевидно надо Over9000×Over9000 библиотек. Это невозможно. Ну хотя-бы тупо негде хранить. Некуда загружать. Но даже если у нас и будет Over9000Gb RAM, всё равно нет времени _искать_. Каждое окошко будет открываться полчаса на квантовом компьютере.

Да и не нужно это, ибо сам смысл shared lib исчезает. Библиотеки никто не будет разделять, ибо они все разные.

Давай уж тогда статически ВСЁ слинкуем, если уж так надо. Это проще, и ничем не хуже твоего варианта.

Ты, по-моему, или прикидываешься, или у тебя нейронов 30% от среднестатистического количества.

Наоборот, для хранения рантайма, в котором единицей является не библиотека, а метод/класс, требуется МЕНЬШЕ места, чем когда у тебя каждая софтина тащит все рантаймы с собой (SxS, 99% проприетарных софтин под линукс, 100% жабьих софтин).

Да, мой подход делает бессмысленным shared libraries, поскольку вместо них получаются shared routines и shared classes.

Также, возможно, он делает бессмысленными исполняемые файлы, поскольку нужен только дескриптор точки входа. Все остальное - укладывается в системное хранилище кода.

Давай уж тогда статически ВСЁ слинкуем,

Идиотизм на марше. Жабу ты статически не слинкуешь, лолка.

Ты, по-моему, или прикидываешься, или у тебя нейронов 30% от среднестатистического количества.

просто не все здесь жабокодеры. Лично мне непонятно, каким образом можно отделить метод от класса. Расскажешь?

Или твой способ только для жабокода работает?

Жабу ты статически не слинкуешь, лолка.

а мне и не нужно. Нет у меня жабакода.

это всё от того, что пакетный менеджер не используют, он бы разруливал зависимости

а он их в таком случае разруливает шикарно — просто не даёт установить пакет

Лично мне непонятно, каким образом можно отделить метод от класса.

В нативном коде нет классов, не поверишь.

Или твой способ только для жабокода работает?

Для пролетариата: в случае жабы - на уровне классов, в случае нативного кода - на уровне методов. Единственный момент - конвенцию именования я бы стандартизировал.

объясни пролетарию: что такое «метод» на нативном уровне? Каким образом их вообще вытаскивать из нативного кода, дабы считать их хеш? Что делать с зависимостями метода(они, внезапно, называются «классом» в C++. Т.е. класс — это совокупность зависимых методов. Потому не очень понятно, что значит твоё «нет»?)

Метод на нативном уровне - это просто функция с длинным сложным именем. Кусок кода. Независимый, вообще говоря. Он ожидает, что на стэке будут все аргументы, первым - указатель на экземпляр класса.

Хотя я предлагаю не раздербанивать готовые бинари, а генерировать новые, в другом формате. И конвенцию именования тоже поправить.

Кусок кода. Независимый, вообще говоря.

это не тебе решать. IRL он зависимый, и ты с этим ничего не сделаешь.

Хотя я предлагаю не раздербанивать готовые бинари, а генерировать новые, в другом формате.

ну сделай gcc с линкером новые.

И конвенцию именования тоже поправить.

и русский язык тоже за одно. Чтоб все слова были из 5и букв.

IRL он зависимый, и ты с этим ничего не сделаешь.

Фейспальм.жпг... Человек не представляет, из чего состоят объектники.

ну сделай gcc с линкером новые.

Я думал сделать бэкенд к ллвм, но заинтересованных нет.

Чтоб все слова были из 5и букв.

Ты, пролетарий, хоть раз видел, какие имена у методов в нативном коде C++ный конопелятор нагенеривает? Знаешь, почему нежелательно начинать имя сущности с «_»? В курсе о том, что конвенция именования у каждого компилятора своя?

Каждая свинья лезет про апельсины порассуждать.

Человек не представляет, из чего состоят объектники.

это ты не представляешь. Не видишь наверное никаких зависимостей. А они есть, и их много.

Я думал сделать бэкенд к ллвм, но заинтересованных нет.

про ллвм я не в курсе. Может и можно. Про gcc: это деление на ноль.

Ты, пролетарий, хоть раз видел, какие имена у методов в нативном коде C++ный конопелятор нагенеривает?

в том-то и дело, что я пролетарий, а не теоретик. И как пролетарий тебе заявляю: никаких имён в коде нет. Там только адреса. А имена все стрипаются, чтоб не мешали. Да и нужны они исключительно для облегчения отладки.

Каждая свинья лезет про апельсины порассуждать.

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

Сцукодебил. Конечно-конечно, в таблицах экспорта нет никаких имен, одни адреса.

Тебе не повезло и версии C несовместимы либо по интерфейсам, либо по поведению.

Ну, у меня много говнокода, который хочет одновременно libusb-0.1.14 и libusb-1. Никто не умер, в чем проблема?

Впрочем, при нормальном подходе к версионированию библиотек, такого дерьма вообще не должно возникать

Dependency hell

На винфааак!

Еще один. Проблема имеет место быть везде, где есть версионирование.

К сожалению, нормальный подход возможен только в идеальном мире.

Никто не умер, в чем проблема?

Погугли про конвергенцию зависимостей, про SxS

К сожалению, нормальный подход возможен только в идеальном мире.

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

В реальном мире проблема уязвимостей в распространяемых вместе с приложением рантаймах точно так же не решается.

При моем подходе в случае введения псевдонимов решение будет даже более простым.

в распространяемых вместе с приложением рантаймах

Будто бы проблема версионирования актуальна для распространяемых вместе с приложением рантаймов

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

Также - в жабе проблема конвергенции - предельно актуальна, по треду выше был уже один пострадавший.

Будто бы с динамическим связыванием «дедупликация» не работает. К тому же динамическое связывание это не только дедупликация, да и за счет всякой ереси типа конструкторов, tbss и прочего функциональность динамически связываемых объектов имеет несколько более широкие очертания.

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

А что до джавы, там эта проблема пожалуй действительно актуальна