кстати, а scheme/guile — это разве чистые функциональные языки?

чтобы сделать чистый функциональный язык

Мне он напоминает объектный, когда есть дерево вложений, например в nixos-option.

Из настроек браузера?! Нет, оно, конечно, действительно работает. Так и приходится делать. Но вручную скачивать в каждый профиль этот языковой пакет, когда он мог бы быть в системе… Как-то на Linux всё-таки привыкаешь к хорошему.

То есть, смысл вообще не в этом и на локализацию они вообще никак влиять не должны (потому что и так устанавливаются по зависимостям)? Но тем не менее, с ними и без них локализация в KDE-программах выглядит заметно по-разному.

Dolphin без этих пакетов дериваций

Какое занятное сочетание не(до)локализованных фрагментов, не так ли? Однако всё меняется, стоит только добавить в систему предложенный выше список пакетов.

Dolphin с добавленными .out-пакетами

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

Так чем же всё это считать, багом или фичей?

И вот он, огромный организационный недостаток NixOS во всей красе. Чтобы опакетить что-нибудь новое, приходится трогать чужой репозиторий, а в некоторых случаях ещё и чужой код, который местами ещё и может требовать рефакторинга. Для программистов, наверное, это почти столь же естественно, как дышать, но ведь для всех остальных это скорее барьер! И это ещё не вспоминая о том, что и сугубо технически писать пакеты на Nix lang ощутимо сложнее.

Как-то вот так это должно выглядеть?

ru_RU = ru-ru;
ru-ru = mkDict rec {
  name = "hunspell-dict-ru-ru-${version}";
  dictFileName = "ru_RU";
  version = "20131101";
  src = fetchurl {
    url = "https://bitbucket.org/Shaman_Alex/russian-dictionary-hunspell/downloads/ru_RU_UTF-8_${version}.zip"
    sha256 = "c9c30ca305705691fea4810137763f3b790676aa534a5cd6dfc9b45659aa9408"
  };
  buildInputs = [ unzip ];
  unpackCmd = ''
  unzip $src ${dictFileName}.dic ${dictFileName}.aff
  '';
  meta = with stdenv.lib; {
    description = "Hunspell dictionary for Russian (Russia)";
    platforms = platforms.all;
  };
};

Точнее нет: что здесь не так? (Потому что явно будет что-то не так). И как туда правильно добавить несколько словарей для одной и той же локали ru_RU?

Рефакторинга оно требует именно потому, что требуется трогать чужой код.

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

Вот - именно jack у меня не заработал, а мне он очень нужен. Сделал как в этом вики, Cadence не видит jackbus.

Он запускается без поддержки dbus, так что тут никак. А что Cadence не может просто через сокет подрубиться, как другие приложения делают?

Видимо нет, в нем вообще все неактивно, а настройки такой по-моему нет.

Вероятно, он собран без поддержки JACK. Попробуй поставить Carla, она видит джек?

Не пробовал, пока нет времени. Возможно, позже вернусь к этому.

Тогда непонятно что делать. jack не запустится в системном режиме, а упадет с ошибкой «Failed to connect to session bus for device reservation: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11»

Для пользовательских юнитов systemd экспортирует DBUS_SESSION_BUS_ADDRESS и jackdbus взлетит, но для системных юнитов systemd этого не делает.

Возможно кто-нибудь из команды NixOS подскажет как они эту проблему решают для модулей. Я спрошу.

anonymous это не работает инфа 100% и даже 200% у меня с тех пор не починилось. Возможно если поставить с нуля и заработает а так пока что у меня всё так же.

anonymous

Лол

у меня с тех пор не починилось

Возможно, если явно поставить в профиль те пакеты, про которые пишут выше, то починится?

Какой впечатляющий каст!

А если добавить в систему пакеты как в этом комментарии (как оказалось, рецепт взят именно из одного из упомянутых багов), то локализация появляется сразу после nixos-rebuild switch, не нужно даже перелогиниваться, достаточно только перезапустить программу.

Dolphin до

Dolphin после

Это всё на 19.03, если что. Но в конце того обсуждения говорится, что в 19.09 всё это «чудесным образом починилось» (!) и в KDE-программах не осталось ничего непереведённого. Так это или нет — пока неясно, но баг уже успели торжественно закрыть.

Отдельно радует, что на Nixos wiki по этому поводу вообще ни слова, как и по поводу локализации в целом. Нет, можно, конечно, предположить, что на NixOS изучение опций конфигурации и их описаний может заменить добрую половину документации. Но не полностью же!

