The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Документация для Linux" (Архив | Для печати)

Guix: Самая совершенная операционная система

Оригинал статьи: https://ambrevar.xyz/guix-advance/

Перевел Google и NuINu

Быстрый обзор истории операционных систем

Операционные системы (ОС) представляют собой очень большую тему и на протяжении десятилетий в них доминировал единственный подход: Unix. Действительно, большинство современных систем, включая большинство дистрибутивов GNU/Linux, *BSDs, и macOS следуют дизайну Unix. (Windows ему не соответствует, но он и не имеет интересных особенностей под рукой.)

В 2000 году, Rob Pike выступил с докладом о том почему Исследование системного программного обеспечения не имеет значения. Будь то из за пессимизма или пренебрежения к сообществу, похоже он полностью отбросил все призывы, которые собрали многие пользователи Unix в 1994 в The Unix-Haters Handbook. Несмотря на целенаправленную саркастичность, эта книга указала на некоторые критические проблемы с системами Unix, которые до сих пор не решены.

В 2006, Eelco Dosltra опубликовал свою дисертацию, Модель развертывания чисто функционального программного обеспечения, в которой представлен Nix, функциональный менеджер пакетов. В 2008, он опубликовал NixOS: Чисто Функциональный дистрибутив Linux. В то время как NixOS повторно использует много свободного программного обеспечения, которое традиционно предназначалось для систем в стиле Unix, оно настолько сильно отличается от дизаайна и философии Unix, что его уже вряд ли можно назвать системой Unix.

Nix - это огромный шаг вперед в иследовании операционных систем. Мало того, что он направлен на большую часть критики Unix (включая те, что описаны в справочнике Unix Haters Handbook), он также прокладывает путь для многих других функций и исследований, которые могут быть критически важными в наши дни, когда такие темы как надежность и доверие находятся в центре не только многих научных, но также и социальных и политических дискуссий.

Pike был не прав! И это доказывает еще один более общий момент: вероятно, разумнее воздержаться от заявления о том, что любое исследование стало неактуальным, если только вы не докажете, что дальнейшее развитие(разработка) невозможно. И разговор о Юте(Utah) вряд ли был математическим доказательством. Это только послужило дальнейшему утверждению идеи о том, что Unix достаточно хорош и что мы должны жить с его специфическими особенностями и проблемами.

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

Введение в Guix

Guix - это менеджер пакетов основанный на Nix, а GuixSD это эквивалент операционной системы NixOS. GuixSD стремиться быть полностью программируемой ОС. Действительно, в основном всё от управления пакетами (с Guix) до системы инициализации(init system) (GNU shepherd) написано и настраивается в Guile Scheme.

Он значительно отличается от операционных систем в стиле Unix, и вам возможно захочется прочитать еще немного, прежде чем вы получите хорошее представление о степени изменений:

Перки(Преимущества) Guix

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

