Продублирую потерянное сообщение.
https://www.linux.org.ru/forum/talks/16703136?cid=16704645
/thread
Вот мысль, которая не проскакивала вроде в том обсуждении.
NixOS всем хорошо, но есть серьезный недостаток, из-за которого она в маргинальном положении. Он же - ее основное преимущество.
Она дает слишком большие возможности по кастомизации системы пользователю. В такой системе невозможно дать какие-либо гарантии.
То есть техподдержка практически невозможна.
Поэтому та же Шапка, вместо того чтобы принять неизбежное и перейти на Nix, пытается те же проблемы решить с помощью OSTree. А оно как раз гарантирует одинаковость образа системы у пользователя и у Шапки - идеально для техподдержки.
Но там обратная проблема - пользователь не может ничего менять, отсюда всякие флатпаки, в которых все равно нельзя ничего менять. И разработка только в контейнере, что на полном серьезе Шапка предлагает делать в такой системе.
А для контроля самих файлов должен применяться как минимум Git
Очередной оверинженеринг
Ну, может, и не Git, но какой-то контроль изменений, чтобы можно было отследить вносимые пользователем изменения. У проблем подобного класса не бывает простых решений.
Проблема управления конфигурацией в GNU/Linux стоит отдельно. Я думал над решением, но к чему-то конкретному и окончательному так и не пришёл.
чтобы можно было отследить вносимые пользователем изменения
Зачем? Есть значения по умолчанию и есть пользовательские значения. Зачем вся история изменений?
Зачем?
Месье админ локалхоста?
Есть значения по умолчанию и есть пользовательские значения.
И давно вся системная конфигурация стала задаваться через dconf?
Зачем вся история изменений?
Вся, может, и не нужна, но, во-первых, должен храниться diff между тем, что было в системе (т. е. по умолчанию или в результате настройки через nix-модули) и тем, что натворил пользователь; во-вторых, должна быть возможность переключиться между n последними версиями конфигурации.
Месье админ локалхоста?
Да, и сабжевый вопрос, по-моему, вообще не про серверы. На серверах докер и прочие приблуды решают означенную проблему чуть более чем полностью.
А вот на десктопах беда.
На серверах докер и прочие приблуды решают означенную проблему чуть более чем полностью.
“Прочие приблуды” — это не Ansible случаем? Ничего они не решают. А Docker — это как Flatpak, только для серверов.
Ну я и имею в виду, что на серверах можно всё в докер засунуть и наворотить гит для конфигов. А для десктопов это не пойдёт.
Таковые системы есть (например, 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 ]
Допустим, приложения ставятся в каталог ~/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 и его зависимостей. А сам скрипт можно будет запускать глобально.
Т.е. будет запуск программ не напрямую бинарниками, а промежуточными сгенерированными скриптами, только и всего.
Да, по такому пути можно попробовать пойти.
Ещё чуть-чуть и ты переизобретёшь Flatpak :P
Поэтому главное - вовремя остановиться 😁
В общем что если директории в переменой 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/binversion берётся из полного пути к запускаемому бинарнику.
То есть запустил бинарник из version то линковщик автоматом и будет искать библиотеки в version.
Но тогда надо чтобы ядро всегда помнила полный путь к основному бинарнику процесса.Но по уму бинарник просто должен предъявлять компоновщику ядра требования к версии библиотеки.
Можно в кратце, о чем тут было?
Судя по этому твоему посту, вы тут NixOS переизобрести пытаетесь что ли?
@cvs-255 хочет чтобы бинарники и библиотеки из одного пакета программ сидели в своей директории, а не как сечас большой кучей в /usr/bin
Ну я и предложил самое простое на мой взгляд решение.
Это отличная идея. NixOS можете ставить уже сейчас, вместо того чтобы ее хотеть.
А что предлагается делать сверх того что уже есть в ней?
Так он хочет чтобы это было в linux
Да и я не против, если в конце проверить директорию из PATH как таковую то это будет полная совместимость с текущим лиуксом.
Так он хочет чтобы это было в linux
А NixOS это по-твоему что - Windows??? Это и есть линукс.
Ну хорошо, нужно так пакеты ставить на вашей бубунте - ставим Nix на убунту или на любой другой дистрибутив. Он же как флатпак, кроссдистрибутивно работает. В чем суть изобретения велосипеда?
Флатпак в принципе норм, но на мой взгляд переусложнён, плюс у него есть крупный недостаток - файлы программы лежат не в ~/.config и ~/.local, а вместе с программой хер пойми где. И бывает что настройки прог из флатпака не соответствуют общесистемным (шрифты бывают полное говно)
файлы программы лежат не в ~/.config и ~/.local, а вместе с программой хер пойми где
Нууу не совсем так. Во-первых людям, которые читали доки известно где. Во-вторых это еще от программы зависит, у многих программ они и лежат где обычно. И это еще хуже, так как создается каша.
Я бы не относил это к крупным недостаткам, у него есть недостатки намного крупнее.
И бывает что настройки прог из флатпака не соответствуют общесистемным
У флатпака, как и у всего подобного, философия такая - приложение должно использовать только свой собственный набор библиотек, независимо от системы и всех других приложений.
Вопрос в том, как это достигается. У флатпака это достигается помещением в “контейнер” где доступны только свои библиотеки. и приложению некуда деваться, оно использует именно их. Но это же решение и порождает кучу проблем - приложение оказывается в полной изоляции. А потом эту изоляцию героически преодолевают порталами.
У Nix это решается совсем по другому - в каждый бинарник прописываются пути к “своим” пакетам, и приложение подхватывает библиотеки именно из них. И при этом не нужен никакой контейнер, приложения точно так же видят друг друга и всю систему как и в обычном линуксе.
каждый бинарник прописываются пути к «своим» пакетам
Но так или иначе как я понял из твоего описания без костыля подложить "не свой" пакет нельзя.
Надо чтобы бинарник именно предъявлял требования, а линковщик сам подбирал наиболее подходящие под них библиотеки.
людям, которые читали доки известно где
Никто не читает доки.
И это еще хуже, так как создается каша
Ну вот. Сделали опять хрень какую-то 😁
У Nix это решается совсем по другому - в каждый бинарник прописываются пути к «своим» пакетам
Как это - “в бинарник”? Там программы нужно специально пересобирать под Nix? Если да, то это провал.
FUCK
интересная тема, только хотел почитать а тут вайп тотальный.
