Вышел GNU Guix 1.0.0

А на guix вообще никаких вакансий я пока нигде не видел.

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

extraCommands = builtins.mapAttrs (_: v: "iptables -A OUTPUT -d ${v} -j ACCEPT) vpn;

Как два пальца об асфальт.

import (builtins.fetchGit {...}) {}, вроде бы. Ну либо где-то ещё внутри инкрементальный гит, но это потом

Завезли, только не очень работает.

А шо, не так чтоли? :)

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

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

Да, nix требовательный к пользователю с точки зрения знания ЯП.

Ординалы не имеют смысла для вещественных чисел. 1.0 не является «первым» вещественным числом. Поэтому хочу заметить, что первая версия вышла уже 7 лет назад.

В Nix 2.0 некоторые проблемы решили, но в целом UX отстает. Хотя бы теперь не нужно использовать веб интерфейс для поиска пакетов, лол, ибо было невыносимо медленно.

Задолго до nix 2.0 были nox и nix-env -qa > packages.list | grep ... packages.list

extraCommands = builtins.concatStringsSep "\n" (builtins.mapAttrs (_: v: "iptables -A OUTPUT -d ${v} -j ACCEPT) vpn);

, конечно.

Переходи к следующему пункту.

Раньше у меня было такое в конфигах.

В чем проблема каналов?

Ординалы не имеют смысла для вещественных чисел. 1.0 не является «первым» вещественным числом. Поэтому хочу заметить, что первая версия вышла уже 7 лет назад.

Почитай про версионирование.

Проблема каналов в их императивности. Eelco хочет чистоты в nix, и она достигается либо fixed-hash деривэйшенами (fetchurl, fetchTarball) либо fixed-commit (fetchGit).

Я про то, что называть 1.0.0 «первой версией» не совсем верно.

0.0.1 – версия? Да, версия. А какой у неё номер получается, если называть 1.0.0 «первой»? Никакой?

А у 1.0.1 номер какой? Второй? или опять нет номера?

Короче говоря, лучше не натягивать сову на глобус и говорить не «первая версия», а «релиз».

Проблема каналов в их императивности. Eelco хочет чистоты в nix, и она достигается либо fixed-hash деривэйшенами (fetchurl, fetchTarball) либо fixed-commit (fetchGit).

Да я бы не сказал, что это проблема. Я каналы как раз и использую из-за того, что оно само по себе находится на bleeding edge.

Если определенную версию пакета нужно поставить, то fetchGit во все поля, но если привык держать последнюю версию Chromium – он что предлагает, руками бампать?

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

Тут расходятся ваши идеи о том, что должен представлять из себя Nix, и идеи остальных разработчиков. У разработчиков была мысль сделать язык с чётким разделением на build-time (сборка nix-expressions в .drv) и eval-time (сборка .drv). При этом build-time в идеале должен быть абсолютно чистым и никакого «резолва» доменного имени в нем быть не может. То, что вы хотите сделать, можно прикрутить «сбоку» в виде, например, JSON-файлеца рядом с конфигом с автообновлением по скрипту.

само по себе находится на bleeding edge.

system.autoUpgrade? Так можно аналогично и для fetchGit вынести версии в JSON-файлец и обновлять его по таймеру.

что предлагает, руками бампать?

В nix будут специальные инструменты для этого, а пока что можешь глянуть на текущую реализацию у меня. Я использую git submodules и храню в нем nixpkgs, благодаря этому обновление до последней версии проходит в две команды.

Я про то, что называть 1.0.0 «первой версией» не совсем верно.

Можно добавлять «мажорной» для повышения однозначности. Но в выражении «первая версия была 10 дней назад» – что имеется ввиду весьма очевидно.

Короче говоря, лучше не натягивать сову на глобус и говорить не «первая версия», а «релиз».

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

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

Это не было идеей о том, что должен из себя представлять Nix. Это описание ограничений.

Функциональная чистота как раз центральная идея никса.

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

system.autoUpgrade? Так можно аналогично и для fetchGit вынести версии в JSON-файлец и обновлять его по таймеру.

Костыльно.

В nix будут специальные инструменты для этого, а пока что можешь глянуть на текущую реализацию у меня.

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

Судя по тону сообщений, вас эти ограничения не устраивают.

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

Далее, в принципе – аналогично. По тексту сообщения не похоже, чтобы ты вообще со мной говорил, ибо после прочтения моих сообщений на тему NixOS подобное писать весьма бессмысленно.

Функциональная чистота как раз центральная идея никса.

Надо же! А я и не догадывался.

Ровно настолько же костыльно, как и autoUpgrade. Он делает на самом деле ровно то же самое.

Ну тогда почему предлагаешь грязные решения?

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

Что, в целом, отрицает какую-либо возможность говорить с тобой конструктивно.

Упоминать про то, что дистрибутивы вроде Guix наиболее удобны для того, чтобы имея базу свободного ПО добавлять те проприетарные части, которые необходимы (просто добавляя канал/fetchGit аналогично NixOS) – наверное излишне.

Ну тогда почему предлагаешь грязные решения?

Guix это тоже purely functional package manager.

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

Что, в целом, отрицает какую-либо возможность говорить с тобой конструктивно.

А удаление сообщения из-за того, что я называю вещи своими именами (а навязанная свобода – это не свобода, а кое-что другое) – прям верх конструктивной беседы, да.

Упоминать про то, что дистрибутивы вроде Guix наиболее удобны для того, чтобы имея базу свободного ПО добавлять те проприетарные части, которые необходимы (просто добавляя канал/fetchGit аналогично NixOS) – наверное излишне.

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

Хотя, для любителей настоящей ш свободы это, наверное, просто отлично.

И я говорил не про устаревание свободного ПО (я обеими руками за его развитие), а про заведомую провальность идеологии GNU (например, когда clang отказываются интегрировать в emacs, а сборка chromium в guix превращается в ад). Навязанная свобода – это не свобода, а вполне себе наоборот.

Людям нужно работу работать, а не только ш свободой заниматься. И для этого NixOS (пока что) подходит гораздо лучше, чем Guix, и я не наблюдаю особых причин для изменения этого положения.

Если оно изменится и мне правда станет удобнее писать код из и на Guix, то я начну это делать.

Нет, Guix – это точно не шаг назад. Оставляя функциональную чистоту в рамках пакетов – Guix не ограничивает пользователя возможностями.

Мы теряем как раз гарантию чистоты на уровне пакетов и модулей – в них может выполняться произвольный код.

От того, что ты напишешь build script не на bash, как это делается в Nix, а на Guile – уж точно никакой гарантии чистоты не потеряется.

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

Новая генерация происходит после завершения вычисления описания конфигурации.

Только вот теперь это не «вычисление», а «выполнение». Результат вычисления должен зависеть только от входных параметров, а не от того, во что там резолвятся доменные имена.

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

По такой логике можно рассовывать unsafePerformIO повсюду и тоже говорить «одна строка кода вместо костылей». Только вот почему-то делать так не принято. Почему – да потому что противоречит идее чистоты, ради которой все и затевалось. Из одного кода у нас должны получиться одинаковые результаты. Если ЯП не чистый – гарантировать этого нельзя. Зачем тогда нужен чистый ПМ?

Только вот почему-то делать так не принято.

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

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

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

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

Сабмодули гарантируют одинаковые результаты при одинаковом коммите в репозитории. Каналы, unsafePerformIO или сортировка по пингу в конфиге – не гарантируют, а скорее наоборот.

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

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

Так пока что о реальность разбивается как раз Guix, не находите? Я вот попробовал накатить 1.0.0 с несколькими интересными мне пакетами. Ну так вот:

1. Хромиум собирается у меня из исходников
2. Кеды я так и не осилил накатить
3. Никакого аналога home-manager нет и не предвидится, так что декларативные конфиги хомяка отпадают
4. Пакетная база на схеме печальна

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

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

Я же ещё раз повторяю: это не религия, это желание завтра утром включить компьютер и работать, а не хромиум из исходников собирать или чинить невоспроизводимые билды у разработчиков. Когда (если) оба эти пункта будут легко решаться на сабже – я с радостью свалю с NixOS, ибо тоже очень интересно писать всё на одном языке. Пока что даже в перспективе я вижу лишь навязывание идеологии «только GNU, только свобода» и бесчисленные возможности выстрела себе в ногу.

Я же ещё раз повторяю: это не религия

home-manager нет и не предвидится

не предвидится

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

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

Запрета подключать репозитории с несвободным ПО в Guix нет. Прекращай, это уже даже не смешно.

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

Это я говорю после расспрашивания в IRC и телеграме в соответствующих каналах. Никто не знает, как реализовать (вернее, кто-то предложил, но нерабочий способ…). Ну и учитывая то, что уже 7 лет идет разработка, а у сообщества нет даже идей реализации, не предвидится home-manager в guix.

Запрета подключать репозитории с несвободным ПО в Guix нет. Прекращай, это уже даже не смешно.

Только вот и удобства их подключения тоже нет. Почему в NixOS я делаю nix build nixpkgs.chromium и у меня скачивается уже собранный бинарь, а guix мне приходится компилировать? И это даже не ПО с закрытыми исходниками, это опен-сорц (но не FOSS), причём активно разрабатываемый и очень популярный. Я называю это «навязанной свободой» – и я не очень хочу этим пользоваться, потому что МНЕ НЕУДОБНО. Не религиозное отвращение к схеме, не отрицание свободного ПО – неудобство.

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

С недоумением написал это сообщение из Guix с Chromium, который я просто поставил и точно не компилировал.

Остановись, ты со своей ненавистью к GNU уже начал откровенную ложь писать.

Что делал я:

1. скачал образ https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz
2. установил в virtualbox
3. допилил стандартный конфиг, попытался включить кеды
4. fail
5. включил xfce и добавил нужных приложенек
6. оставил конфиг собираться
7. увидел сборку chromium
8. выключил и удалил машину нафик.

ЧЯДНТ?

Хорошо, начинаем попытку 2.

Я просто сделал guix search chromium, увидел название пакета, запустил guix install ungoogled-chromium, оно скачалось и поставилось.

Ощущение, что из исходников собираются всё время случайные пакеты – в этот раз libvdpau, что-то из xlibs, xf86-*, cups и ещё какая-то хрень. Как будто CI не успевает собирать.

chromium пока не пробовал ставить, решил начать с чистой системы.

И при установке ungoogled-chromium он конечно же начинает собираться.

https://pic4a.ru/ihKa/

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

Нет, хрен там.

https://pic4a.ru/ixc2/

Дата – текущая.

Что я делал:

1. Скачал установщик, проверил sha.
2. Загрузил его в VirtualBox [Other Linux 64 bit, 2GB RAM, 8GB VDI]
3. В этот раз не стал запариваться с написанием конфига, просто выбрал дефолты (+i3)
4. В свежезагруженной системе: a) guix pull b) guix install xterm c) guix install ungoogled-chromium d) Получил пикчу

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

И да, заметка для себя на будущее: религия – это как раз GNU-лагерь, ш свободный и беспощадный. Я конечно подожду пару месяцев и попробую guix system снова, но… Что-то мне подсказывает, что ничего не изменится и я опять увижу сборку половины нужного софта из исходников.

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

Еще раз, я использую на Guix Chromium, который не собирал. Следовательно твои слова о том, что бинарной сборки Chromium в Guix нет – ложь.

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

Эта статья? Там в комментариях написали что хотят видеть статью про GuixSD.

я не могу назвать, что он популярен

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

Не вижу особой проблемы, если основной репозиторий не будет содержать проприетарного ПО.

Так проблема не в этом, а в именном в том, что репозитория с проприетарным софтом и не libre-ядром пока вовсе нет. Сделали бы как в дебиане например.

Будь добр, расскажи как именно ты это сделал - чтобы в виртуалке можно было воспроизвести. Вот у Balsofta не срастается и он пошагово расписал что именно делал.

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

Установил, набрал `guix install ungoogled-chromium`.

Результат: https://imgur.com/a/e2EFPhO

Эта статья? Там в комментариях написали что хотят видеть статью про GuixSD.

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

GuixSD я пока активно не использовал, ибо ждал первой мажорной версии.

Так проблема не в этом, а в именном в том, что репозитория с проприетарным софтом и не libre-ядром пока вовсе нет.

Я репозитории видел с !libre-ядром, но меня они как-то совсем не впечатлили. Надо свое делать и продвигать, по всей видимости.

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

а [в] guix мне приходится компилировать [chromium]

Что и доказываю путем пикчи и инструкции по её повторению.

То, что вы там себе придумали про «бинарной сборки нет» не имеет к моим словам никакого отношения.

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

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

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

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

Я ей хочу пользоваться

Не смеши. Только что ныл на тему того, как GNU ограничивает твою свободу, а теперь внезапно «хочешь пользоваться».

Просто у тебя GNU-фобия, и единственная цель твоих сообщений — сломать что-то и после ныть о том, как все плохо.

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

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

Если поменяется и станет юзабельным – я перелезу, что непонятного?