Ну хорошо, можно посчитать, что это был частный случай. Который, однако, оказался возможен. Но необходимости трогать чужой репозиторий это всё равно не отменяет. Отправлять pull requestы, претендовать на их рассмотрение и одобрение и вот это всё. Каждый раз беспокоить основных мейнтейнеров, говоря проще. Что и выглядит как большой Барьерный риф организационный барьер. И всё это не считая барьера технического, что в совокупности заметно повышает планку для потенциальных мейнтейнеров.

Да чем вообще эта полуось лучше тех же AmigaOS или BeOS? Одинаковое мышетыкательное ненужно

Злостный оффтопик, но «народные умельцы» сделали для OS/2 текстовый менеджер задач и он работал там где линукс и не мог взлететь. В моём распоряжении был 386SX/2Mb памяти где крутился узел ФИДО в фоновой ДОС сессии и при этом во второй сессии я сидел в Нортоне(Norton Commander) и Голдеде(GoldEd)... ну и другие досовские программы запускал я и другие пользователи этого компа. Они просто работали в ДОС и даже не подозревали что этот компьютер делает что то ещё...

А базар в основном про ОО архитектуру WPS которая позволяла приложениям встраивать свои пункты в системное меню. Так же про Rexx который на системном уровне предлагал механизм вызова скрипта из программы и вызова функций программы из этого скрипта.

Я к сожалению такого не пробовал в Linux но допускаю что такое и тут есть - но обилие скриптовых языков приводит в замешательство - а там был лишь один... В системе... В Linux конечно тоже есть sh и bash которые как бы одинаковые но разные...

Кстати кто из общественности может назвать кодовые слова позволяющие в Linux вызвать скрипт из приложения и в скрипте использовать функции экспортированные приложением?

balsoft, anonymous Dolphin это не вся plasma. Я вот о чём - см список локализаций в "Системных настройках/Локализация/Язык «Настройка переводов Plasma»/Добавить языки". Он, если что, неизменен при любых из описанных в багах манипуляций и Русского там нет.

да, полумух это вещь

Итак резюамирую OS/2 с моей точки зрения.
1. ОО Интерфейс позволявший модифицировать стандартное поведение WPS системы своими дополнениями. (В абсолюте чуть ли не rexx скриптами)

причём здесь ООП правильное, базирующееся на SOM — в отличие от COM компоненты можно наследовать, есть метаклассы, С ABI прозрачность (то есть объект это C код написанный специальным образом. даже был IBM VisualAge С++ DirectToSOM компилятор, который умел С++ в такой С транслировать, то есть можно было написать «SOM класс» или «C++ класс», и всё остальное прозрачно делал компилятор + прагмы + IDL).

rexx здесь была особенная версия Object Rexx. сейчас есть современный oorexx — «Open Object Rexx», в котором есть кроссплатформность подо всё, открытые исходники, но интеграцию с SOM таки выпилили.

где-то вроде бы гуляют исходники SOM, там какая-то магия с thunks на ассемблере, завязано на особый system calling convention. непортабельно прям совсем. вроде OCTAGRAM пилит какой-то свой SOMfree клон с открытыми исходниками, попутно разбирается с прикручиванием SOM IDL под Dephi/Аду и т.п.

ориентированность SOM на WPS позволяла писать например такие вещи (для моделирования/метамоделирования). есть например в WPS объектная модель системы, десктопа, файловой системы. и вещи аналогичные FUSE можно было писать на object rexx лет тридцать назад.

например, есть набор классов предметной области, представляющих какие-то модели данных. их можно представить объектами WPS «каталог», «файл» просто отнаследовавшись от стандартных и перекрыв нестандартное поведение. то есть, сделать вещи аналогичные FUSE, например (а в реальности это какая-то модель в базе данных). при этом в SOM из коробки были, по крайней мере, в последних версиях «персистентные объекты», хранимые в базе/файле/памяти/где угодно. была целая CORBA с распределёнными объектами.

2. Системный скриптовый язык rexx который позволял писать сложные и даже ОО скрипты. Позволял вызывать скрипты из приложения - экспортируя функции приложения в rexx скрипт и из скрипта можно было вызывать функции, передавать параметры и получать результат.

