Guix — самая продвинутая операционная система

https://ambrevar.xyz/guix-advance/index.html
  • Translation
Операционные системы (ОС) — обширная тема. На протяжении десятилетий здесь доминировал один подход: Unix. Действительно, большинство современных систем, включая большинство дистрибутивов GNU/Linux, *BSD и macOS, придерживаются архитектуры Unix. (Windows нет, но там почти ничего интересного по этой теме).

В 2000 году Роб Пайк выступил с докладом о том, почему исследования системного ПО не релеванты. Из-за пессимизма или пренебрежения к сообществу он, кажется, полностью проигнорировал жалобы, собранные многими Unix-пользователями в книге The Unix-Haters Handbook (1994). Книга умышленно саркастична, однако указывает на некоторые критические проблемы систем Unix — и они не решены до сих пор.

В 2006 году Элко Доситра опубликовал диссертацию «Полностью функциональная модель развёртывания программного обеспечения», где описан функциональный менеджер пакетов Nix. В 2008 году автор опубликовал NixOS: полностью функциональный дистрибутив Linux. В то время как NixOS повторно использует много свободного ПО для Unix-систем, она настолько отходит от дизайна и философии Unix, что вряд ли её можно назвать «системой Unix».

Nix — гигантский шаг вперёд в системной разработке. Эта ОС не только решила множество проблем Unix (включая критику из вышеупомянутого сборника), но также открыла путь для многих других функций и исследований, которые могут сыграть очень важную роль в наше время, когда надёжность и безопасность стали главной темой многих научных, общественных и политических дебатов.

Пайк ошибался. И это доказывает ещё один более общий момент: вероятно, разумнее воздержаться от объявления нерелевантности любого исследования, если ты не можешь доказать невозможность дальнейшего развития. И упомянутый доклад вряд ли можно считать математическим доказательством. Он только укрепил идею, что Unix «достаточно хорош» и что следует смириться с его особенностями и проблемами.

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

Появление Guix


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

Guix значительно отличается от операционных систем Unix. Можете просмотреть документацию и оценить степень изменений:


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


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

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

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

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

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


Debian, Arch Linux и большинство других дистрибутивов GNU/Linux


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

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

Gentoo, *BSD


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

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

Для сравнения, Guix позволяет полную настройку всего, хотя и с немного бóльшим количеством кода Scheme. В псевдокоде это выглядит примерно так:

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

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

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

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

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

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

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

Nix


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

На мой взгляд, Guix решает основную проблему Nix: вместо собственного предметно-ориентированного языка (DSL) тут применяется полноценный язык программирования Guile Scheme на основе Lisp.

«Внедрение собственного языка программирования» — очень распространённое заблуждение в разработке программного обеспечения. Это сильно ударило по многим проектам, где конфигурация или язык программирования страдали от следующих недостатков:

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

Есть огромное множество проектов на доморощенных или слишком ограниченных языках:

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

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

Не только для десктопа


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

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

Самовоспроизводимые live USB


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

Таким образом клон текущей системы легко подключить в любом месте и реплицировать точную актуальную среду (за вычетом аппаратного обеспечения). Туда можно включить пользовательские данные: ключи PGP, электронную почту. Всё доступно сразу после загрузки.

Очевидно, что клонирование работает и дальше с той машины, на которой установлен клон: вместо «голой» 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"))))