Мои любимые функции:

  • Нерушимость системы: Guix ведет историю всех изменений как на уровне системы, так и на уровне пользователя. Если обновление, что-либо нарушает, всегда можно выполнить откат. Это эффективно делает систему нерушимой.
  • Целостность системы: поскольку конфигурация системы декларативна, пользователь или системный администратор полностью контролирует происходящее в системе. понимания того, что происходит. В других Unix системах, гораздо сложнее определить, когда какой-либо случайный файл конфигурации был изменен.
  • Полностью программируемая операционная система: запрограммируйте конфигурации вашей системы и держите их под управлением системы контроля версий. Многие системные службы могут быть настроены в Guile Scheme, от правил udev до Xorg, PAM, и т.д.. Благодаря Guile, конфигурация может быть сделана условной для аппаратного обеспечения или даже для имени хоста(hostname)!
  • Замена других (не очень хороших) пакетных менеджеров: не нужно отдельно управлять пакетами Emacs, Python или TeXlive, вы можете использовать один унифицированный интерфейс для управления ими всеми! (См ниже.) Это значительно облегчает написание и сопровождение профилей пользователей.
  • Определения пакетов с испольованием Guile: это гораздо эффективнее разрабатывать определения(переопределения) пакетов массово. Оно выгодно заменяет такие понятия как USE флаги Portage (см ниже).
  • Несколько выходов пакета: пакет Guix может иметь несколько выходов, которые служат средством для разделения различных компонентов программы(библиотеки, дополнительные утилиты, документация, и т.д). В других операционных системах (чаще всего в Debian), будет сложнее угадать, какие пакеты принадлежат друг другу.
  • Не распространяемые входы: Входы, на языке Guix являются зависимостями пакета. Профиль пользователя и среда содержат только те пакеты, которые польозватель явно установил, и не обязательно зависимости этих пакетов. См например inxi инструмент для создания отчетов о системной информации: если я забочусь только о системных/аппаратных отчетах inxi, я не обязательно хочу, чтобы к моей переменной PATH добавлялись 2 или 3 десятка дополнительных инструментов коммандной строки. Guix позволяет отображать в профиле пользователя только то, что пользователь действительнро хочет.
  • Среды(Окружения) Guix: При запуске guix environment SOME-PACKAGES, Guix устанавливает временную среду, в которой выставляются все требования для SOME-PACKAGES. Это может использоваться для настройки среды сборки для проекта, но также может использоваться для других целей(см ниже). Одним из замечательных свойств является то, что он позволяет запускать программы, н устанавливая их в профиль польователя.
  • Частичные обновления: они поддерживаются на 100%. Возможно, это является основной причиной сбоев в системах с непрерывным выпуском(rolling-release), таких как Arch Linux и Gentoo: поскольку одновременно поддерживается только несколько версий (в основном только одна), необходимо обновить всю систему одновременно. Что означает значительное использование полосы пропускания интернета при каждом обновлении. С Guix, вполне возможно обновить любой пакет индивидуально.
  • Непрерывная интеграция или Почему Guix может работать без сопровождающих пакеты людей(maintainers): Благодаря воспроизводимым сборкам(reproducible builds) и поддержке частичного обновления, когда пакет работает в Guix, он работает всегда, он не сломается при следующем обновлении некоторой зависимости. (Точнее, если зависимость разрушает пакет, просто исправить ее используя правильную версию библиотеки.) Это означает, что рабочую нагрузку по пакетам можно перенести на фермы сборки (одна работает под управлением Hydra из проекта Nix, другая работает под управлением Cuirass). Сравните это с большинством других сообществ GNU/Linux, которым требуется пара десятков сопровождающих, чтобы обновлять тысячи пакетов. Это не маштабируется: в конечном итоге эти операционные системы останавливаются на паре тысяч пакетов. С Guix, количество пакетов может безопасно расти не опасаясь краха. Тем временем, времени участников можно найти лучшее применение.

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

  • guix import и guix refresh: генерация или обновление определений пакетов автоматически и рекрсивно. Сотни определений пакетов могут быть обработаны одновременно. Подобные функции подчеркивают преимущество наличия настоящего языка программирования под рукой. То, что является трудной проблемой в большинстве операционных систем, становиться относительно легко реализовать с помощью Guix.
  • Guix каналы: Одна из моих любимых функций! В Arch Linux или Gentoo, нужно будет создать локальный репозиторий. Поскольку они не поддерживают частичное обновление, это означает, что пользователь должен время от времени выполнять некоторое обслуживание(то есть убеждаться, что обновления зависимостей не нарушают пакеты пользователя) Например, наследование пакетов позволяет очень легко настраивать пакеты с помощью патча. Guix каналы выгодно заменяют наложения(overlays) Arch Linux AUR и Gentoos, позволяя любому распространять определения своих пакетов, например, из репозиториев Git. Опять же, это гарантирует полную прозрачность (откаты, история и т.д).
  • Emacs-Guix: Guix единственный дистрибутив который я знаю, который поставляется с самым мощным пользовательским интерфейсом Emacs!
  • Guix пакеты: Они позволяют создать альтернативу контейнерам, таким как Docker. Большинство контейнерных систем страдают от критических проблем: они не воспроизводимы и действительно являются непрозрачными двоичными файлами, что является большим запретом для пользователей, которые заботятся о доверии, безопасности и конфиденциальности. Напротив, пакеты Guix полностью определены, вопспроизводимы и прозрачны.
  • guix system vm и guix system disk-image: Guix позволяет записать текущее состояние системы в видее live USB или окружений для виртуальных машины или удалённых систем.

Guix по сравнению с конкурентами

Debian, Arch Linux, и другие дистрибутивы GNU/Linux