да, другая полезная фича object rexx — подключить C dll и вызывать из неё функции прозрачно, написав пару строчек. то есть эта скриптуха была расширяемой — мало того что ООП правильный, с метаклассами, так ещё и сишные функции прозрачно подключаются и вызываются в пару строчек. прототипы правда надо было писать вручную.

в oorexx упростили: помимо старого механизма где FFI надо было руками описывать для отдельных функций добавили С/С++ интерфейс с парой строчек где нужно «библиотеку загрузить»,«библиотеку выгрузить». при загрузке автоматически в пространство имён oorexx подгружаются С прототипы. ещё в сторону интеграции с С++ в oorexx есть движения по сравнению с oorexx и C ABI SOM.

вообще oorexx такой вполне себе питон, как язык. даже легче и проще читается. есть стандартная библиотека, API с метаклассами, прозрачность подключения С dll и встраиваемость в С/С++ приложения.

мегафича rexx / oorexx / object rexx в том, что это «командный язык». то есть, например есть команда ADDRESS SYSTEM после которой если написать «команду» HELLOWORLD (которой нет в языке в качестве ключевых слов или процедур), то аналогично шеллу запустится HELLOWORLD.exe — это standalone rexx, запущенный из шелла. если это встраиваемый в приложение rexx, то после переключения окружения ADDRESS EDITOR например, команда/субкоманда HELLOWORLD вызовет встроенный примитив (написанный на С).

например, посмотрим на gnu emacs, расширяемый elisp-ом. модули на С там появились только совсем недавно (в отличие от xemacs и других альтернативных емаксов). сами «расширения» на elisp — в глобальном пространстве имён, с глобальными переменными. язык elisp специфический, хотя для обработки структурных выражений в целом неплох.

или на текстовый редактор THE или KEDIT/ISEDIT с мейнфреймов (также есть XE XWing X2 Editor).

они расширяются rexx-ом. в XWing и/или THE есть xoon — целый NNTP клиент, на rexx-е. читая его исходники видно, что возможности по рулению редактором в целом не хуже емаксовых, а код явно понятней elisp-овского. опять же, можно что-то тяжелое вызвать из C dll-ки. у THE открытые исходники, KEDIT удобный но платный какими-то проприетарщиками, XWing X2 — бинарный, но есть интерфейс к dll-кам для расширения.

в целом, oorexx — это такой более правильный питон с более удобным синтаксисом, прозрачной встраиваемостью в/из С++ приложение, вызовом C API из dll-ки, хештаблицами STEMS и «правильным» ООП с метаклассами в духе смоллтока.

хотя... я вот недавно наткнулся на исходники на питоне где C.LoadLibrary(«msvcrt»), C.LoadLibrary(«USER32.dll») и C.WinAPI.MessageBox(...)

радует что такие штуки вообще в питоне можно делать (за что его любят в каком-нибудь ML, врапперы к TensorFlow/PyTorch примерно такие везде). не сильно сложнее rexx-овых. ...

3.Файловая система HPFS отличавшаяся хорошей производительностью, отказоустойчивостью и «расширенными аттрибутами» позволявшими к каждому файлу прицепиить целый список значений копировавшихся вместе с файлом. Так что вместе с файлом могло быть его описание, а исполняемому exe файлу можно было добавить пачку параметров которые он и сам мог прочитать и другое ПО записать.

журналирование вроде какое-там было, но могло портить тома, в JFS стало понадёжнее и появились логические тома типа LVM.

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

по моему, там везде был один пользователь. вообще чего принципиально не было в OS/2 и не появится — многопользовательность и поддержка 64 бит. всё остальное в принципе расширяемо, согласно той красивой архитектуре которой лет 30 уже. есть форк ядра OS/2 на L4, OS4 там что-то пилят вроде с опенсорсным API ядра (аналогично ReactOS). консольное уже работает, GUI приложения и PM в процессе (пилит 1-2 человека). про графическое есть прогресс у Ryan который icculus — он на patreon в бложике выкладывал аналогичное Wine поделие для запуска PM приложений. ну то есть, есть аналоги ReactOS и Wine.

онтопик: в eCS и далее ArcaOS, кстати, появились пакетные менеджеры. используется rpm, yum с бинарными репозиториями. юзеры-старожилы говорят,что rpm сложно пользоваться, установка через unzip — наше всё :))

ИМХО, имело бы бОльший смысл тот же Nix прикрутить вместо rpm болота... итак там на netlabs практически тот же gcc/libc/firefox и прочее есть практически в полном комплекте