Кастомное ядро и встроенное ПО можно условно включить в текущую конфигурацию системы (какой-нибудь файл 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 позволяет запускать любое приложение в изолированном контейнере, который ограничивает доступ к сети, скрывает файловую систему (нет риска, что проприетарная программа украдёт какой-то из ваших файлов, скажем, биткоин-кошелек или ключи PGP) и даже информацию системного уровня, такую как имя пользователя. Это необходимо для запуска любой ненадёжной программы с закрытым исходным кодом.
  • Функциональное управление пакетами: программы с закрытым исходным кодом обычно не выдерживают проверку временем и ломаются, когда зависимость библиотеки изменяет свой API. Поскольку Guix определяет пакеты поверх любой версии любой зависимости (без конфликтов с текущей системой), Guix позволяет создавать пакеты для игр с закрытым исходным кодом, которые будут работать вечно.
  • Воспроизводимая среда: программы с закрытым исходным кодом обычно плохо переносятся и могут вести себя по-разному в системах с немного разными зависимостями. Свойство воспроизводимости Guix подразумевает, что если мы заставим пакет Guix работать один раз, то он будет работать всегда (если не считать поломку железа или изменение аппаратной конфигурации).

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

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

Хитрости и советы


Emacs-Guix


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

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

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

Хранение данных


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

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

Для очистки хранилища удобно использовать команду 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

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


Часто бывает полезно сгенерировать манифест всех пакетов, установленных в каком-то профиле.

Это можно сделать с помощью следующего скрипта 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, то могу вернуться к точному состоянию своей системы в любой момент в прошлом.

Ссылки


Некоторые веб-интерфейсы:


Документы:


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

Share post

Similar posts

Comments 113

    +2
    Непрерывная интеграция или почему Guix может работать без мейнтейнеров пакетов: благодаря воспроизводимым сборкам и поддержке частичных обновлений, если пакет работает в Guix, то он будет работать «всегда» и не сломается при следующем обновлении какой-то зависимости (точнее, если зависимость ломает пакет, то это тривиально исправляется, чтобы использовать правильную версию библиотеки). Таким образом, работу с пакетами можно перенести на «фермы сборки» (одна на Hydra из проекта Nix, другая на Cuirass). Сравните это с большинством других сообществ GNU/Linux, которым для обновления тысяч пакетов требуются десятки мейнтейнеров. Такой подход не масштабируется: в итоге эти дистрибутивы стагнируют на паре тысяч пакетов. В Guix количество пакетов может спокойно расти, не опасаясь краха. В то же время контрибуторов можно использовать более эффективно.

    А как это работает? Ну вот вы берете пакет X, который зависит от пакета A версии 1.0, берете пакет Y, который зависит от пакета A версии 2.0, которая не совместима с версией 1.0.


    У вас есть три варианта:


    1. Обновить код пакета Y для версии 2.0, для этого нужны мейнтейнеры.
    2. Даунгрейднуть пакет X до версии, которая работала с 1.0, для этого так же нужны мейнтейнеры, что бы перенести фиксы.
    3. Статическая линковка, которая в рамках десктопных систем недопустима, потому что системе будет весит чертовы террабайты.

    Чем Guix лучше? Тем, что может в простых случаях собрать валидный сабсет пакетов? Ну, такое можно в большом количестве систем.

      +3

      Есть ещё вариант. Динамическая линковка X и Y к нужным версиям. т.е. будет в системы два пакета A версии 1.0 и 2.0, до тех пор пока разрабы X-а не обновят зависимости до 2.0 и можно будет старую версию автоматом почистить.

        0
        На самом деле это только часть проблемы. Если речь про обновление пакета, особенно до очередной мажорной версии, то кроме обновления зависимостей может потребоваться обновление самой процедуры сборки, и также, вероятно, окружения и конфигурации, а для этого опять-таки нужны мейнтейнеры… Ну или мириться с тем что пакет древний, в лучшем случае с обновлениями безопасности.
          0
          Кстати еще интереснее что например делать если:
          — если пакет A в версии 1.0 — зависит от пакета K версии 4.3.1 и только так. в K версии 4.4.0 — убрана какая то нужная вещь. При этом две версии K одновременно — запущены быть не могут никак. Потому что это ядро.
          — если пакет A в версии 1.0 — имеет удаленно-эксплуатируемую дыру и при этом обновление A — все же сломает частично пакет Y (и без этого — либо никак либо очень долго и сложно). Кто должен принять решение что да — мы частично ломаем функционал пакета Y но спасаем пользователей. Сам пользователь? Сисадмин?
          — если пакет А в версии 1.0 имеет какой то функционал который разработчикам пришлось вырезать в версии 2.0 потому что выяснилось что патенты. Как быть тем кто поддерживает репозитории — выносить A в non-free-репозиторий не смотря на то что поправлено? Рисковать что на них наедут с теми же патентами?
          — если у нас стоит задача запустить вот это вот — на системе где то что должно быть пакетом K — вот конкретно этой фиксированной версии (для которой даже пакета то не сделали) и изменить это — нельзя. Например...K это ядро а задача стоит — запустить систему под Linux-on-DeX ну или — внутри контейнера той же Virtuozzo (про докер даже не говорю пока).
            +2

            В Guix в описанном случае в описании пакета X может быть указано явное использование A версии 1.0, и пакет продолжит собираться и работать так же, как и раньше (в том числе со всеми ошибками и проблемами безопасности, присутствовавшими в A 1.0). Теоретически такое возможно и в обычном rpm-based или deb-based дистрибутиве, если мантейнер пакета A вместо простого обновления пакета A с версии 1.0 до 2.0 создаст отдельные пакеты A1 и A2 (и к ним, скорее всего, A1-devel и A2-devel), однако в Guix подобное «размножение» пакетов происходит само собой — при любом изменении в исходных текстах, скриптах сборки или других используемых при сборке пакетах меняется и хеш собираемого пакета, в результате новая сборка помещается в отдельный каталог в /gnu/store, где может существовать одновременно с любым количеством предыдущих сборок того же пакета. В бинарных файлах пакетов X и Y при их сборке прописываются конкретные пути в /gnu/store, указывающие на точную версию их зависимостей, в результате они могут использовать разные версии пакета A, даже если разделяемые библиотеки в этих версиях по каким-то причинам имеют одинаковые soname (в обычных дистрибутивах такое возможно только при различных soname).

              +3

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

                –2
                Статическая линковка, которая в рамках десктопных систем недопустима, потому что системе будет весит чертовы террабайты.

                Это уже произошло в JavaScript и постепенно происходит в десктопе (например, winsxs). Игры вообще испокон веков распространялись вместе со своим рантаймом: vcc redist, DirectX, не говоря уже о middleware.

                P.S. Терабайт не имеет ничего общего с землёй.
                  0
                  DirectX хотя бы ставится не с каждой игрой, а один раз на систему.
                    0
                    В свое время был целый вал «месячных» обновлений DX, штук пять разных, так что практически каждая игра таки что-то доустанавливала.
                      0
                      Я о том, что в системе, как правило, не требовалось иметь сразу 100500 копий одной и той же библиотеки (что как раз и наблюдается при работе с тем же npm).
                        0
                        Это да. Но примеров обратного тоже полно, так что ситуация, аналогичная npm не является чем-то новым даже на десктопе.
                +1
                Роб Пайк принял деятельное участие в разработке Plan9 в BellLabs, последней инкарнации Unix, революционной, пересматривающей основопологающее. Система не нашла массового пользователя, в основном по причинам маркетингового характера. Однако большинство заложенных идей подхвачено и реализовано разрозненно в user space. В упомянутом докладе Pike, как архитектор действительно новационной системы, сетует на отсутствие новизны в идеологии массовых операционных систем и прорывных исследований. Так, Nix — пусть и очень достойный, но всего лишь менеджер пакетов решающий один аспект управления системой.
                  +2

                  NixOS решает очень много аспектов управления системой.

                  +9
                  Есть огромное множество проектов на доморощенных или слишком ограниченных языках:

                  Повторное изобретение колеса, обычно, не самая хорошая идея.

                  А что нужно использовать вместо SQL, Octave, JSON или LaTeX? Может, стоило вообще остановиться на Fortran, чтоб не изобретать колесо?

                    +1

                    самое интересное что они Lisp и Scheme записали в "доморощенные или слишком ограниченные языки" в то время как сами продвигают свой Guile.

                      +4

                      Переводчику надо оторвать руки. Оригинал:


                      Octave, R, PARI/GP, most scientific programs (better ideas: Common Lisp, Racket and other Scheme)

                      Правильный перевод:


                      Octave, R, PARI/GP, большинство научных программ (более лучшая альтернатива им: Common Lisp, Racket и другие реализации Scheme)

                      Совершенно другой смысл.

                        +1
                        Если позволите, если мы делаем правильный перевод, то «более хорошая», а не «более лучшая» :) Если вы использовали такую конструкцию сознательно, прошу прощения, просто, как во многих других случаях до этого, над ней вначале смеялись, но смеялись так долго, что глаз за неё цепляться у людей перестаёт.
                          0

                          Главная цель перевода — передать исходную идею. Это и есть критерий правильности. А если я вдруг надумаю переводить в массовом масштабе, то назначу вас моим редактором, видимо у вас куча свободного времени и въедливые глаза.

                            +1
                            К сожалению важна не только идея, но и форма ее подачи…
                            В любом случае — сообщество (включая меня) готово Вам помочь сделать все красиво и аккуратно )
                              0
                              Да нет, всего лишь любовь к родному языку) Впрочем, я рад, что вы осознаёте собственные недостатки (у кого же их нет?) и нужду в редактуре)
                      –9

                      Очередной БолгенОС с нескучными пакетами?


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

                        +8
                        А как они сейчас запускаются на GNU/kFreeBSD или GNU Hurd? То что собрали под платформу, то и будет доступно. Ну и конечно сравнение с BolgenOS мне кажется перебором.
                          +3
                          Очередной БолгенОС с нескучными пакетами?

                          Нет. Тут принципиально новый подход к управлению пакетами и системой в целом.
                            +1
                            Через настраиваемый слой совместимости, с трансляцией системных вызовов?

                            Почему бы и нет? Скажем, ZFS во FreeBSD работает через opensolaris.ko

                            +11

                            Благородное начинание, гарантированное на умирание (жизнь в своей нише). Причина? Выбор schema как языка. Никто не будет учить новый тьюринг-полный язык, чтобы чуть сделать пакет.


                            В целом — идея интересная, и вот вам несколько простеньких задачек для решения:


                            • dpkg-divert --local --divert /etc/ansible/ansible.cfg.dist --no-rename /etc/ansible/ansible.cfg
                            • update-initramfs при установке нового компонента (например, dm-crypt) для обработки initramfs хука (надо же добавить программу для расшифровки диска на этап до расшифровки диска, ha.ha).
                            • update-alternatives (например, editor -> /usr/bin/vim)
                            • apt-mark hold libfoobar-3.2-3-nmu3
                            • Package: *
                              Pin: origin private.example.com
                              Pin-Priority: 600


                            Если для каждого из них покажете пример в этой самой schema-driven package management, то тогда я его перестану считать CS-экспериментом.


                            (Upd: это перевод… мдя, извините за энтузиазм).

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

                              repology.org
                              Most packages: nixpkgs unstable
                              Ну никто, да-да-да.
                                +1

                                Извините, на Scheme не можу, буду на nix.


                                • dpkg-divert --local --divert /etc/ansible/ansible.cfg.dist --no-rename /etc/ansible/ansible.cfg
                                  Просто перетаскивание файлика пакета в другое место — легко через override. Если нужно файлики конфигурации перетаскивать — элементарно в NixOS через environment.etc или в home-manager через home.file


                                • update-initramfs при установке нового компонента (например, dm-crypt) для обработки initramfs хука (надо же добавить программу для расшифровки диска на этап до расшифровки диска, ha.ha).
                                  Реализовано в NixOS. Просто выставляете опцию шифрования диска, всё остальное — автоматически.


                                • update-alternatives (например, editor -> /usr/bin/vim)


                                  stdenv.mkDerivation {
                                  name = "editor";
                                  buildPhase = ''
                                  mkdir -p $out/bin
                                  ln -s ${pkgs.vim}/bin/vim $out/bin/editor
                                  '';
                                  }

                                  Как пример. Можно сделать через alias, или ещё кучей способов, если мы на NixOS.


                                • apt-mark hold libfoobar-3.2-3-nmu3
                                  nixpkgs pinning для одного пакета. Известная техника. Суть такая:


                                  let nixpkgs_pin = import (builtins.fetchGit {url = "https://github.com/nixos/nixpkgs"; rev="commit-with-needed-package-version";}) {};
                                  pinned_libfoobar = nixpkgs_pin.libfoobar;
                                  in pinned_libfoobar;

                                • Package: *
                                  Pin: origin private.example.com
                                  Pin-Priority: 600

                                  Что это такое?


                                  0
                                  Package: *
                                  Pin: origin private.example.com
                                  Pin-Priority: 600

                                  Что это такое?

                                  Это /etc/apt/preferences.d/ — приоритеты для реп в apt

                                    0

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

                                      0
                                      Тогда у меня вопрос, а как сделать, вот это:
                                      ```
                                      Package: *
                                      Pin: origin private.example.com
                                      Pin-Priority: 600

                                      Package: *
                                      Pin: origin private.example.net
                                      Pin-Priority: 600

                                      ```
                                      Т.е. указать два репозитория с одинаковым приоритетом?
                                        0

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

                                    +1

                                    Извините за задержку с ответом.


                                    Итак, у нас декларативный язык, который решает проблему update-alternatives… исполнением mkdir и ln. Это точно, guile, а не bash?


                                    Дальше, я написал простое: apt-mark hold libfoobar-3.2-3-nmu3. Вы написали


                                    let nixpkgs_pin = import (builtins.fetchGit {url = "https://github.com/nixos/nixpkgs"; rev="commit-with-needed-package-version";}) {};
                                    pinned_libfoobar = nixpkgs_pin.libfoobar;
                                    in pinned_libfoobar;

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

                                      0
                                      Итак, у нас декларативный язык, который решает проблему update-alternatives… исполнением mkdir и ln. Это точно, guile, а не bash?

                                      1. Это не guile, это nix
                                      2. Если мы не ограничены присутствием другого пакетного менеджера в системе (т.е. мы находимся на nixos/guixsd), у нас есть куча других способов добавить в PATH бинарник с нужным именем, указывающий на другой бинарник. (А мне лично удобнее пользоваться alias'ами, которые у меня декларативно указывают на нужное мне приложение, например e -> emacsclient)
                                      3. Не вижу ничего плохого в использовании UNIX-утилит. Те, кто видят в этом плохое, используют guix и пишут установочные скрипты на scheme.

                                      Дальше, я написал простое: apt-mark hold libfoobar-3.2-3-nmu3

                                      И через пару апдейтов всё сломалось, а у меня будет работать (условно) всегда, пока github.com онлайн и старая версия libfoobar с зависимостями не удалена из интернетов. Ну и я забыл упомянуть, что pin можно сделать один на всю конфигурацию, и потом писать просто [ pin.libfoobar pin.bash pin.hello ].

                                        0
                                        Не сломается. Максимум, мне скажут, что апдейт не возможен. Обычно это выглядит как отказ обновлять программы, которые будут ломать зависимости на холде. Именно для этого холд и нужен.
                                          +1
                                          А у меня остальную систему (включая всякие glib и прочие системные вещи) можно обновлять отдельно от libfoobar с его зависимостями (скорее всего, пинить нужно не libfoobar, а приложения, которым он нужен. Тогда libfoobar автоматически запинится для этих приложений). В этом прелесть чистых ПМ — можно держать сколько угодно версий чего угодно одновременно в системе, и они не будут друг другу мешать.
                                        +2

                                        Хотите эстетики?


                                        let 
                                          nixpkgs_pin = import (
                                            builtins.fetchGit 
                                            {
                                              url = "https://github.com/nixos/nixpkgs"; 
                                              rev = "commit-with-needed-package-version";
                                            }
                                          ) {};
                                          pinned_libfoobar = nixpkgs_pin.libfoobar;
                                        in pinned_libfoobar;

                                        Это как я бы написал у себя в конфиге.
                                        Теперь к настоящей красоте nix: оверрайдам. Хочу, чтобы compton с анимациями!


                                            compton = old.compton.overrideAttrs (oldAttrs: {
                                              src = builtins.fetchGit {
                                                url = "https://github.com/BlackCapCoder/compton";
                                                ref = "master";
                                              };
                                            });

                                        И мне не нужно заботится о процессе сборки compton.
                                        Хочу телеграм с wide-baloons!


                                        tdesktop = old.tdesktop.overrideAttrs (oldAttrs: {
                                                patches =
                                                [
                                                  ("${builtins.fetchGit
                                                  {
                                                    url = "https://github.com/msva/mva-overlay";
                                                    rev = "7b61558a20a92920c1594d46a68f713e199957ad";
                                                  }}/net-im/telegram-desktop/files/patches/1.5.8/conditional/wide-baloons/0001_baloons-follows-text-width-on-adaptive-layout.patch"
                                                  )
                                                ] ++ oldAttrs.patches;
                                            });

                                        Ещё одно преимущество, вытекающее из повторяемости — хорошая "оффлайновость." Нужно поставить пакет на компьютер без интернета?


                                        nix-store --export $(nix-store -qR $(nix-build 'nixpkgs-version-on-offline-pc' -A firefox)) > out

                                        out кидаем на флешку, переносим на компьютер без интернета,


                                        nix-store --import < out

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

                                          0
                                          Мне вот интересно. Вот этот чудесный nix-build — он же берет среду для компиляции самую свежую из системы? А если программа собирается только каким-нибудь древним autotools + древний gcc? Как Вы скажете системе, что нужно так делать? Это тогда получается минимум два блока зависимостей (один — для сборки, второй — для запуска)
                                            +1

                                            В nixpkgs есть древние версии gcc и средств сборки специально для таких случаев. Даже пинить ничего не надо — просто выбираем версию постарше в buildInputs.

                                              0
                                              Пример покажите, пожалуйста.
                                              Вообще пока что я вижу, что хоть и nixpkgs гибче, но бинарные ПМ типа rpm/deb при условии верного прописывания версий зависимостей в манифестах (это на самом деле очень важно!) работают как-то попроще. Для пользователя.
                                                +1

                                                Предположим, что для сборки cmake-проекта foobar нужен gcc версии 4 и утилиты, которые идут с этим gcc. Пишем


                                                stdenv.mkDerivation {
                                                    name = "foobar";
                                                    src = ./.; # Сырцы там же, где и default.nix
                                                    nativeBuildInputs = [ gcc49 cmake pkgconfig ]; 
                                                    buildInputs = [ libfoo libbar libbaz ]; # Используемые библиотеки
                                                }

                                                И получаем именно то, что нам нужно.

                                                  0
                                                  Спасибо за пример, но я так понимаю, что в этом примере только выбрана одна конкретная версия gcc 4.9, а остальные пакеты — отданы на откуп самому менеджеру пакетов.
                                                  Ну, и вообще хочется понять насколько это годная история, поэтому задаю такие вопросы.
                                                  Здорово, что есть возможность руками выбрать, но все-таки, как мне кажется, это задача мейнтейнера задавать вот эти вот ключи для правильной сборки.
                                                    +2

                                                    Именно мейнтейнеры nixpkgs и занимаются выбором правильных ключей сборки и зависимостей так, чтобы пользователь набрал просто nix-env -iA nixos.foobar и получил нужную программу, не задумываясь о ключах сборки и зависимостях. Когда мы пишем пакет сами, вполне логично, что мы должны выполнять работу мейнтейнера.

                                      +1
                                      Выбор schema как языка. Никто не будет учить новый тьюринг-полный язык, чтобы чуть сделать пакет

                                      Lisp/scheme "учится" за полчаса и на всю жизнь. Хотя соглашусь, что тонны скобок могут напрягать.

                                        +1

                                        Да, он действительно несложный, но меня очень напрягает читаемость и неявные сайд-эффекты. Я бы предпочёл, чтобы условный guix был написан на условном Haskell.

                                        0
                                        amarao, тебя не устраивают мои решения? Или вопрос был только к scheme и в nix ты и так не сомневаешься?
                                          0
                                          Выбор schema как языка. Никто не будет учить новый тьюринг-полный язык, чтобы чуть сделать пакет.

                                          Он, увы, не новый.


                                          Но если конкретно по этому пункту рассуждать, то, ИМХО, тут бы куда лучше подошёл язык с явным управлением эффектами.

                                          0
                                          Сидел на NixOS где-то год, ощущения двойственные, с одной стороны декларативная конфигурация в одном месте и возможность откатиться в любой момент радовали, с другой система для меня выглядела как черный ящик, слишком много отличий от привычного гну/линукса. Подумываю попробовать ещё раз, поставить core crux и на него nix, возможно в таком варианте будет проще освоиться. А про GuixSD (в заголовке ошибка — нет ОС Guix) слышал что оно пока не готово.
                                            +2
                                            Идея этих дистрбутивов всегда мне казалась верной — иммутабельность это единственный способ убрать все грабли, но я како-то не уверен, что лисп лучше специального DSL.
                                              0

                                              В использовании DSL и есть идеология Unix. Но как только вам нужно выйти за рамки специального DSL, то начинается ад, начиная с выбора инструмента, на котором вы будете это делать и заканчивая установкой всех необходимых для этого зависимостей. Количество новых проблем начинает расти экспоненциально. Хотите расширить что-то работой другого разработчика, а он принял другие решения, использует другие инструменты, тянет очередные зависимости. В итоге получаем Linux с его зоопарком дистрибутивов, конфликтами зависимостей и отсутствием общеупотребимых инструментов автоматизации. О чем и написано в статье.


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

                                              0
                                              В чем преимущество над NixOS?
                                                0
                                                В основном в использовании Scheme вместо Nix. Ещё тут очень много пакетов бутстрапятся, а инструментарий внезапно поудобнее, чем у nix. Но я не очень много пользовался GuixSD, возможно, есть ещё преимущества. Пока что Nixos выглядит получше из-за обилия модулей и пакетов.
                                                0
                                                Кроме того, Portage страдает от той же проблемы с отсутствием надлежащей поддержки нескольких версий


                                                Да ладно? А слоты?
                                                  0
                                                  почитайте багрепорт о nodejs, слотами не решается.
                                                    0
                                                    NVM же?
                                                  0
                                                  Это прекрасно, что Guix так развился.
                                                  Да apt, portage и подобные обросли, но у них нет будущего.
                                                  Надеюсь, Guix и Nix вытеснят уже архаичные костыли apt, yum и им подобное.
                                                    –5
                                                    Скажем, последний mpv требует нового ffmpeg, но обновление ffmpeg ломает большинство других программ. Мы застряли перед дилеммой: либо ломаем некоторые пакеты, либо сохраняем старые версии.

                                                    Если авторы mpv не умеют правильно собрать пакет под конкретную версию дистрибутива, или вы пытаетесь воткнуть в систему пакет собранный для другой версии, то вы, очевидно, сами себе ищете приключений.
                                                      –1
                                                      И опять те же грабли изолированности…
                                                      Да всем(подавляющей части обычных юзеров планеты) плевать на открытость, какие-то там решения по настройке\сборке пакетов и прочее подобное.

                                                      А ведь рецепт(вкратце) убийцы винды\осх прост — красивенький и понятный, никаких hrenznaet4tozademon.conf на 100500 строчек ui + запуск пакета адоба + MS Office + всякие автокады в 1 очередь. Остальное и так почти все уже кроссплатформенное или умеет в wine. И никаких заменителей никому нахрен не нужен например опенофис на самом деле. Все -профит :)

                                                      Я до сих пор искренне не понимаю почему какой-нить дистр на Linux до этого не дошел — все пляшут на одних и тех же граблях и пытаются переизобрести свое колесо
                                                        0
                                                        Зря вы так про опенофис. Уже как лет 5-6 пользуюсь без какого либо неудобства. Особенно после того как МС перешел на табы в менюшках. Так что тут вопрос скорее вкуса.
                                                          0

                                                          Периодически смотрю, но он, к сожалению, как умирал на средненькой портянке 400x8000, так и умирает.

                                                            +1
                                                            К сожалению, и в LibreOffice, и в MS Office for Mac регулярно едет форматирование и появляются странные непечатаемые символы.
                                                            Получается, что совместимость на уровне форматов есть (docx, odt etc.), но фактически юзеры как раньше страдали, так и страдают раньше.
                                                              +4
                                                              Может дело в том, что форматам не следует MS Office?
                                                              (просто предположение)
                                                                0
                                                                Ваше предположение — предположение Шредингера :)
                                                                1) Оно верно
                                                                2) Whocares

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

                                                                  0
                                                                  Нет, я предлагаю смотреть с чуть другой стороны. Насколько помню, формат doc опубликован, «от доброты душевной». Не имеет смысла с точки зрения открытых инструментов этому формату следовать плохо, зато имеет огромный смысл с точки зрения Microsoft следовать формату «лучше». Например, я сталкивался с ситуацией: границы независимых таблиц были выровнены в MSWord, но отображаются с малюсеньким таким сдвигом в Libre. Я предполагаю, что в самом файле координаты границ в этих таблицах не равны, и Libre честно это отображает, а вот MSWord достаточно умён, чтобы «угадать» намерение пользователя и применить там дополнительное форматирование, хотя формально здесь они не следуют ими же опубликованному стандарту. Это, разумеется, только спекуляции, и вообще, надо на шапочку ещё слой намотать, а то блеск уже не тот.

                                                                  А отношение про «стандарт — это то, что [только] мы используем» — очень полезное с точки зрения vendor lock-in, но крайне вредное для кооперации B2B, конкуренции в сфере услуг, и с точки зрения антимонопольных законов тоже.
                                                          +2

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

                                                            –2
                                                            Ну, а чего тогда они вечн удивляются в стиле *а чойто к нам с венды не уходят* ?)

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

                                                            А теперь берем, ну например hMail или, даже, Exchange — поменяется только кол-во доступных фишек: далее-далее-далее-%мастер настройки фичи%-ок.
                                                            Все. Все уже работает и через 15 мин в продакшене и может поддерживаться джуниор-помошником админа. Профит.
                                                            Вот пока в линуксе не будет чегонить подобного(есть конечно зимбра, но при ее аппетитах — шилонамыло) у линукса шансов объективно примерно чуть ниже нуля.
                                                              0
                                                              Есть еще Керио.
                                                                +1
                                                                А кто удивляется?

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

                                                                  Как раз на лине масштабируется легко, в отличие от Win. Времени на настройку уходит не сильно больше (в пределах одного порядка, по личному опыту), а вот квалификация требуется сильно повыше. Так что если нужна надёжная система с высокой масштабируемостью — берут линукс и нанимают профессионала, если нужно просто вот сейчас сервачок — то берут сына ген. директора и win.

                                                              0
                                                              Если обновление что-то сломает, всегда можно откатить.
                                                              Объясните мне на пальцах, как это спасёт от
                                                              rm -rf /usr /share/...
                                                                0
                                                                Никак. Хотите удалить usr — ваше право. Только в процессе обновления таких команд быть не может.
                                                                  +1
                                                                  Только в процессе обновления таких команд быть не может.
                                                                  ORLY?
                                                                    0
                                                                    А теперь найдите это в nixpkgs
                                                                      +1
                                                                      Это было в коде драйвера (скрипт апдейта), ничто не мешает там быть
                                                                      rm -rf /nix
                                                                      nixpkgs съест и получится то, что получится.
                                                                        0
                                                                        Дело в том, что никс не удаляет предыдущие версии при помощи rm -rf
                                                                          +1
                                                                          Ещё раз: это содержимое пакета.
                                                                            0
                                                                            Каждая версия ставится в отдельную папку с уникальным именем, в скрипте попросту незачем использовать rm -rf
                                                                            Ситуация, когда вам надо использовать rm -rf — крайне маловероятна, потому-что у вас нет ни одной причины удалять предыдущую версию, в общем случае вы даже не знаете, как называется папка, в которой она лежит.
                                                                              0
                                                                              3 раз пишу: это код приложения, внутри пакета, а не debian postinstall/installscript/scheme/etc, откатить никак не получится если вы не делаете снапшоты ФС на каждое обновление (:
                                                                                0
                                                                                В том-то и дело, что такой скрипт — это в 99.99% императивный кусок какого-то функционала, нужного чтобы «удалить бывшее раньше».
                                                                                В функциональных менеджерах нет императивного удаления.
                                                                                Если надо обновить версию драйвера — прописываете его в конфиг и делаете операцию «привести систему в соответствие с конфигом» — и он сам удалит всё что не нужно.
                                                                                  0
                                                                                  В функциональных менеджерах нет императивного удаления.
                                                                                  Если надо обновить версию драйвера — прописываете его в конфиг и делаете операцию «привести систему в соответствие с конфигом» — и он сам удалит всё что не нужно.

                                                                                  типичное заблуждение касательно любых SCM (ansible, puppet etc.). Они действительно должны так работать, но под капотом все равно императивщина (а как еще назвать инструкции вроде «удали файл такой-то», «перезапусти сервис» и пр.). Даже хуже — некоторые вещи в парадигме «хочу что-то» (т.е. описываем желаемый конфиг) не работают, что и приводит к необходимости написанию своих модулей для SCM и модулей типа «kubernetes operator» для k8s.
                                                                                  0

                                                                                  ну так не надо левые приложения запускать под рутом. А если такого сорта баг в ядре (т.е. в основе системы, не обязательно kernel), тогда спасут только бэкапы на сервер расположенный в другой пожарной зоне :)

                                                                                  0
                                                                                  То есть, можно просто grep-нуть исходники пакета, и если в нём есть rm -rf — то нафиг такой пакет?
                                                                                    0
                                                                                    Можно? Да, конечно.
                                                                                    Будет ли это кто-то делать, когда мы тут за bleeding edge и git clone в качестве первого шага установки, указанный мной инцидент прекрасно продемонстрировал.
                                                                                      +1
                                                                                      Можно каждую установку пакета запускать в чруте, что на выходе получилось — уже устанавливать.
                                                                                        0

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

                                                                                          0
                                                                                          потому что способов навредить системе, вообще говоря, счётное число,

                                                                                          Или, может — несчетное, все-таки?
                                                                                            +1

                                                                                            Мы же алгоритмически хотим вредить? Значит, не более чем счётное.


                                                                                            Язык же Тьюринг-полный, то есть, порождает главную нумерацию? Значит, ровно счётное.

                                                                                  0

                                                                                  Не съест. Прав у nix-builder-0 не хватит на удаление этой папки, в "худшем" случае удалится только $out, т.е. сам пакет.

                                                                                    +1

                                                                                    По умолчанию используется sandbox сборка. Этот каталог не будет виден билдеру

                                                                                  0
                                                                                  Да и в любом случае — в /usr просто симлинки хранятся, полагаю после обновления системы они пересоздадутся.
                                                                                    0
                                                                                    Специально проверил свой /usr — симлинки конечно присутствуют, но в основном лежат реальные файлы. Предлагаю снести /usr/bin /usr/sbin и посмотреть выйдет ли вообще после этого систему обновить.
                                                                                      0
                                                                                      [root@nixos:~]# ls -la /usr/bin/
                                                                                      total 0
                                                                                      drwxr-xr-x 2 root root 60 Jan 22 11:20.
                                                                                      drwxr-xr-x 3 root root 60 Jan 22 11:20…
                                                                                      lrwxrwxrwx 1 root root 66 Jan 22 11:20 env -> /nix/store/dm20hrdk6s4jzfmk1197p2nya0p8fy3a-coreutils-8.29/bin/env

                                                                                      root@nixos:/]# ls -la /bin
                                                                                      total 0
                                                                                      drwxr-xr-x 2 root root 60 Jan 22 11:20.
                                                                                      drwxr-xr-x 17 root root 340 Jan 22 11:20…
                                                                                      lrwxrwxrwx 1 root root 75 Jan 22 11:20 sh -> /nix/store/ij6wirzff9id7jr071p04w4nk6hksc3y-bash-interactive-4.4-p23/bin/sh

                                                                                      [root@nixos:~]#
                                                                                        0
                                                                                        Предлагаю снести /usr/bin

                                                                                        Готов прям сейчас. У меня там только env, и тот — симлинк для совместимости с shebangs.

                                                                                  0
                                                                                  Да никак вам не смогут ответить, потому что «современные» ОС из 90 годов скорее не ОС общего назначения, а технические ОС. Настоящие современные ОС — это android и ios. Самое главное отличие: приложения не могут сломать систему, они работают в своей песочнице, контейнере. Конечно, есть исключения, но то такое.
                                                                                  Пока что десктопные ОС похожи на какой-то зоопарк который пытаются решить костылями типа докера, хоть и весьма изящными, но костылями.
                                                                                    0
                                                                                    Так в nix/guix вся сборка и установка происходит на 100% изолированно, и сделать какую-либо операцию (даже чтение) вне собственного каталога сборщик попросту не может. Ну а если поверх довесить firejail, то изоляция будет и на уровне рантайма. Вот вам и изоляция полная.
                                                                                      0
                                                                                      Это хорошо что есть подвижки, а вообще говорю про остальные ОС с общей долей 99.99% рынка.
                                                                                        0
                                                                                        Изменения всегда приходят медленно.
                                                                                    +2

                                                                                    В nix/guix сборщик очень ограничен в своих действиях. Я могу попытаться собрать даже rm -rf /, но nix-builder-0 просто не имеет прав на что-либо, кроме своей папки в tmp (rwxrwxrwx) и buildInputs (r-xr-xr-x). Т.е. читать он может только свою маленькую директорию и директории входных пакетов, а писать может только в свою директорию.

                                                                                    0
                                                                                    Все это красиво и я всеми руками ЗА! за развитие NixOS и GuiX.
                                                                                    Но — NixOS, я пробывал, но этот DSL что то с чем то *непереводимая игра слов*. Прикрутить туда тоже VScode заставило меня достать пылившийся бубен.
                                                                                    Guix — ребят, ну зачем эта излишняя фриварщина? Покупать новое железо под ОСь с неизвестными будущем? и кричать я весь такой фриварный… нет зондам. Emacs? — это прям вообще убер фича? Мое мнение — прикрутить отдельную репу проприетарщины, кому надо то поставит, прикрутить туда IDE из каробки помимо Emacs и VIM. Сделать как Manjaro — Community Release с разными DE. И проект взлетит!
                                                                                      0
                                                                                      Прикрутить туда тоже VScode заставило меня достать пылившийся бубен.

                                                                                      Одна строка в конфиге — это пылящийся бубен? Серьёзно?


                                                                                      Мое мнение — прикрутить отдельную репу проприетарщины, кому надо то поставит, прикрутить туда IDE из каробки помимо Emacs и VIM.

                                                                                      В nixos по-сути так и сделано. Выставляем опцию nixpkgs.config.allowUnfree = true; и ставим несвободные пакеты в своё удовольствие.

                                                                                        0
                                                                                        Одна строка в конфиге — это пылящийся бубен? Серьёзно?

                                                                                        Я «курил» NixOS, когда VScode еще не было в pkgs.
                                                                                      +1

                                                                                      Статья написана так, будто guix сам сын автора создавал)

                                                                                        –2
                                                                                        Сын маминой подруги.
                                                                                        +1
                                                                                         Что я могу сказать. Действительно, текущая парадигма пакетных менеджеров изжила себя. Иначе бы не появлялись статьи подобно настоящей или этой: habr.com/ru/post/433052
                                                                                        Но решение приведенное в статье выглядит как академические изыскания, а не как реальное решение проблемы. К тому же, я, как и многие другие, скорее готов изучить YAML/JSON/TOML или любой другой человеко-читаемый формат описания манифестов пакетов, чем генерировать код на Scheme, который может все. К тому же, раз код манифестов в GuiX по сути написан на Scheme и обладает бесконечными возможностями расширения, то это очередная Тьюринг-полная машина, в которой можно насоздавать бесконечное количество уязвимостей. Как это все аудировать? Ответа нет.

                                                                                        Для серверов будущее очевидно. Оно в ОС, изменяющихся атомарно (CoreOS Container Linux и клоны). Программы — в контейнерах типа docker («все свое ношу с собой»). Если заглядывать дальше, то вообще переход на serverless (aka lambda).
                                                                                          0
                                                                                          Самый шикарный случай rm -R на моей памяти, это когда достался 486, с мизером оперативки, куцым хардом — удавалось поставить w98, (в одном офисе было веселее — ХПя требовала памяти, но в пк стока не было., но в кабинете было ещо 3 таких же пк — собирались плашки по всем машинам, и поочереди с донорской памятью накатывалсь ось, потом органы раздавались благотетялям, после запуска винда офигивала, что так жостко обошли системные требования, но почта вроде работала) но когда захотелось поиграть — места на нжмд не хватало, выход — удалялись все файлы, не запущенные в данный момент. некоторые игрушки устанавливались, и запускались. После ребута — новый накат системы…

                                                                                          А по мне джента ничего так — если ставятся пакеты, которые скоро удалятся — emerge undelete xxx в системе после depcleana останется, будет в 2х слотах… про зависимости — а кто мешает в \etc\portage\use написать для проги yyy use python2 для проги zzz python3… правда заморочки с версиями ruby достают надо явно писать use ruby 5.2 <<-4.8 Также — про «одну актуальную версию» — гугль в помощь, как правило лежат нестабильные версии, актуальная и 5-6 предыдущих — никто не запрещает скачать исходники в локальный портаж, было-бы желание можно и 2.26 ядро собрать, с gcc и linux-headers…
                                                                                            –4
                                                                                            На счет хороших конфигов в линуксе и плохого реестра винды.

                                                                                            Как-то на raspberry pi настраивал сеть, сам я не админ, поэтому многое было в новинку. Дело осложняло то что версий малины за 5 лет накопилось много и часто гайды были устаревшими. По итогу пришлось настраивать сразу 2 компонента из-за того что новый не работал во всех случаях.

                                                                                            Другой случай был с rtx 2080 fe на убунте. Эта видеокарта не работала должным образом из-за отсутствия драйверов, можно было разве что довольствоваться разрешением ~600х600. После установки дев-версий драйверов, разрешение удалось выставить в 1440p, но необходимую частоту — нет. После нескольки часов гугления и работы с разными конфигами удалось все же выставить частоту обновления 165гц. Так же пока что нет сборки хрома с поддержкой 165гц для линукса, только хроминум который не может стабильно выдавать такую частоту и выдает 80fps с просадками до 40.
                                                                                            Что в винде? В винде через 5 минут скачался и установился драйвер, через 1 минуту была выставлена настройка 165гц обновления, хром сразу перешел на нужную частоту.
                                                                                            При корявости винды все заработало за условные 6 минут, в линуксе за 2-3 часа и не полностью.
                                                                                              +1
                                                                                              Есть же разные atomic OS, есть modular Fedora. Есть snap, flatpack, appimage.
                                                                                              Есть докер и k8s, наконец, где вообще не так важно, какая там у тебя операционная система под капотом и где пакеты вообще не особо нужны.
                                                                                              Ниша у «полностью программируемой OS» наверняка есть, но тратить месяц на настройку, чтобы потом держать 100 человек на поддержке — очень специфичный use case.
                                                                                              Ехать же надо, а не шашечки. Если для каждой поездки надо месяц готовить машину, в большинстве случаев такое не взлетит.
                                                                                                +1

                                                                                                Nixos/guixsd очень хорош, когда машин больше десяти. Тогда ты пишешь один раз конфиг (да, это может занять пару дней или даже неделю), а потом просто раскатываешь его по всем машинам. Если всё правильно сделать, то изменения настроек можно делать просто редактированием конфига и после этого nixos-rebuild switch --target-host .... Когда машина одна, преимущества тоже есть (атомарность + декларативность + rollbacks + изолированность + повторяемость + легкость оверрайдов a-la gentoo, только эти оверрайды ещё и аддитивны, и т.д.)


                                                                                                не так важно, какая там у тебя операционная система под капотом

                                                                                                nix тоже запускается на всём POSIX-совместимом.


                                                                                                А вообще — относитесь ко мне с подозрением, ведь я уже потратил месяц на написание конфига и теперь ни за что не признаю ошибки :)

                                                                                                  0
                                                                                                  но тратить месяц на настройку, чтобы потом держать 100 человек на поддержке — очень специфичный use case.

                                                                                                  Около 400. + NixOps. И да, rollback. Месяц, хм, Вы не поверите…
                                                                                                  +1
                                                                                                  Невероятно интересный проект, аж захотелось попробовать в качестве основной системы. Есть вопрос: много ли геморроя с проприетарными пакетами? Например, хочу поставить Skype, какая (хотя бы в общих чертах) должна быть последовательность действий?
                                                                                                    +1

                                                                                                    Если нужно много проприетарщины, то лучше попробовать NixOS. Там достаточно nixpkgs.config.allowUnfree = true и можно ставить скайпы и прочую проприетарщину прямо из бинарных репозитариев. В guix с проприетарщиной гораздо хуже отношения (GNU как-никак).

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

                                                                                                    По сравнение с арч в nixos не так оперативно выкатывают обновления на новые версии.

                                                                                                      0
                                                                                                      Обновления — лучше всего в alpine :-) не удивлен, учитывая направленность дистрибутива ))))

                                                                                                    Only users with full accounts can post comments. Log in, please.