Концептуальный дистрибутив - почти lisp os? :)

Почему неудачная

Сравни экосистемы с точки зрения разработки/девопса/одменства/использования на десктопе/использования на сервере/использования в облаке.

Схема отличный язык, получше того невменяемого DSL из NixOS

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

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

https://blogs.gnome.org/mclasen/2018/06/19/flatpak-in-detail-part-2/

Тут кратко про бранчи написано.

А какие там могут быть манипуляции

flatpak update, flatpak install используют ostree, но возможности самой ostree больше, например можно синхронизировать с конкретным коммитом из архива в репозитории, например откатиться таким образом. Но это сильно костыльный способ, для регулярного использования неудобен.

кстати, там можно modularity юзать, не знаешь?

Ну, во flatpak нет, этот фича федоры. Через rpm-ostree может быть и можно, не знаю.

У меня часто была ситуация - давно не обновлялся, обновился - часть программ перестала работать, надо подбирать версии либ.

Мэнтейнеры наркоманы? Такое бывает, но я давно не видел.

Предыдущее состояние чего? Конкретного пакета, его зависимостей, ос?

Неизменяемой части системы(ostree + layered packs), то есть, которая изменяется оффлайн, а потом загружаешься в новую, если дела идут не так, то роллбэк, мне пригодилось уже пару раз.

Как переживут ролбек другие пакеты, подцепившие новые зависимости?

Дык ос, флатпаки и прочие контейнеры автономны в этом смысле.

флатпаки отличаются новизной месяца через четыре

Что это значит?

Речь идет о silverblue, там все новое пару-тройку месяцев, а потом флатпаки начинают отрываться.

А если мне надо не из каких-то версий дистра, а конкретная сборка пакета с github или собственная пропатченная?

У меня было такое с прогой на питоне(frescobaldi, простой случай, да), я просто докидывал нужных пакетов в систему или toolbox, а прогу уже из гита, как-то так.

Уточню для понимания, тут же разные системные ostree-репозитории. /ostree/repo и /var/lib/flatpak/repo. rpm-ostree работает только с первым и во второй не лезет. Flatpak только со вторым. Слои оба используют, но очень разным способом.

Тут кратко про бранчи написано.

Спасибо! Интересно было почитать, но пока не ясно зачем простому юзеру это, stable и так всё новое даёт.

flatpak update, flatpak install используют ostree, но возможности самой ostree больше, например можно синхронизировать с конкретным коммитом из архива в репозитории, например откатиться таким образом. Но это сильно костыльный способ, для регулярного использования неудобен.

Не понимаю какая зависимость флатпака от ostree, если манипуляции с ним не требуют перезагрузки?

Ну, во flatpak нет, этот фича федоры.

Да, я про package layering говорил.

Понял, спасибо, а то я сижу туплю в этот текст(по твоей ссылке):

A remote is a reference to an ostree repository that is available somewhere on the network.

Each installation also has its own local ostree repository…

Потому что невменяемый DSL Nix не от нехрен делать с нуля написали, а ради совершенно конкретных свойств, а именно ленивой эвалюации. А GNUтые фанатики подумали как ты и теперь у них родовая травма всего проекта и аналог nixpkgs эвалится по полчаса.

невменяемый DSL Nix … ради … ленивой эвалюации

Неужели в схемах её нельзя организовать? Что-то слабо верится.

В той мере, в какой она нужна в Nix (maximal laziness в терминах Dolstrы, гарантия максимум однократной эвалюации синтаксически тождественных выражений), её не было даже в хаскелле.

Можно ли добиться этого в Guile? С костылями до небес и по сути ещё одним невменяемым DSL - можно. Но в Guix этого не сделали.

В той мере, в какой она нужна в Nix её не было даже в хаскелле

Хаскель поддерживает ленивость на уровне языка, в чем принципиальная невозможность реализовать твой «maximal laziness»?

гарантия максимум однократной эвалюации синтаксически тождественных выражений

Можешь привести пример?