Я к сожалению такого не пробовал в Linux но допускаю что такое и тут есть - но обилие скриптовых языков приводит в замешательство - а там был лишь один... В системе... В Linux конечно тоже есть sh и bash которые как бы одинаковые но разные...

там другие были и не нужны особо, потому что SOM + метаклассы покрывают API для автоматизации низкоуровневой, на уровне системных компонент, а WPS + набор его объектов — ООП модель объектной системы, десктопа с метаклассами в духе смоллтоковых

Кстати кто из общественности может назвать кодовые слова позволяющие в Linux вызвать скрипт из приложения и в скрипте использовать функции экспортированные приложением?

dlopen/dlclose, LD_PRELOAD, FFI (Foreign Functions Interface из скрипта в C ABI).

в разных языках по разному. где-то встраиваемо как в lua, где-то оборачиваемо как в том же python. где-то нерасширяемо как в bash :) в rexx/ oorexx можно и так и так делать (но лучше почитать его мануал про то как написать специальным образом C dll с 2 дополнительными функциями, «загрузить библиотеку+подключить C функции, экспортированные в rexx»/«выгрузить библиотеку», чем писать 10500 прототипов отдельных функций).

что любопытно, что тот же rc shell аналогичный bash в plan9 в inferno развился в полноценный shell с модулями, графикой на tk (без tcl), списками и функциями высшего порядка, и да — подгрузкой C/Limbo модулей из отдельных dll.

вообще, тот же THE например показывает емакс, который мы потеряли... с нормальным человекоподобным скриптовым языком, с си расширяемостью си модулями, с полнофункциональными расширениями на rexx а не на elisp.

оно консольное но может использовать open source встроенный rexx (Regina) или если удалить regina*.dll из папки с THE.exe — то общесистемный oorexx в котором есть ООП и метаклассы.

единственное что, у всех THE-подобных редакторов (THE/KEDIT/ISEDIT/X2 XWing) — какой-то неудобный GUI. здесь самый удобный у KEDIT или XWing, но опять же, проприетарщики или бинарные сборки...

чего не хватает — THE с человеческим интерфейсом, в духе Crimson Editor того же с MDI окнами, но расширяемый oorexx-ом.

вот например есть GWindows — библиотека под Ada GNAT к WinAPI, там в поставке пример текстового редактора на Scintilla, довольно простой. опять же, C библиотеки на Ada подключаются простыми прагмами, код довольно простой и понятный в целом. осталось только oorexx прикрутить, и или свелосипедить свой набор команд, либо прикрутить ядро от THE к такому scintilla редактору на Аде, и будет практически мой идеальный текстовый редактор — емакс с человеческим лицом, расширяемый oorexx-ом.

Вот тайловый WM с клавиатурным управлением - наша тема. OS/2 вряд ли мне бы такое предложил когда, как и любая другая ОС где гуй намертво прибит к системе.

Project Oberon от Вирта с тайловым интерфейсом 100 лет в обед, по моему ещё на модуле что-то такое было ещё точно до полуоси.

OS/2 вряд ли мне бы такое предложил когда, как и любая другая ОС где гуй намертво прибит к системе.

вот не намертво он там прибит, что в OS/2 с object rexx-ом, что в AmigaOS с ARexx-ом.

в ARexx: есть стандратный GUI BOOPSI, C ABI к ООП GUI в MUI/Zune библиотеке. GUI стандартно скриптуется REXX-ом, все приложения. приложения регистрируют «порты», куда можно слать сообщения. сообщения в MUI/Zune высокоуровневые ориентированы на гаджеты/виджеты, то есть можно программно нажать на кнопку или вызвать пункт меню. низкоуровневые — только то API что автор приложения руками в rexx экспортировал. по умолчанию если используется стандартные библиотеки (ООП на C API в Intuition, ООП GUI BOOPSI в MUI/Zune) — скриптуемо ЛЮБОЕ GUI приложение (включая ещё не написанные, ибо ООП).

есть рефлексия и метаданные, что-то можно автоматически генерировать.

вообще, в AmigaOS на ARexx, в BeOS/Haiku на его нативном API любое GUI приложение является скриптуемым если не велосипед а стандартные библиотеки для GUI.

в OS/2 есть SOM, в WPS есть object rexx + SOM + стандартная модель системных объектов, весь GUI объектно-ориентированный.

в нормальном ООП с метаклассами типа смоллтока.

так что ни разу гуй намертво прибит к системе

наоборот, через 20 лет после того как полуось сдохла, благодаря правильной архитектуре её десктопный GUI всё ещё можно расширять плагинами и C dll-ками (cм. аналоги WPS опенсорные и примочки к WPS стандартному).

Если хочешь сделать хорошо – отправляй PR в nixpkgs. Если хочешь просто решить свою проблему здесь и сейчас, никого не дергая – пишешь пакет сам. В данном случае из-за неправильной архитектуры придется копипастить. Чаще всё будет гораздо компактнее и удобнее.

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

Да, в некоторых местах всё равно остаются непереведённые фрагменты. Например, в KSysGuard и Kate. Выбора локализации в настройках не появляется, ага. Но всё равно становится заметно лучше! И скриншоты с Dolphin больше для того, чтобы было заметно, что эти пакеты действительно влияют на локализацию существенным образом. Остаётся только проверить, как в 19.09 вон то восторженное закрытие согласуется с реальностью.

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

Вот именно! Две крайности и ни одного оптимума. Два барьера и ни одного упрощения. Или это так и задумано, чтобы не самого лучшего кода в дистрибутиве появлялось поменьше?

так что ни разу гуй намертво прибит к системе

это ты про гуишные приложения говоришь. меня больше штатный оконный менеджер напрягает: окружение с устаревшей метафорой рабочего стола и иконостасом это ужасно.

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

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

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

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

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

• Kate и всё остальные, что основаны на компоненте KTextEditor, раньше могли через PolicyKit запрашивать разрешение на сохранение, если права на файл не позволяли это сделать текущему пользователю. Теперь они сразу говорят «не могу».

• PowerDevil напрочь отказывается запускаться, из-за чего полностью невозможно изменить яркость подсветки штатными средствами и не только. https://github.com/NixOS/nixpkgs/issues/69150 https://github.com/NixOS/nixpkgs/issues/71102

Как-то не всё в NixOS выходит гладко в части интеграции и взаимодействия программ друг с другом.

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

Интеграция, настраиваемость и пакет хороших программ же! Это если в двух словах. АПВС?

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

Может кто-нибудь объяснить зачем пользоваться такой горбухой как кеды?

Удобно же.

Если честно, не знаю, зачем она присутствует в опциях и что мешает получать название первого релиза по тем же stateful-файлам. Как есть.

Про polkit: ты его как-то настраиваешь? Есть предположение, что дефолтные настройки не предназначены для десктопа.

Нет, вообще его не трогаю. Ну и в 19.03 оно безо всякой дополнительной настройки работало. И pkexec сам по себе тоже продолжает исправно работать. А вот в Kate — нет.

Как-то не всё в NixOS выходит гладко в части интеграции и взаимодействия программ друг с другом.

С нашей точки зрения это во всех остальных дистрах сопли вместо интеграции. Просто у нас не работоспособность этих неявных соплей является фичей.

Нуу нет, но у guix в style guide написано быть паиньками и писать типизированный код в чистом функционально стиле.

Если честно, не знаю, зачем она присутствует в опциях и что мешает получать название первого релиза по тем же stateful-файлам.

Чтобы а) не делать этого б) ты мог вручную обновить state и, после этого, stateversion. Совместимость со старыми форматами не будет тянуться вечно, и однажды тебе придётся это сделать.

Сегодня рассказывали, что для таких упоротых как ты, (которые в упор считают главный источник проблем у недопакетных менеджеров фичей и не пересобирают обратные зависимости, надеясь на авось) в guix есть механизм обобщенной подмены зависимостей без пересборки, называется grafting.

Однажды надо собрать нужные слова и объяснить тебе, почему отказ от пересборки обратных зависимостей в частности и суматошное накидывание файлов в кучку в общем суть не фича, но первородный грех дистрибутивостроения, и целые классы проблем в случае Nix канут в nix, но сегодня я слишком устал.

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

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

Ну я начинал с 15.09, оказалось что реальных мест где стейт влияет — было всего два или три (локации, где создаются базы потсгресса и еще что-то), я прошелся грепом по nixos/ в исходниках, и проверил, что у меня на «новых» местах. И поднял стейт до 19.03

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

Пересборка обратных зависимостей — это как бы тоже не фича, а адовый костыль для защиты от быдлокодеров, не знающих, что такое семантическое версионирование. Примерно такого же рода адовый костыль, как статическая компоновка — для защиты от быдлокодеров, не знающих, что такое ABI (в т. ч. быдлокодеров со стороны тулчейна, привет, Rust/Go/Haskell, я смотрю на вас).

в guix есть механизм обобщенной подмены зависимостей без пересборки, называется grafting

А что, в этих ваших никсах и graft-ов нет? Как всё запущено.

Но на самом деле подмена зависимостей — это плюс-минус бесполезная штука, вне завимости от того, насколько она обобщённая. Я считаю, что обобщать нужно в другом месте, а именно 1) в том месте, где вычисляется хэш артефакта (ты не против, если я буду использовать традиционные термины вместо хипстерских названий из Nix’а?), и 2) в том месте, где по хешу этот самый артефакт достаётся.

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

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

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

А твоя идея графтинга очень просто реализуется. Доступом по хешу занимается файловая система, так что то, что ты хочешь, похоже на бинд-маунт или даже просто симлинк. А вот интерфейса для него не завезли одновременно и потому что нефиг, и потому что не надо. Дистростроители коммитят в trunk/release и быстро пересобирают все на гидре; компании, как я узнал, заводят себе билдсервера на 64 ядер и пересобирают мир примерно со скоростью скачивания; остаются только простые юзеры, которые хотят 1) пропатчить уберпопулярную в системе либу 2) не слать при том патч в апстрим nixpkgs 3) пропатчить её прям обязательно для всех дериваций. Таким да, приходится ночь поспать.

Я об это спотыкался за пару лет лишь один раз, и то, оказалось, что потому что systemd неправильно подменял, можно было правильно и без пересборки мира.

Видимо, эти зависимости не прописаны в propogatedBuildInputs

propogated

Лол. Или оно там так с ошибкой и конфигурируется?

Примерно такого же рода адовый костыль, как статическая компоновка — для защиты от быдлокодеров, не знающих, что такое ABI (в т. ч. быдлокодеров со стороны тулчейна, привет, Rust/Go/Haskell, я смотрю на вас).

Интересно девки пляшут. На самом деле — от быдлокодеров, пишущих такое ABI, для компоновки с которым надо качать и настраивать гигабайты шлака (авторы бионика, я смотрю на вас). Проще, не выходя из докера, слинковать под нужную архитектуру статически с тем, что 100% работает.

Да, моя неграмотность. Конечно propagated

а потом узнал, что внутри одной версии есть ещё символьное версионирование

В смысле soversion? Такая-то проблема. Если что, soversion бампать научились уже чуть ли не автоматически (или совсем автоматически).

семантическое версионирование это хорошо и его хватает всем

Его хватает всем, где нет ABI. Где есть ABI — рядом с семантической версией нужна ещё версия ABI.

С нашей точки зрения пересборка есть сама по себе достойная самоцель

Ну я вижу. Повторяю, более чем на обобщение докера этот ваш никс в текущем виде не годится.

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

Прочитай мой ответ чуть тщательнее, чем по диагонали. Графтинг в любом виде — это не то, чего мне хотелось бы.

Дистростроители коммитят в trunk/release и быстро пересобирают все на гидре

Я ему про обобщённое решение зависимостей в рантайме, а он мне про гидру.

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

Нет, symbol versioning - http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols : в одном soшнике лежит несколько наборов функций с различающимся поведением, и механизм выбора нужного для неготовой к возникновению из ниоткуда такой подставы аппликухи держится на неявных соплях.

Nix в текущем виде ни на что серьёзное-ынтырпрайзное все ещё не годится, кто бы спорил. Но концепция его насильно заставляет избавиться от кучи разномастных ad-hoc хаков, и выбор Nix спасает всех причастных от нескольких классов неявных костылей, которые работают не потому, что чётко описаны, а вопреки этому. Это надо ценить и развивать, а не продлять агонию от их нагромождения.

И если ты выбираешь дистр по возможности легко и грязно пересобрать и подменить libc без тестирования, изоляции и прочей фигни, которая только мешает, то тебе не только Nix, тебе любой пакетный менеджер мешает. Просто остальные скидали файлов в /usr и надеются на лучшее, а Nix этим не ограничивается. Больше пэкэдж-мэнэджмэнта - сложнее стрелять в ногу - недовольнее intelfx.

Во, уже свой Nix-царь у нас появился. Значит, NixOS точно взлетел.

Я об это спотыкался за пару лет лишь один раз, и то, оказалось, что потому что systemd неправильно подменял, можно было правильно и без пересборки мира.

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