Tech / Games / Dev

https://www.linux.org.ru/forum/talks/16703136?cid=16704645 /thread

Таковые системы есть (например, https://www.softwarecollections.org от RH, и devtoolset в частности, раз речь о gcc). Есть и более продвинутые, которые кодируют в PREFIX не только версию, но и многие другие данные в виде хэша (conan, nix). Обьединяет все три, если в двух словах, то, что они удобны для роботов, и неудобны для человеческих операторов, которые быстро начинают ошибаться в длинных путях. Чисто же для души я предпочитаю порты от нетки https://pkgsrc.org, они бутстрапятся на линуксе). Не понравились что-то - тупо сделал rm -rf и пересобрал начисто. Или сделал несколько префиксов, с разных версий.

FHS нормально работала когда системы были юными и компактными, а экосистема - маленькой. Для больших зрелых систем, понятное дело, она нихера не годится. Решение лежит на поверхности: выделить отдельно систему и оставить ей FHS, все остальные приложения перевести в хомяк (чтобы не требовался пароль рута) и посадить каждое в свой каталог a la винда.

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

Ну вот посадили мы каждое приложение в свой каталог а-ля винда (сосбвенно как я и предлагаю). Но дальше то нужно как-то удобно их запускать. Вот этот вопрос я и прорабатываю

Я думаю есть простое решение, надо поменять алгоритм поиска по переменной PATH: пусть в каталоге на который указывает эта переменная бинарники и библиотеки лежат не напрямую, а в директориях progname. Может в директориях вида /usr/progs/packet_prog_name/bin и /usr/progs/packer_prog_name/lib То есть принципиально ничего не меняется, но связанные файлы лежат ближе друг к другу. Но перелопачивать под это дистры и исходники будет та ещё возня.

[ message lost ]

В общем что если директории в переменой PATH сделать по принципу
$dir_path/$packet_prog_name/bin
и
$dir_path/$packet_prog_name/bin

и переписать линковщик ядра чтобы он при поиске бинарников и библиотек их обходил по шаблону:
$dir_path/*/bin
Начиная с конкретной директории $packet_prog_name из которой был запущен ищущий библиотеки процесс.
Ну или если программа указала конкретный $packet_prog_name для поиска бинарника или библиотеки.

@cvs-255 твоё мнение о посте выше?

FUCK

интересная тема, только хотел почитать а тут вайп тотальный.

Можно в кратце, о чем тут было?

Судя по этому твоему посту, вы тут NixOS переизобрести пытаетесь что ли?

@cvs-255 хочет чтобы бинарники и библиотеки из одного пакета программ сидели в своей директории, а не как сечас большой кучей в /usr/bin

Ну я и предложил самое простое на мой взгляд решение.

Это отличная идея. NixOS можете ставить уже сейчас, вместо того чтобы ее хотеть.

А что предлагается делать сверх того что уже есть в ней?

ну да, это один из вариантов. Только еще версионирование итд

Так он хочет чтобы это было в linux

Да и я не против, если в конце проверить директорию из PATH как таковую то это будет полная совместимость с текущим лиуксом.

Так он хочет чтобы это было в linux

А NixOS это по-твоему что - Windows??? Это и есть линукс.

Ну хорошо, нужно так пакеты ставить на вашей бубунте - ставим Nix на убунту или на любой другой дистрибутив. Он же как флатпак, кроссдистрибутивно работает. В чем суть изобретения велосипеда?

Флатпак в принципе норм, но на мой взгляд переусложнён, плюс у него есть крупный недостаток - файлы программы лежат не в ~/.config и ~/.local, а вместе с программой хер пойми где. И бывает что настройки прог из флатпака не соответствуют общесистемным (шрифты бывают полное говно)

Можно сделать так:
$dir_path/$packet_prog_name/$version/bin

version берётся из полного пути к запускаемому бинарнику.
То есть запустил бинарник из version то линковщик автоматом и будет искать библиотеки в version.
Но тогда надо чтобы ядро всегда помнила полный путь к основному бинарнику процесса.

Но по уму бинарник просто должен предъявлять компоновщику ядра требования к версии библиотеки.

файлы программы лежат не в ~/.config и ~/.local, а вместе с программой хер пойми где

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

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

И бывает что настройки прог из флатпака не соответствуют общесистемным

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

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

У Nix это решается совсем по другому - в каждый бинарник прописываются пути к «своим» пакетам, и приложение подхватывает библиотеки именно из них. И при этом не нужен никакой контейнер, приложения точно так же видят друг друга и всю систему как и в обычном линуксе.

каждый бинарник прописываются пути к «своим» пакетам

Но так или иначе как я понял из твоего описания без костыля подложить "не свой" пакет нельзя.

Надо чтобы бинарник именно предъявлял требования, а линковщик сам подбирал наиболее подходящие под них библиотеки.

Нельзя (в NixOS), надо все пересобирать.

Хотя технически это сделать не проблема - просто поменять в нужных бинарниках пути на новые. Но это ломает всю систему повторяемой сборки, версионирования пакетов в Nix, то есть бессмысленно в рамках этой системы.

Надо чтобы бинарник именно предъявлял требования, а линковщик сам подбирал наиболее подходящие под них библиотеки

А смысл? Зачем это нужно?

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

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

Ну или переименовать библиотеку.

В общем NixOS тоже не тянет.

Так какие конкретно цели, и что не тянет? Можешь четко сформулировать? И ответить на вопрос - это надо чтобы что?

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

То что я предложил это решает, но требует переработки ядра.

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

NixOS. Всё.

И без переработки ядра. Зачем велосипед изобретаете?

И кстати ядро то тут причем. За динамическую линковку интерпретатор ld.so отвечает, а не ядро.

То есть для решения проблемы @cvs-255 достаточно написать свою версию ld.so и добиться её принятия в апстрим?

Продублирую потерянное сообщение.

https://www.linux.org.ru/forum/talks/16703136?cid=16704645

/thread

Ну насколько я понял по твоему изложению, для решения проблемы cvs-255 достаточно установить NixOS и перестать дурить людям голову. ld.so там обычный.

Возможно, имелось в виду что-то другое, тогда надо обсуждать.

Вот мысль, которая не проскакивала вроде в том обсуждении.

NixOS всем хорошо, но есть серьезный недостаток, из-за которого она в маргинальном положении. Он же - ее основное преимущество.

Она дает слишком большие возможности по кастомизации системы пользователю. В такой системе невозможно дать какие-либо гарантии.

То есть техподдержка практически невозможна.

Поэтому та же Шапка, вместо того чтобы принять неизбежное и перейти на Nix, пытается те же проблемы решить с помощью OSTree. А оно как раз гарантирует одинаковость образа системы у пользователя и у Шапки - идеально для техподдержки.

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

Допустим, приложения ставятся в каталог ~/Apps по схеме ~/Apps/VideoLAN/VLC#3.6.8/{bin,lib,share}

Тогда можно сделать каталог ~/Apps/bin и внести его в глобальный PATH. В этот каталог пакетный менеджер будет класть автоматически сгенерированные скрипты, в нашем случае это скрипт под названием vlc#3.6.8. Этот скрипт будет через переменные LD_LIBRARY_PATH и прочие подхватывать для vlc каталоги bin, lib, share самого vlc и его зависимостей. А сам скрипт можно будет запускать глобально.

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

людям, которые читали доки известно где

Никто не читает доки.

И это еще хуже, так как создается каша

Ну вот. Сделали опять хрень какую-то 😁

У Nix это решается совсем по другому - в каждый бинарник прописываются пути к «своим» пакетам

Как это - «в бинарник»? Там программы нужно специально пересобирать под Nix? Если да, то это провал.

А для контроля самих файлов должен применяться как минимум Git

Очередной оверинженеринг

Да, по такому пути можно попробовать пойти.

Ещё чуть-чуть и ты переизобретёшь Flatpak :P

Поэтому главное - вовремя остановиться 😁

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

Проблема управления конфигурацией в GNU/Linux стоит отдельно. Я думал над решением, но к чему-то конкретному и окончательному так и не пришёл.

чтобы можно было отследить вносимые пользователем изменения

Зачем? Есть значения по умолчанию и есть пользовательские значения. Зачем вся история изменений?

Зачем?

Месье админ локалхоста?

Есть значения по умолчанию и есть пользовательские значения.

И давно вся системная конфигурация стала задаваться через dconf?

Зачем вся история изменений?

Вся, может, и не нужна, но, во-первых, должен храниться diff между тем, что было в системе (т. е. по умолчанию или в результате настройки через nix-модули) и тем, что натворил пользователь; во-вторых, должна быть возможность переключиться между n последними версиями конфигурации.

Месье админ локалхоста?

Да, и сабжевый вопрос, по-моему, вообще не про серверы. На серверах докер и прочие приблуды решают означенную проблему чуть более чем полностью.

А вот на десктопах беда.

На серверах докер и прочие приблуды решают означенную проблему чуть более чем полностью.

«Прочие приблуды» — это не Ansible случаем? Ничего они не решают. А Docker — это как Flatpak, только для серверов.

Ну я и имею в виду, что на серверах можно всё в докер засунуть и наворотить гит для конфигов. А для десктопов это не пойдёт.

Почему? Базовая система что на сервере, что на ПК одна и та же.

Это всё не для десктопных пользователей

Что «это» и почему?

Докер и вся херня. Потому что на десктопе оно никому не сдалось

Потому что на десктопе оно никому не сдалось

Зачем тогда Podman поставляют в Fedora Silverblue по умолчанию? toolbox/distrobox тоже для серверов придумали?

и вся херня

Какая именно? Вот это всё добро тоже для серверов придумали?

Это придумали для людей, которые на десктопе играются в админов, для кодеров, для прочих нердов.

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

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

«Обычным пользователям» принципе не нужно править никакие конфиги, чем бы они ни управлялись.