С костылями до небес

Там есть макросистема (в отличии от хаскеля, кстати), пусть не такая мощная как в racket, но все же => костылей не будет.

и по сути ещё одним невменяемым DSL - можно.

На схеме он может смотреться абсолютно нативно в s-expressions, неотличимо от вызова ф-ций.

какие преимущества guile перед chez, racket, ecl, sbcl

Для этих целей: ecl глючноват, sbcl жирноват, ccl - норм. Но RMS не признаёт существование CL вообще, поэтому отпали все три.

какие преимущества guile

Тебе ж уже сказали. Оно GNU. Т.е. официально и изначально позиционировалось как язык для скриптов GNU.

Для racket есть компромисс между быстрым стартом и скоростью исполнения (вариант, когда racket уже предустановлен тоже подходит)?

Быстрый старт скриптов возможен через racketd (тогда racket работает в виде службы).

какие преимущества guile

Тебе ж уже сказали. Оно GNU.

Я в курсе, вопрос был по техническим преимуществам, а не почему его выбрали для проекта GNU.

И оно не интерпретирует, а тоже использует jit для скриптов, верно?

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

Если запускать не через демона, то 90% времени уходит на инициализацию стандартной библиотеки.

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

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

Можешь привести пример?

Я попытался, но у меня не вышло вызывать side-effects из Nix и не терять при этом ленивости.

Поэтому просто сошлюсь на страницу 83 кандидатской Dolstr’ы. (Пока искал, нашел еще презентацию на тему).

На схеме он может смотреться абсолютно нативно в s-expressions, неотличимо от вызова ф-ций.

Смотреться. Будучи при этом другим языком, с другой семантикой и иначе интерпретируемым. Лиспы не всасывают волшебным образом свойства всех других лиспов из-за одного лишь общего способа записи =)

Haskell поддерживает, но не гарантирует, ленивость на уровне языка.

Как это поддерживает, но не гарантирует? Не эксперт в хаскелле, но там всего одна эталонная реализация, и ленивость она и поддерживает.

Haskell обычно реализует ленивость, но не «максимальную», на уровне реализации.

Что значит «не максимальную»?

гарантия максимум однократной эвалюации синтаксически тождественных выражений

Можешь привести пример?

Я попытался, но у меня не вышло вызывать side-effects из Nix и не терять при этом ленивости.

Да просто пример про «однократное вычисление» на пальцах в разрезе обсуждаемой темы подойдет.

Поэтому просто сошлюсь на страницу 83 кандидатской Dolstr’ы. (Пока искал, нашел еще презентацию на тему).

Спасибо, почитаю.

На схеме он может смотреться абсолютно нативно в s-expressions, неотличимо от вызова ф-ций.

Смотреться. Будучи при этом другим языком

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

с другой семантикой и иначе интерпретируемым.

Стандартные конструкции тоже вводят «свою семантику». Про «иначе интерпретируемым» не понял - макрос в итоге раскроется в обычные ф-ции и спецопы.

Лиспы не всасывают волшебным образом свойства всех других лиспов из-за одного лишь общего способа записи =)

А должны? Или ты о том, что в guile нет ленивости или о чем вообще? :)

Я о том, что если DSL будет на s-выражениях, он все равно будет отдельным DSL.

И чо? :)

Ну и то, что пох. DSL все равно нужон, Nix все сделал правильно, а синтаксис - не главное. Кто не понял, тот Guix.

eDSL круче, можно обрабатывать средствами хостового языка и расширять семантику, а не ожидать xxx лет, что в язык добавят нужные *тебе* фичи.

Не использовал Linux на десктопе использую на серверах

Всё правильно делаешь, ничего не меняй.

Да, но Nix немного не для засовывания кухонной раковины язык =)

Короче, хочешь починить проблемы Guix - дерзай. А я на Nix посижу.

Добавлением стороннего канала https://gitlab.com/nonguix/nonguix