В дистрибутивах GNU/Linux вообще отстутствуют вышеупомянутые преимущества(перки) Guix. Некоторые из наиболее важных моментов включают в себя:

  • Отсутствие поддержки нескольких версий пакетов, или ад зависимостей. Скажем, когда последний mpv требует нового ffmpeg, но обновление ffmpeg ломает большинство других программ, полагающихся на него, у нас возникает дилема: либо мы ломаем некоторые пакеты, либо мы придерживаемся более старых версий других пакетов. Хуже того, программа может быть вообще не иметь пакета или поддерживаться данной ОС. Эта проблема присуща большинству дистрибутивов, которые не могут предоставить гарантии для выполнения своей основной задачи: упаковки(пакетирования) любой программы.
  • Критическая потребность в сопровождающих. Не функциональное управление пакетами означает, что все пакеты должны всегда тестироваться вместе. Это представляет собой большую тяжелую работу, которая зависит от преданной команды сопровождающих. На практике это означает, что качество управления пакетами сильно зависит от рабочей силы. Дистрибутивы без достаточного количества сопровождающих(maintainers) неизбежно пострадают, и возможно умрут. Это требование рабочей силы плохо маштабируется и вызывает растущую сложность(как для кодовой базы, таки с точки зрения управления) по мере увеличения количества пакетов.

Gentoo, *BSD

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

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

И наоборот, Guix дает вам полную настройку для всего, хотя с немного большим количеством кода на Scheme. Грубо говоря на псевдокоде:

(loop-over (TARGET-PACKAGES)
  (package
    (inherit TARGET)
    (changes-here... including patches, build options, etc.))

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

Я любил Gentoo когда использовал его, но после перехода на Guix стало очевидно, что подход Portage к настройке пакетов более ограничен.

  • Система флагов USE не позволяет настраивать незапланированные, произвольные функции.
  • Флаги USE добавляют целый класс сложности (см довольно сложную семантику атомов) для описания и функциями управления связями между пакетами. Guix полностью обнуляет этот уровень сложности, используя Guile Scheme для программирования отношений между пакетами.

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

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

Системы *BSD (например FreeBSD) страдают от аналогичных проблем с интерфейсом настройки make config.

Nix

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

Guix, вдохновленный Nix, заимствует большинство своих идей и решает основную проблему, которую, на мой взгляд, Nix не понял: вместо того чтобы придумывать доморощенный язык для конкретных областей (domain-specific language) (DSL), Guix использует вполне созревший язык программирования. И это хорошо, поскольку это Guile Scheme, язык на основе Лиспа.

Разработка(Развертывание) собственного языка программирования очень распространенная ошибка в разработке программного обеспечения. Это сильно ударило по многим проектам, где язык конфигурации или программирования был:

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

Таких проектов, использующих саморазрабатываемые язык DSL или слишком ограничивающих языков программирования, легион:

  • XML, HTML (лучшая идея: S-XML)
  • Make, Autoconf, Automake, CMake, etc.
  • Bash, Zsh, Fish (лучшая идея: Eshell or scsh)
  • JSON, TOML, YAML
  • Язык Nix, Portages Ebuild и множество других синтаксических правил определенения пакетов ОС.
  • Firefox когда он использовал XUL (но с тех пор Mozilla с него ушел) и большинство других доморощенных языков программирования расширений
  • SQL
  • Octave, R, PARI/GP, большинство научных программ (лучшая идея: Common Lisp, Racket или другая Scheme)
  • Регулярные выражения(Regular expressions) (лучшая идея: Emacs rx, Rackets PEG, etc.)
  • sed, AWK, etc.
  • Большинство систем конфигурации инициализации, включая systemd (лучшая идея: GNU Shepherd)
  • cron (лучшая идея: mcron)
  • conky (не полностью программируемый, хотя это, вероятно главная особенность, которую вы ожидаете от такой программы)
  • TeX, LaTeX (и все производные), Asymptote (лучшая идея: scribble, skribilo все еще в разработке и с January 2019 TeX/LaTeX все еще используются в качестве промежуточного шага для вывода в PDF)
  • Большинство программ с конфигурациями, в которых не используется язык программирования общего назначения.

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

Не только для рабочих станций

Guix поддерживает несколько архитектур (i686, x8664, ARMv7, и AArch64 по состоянию на январь 2019) и есть планы по поддержке большего количества ядер помимо Linux. (Скажем *BSDs, GNU Hurd, или возможно вашего собственного!)

Это делает Guix отличным инструментом для развертывания (воспроизводимых) серверов, но также других высокоспециализированных систем. Я имею в виду, в частности, встраиваемые системы, которые вполне могут конкурировать с OpenWRT. (Хотя это может потребовать некоторой работы, прежде чем до этого дойдет.)

Самовоспроизводящийся live USB

Я упоминал выше guix system disk-image: Он позволяет, например, воссоздать текущую систему на USB накопителе.

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

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

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

Замена других пакетных менеджеров

Emacs, Python, Ruby и мощь команды guix environment

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

  • Это приносит воспроизводимость везде(всюду).
  • Это позволяет делать откты везде.
  • Это избавляет вас от изучения еще одного менеджера пакетов.

В этом месте я не могу не упомянуть команду guix environment. Эта команда устанавливает временную среду только с определенным набором пакетов, подобно virtualenv. Это функция(фитча) убийца которая универсально доступна для каждого языка или даже лучше, для кажой комбинации языков, если ваш проект смешивает несколько языков.

TeXlive

(Отказ от ответственности: По состоянию на январь 2019, система сборки TeXlive в Guix продолжает обновляться.)

Я чту TeXlive в выделенном разделе, поскольку, хотя это и ужасный менеджер пакетов, как и указанные выше, он исключительно ужасен :) Это еще раз утверждает Guix в качестве спасателя жизни!

