LINUX.ORG.RU

Выход GNU Guix и GuiSD 0.16.0

 , ,


0

4

«Мы рады заявить о выходе GNU Guix и GNU GuixSD версии 0.16.0, содержащих 4515 коммитов от 95 человек за 5 месяцев. Надеемся, это последний релиз перед 1.0», — пишет Людовик Куртес (Ludovic Courtès) в блоге проекта.

GNU Guix — это транзакционный пакетный менеджер. GuixSD — дистрибутив операционной системы GNU, работающий с пакетным менеджером Guix, подсистемой инициализации Shepherd, ядром LinuxLibre, и поддерживает архитектуры i686, x86_64, armv7, aarch64.

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

Guix использует низкоуровневые механизмы, похожие на реализованные в пакетном менеджере Nix, но здесь пакеты определены как модули на языке Guile с использованием расширений языка Scheme. Guix может использоваться для управления пакетами в уже установленном дистрибутиве GNU/Linux.

Основные изменения:

  • Зеркало проекта изменилось на https://ci.guix.info. Сервер с был предоставлен Берлинским институтом медицинских систем в Центре Макса Делбрюка. Фронтенд работает на Cuirass, созданном в рамках инициативы GSoC.
  • guix pull теперь включает опцию --profile, которая позволяет иметь несколько ревизий Guix параллельно.
  • guix pull теперь поддерживает каналы. Вы можете задать каналы в ~/.config/guix/channels.scm, и guix pull будет обращаться к ним, так же можно задать сторонние репозитории. Информация о каналах отражается в guix describe, а guix describe -f channels представляет код, который можно использовать непосредственно в channels.scm.
  • Используя новый механизм inferior, вы можете взаимодействовать с различными ревизиями Guix или даже сравнивать пакеты, поставляемые разными ревизиями Guix.
  • Новые опции работы с пакетами --with-branch и --with-commit позволяют получить версию пакета непосредственно из его Git-репозитория.
  • Guix имел воспроизводимые сборки, а теперь — восстанавливаемый исходный код. Когда пакет ссылается на репозиторий Git, который исчез (что, к сожалению, иногда происходит), ошибка устраняется с помощью Software Heritage. Это делает Guix одним из первых дистрибутивов, который можно восстановить из архивов, хранимых долгое время. Подробнее — в этом патче.
  • Наш пакет Rust теперь полностью генерируется из исходников, начиная с mrustc — компилятора Rust, написанного на C++.
  • Добавлено 985 пакетов, обновлены — 1945, например библиотека GNU C версии 2.28.
  • Сегодня Guix содержит 8715 пакетов.
  • Руководство переведено на немецкий, на 90% готов французский перевод. Вы можете помочь нам перевести руководство на ваш родной язык.

Пользователи Guix могут обновиться командой guix pull.

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

>>> Подробности

★★

Проверено: jollheef ()
Ответ на: комментарий от intelfx

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

PtiCa ★★★★★ ()
Ответ на: комментарий от Chelobaka

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

ados ★★★★★ ()
Ответ на: комментарий от ados

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

Chelobaka ★★★★★ ()

Guix имел воспроизводимые сборки, а теперь — восстанавливаемый исходный код. Когда пакет ссылается на репозиторий Git, который исчез (что, к сожалению, иногда происходит), ошибка устраняется с помощью Software Heritage. Это делает Guix одним из первых дистрибутивов, который можно восстановить из архивов, хранимых долгое время.

Вот это круто. У NixOS есть свой архив tarballs.nixos.org, но неплохо бы и Software Heritage добавить. А ещё лучше - объединить усилия. Архивы-то общие.

anonymous ()

Наш пакет Rust теперь полностью генерируется из исходников, начиная с mrustc — компилятора Rust, написанного на C++.

Радует, что в проекте GNU серьёзно подходят к воспроизводимости. Потом ещё GNU Mes допилят, и вообще им равных не будет. NixOS пускай берёт пример.

anonymous ()

Не котов

Хотел поюзать сабж на VPSке, где отсутствие блобов не помеха. Но оказалось, он LVM до сих пор не поддерживает.

anonymous ()
Ответ на: комментарий от anonymous

Вот бы ещё программисты и учёные начали всерьёз задумываться о воспроизводимости. Хотя, признаки улучшения есть:

a more powerful build farm with terabytes of storage kindly donated by the Bioinformatics platform of the Berlin Institute of Medical Systems Biology (BIMSB) at the Max Delbrück Center (MDC)

— в центре молекулярной медицины имени Макса Дельбрюка уже задумались.

Begpoug ()

Очень упоротая у него концепция «перепишем всё на Guile» (Shepherd), никакой проприетарщины, функциональное задротство с eDSL и G-expressions. Из интересного только подход с bootstrappble builds, но мне GNU Mes руками в отрыве от Guix пока не получилось собрать - очень скудная документация.

Правильная системе сборки достаточно просто брать сборочный рецепт из единого репозитория в формате типа того же rpm spec, строить граф зависимостей между ними, и по хешу от bash вставок и исходников кешировать артефакт сборки. Собирать в контейнере, параллельные альтернативные версии одного софта - в контейнер с другим configure prefix руками. Плодить по 10 версий одного пакета в одной системе - зло с точки зрения аудита безопасности. И никакого функционального языка тут не нужно.

snizovtsev ★★★ ()
Ответ на: комментарий от Unicode4all

Ванильное ведро

Я хотел попробовать guixsd, но там ведро оказалось слишком швабодное и отказалось запускаться на моём железе.

Таки да, но в интернетах чуть более чем дохрена scm'ов сколь-угодно ванильного ядра.

Camel ★★★★★ ()
Ответ на: комментарий от snizovtsev

Победимое зло

Плодить по 10 версий одного пакета в одной системе - зло с точки зрения аудита безопасности.

Это зло легко побеждается силами самого guix'а. Если 10 программам нужна, например, PolarSSL — собираем все 10 программ разом с единственной версией PolarSSL, раздаём получившийся бинарник как substitute. Получаем, по-сути, то же самое что в пекадж менеджерах из прошлого века, типа APT или RPM. С той лишь разницей, что если какая-то одна программа всё же требует другую версию PolarSSL, то мы можем её собрать с другой версией и запустить. Это может быть неудобно для безопасников, но угадайте куда им предложат пойти, если они выставят ультиматум: «либо мы следим за двум версиями PolarSSL, либо одна нужна программа вообще не работает».

Camel ★★★★★ ()
Ответ на: Ванильное ведро от Camel

Вдогонку

Править не даёт, приходится писать отдельным сообщением.

Швабодный Linux даже графоний на моём ноутбуке не показывает, пришлось модуль Xorg'а добавлять. Это было 2 года назад, сейчас таких проблем нет.

Camel ★★★★★ ()
Ответ на: комментарий от t184256

Ага, на практике в банке там в /nix/store будет 10 сборок openssl 2-3 версий, с разными флагами и собранными разными тулчейнами. По одной-две на каждую команду разрабов. Примерно как с докером.

snizovtsev ★★★ ()
Ответ на: комментарий от snizovtsev

Ага, на практике в банке там в /nix/store будет 10 сборок openssl 2-3 версий, с разными флагами и собранными разными тулчейнами. По одной-две на каждую команду разрабов. Примерно как с докером.

Те-о-ре-тик.

Совершенно неважно, что там в /nix/store, важно, что в активном профиле. А пока никто явно не начнет городить такую фигню, openssl там будет один. А никто не начнет, потому что банка с NixOS в мире всего два и в обоих умные люди работают.

t184256 ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от x4DA

Например, посмотри как реализованы override'ы. Также сам формат хранения derivation - какой-то топорный велосипед, который сильно похож на какую-то студенческую поделку птушника. Почему не использовать json/xml или что-нибудь похожее, можно чуть упрощенное и порезанное. Кстати, guix использует nix-store, что уакнентся в будущем.

anonymous ()

А в каких дистрах ваще есть этот guix? в дебиане нету. Но ваще идея прикольная с установкой софта в разные папки. Этот как разные виртуалки. Изоляция, прозрачность, всё такое... но компилишные на любителя. Ну вот собирал ты сутки систему из исходников, а вдруг код кривой попался и деление на ноль? И как это вообще выглядит, если одна софтянка собирается scons'ом, другая рубями, третья make, ещё qmake, cmake и прочие configure? А потом всё это повторять на сотне другой компов/серверов/виртуалок? То ли дело бинарники ммм... пребилды ммм...

anonymous ()
Ответ на: комментарий от anonymous

в дебиане нету

Глубоко пофиг, чего там нету в очередном systemd-based дистрибутиве, гыгы

Ну вот собирал ты сутки систему из исходников

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

И как это вообще выглядит ..

см. выше

anonymous ()

Звучит вкусно, жаль, мое общение с ПМ обычно сводится к редкому вызову apt install <something>, поэтому зачем мне всё это богатство(?)

Наш пакет Rust теперь полностью генерируется из исходников, начиная с mrustc — компилятора Rust, написанного на C++.

Интересно, кто упоролся написать свою реализацию компилятора, и насколько она совместима с референсным rustc?

Virtuos86 ★★★★★ ()
Ответ на: комментарий от anonymous

Вот. По заверениям автора, собирает из сорцов рабочие бинарники rustc и cargo. Borrow checker отсутствует, что несколько снижает полезность.

Я бы сказал, что сильно сужает полезность.

Virtuos86 ★★★★★ ()