eDSL круче, можно обрабатывать средствами хостового языка и расширять семантику, а не ожидать xxx лет, что в язык добавят нужные тебе фичи.

Лол, и каких фич в языке Nix тебе не хватает?

Лисперам не хватает макросов и прочего метапрограммирования, нормальным людям же не хватает типов.

Лол, и каких фич в языке Nix тебе не хватает?

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

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

По содержанию треда, видно то ты как раз из таких лиспофанатиков, что пилят Guix.

Спасибо, сочту за комплимент.

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

А у тебя есть опыт использования NixOS, можешь поделиться впечатлениями?

Nix я пробовал еще очень давно, когда он имел проблемы без допила, а допилом заниматься желания не было. Сейчас же уже и не смотрю на подобные дистры, их подход не для меня. Слежу, может они осознают свои проблемы и у них случится революция, но пока оно к тому не идет. И проблемы не в выборе ЯП.

может они осознают свои проблемы и у них случится революция

Какие там проблемы?

И проблемы не в выборе ЯП.

Это очевидно, но лучше писать сразу на нормальным яп. Хотя я бы выбрал для этих целей не guile, а CL.

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

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

Использование в других дистрах Nix весьма грязное. В Nix не считают видимо достойным делом опуститься для поставки своего пакетного менеджера через нативный формат пакетов дистра и тем более продвижение в репозитории популярных дистров, а вместо того предлагают ставить свой через скрипт от рута. Да, в Nix хотят чтобы вот так ставили их ПМ, чтобы он там мог производить изменения корне.

Более того, это просто очень хреново совместимо с самой организацией других дистрибутивов. Так, Nix продвигался немного и для MacOS, и все превратилось в тыкву, когда те представили свой подход к атомарным обновлениям и перевели корень в RO в MacOS Catalina. А Nix просто хочет создавать и писать в /nix/ и это жестко задано и неизменяемо. Но не только макось, линуксовые тоже начинают использовать подходы с атомарными обновлениями и корневой ФС в режиме чтения, и так или иначе, к этому идет, из-за замечательной отказоустойчивости. Вот это в Nix не предусмотрели, что оказывается не только у них может быть RO корень, но где угодно, и Nix там будет иметь проблемы. Как насчет использования Nix в Guix и наоборот?

Вот и выходит, что это никакое не универсальное решение, а лишь очередной дистр. Да, с большими возможностями и отсутствием dephell’а, но тем не менее.

Ты правильные мысли озвучил, я тоже не понимаю весь этот зоопарк, и нормальная система pm, на мой вкус, должна быть организована как мета-система: то есть, чтобы этот менеджер пакетов можно было установить в любой дистр, с его пакетным форматом. Если не хватает какой-то метаинформации, например, поверх .deb или .rpm - хранить ее в отдельном месте, каком-нибудь аналоги ebuild-а поверх штатного пакета. Мне тоже очень странно наблюдать весь этот зоопарк, когда можно использовать уже готовые репы, различные ядра на любой вкус итд. И для этого не обязательно ломать FHS, просто чуток пропатчить.

Лол, и каких фич в языке Nix тебе не хватает?

Можешь поискать реквесты людей по запросу (add|new) builtin в issues на гитхабе.

Да просто пример про «однократное вычисление» на пальцах в разрезе обсуждаемой темы подойдет.

Я так понимаю, про конструкции вида

f x = a x + b x 
  where 
    a x = longcomp x
    b x = longcomp x

Haskell может произвести вычисление longcomp x дважды.

А в racket есть возможность организовать подобное вычисление единожды? Как я себе это представляю - придется организовать подобие where на макросах, и сопоставлять эквивалентность независимых друг от друга внутренних форм и их подформ. На сколько просто это можно реализовать хз.

Лол, и каких фич в языке Nix тебе не хватает?

Человеческая модификация (расширение, изменение) уже существующего пакета. А не хак посредством ущербного override (который не в самом языке nix).

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