Большинство операционных систем на основе Unix обычно упаковывают TeXlive в виде связки, например, в Arch Linux их насчитывается дюжина. Если вам понадобиться пара пакетов TeX, распределенных по разным пакетам(связкам, узлам), Arch Linux не оставит вам другого выбора, кроме как установить пакеты, которые включают в себя тысячи (возможно не нужных) пакетов. А TeXlive БОЛЬШОЙ, а это значит он потребует несколько сотен мегабайт.

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

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

Ядро

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

Как известно Gentoo требует пользовательское ядро в качестве рекомендуемого(обязательного?) шага установки. Это жестко заявлено, и пользователи должны сами поддерживать конфигурацию ядра.

С Guix, ядро является полностью настраиваемым пакетом, как и любой другой. Можно настроить все или передать собственный файл конфигурации ядра в определение пакета.

Например, здесь следует определение несвободного ядра Linux с драйвером iwlwifi (Предупреждение: Я настоятельно рекомендую не использовать несвободные драйверы, поскольку они представляют серьезную угрозу вашей конфеденциальности и свободе):

(define-module (ambrevar linux-custom)
  #:use-module (guix gexp)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix git-download)

  #:use-module (guix build-system trivial)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (gnu packages linux)
  #:use-module (srfi srfi-1))

(define-public linux-nonfree
  (package
    (inherit linux-libre)
    (name "linux-nonfree")
    (version (package-version linux-libre))
    (source
     (origin
      (method url-fetch)
      (uri
       (string-append
	"https://www.kernel.org/pub/linux/kernel/v4.x/"
	"linux-" version ".tar.xz"))
      (sha256
       (base32
	"1lm2s9yhzyqra1f16jrjwd66m3jl43n5k7av2r9hns8hdr1smmw4"))))
    (native-inputs
     `(("kconfig" ,(local-file "./linux-custom.conf"))
       ,@(alist-delete "kconfig" (package-native-inputs linux-libre))))))

(define (linux-firmware-version) "9d40a17beaf271e6ad47a5e714a296100eef4692")
(define (linux-firmware-source version)
  (origin
    (method git-fetch)
    (uri (git-reference
	  (url (string-append "https://git.kernel.org/pub/scm/linux/kernel"
			      "/git/firmware/linux-firmware.git"))
	  (commit version)))
    (file-name (string-append "linux-firmware-" version "-checkout"))
    (sha256
     (base32
      "099kll2n1zvps5qawnbm6c75khgn81j8ns0widiw0lnwm8s9q6ch"))))

(define-public linux-firmware-iwlwifi
  (package
    (name "linux-firmware-iwlwifi")
    (version (linux-firmware-version))
    (source (linux-firmware-source version))
    (build-system trivial-build-system)
    (arguments
     `(#:modules ((guix build utils))
       #:builder (begin
		   (use-modules (guix build utils))
		   (let ((source (assoc-ref %build-inputs "source"))
			 (fw-dir (string-append %output "/lib/firmware/")))
		     (mkdir-p fw-dir)
		     (for-each (lambda (file)
				 (copy-file file
					    (string-append fw-dir (basename file))))
			       (find-files source
					   "iwlwifi-.*\\.ucode$|LICENSE\\.iwlwifi_firmware$"))
		     #t))))
    (home-page "https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi")
    (synopsis "Non-free firmware for Intel wifi chips")
    (description "Non-free iwlwifi firmware")
    (license (license:non-copyleft
	      "https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.iwlwifi_firmware?id=HEAD"))))

Пользовательское ядро и прошивка могут быть условно(conditionally) включены в вашу текущую конфигурацию системы (некоторый файл config.scm):

(define *lspci*
  (let* ((port (open-pipe* OPEN_READ "lspci"))
	 (str (get-string-all port)))
    (close-pipe port)
    str))

(operating-system
 (host-name "...")
 ;;...

 (kernel (cond
	   ((string-match "Network controller: Intel Corporation Wireless 8888"
			  *lspci*)
	    linux-nonfree)
	   (#t linux-libre)))
 (firmware (append (list linux-firmware-iwlwifi)
		    %base-firmware))

Затем выполните следующую команду, чтобы установить новую конфигурацию системы:

sudo -E guix system reconfigure config.scm

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

Игры

Поскольку пакеты Guix являются наисвежайшими (например последние версии Mesa легко доступны) в то же время он позволяет полностью настроить ядро, он может стать идеальной платформой для игр и, в частности, для упаковки игр!

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

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

Некоторые из перков(преимуществ):

  • guix environment позволяет вам запускать любое приложение в изолированном контейнере, которые ограничивает доступ к сети, скрывает файловую систему(нет риска, что программа с закрытым исходным кодом украдет любой из ваших файлов, скажем, ваш Bitcoin кошелек или ваши PGP ключи) и даже информацию системного уровня такую как имя польователя. Это важно для запуска любой ненадежной программы с закрытым исходным кодом.
  • Функциональное управление пакетами: программы с закрытым исходным кодом обычно не выдерживают испытания временем и ломаются, когда зависимые библиотеки меняют свой API. Поскольку Guix может определять пакеты для любой версии любой зависимости ( без риска конфликта с текущей системой), Guix позволяет создавать пакеты игр с закрытым исходным кодом, которые будут работать вечно.
  • Воспроизводимая среда: программы с закрытым исходным кодом, как правило, плохо переносимы и могут вести себя по разному в разных системах с немного разными зависимостями. Черта воспроизводимости Guix подразумевает, что если мы заставим пакет Guix работать один раз, он будет работать вечно (минус смена/поломка оборудования).

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

Однако это длинная тема, и мы оставим ее для другой статьи.

Секреты и тонкости

Emacs-Guix

Одним из замечательных преимуществ Guix является его интефрейс Emacs: Emacs-Guix позволяющий вам инсталировть и удалять пакты, выброчно обновлять, искать, переходить к определению пакетов, управлять поколениями(generations), распечатывать различия(diff) между ними, и многое другое.

Он также имеет режимы для построения и программирования, а также отдельный буфер Scheme REPL.

Это уникальный пользовательский интерфейс для операционной системы.

Существует также Helm System Packages который походит по функцональности на Emacs-Guix, но предоставляет более приятный интерфейс для быстрого поиска пакетов и быстрого выполения операций.

Управление хранением

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

По моему опыту, в 2018, 25GB раздел для хранилища заставлял меня делать уборку примерно раз в месяц (учитывая, что у меня жестки требования к пакетам), в то время как 50GB раздел оставлял бы меня в комфорте в течении всего года.

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

В Emacs-Guix, есть M-x guix-store-dead-item который позволяет вам сортировать мертвые пакеты по размеру и вы можете удалять их по отдельности.

Если вам нужно проанализировать зависимости, взгляните на guix gc --references и guix gc --requisites. Его можно объединить с результатом guix build ... чтобы получить доступ, к различным элементам графа зависимостей.

Например, чтобы посмотреть код одного из сценариев сборки, откройте файл возвращаемый:

$ guix gc --references $(guix build -d coreutils) | grep builder
/gnu/store/v02xky6f5rvjywd7ficzi5pyibbmk6cq-coreutils-8.29-guile-builder

Генерация манифестов

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

Это можно сделать с помощью слеюующего скрипта Guile:

(use-modules (guix profiles)
	     (ice-9 match)
	     (ice-9 pretty-print))

(match (command-line)
  ((_ where)
   (pretty-print
    `(specifications->manifest
      ',(map manifest-entry-name (manifest-entries (profile-manifest where))))))
  (_ (error "Please provide the path to a Guix profile.")))

Затем назовите его, например ~/.guix-profile :

$ guile -s manifest-to-manifest.scm ~/.guix-profile

Я держу свои настройки (dotfiles под управлением сисетмы контроля версий, чтобы отслеживать историю моих установленных пакетов. Поскольку я также сохраняю версию Guix, я могу вернуться к точному состоянию моей системы которое было в любой момент времени в прошлом.

Ссылки

Некоторые web интерфейсы:

Некоторые документы:

Некоторые не официальные пакеты:

Comments

Date: 2019-01-14 (Last update: 2019-01-18)

Made with Emacs 27.0.50 (Org mode 9.1.9)

Creative Commons License




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру