В общем что если директории в переменой PATH сделать по принципу
$dir_path/$packet_prog_name/bin
и
$dir_path/$packet_prog_name/bin
и переписать линковщик ядра чтобы он при поиске бинарников и библиотек их обходил по шаблону:
$dir_path/*/bin
Начиная с конкретной директории $packet_prog_name из которой был запущен ищущий библиотеки процесс.
Ну или если программа указала конкретный $packet_prog_name для поиска бинарника или библиотеки.
Можно сделать так:
$dir_path/$packet_prog_name/$version/bin
version берётся из полного пути к запускаемому бинарнику.
То есть запустил бинарник из version то линковщик автоматом и будет искать библиотеки в version.
Но тогда надо чтобы ядро всегда помнила полный путь к основному бинарнику процесса.
Но по уму бинарник просто должен предъявлять компоновщику ядра требования к версии библиотеки.
А NixOS это по-твоему что - Windows??? Это и есть линукс.
Ну хорошо, нужно так пакеты ставить на вашей бубунте - ставим Nix на убунту или на любой другой дистрибутив. Он же как флатпак, кроссдистрибутивно работает. В чем суть изобретения велосипеда?
Флатпак в принципе норм, но на мой взгляд переусложнён, плюс у него есть крупный недостаток - файлы программы лежат не в ~/.config и ~/.local, а вместе с программой хер пойми где. И бывает что настройки прог из флатпака не соответствуют общесистемным (шрифты бывают полное говно)
файлы программы лежат не в ~/.config и ~/.local, а вместе с программой хер пойми где
Нууу не совсем так. Во-первых людям, которые читали доки известно где. Во-вторых это еще от программы зависит, у многих программ они и лежат где обычно. И это еще хуже, так как создается каша.
Я бы не относил это к крупным недостаткам, у него есть недостатки намного крупнее.
И бывает что настройки прог из флатпака не соответствуют общесистемным
У флатпака, как и у всего подобного, философия такая - приложение должно использовать только свой собственный набор библиотек, независимо от системы и всех других приложений.
Вопрос в том, как это достигается. У флатпака это достигается помещением в “контейнер” где доступны только свои библиотеки. и приложению некуда деваться, оно использует именно их. Но это же решение и порождает кучу проблем - приложение оказывается в полной изоляции. А потом эту изоляцию героически преодолевают порталами.
У Nix это решается совсем по другому - в каждый бинарник прописываются пути к “своим” пакетам, и приложение подхватывает библиотеки именно из них. И при этом не нужен никакой контейнер, приложения точно так же видят друг друга и всю систему как и в обычном линуксе.
Хотя технически это сделать не проблема - просто поменять в нужных бинарниках пути на новые. Но это ломает всю систему повторяемой сборки, версионирования пакетов в Nix, то есть бессмысленно в рамках этой системы.
Надо чтобы бинарник именно предъявлял требования, а линковщик сам подбирал наиболее подходящие под них библиотеки
А смысл? Зачем это нужно?
Так и делается в обычном линуксе. Проблем порождает больше чем решает.
Подходящие библиотеки - это те, с которыми приложение было собрано, а в идеале - с которыми оно тестировалось разработчиком. Подменять их совсем не нужно.
Я понимаю так, @cvs-255 хочет чтобы в системе штатным образом стояли старая и новая версии программы скомпилированные в разное время у которых одна и таже библиотека с одним и тем же названием бы имела совершенно разные свойства.
То что я предложил это решает, но требует переработки ядра.
Я понимаю так, @cvs-255 хочет чтобы в системе штатным образом стояли программы скомпилированные в разное время у которых одна и таже библиотека с одним и тем же названием бы имела совершенно разные свойства.
NixOS. Всё.
И без переработки ядра. Зачем велосипед изобретаете?
Приведу аналогию. Проекты автомобильных автопилотов существуют уже несколько десятилетий, но взлетела эта тема только с появлением достаточно мощных нейросетей. Почему? Да потому что все прежние автопилоты требовали специально оборудованных дорог, а это нахер никому не упало - переделывать все дороги под эти распрекрасные машины с автопилотами. Тогда как нейросетка нормально справляется с самыми обычными дорогами, даже с просёлочными. Потому и взлетело, наконец.
Вот так и тут. Есть мегатонны софта, в том числе и старого. Хорошая система должна давать ему рабочее окружение без лишних движений. В идеале можно будет взять какой-нибудь deb-пакет приложухи, которая уже 15 лет не обновлялась, кинуть в систему - и она обеспечит этому пакету всё нужное для работы. А когда все эти мегатонны софта нужно пересобирать/патчить под распрекрасный дистрибутив - это тупак полнейший. Никто этим заниматься не будет, кроме кучки энтузиастов и мантейнеров, а все минусы привязки к мантейнерам мы уже давно видим.
Если ты придерживаешься позиции “я лучше знаю что нужно пользователям”, то пожалуйста, все эти Никсосы и большая часть Линуксов - именно про это. А я вот считаю, что пользователи сами разберутся, и что задача операционки - не ограничивать их.
Но может тогда действительно достаточно стартового скрипта который задаст индивидуальные пути к бинарникам и библиотекам для одного единственного старого приложения?
В общем что если директории в переменой PATH сделать по принципу
$dir_path/$packet_prog_name/bin
и
$dir_path/$packet_prog_name/bin
и переписать линковщик ядра чтобы он при поиске бинарников и библиотек их обходил по шаблону:
$dir_path/*/bin
Начиная с конкретной директории $packet_prog_name из которой был запущен ищущий библиотеки процесс.
Ну или если программа указала конкретный $packet_prog_name для поиска бинарника или библиотеки.
@cvs-255 твоё мнение о посте выше?
ну да, это один из вариантов. Только еще версионирование итд
Можно сделать так:
$dir_path/$packet_prog_name/$version/bin
version берётся из полного пути к запускаемому бинарнику.
То есть запустил бинарник из version то линковщик автоматом и будет искать библиотеки в version.
Но тогда надо чтобы ядро всегда помнила полный путь к основному бинарнику процесса.
Но по уму бинарник просто должен предъявлять компоновщику ядра требования к версии библиотеки.
Можно в кратце, о чем тут было?
Судя по этому твоему посту, вы тут NixOS переизобрести пытаетесь что ли?
@cvs-255 хочет чтобы бинарники и библиотеки из одного пакета программ сидели в своей директории, а не как сечас большой кучей в /usr/bin
Ну я и предложил самое простое на мой взгляд решение.
Это отличная идея. NixOS можете ставить уже сейчас, вместо того чтобы ее хотеть.
А что предлагается делать сверх того что уже есть в ней?
Так он хочет чтобы это было в linux
Да и я не против, если в конце проверить директорию из PATH как таковую то это будет полная совместимость с текущим лиуксом.
А NixOS это по-твоему что - Windows??? Это и есть линукс.
Ну хорошо, нужно так пакеты ставить на вашей бубунте - ставим Nix на убунту или на любой другой дистрибутив. Он же как флатпак, кроссдистрибутивно работает. В чем суть изобретения велосипеда?
Флатпак в принципе норм, но на мой взгляд переусложнён, плюс у него есть крупный недостаток - файлы программы лежат не в ~/.config и ~/.local, а вместе с программой хер пойми где. И бывает что настройки прог из флатпака не соответствуют общесистемным (шрифты бывают полное говно)
Нууу не совсем так. Во-первых людям, которые читали доки известно где. Во-вторых это еще от программы зависит, у многих программ они и лежат где обычно. И это еще хуже, так как создается каша.
Я бы не относил это к крупным недостаткам, у него есть недостатки намного крупнее.
У флатпака, как и у всего подобного, философия такая - приложение должно использовать только свой собственный набор библиотек, независимо от системы и всех других приложений.
Вопрос в том, как это достигается. У флатпака это достигается помещением в “контейнер” где доступны только свои библиотеки. и приложению некуда деваться, оно использует именно их. Но это же решение и порождает кучу проблем - приложение оказывается в полной изоляции. А потом эту изоляцию героически преодолевают порталами.
У Nix это решается совсем по другому - в каждый бинарник прописываются пути к “своим” пакетам, и приложение подхватывает библиотеки именно из них. И при этом не нужен никакой контейнер, приложения точно так же видят друг друга и всю систему как и в обычном линуксе.
Но так или иначе как я понял из твоего описания без костыля подложить "не свой" пакет нельзя.
Надо чтобы бинарник именно предъявлял требования, а линковщик сам подбирал наиболее подходящие под них библиотеки.
Нельзя (в NixOS), надо все пересобирать.
Хотя технически это сделать не проблема - просто поменять в нужных бинарниках пути на новые. Но это ломает всю систему повторяемой сборки, версионирования пакетов в Nix, то есть бессмысленно в рамках этой системы.
Ну или переименовать библиотеку.
В общем NixOS тоже не тянет.
Так какие конкретно цели, и что не тянет? Можешь четко сформулировать? И ответить на вопрос - это надо чтобы что?
А смысл? Зачем это нужно?
Так и делается в обычном линуксе. Проблем порождает больше чем решает.
Подходящие библиотеки - это те, с которыми приложение было собрано, а в идеале - с которыми оно тестировалось разработчиком. Подменять их совсем не нужно.
Я понимаю так, @cvs-255 хочет чтобы в системе штатным образом стояли старая и новая версии программы скомпилированные в разное время у которых одна и таже библиотека с одним и тем же названием бы имела совершенно разные свойства.
То что я предложил это решает, но требует переработки ядра.
NixOS. Всё.
И без переработки ядра. Зачем велосипед изобретаете?
И кстати ядро то тут причем. За динамическую линковку интерпретатор ld.so отвечает, а не ядро.
То есть для решения проблемы @cvs-255 достаточно написать свою версию ld.so и добиться её принятия в апстрим?
Ну насколько я понял по твоему изложению, для решения проблемы cvs-255 достаточно установить NixOS и перестать дурить людям голову. ld.so там обычный.
Возможно, имелось в виду что-то другое, тогда надо обсуждать.
Никто не читает доки.
Ну вот. Сделали опять хрень какую-то 😁
Как это - “в бинарник”? Там программы нужно специально пересобирать под Nix? Если да, то это провал.
В чем провал?
И да, пересобирать не нужно. Можно просто патчить бинарник.
Приведу аналогию. Проекты автомобильных автопилотов существуют уже несколько десятилетий, но взлетела эта тема только с появлением достаточно мощных нейросетей. Почему? Да потому что все прежние автопилоты требовали специально оборудованных дорог, а это нахер никому не упало - переделывать все дороги под эти распрекрасные машины с автопилотами. Тогда как нейросетка нормально справляется с самыми обычными дорогами, даже с просёлочными. Потому и взлетело, наконец.
Вот так и тут. Есть мегатонны софта, в том числе и старого. Хорошая система должна давать ему рабочее окружение без лишних движений. В идеале можно будет взять какой-нибудь deb-пакет приложухи, которая уже 15 лет не обновлялась, кинуть в систему - и она обеспечит этому пакету всё нужное для работы. А когда все эти мегатонны софта нужно пересобирать/патчить под распрекрасный дистрибутив - это тупак полнейший. Никто этим заниматься не будет, кроме кучки энтузиастов и мантейнеров, а все минусы привязки к мантейнерам мы уже давно видим.
Примеры такого софта в студию.
А зачем понадобится программа 15-летней давности? Что это, например?
Затем.
Если ты придерживаешься позиции “я лучше знаю что нужно пользователям”, то пожалуйста, все эти Никсосы и большая часть Линуксов - именно про это. А я вот считаю, что пользователи сами разберутся, и что задача операционки - не ограничивать их.
Но может тогда действительно достаточно стартового скрипта который задаст индивидуальные пути к бинарникам и библиотекам для одного единственного старого приложения?
Даже для единственного приложения лень делать всё это руками
Что значит лень. Все же для пользователя, значит программист должен корячиться, и пользователя это не волнует тогда.
Разумеется. Зачем ещё программисты нужны? 😁
С моей точки зрения таие файлы пишет сам пользователь, ничего принципиально сложного в натаскивании мылкой библиотек и бинарников нету.
Ну в худщем случае это за пользователя делате админ,но ни как не прграммист, не тот уровень задачи.