Если бы я задался задачей это реализовать, то делал бы мета-пакетный / мета-дистр менеджер, то есть поверх ebuild, deb, rpm итд + использование реп.

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

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

Это язык для конфигураций, не нужен там еще один Тьюринг-полный язык.

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

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

Щас бы различать Тьюринг-полные языки (которые одинаково плохие из-за проблемы останова) по способности описать конфигурации (допустим, что не полные по Тьюрингу).

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

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

Щас бы различать Тьюринг-полные языки (которые одинаково плохие из-за проблемы останова) по способности описать конфигурации

Опиши xml / sql в синтаксисе питона, например. Или на своем С, посмеемся :)

будет очень хреновенько выглядеть

Ну конечно же, 10 закрывающих скобок отлично выглядят.

xml

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

sql

Не эксперт. Но вроде тоже Тьюринг-полный.

Ну конечно же, 10 закрывающих скобок отлично выглядят.

Да.

xml

Сложный контексто-зависимый язык.

Я не предлагаю на xml-e писать конфиги. Это просто пример того, что далеко не на всех языках можно (удобно) организовать различные форматы хранения данных / конфигов, в лиспе можно и выглядит это красиво. Ты ж на С предложил конфиги писать, это не намного лучше, чем на ini, а в основном и хуже.

Не эксперт. Но вроде тоже Тьюринг-полный.

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

Ну конечно же, 10 закрывающих скобок отлично выглядят.

Да.

Тебе и xml так же нравится?

различные форматы хранения данных / конфигов, в лиспе можно и выглядит это красиво.

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

Хотя… для тебя xml - эталон красоты.

нормальном языке можно писать конфиги (данные), которые легко обрабатывать средствами яп.

Сколько не работал с форматами данных, либо они удобны для машины, либо для человека, либо это xml неудобно ни для человека, ни для машины.

Тебе и xml так же нравится?

Нет, он практически для всего плохой.

различные форматы хранения данных / конфигов, в лиспе можно и выглядит это красиво.

Красиво выглядит только после ручного форматирования.

Зачем ручного? Автоматически все форматируется или по хоткеям.

Не дай боже автоматическим форматером пройдешься - будет выгдядеть хуже чем xml.

С чего бы вдруг? Ты их хоть видел те автоматические форматеры лисп-кода? (я знаю, что нет)

Хотя… для тебя xml - эталон красоты.

Ну вот где ты это увидел? :)

нормальном языке можно писать конфиги (данные), которые легко обрабатывать средствами яп.

Сколько не работал с форматами данных, либо они удобны для машины, либо для человека

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

либо это xml неудобно ни для человека, ни для машины.

Да с чего ты взял, что я предлагаю хранить что-либо в xml?!

С чего бы вдруг? Ты их хоть видел те автоматические форматеры лисп-кода? (я знаю, что нет)

Атоматический форматер для лиспа начинает более менее нормально форматировать только после того как в него загнать как форматировать все ключевые слова. И этот форматер узко специализирванный.

Потому что лисп - это двоичное дерево с узлом (голова . хвост). Вот и всё его форматирование.

Красиво выглядит двоичное дерево?

Дальше форматировать можно только зная информацию о узлах, то есть надо знать то, что выше самого языка, надо знать решаемую задачу - «рисуешь» html или комбинируешь комбинаторы.

Есть компромисные варианты - вот лисп как раз из этой оперы.

Лисп - это не копромисный вариант. Это формат близкий к машине. Человеку это читать очень трудно без узко-специализированного как-бы ide.

А в racket есть возможность организовать подобное вычисление единожды?

Есть мемоизация. В haskell с ней всё гораздо сложнее (https://wiki.haskell.org/Memoization).

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

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

  where 
    a x = longcomp x
    b x = longcomp x

то потом возникает желание потребовать от компилятора разрешать ситуации типа

  where 
    a x = longcomp (x + 1)
    b x = longcomp (x + i)
    i = sin y * sin y + cos y * cos y

или даже

    fib n = fib (n-2) + fib (n-1)