В 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 революционны до такой степени, что остальные ОС выглядят устаревшими системами по сравнению с ней.
Мои личные любимые функции:
- Неуязвимость системы: 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-PACKAGESGuix устанавливает временное окружение, где представлены все требования для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 позволяет полную настройку всего, хотя и с немного бoльшим количеством кода 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, то могу вернуться к точному состоянию своей системы в любой момент в прошлом.
Ссылки
Некоторые веб-интерфейсы:
Документы:
- «Обкатка кода (staging) в GNU Guix» (почему Lisp сыграл важную роль в разработке)
- Заметки Петра
Неофициальные пакеты:
Комментарии (83)
uvelichitel
21.01.2019 17:03Роб Пайк принял деятельное участие в разработке Plan9 в BellLabs, последней инкарнации Unix, революционной, пересматривающей основопологающее. Система не нашла массового пользователя, в основном по причинам маркетингового характера. Однако большинство заложенных идей подхвачено и реализовано разрозненно в user space. В упомянутом докладе Pike, как архитектор действительно новационной системы, сетует на отсутствие новизны в идеологии массовых операционных систем и прорывных исследований. Так, Nix — пусть и очень достойный, но всего лишь менеджер пакетов решающий один аспект управления системой.
masai
21.01.2019 17:40Есть огромное множество проектов на доморощенных или слишком ограниченных языках:
…
Повторное изобретение колеса, обычно, не самая хорошая идея.А что нужно использовать вместо SQL, Octave, JSON или LaTeX? Может, стоило вообще остановиться на Fortran, чтоб не изобретать колесо?
encyclopedist
22.01.2019 03:13самое интересное что они Lisp и Scheme записали в "доморощенные или слишком ограниченные языки" в то время как сами продвигают свой Guile.
snp
22.01.2019 07:16Переводчику надо оторвать руки. Оригинал:
Octave, R, PARI/GP, most scientific programs (better ideas: Common Lisp, Racket and other Scheme)
Правильный перевод:
Octave, R, PARI/GP, большинство научных программ (более лучшая альтернатива им: Common Lisp, Racket и другие реализации Scheme)
Совершенно другой смысл.
FreeNickname
22.01.2019 22:20-1Если позволите, если мы делаем правильный перевод, то «более хорошая», а не «более лучшая» :) Если вы использовали такую конструкцию сознательно, прошу прощения, просто, как во многих других случаях до этого, над ней вначале смеялись, но смеялись так долго, что глаз за неё цепляться у людей перестаёт.
snp
23.01.2019 07:09Главная цель перевода — передать исходную идею. Это и есть критерий правильности. А если я вдруг надумаю переводить в массовом масштабе, то назначу вас моим редактором, видимо у вас куча свободного времени и въедливые глаза.
gecube
23.01.2019 09:09+1К сожалению важна не только идея, но и форма ее подачи…
В любом случае — сообщество (включая меня) готово Вам помочь сделать все красиво и аккуратно )
Dorogonov_DA
21.01.2019 18:21Очередной БолгенОС с нескучными пакетами?
Как собрались запускать системные утилиты с другими ядрами? Через настраиваемый слой совместимости, с трансляцией системных вызовов?
ddidwyll
22.01.2019 19:27+1А как они сейчас запускаются на GNU/kFreeBSD или GNU Hurd? То что собрали под платформу, то и будет доступно. Ну и конечно сравнение с BolgenOS мне кажется перебором.
balsoft
22.01.2019 21:13Очередной БолгенОС с нескучными пакетами?
Нет. Тут принципиально новый подход к управлению пакетами и системой в целом.
mxms
22.01.2019 21:42Через настраиваемый слой совместимости, с трансляцией системных вызовов?
Почему бы и нет? Скажем, ZFS во FreeBSD работает через opensolaris.ko
amarao
21.01.2019 18:57+1Благородное начинание, гарантированное на умирание (жизнь в своей нише). Причина? Выбор schema как языка. Никто не будет учить новый тьюринг-полный язык, чтобы чуть сделать пакет.
В целом — идея интересная, и вот вам несколько простеньких задачек для решения:
dpkg-divert --local --divert /etc/ansible/ansible.cfg.dist --no-rename /etc/ansible/ansible.cfgupdate-initramfsпри установке нового компонента (например, dm-crypt) для обработки initramfs хука (надо же добавить программу для расшифровки диска на этап до расшифровки диска, ha.ha).update-alternatives(например, editor -> /usr/bin/vim)apt-mark hold libfoobar-3.2-3-nmu3Package: * Pin: origin private.example.com Pin-Priority: 600
Если для каждого из них покажете пример в этой самой schema-driven package management, то тогда я его перестану считать CS-экспериментом.
(Upd: это перевод… мдя, извините за энтузиазм).
balsoft
22.01.2019 21:14Никто не будет учить новый тьюринг-полный язык, чтобы чуть сделать пакет.
repology.org
Most packages: nixpkgs unstable
Ну никто, да-да-да.
balsoft
22.01.2019 21:28Извините, на 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
Что это такое?
RNZ
21.01.2019 23:21Package: *
Pin: origin private.example.com
Pin-Priority: 600
Что это такое?
Это /etc/apt/preferences.d/ — приоритеты для реп в apt
balsoft
21.01.2019 23:24Тогда можно провести прямую аналогию с каналами в Nix. Только в nix всегда явно указывается канал, так что проблем с приоритетом каналов нет.
snp
22.01.2019 07:22Выбор schema как языка. Никто не будет учить новый тьюринг-полный язык, чтобы чуть сделать пакет
Lisp/scheme "учится" за полчаса и на всю жизнь. Хотя соглашусь, что тонны скобок могут напрягать.
0xd34df00d
23.01.2019 17:22Выбор schema как языка. Никто не будет учить новый тьюринг-полный язык, чтобы чуть сделать пакет.
Он, увы, не новый.
Но если конкретно по этому пункту рассуждать, то, ИМХО, тут бы куда лучше подошёл язык с явным управлением эффектами.
ddidwyll
22.01.2019 19:23Сидел на NixOS где-то год, ощущения двойственные, с одной стороны декларативная конфигурация в одном месте и возможность откатиться в любой момент радовали, с другой система для меня выглядела как черный ящик, слишком много отличий от привычного гну/линукса. Подумываю попробовать ещё раз, поставить core crux и на него nix, возможно в таком варианте будет проще освоиться. А про GuixSD (в заголовке ошибка — нет ОС Guix) слышал что оно пока не готово.
worldmind
22.01.2019 19:55Идея этих дистрбутивов всегда мне казалась верной — иммутабельность это единственный способ убрать все грабли, но я како-то не уверен, что лисп лучше специального DSL.
rumkin
22.01.2019 18:18В использовании DSL и есть идеология Unix. Но как только вам нужно выйти за рамки специального DSL, то начинается ад, начиная с выбора инструмента, на котором вы будете это делать и заканчивая установкой всех необходимых для этого зависимостей. Количество новых проблем начинает расти экспоненциально. Хотите расширить что-то работой другого разработчика, а он принял другие решения, использует другие инструменты, тянет очередные зависимости. В итоге получаем Linux с его зоопарком дистрибутивов, конфликтами зависимостей и отсутствием общеупотребимых инструментов автоматизации. О чем и написано в статье.
Ничто не мешает создать подмножество Lisp/Guile для конфигурационных файлов с урезанным функционалом.
interprise
22.01.2019 21:36В чем преимущество над NixOS?
balsoft
21.01.2019 22:21В основном в использовании Scheme вместо Nix. Ещё тут очень много пакетов бутстрапятся, а инструментарий внезапно поудобнее, чем у nix. Но я не очень много пользовался GuixSD, возможно, есть ещё преимущества. Пока что Nixos выглядит получше из-за обилия модулей и пакетов.
Arris
21.01.2019 22:21Кроме того, Portage страдает от той же проблемы с отсутствием надлежащей поддержки нескольких версий
Да ладно? А слоты?
RNZ
21.01.2019 23:30Это прекрасно, что Guix так развился.
Да apt, portage и подобные обросли, но у них нет будущего.
Надеюсь, Guix и Nix вытеснят уже архаичные костыли apt, yum и им подобное.
9660
22.01.2019 06:16-2Скажем, последний mpv требует нового ffmpeg, но обновление ffmpeg ломает большинство других программ. Мы застряли перед дилеммой: либо ломаем некоторые пакеты, либо сохраняем старые версии.
Если авторы mpv не умеют правильно собрать пакет под конкретную версию дистрибутива, или вы пытаетесь воткнуть в систему пакет собранный для другой версии, то вы, очевидно, сами себе ищете приключений.
Merkat0r
22.01.2019 08:46И опять те же грабли изолированности…
Да всем(подавляющей части обычных юзеров планеты) плевать на открытость, какие-то там решения по настройке\сборке пакетов и прочее подобное.
А ведь рецепт(вкратце) убийцы винды\осх прост — красивенький и понятный, никаких hrenznaet4tozademon.conf на 100500 строчек ui + запуск пакета адоба + MS Office + всякие автокады в 1 очередь. Остальное и так почти все уже кроссплатформенное или умеет в wine. И никаких заменителейникому нахрен не нужен например опенофис на самом деле. Все -профит :)
Я до сих пор искренне не понимаю почему какой-нить дистр на Linux до этого не дошел — все пляшут на одних и тех же граблях и пытаются переизобрести свое колесоalekssaff
22.01.2019 13:08Зря вы так про опенофис. Уже как лет 5-6 пользуюсь без какого либо неудобства. Особенно после того как МС перешел на табы в менюшках. Так что тут вопрос скорее вкуса.
mjr27
22.01.2019 14:31Периодически смотрю, но он, к сожалению, как умирал на средненькой портянке 400x8000, так и умирает.
gecube
22.01.2019 14:33К сожалению, и в LibreOffice, и в MS Office for Mac регулярно едет форматирование и появляются странные непечатаемые символы.
Получается, что совместимость на уровне форматов есть (docx, odt etc.), но фактически юзеры как раньше страдали, так и страдают раньше.transcengopher
22.01.2019 15:48Может дело в том, что форматам не следует MS Office?
(просто предположение)
0xd34df00d
23.01.2019 17:24Потому что большинству дистрибутивов не очень важна популярность у этих обычных юзеров планеты.
chupasaurus
22.01.2019 10:19Если обновление что-то сломает, всегда можно откатить.
Объясните мне на пальцах, как это спасёт отrm -rf /usr /share/...rkuvaldin
22.01.2019 10:37Никак. Хотите удалить usr — ваше право. Только в процессе обновления таких команд быть не может.
chupasaurus
22.01.2019 10:40Только в процессе обновления таких команд быть не может.
ORLY?rkuvaldin
22.01.2019 10:42А теперь найдите это в nixpkgs
chupasaurus
22.01.2019 10:57Это было в коде драйвера (скрипт апдейта), ничто не мешает там быть
nixpkgs съест и получится то, что получится.rm -rf /nixrkuvaldin
22.01.2019 10:58Дело в том, что никс не удаляет предыдущие версии при помощи rm -rf
chupasaurus
22.01.2019 11:00Ещё раз: это содержимое пакета.
rkuvaldin
22.01.2019 12:17Каждая версия ставится в отдельную папку с уникальным именем, в скрипте попросту незачем использовать rm -rf
Ситуация, когда вам надо использовать rm -rf — крайне маловероятна, потому-что у вас нет ни одной причины удалять предыдущую версию, в общем случае вы даже не знаете, как называется папка, в которой она лежит.chupasaurus
22.01.2019 12:503 раз пишу: это код приложения, внутри пакета, а не debian postinstall/installscript/scheme/etc, откатить никак не получится если вы не делаете снапшоты ФС на каждое обновление (:
rkuvaldin
22.01.2019 12:59В том-то и дело, что такой скрипт — это в 99.99% императивный кусок какого-то функционала, нужного чтобы «удалить бывшее раньше».
В функциональных менеджерах нет императивного удаления.
Если надо обновить версию драйвера — прописываете его в конфиг и делаете операцию «привести систему в соответствие с конфигом» — и он сам удалит всё что не нужно.gecube
22.01.2019 15:27В функциональных менеджерах нет императивного удаления.
Если надо обновить версию драйвера — прописываете его в конфиг и делаете операцию «привести систему в соответствие с конфигом» — и он сам удалит всё что не нужно.
типичное заблуждение касательно любых SCM (ansible, puppet etc.). Они действительно должны так работать, но под капотом все равно императивщина (а как еще назвать инструкции вроде «удали файл такой-то», «перезапусти сервис» и пр.). Даже хуже — некоторые вещи в парадигме «хочу что-то» (т.е. описываем желаемый конфиг) не работают, что и приводит к необходимости написанию своих модулей для SCM и модулей типа «kubernetes operator» для k8s.
technic93
22.01.2019 16:45ну так не надо левые приложения запускать под рутом. А если такого сорта баг в ядре (т.е. в основе системы, не обязательно kernel), тогда спасут только бэкапы на сервер расположенный в другой пожарной зоне :)
Cerberuser
22.01.2019 12:51То есть, можно просто grep-нуть исходники пакета, и если в нём есть rm -rf — то нафиг такой пакет?
chupasaurus
22.01.2019 13:14Можно? Да, конечно.
Будет ли это кто-то делать, когда мы тут за bleeding edge и git clone в качестве первого шага установки, указанный мной инцидент прекрасно продемонстрировал.
Daemon_Hell
22.01.2019 13:29Можно каждую установку пакета запускать в чруте, что на выходе получилось — уже устанавливать.
0xd34df00d
23.01.2019 17:27Грепнуть можно, но сложно, потому что способов навредить системе, вообще говоря, счётное число, замучаетесь грепать.
gecube
23.01.2019 17:38потому что способов навредить системе, вообще говоря, счётное число,
Или, может — несчетное, все-таки?0xd34df00d
23.01.2019 17:43+1Мы же алгоритмически хотим вредить? Значит, не более чем счётное.
Язык же Тьюринг-полный, то есть, порождает главную нумерацию? Значит, ровно счётное.
balsoft
22.01.2019 22:40Не съест. Прав у nix-builder-0 не хватит на удаление этой папки, в "худшем" случае удалится только $out, т.е. сам пакет.
rkuvaldin
22.01.2019 10:45Да и в любом случае — в /usr просто симлинки хранятся, полагаю после обновления системы они пересоздадутся.
Daemon_Hell
22.01.2019 13:34Специально проверил свой /usr — симлинки конечно присутствуют, но в основном лежат реальные файлы. Предлагаю снести /usr/bin /usr/sbin и посмотреть выйдет ли вообще после этого систему обновить.
rkuvaldin
22.01.2019 14:26[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:~]#
balsoft
22.01.2019 23:01Предлагаю снести /usr/bin
Готов прям сейчас. У меня там только
env, и тот — симлинк для совместимости с shebangs.
springimport
22.01.2019 18:59Да никак вам не смогут ответить, потому что «современные» ОС из 90 годов скорее не ОС общего назначения, а технические ОС. Настоящие современные ОС — это android и ios. Самое главное отличие: приложения не могут сломать систему, они работают в своей песочнице, контейнере. Конечно, есть исключения, но то такое.
Пока что десктопные ОС похожи на какой-то зоопарк который пытаются решить костылями типа докера, хоть и весьма изящными, но костылями.balsoft
22.01.2019 22:33Так в nix/guix вся сборка и установка происходит на 100% изолированно, и сделать какую-либо операцию (даже чтение) вне собственного каталога сборщик попросту не может. Ну а если поверх довесить firejail, то изоляция будет и на уровне рантайма. Вот вам и изоляция полная.
springimport
22.01.2019 22:56Это хорошо что есть подвижки, а вообще говорю про остальные ОС с общей долей 99.99% рынка.
balsoft
22.01.2019 22:31+2В nix/guix сборщик очень ограничен в своих действиях. Я могу попытаться собрать даже
rm -rf /, но nix-builder-0 просто не имеет прав на что-либо, кроме своей папки в tmp (rwxrwxrwx) и buildInputs (r-xr-xr-x). Т.е. читать он может только свою маленькую директорию и директории входных пакетов, а писать может только в свою директорию.
dnbstd
22.01.2019 11:57Все это красиво и я всеми руками ЗА! за развитие NixOS и GuiX.
Но — NixOS, я пробывал, но этот DSL что то с чем то *непереводимая игра слов*. Прикрутить туда тоже VScode заставило меня достать пылившийся бубен.
Guix — ребят, ну зачем эта излишняя фриварщина? Покупать новое железо под ОСь с неизвестными будущем? и кричать я весь такой фриварный… нет зондам. Emacs? — это прям вообще убер фича? Мое мнение — прикрутить отдельную репу проприетарщины, кому надо то поставит, прикрутить туда IDE из каробки помимо Emacs и VIM. Сделать как Manjaro — Community Release с разными DE. И проект взлетит!balsoft
22.01.2019 22:36Прикрутить туда тоже VScode заставило меня достать пылившийся бубен.
Одна строка в конфиге — это пылящийся бубен? Серьёзно?
Мое мнение — прикрутить отдельную репу проприетарщины, кому надо то поставит, прикрутить туда IDE из каробки помимо Emacs и VIM.
В nixos по-сути так и сделано. Выставляем опцию
nixpkgs.config.allowUnfree = true;и ставим несвободные пакеты в своё удовольствие.dnbstd
23.01.2019 11:23Одна строка в конфиге — это пылящийся бубен? Серьёзно?
Я «курил» NixOS, когда VScode еще не было в pkgs.
gecube
22.01.2019 14:29Что я могу сказать. Действительно, текущая парадигма пакетных менеджеров изжила себя. Иначе бы не появлялись статьи подобно настоящей или этой: habr.com/ru/post/433052
Но решение приведенное в статье выглядит как академические изыскания, а не как реальное решение проблемы. К тому же, я, как и многие другие, скорее готов изучить YAML/JSON/TOML или любой другой человеко-читаемый формат описания манифестов пакетов, чем генерировать код на Scheme, который может все. К тому же, раз код манифестов в GuiX по сути написан на Scheme и обладает бесконечными возможностями расширения, то это очередная Тьюринг-полная машина, в которой можно насоздавать бесконечное количество уязвимостей. Как это все аудировать? Ответа нет.
Для серверов будущее очевидно. Оно в ОС, изменяющихся атомарно (CoreOS Container Linux и клоны). Программы — в контейнерах типа docker («все свое ношу с собой»). Если заглядывать дальше, то вообще переход на serverless (aka lambda).
dimitry78
22.01.2019 17:04Самый шикарный случай 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…
springimport
22.01.2019 19:13На счет хороших конфигов в линуксе и плохого реестра винды.
Как-то на raspberry pi настраивал сеть, сам я не админ, поэтому многое было в новинку. Дело осложняло то что версий малины за 5 лет накопилось много и часто гайды были устаревшими. По итогу пришлось настраивать сразу 2 компонента из-за того что новый не работал во всех случаях.
Другой случай был с rtx 2080 fe на убунте. Эта видеокарта не работала должным образом из-за отсутствия драйверов, можно было разве что довольствоваться разрешением ~600х600. После установки дев-версий драйверов, разрешение удалось выставить в 1440p, но необходимую частоту — нет. После нескольки часов гугления и работы с разными конфигами удалось все же выставить частоту обновления 165гц. Так же пока что нет сборки хрома с поддержкой 165гц для линукса, только хроминум который не может стабильно выдавать такую частоту и выдает 80fps с просадками до 40.
Что в винде? В винде через 5 минут скачался и установился драйвер, через 1 минуту была выставлена настройка 165гц обновления, хром сразу перешел на нужную частоту.
При корявости винды все заработало за условные 6 минут, в линуксе за 2-3 часа и не полностью.
SirEdvin
А как это работает? Ну вот вы берете пакет X, который зависит от пакета A версии 1.0, берете пакет Y, который зависит от пакета A версии 2.0, которая не совместима с версией 1.0.
У вас есть три варианта:
Чем Guix лучше? Тем, что может в простых случаях собрать валидный сабсет пакетов? Ну, такое можно в большом количестве систем.
technic93
Есть ещё вариант. Динамическая линковка X и Y к нужным версиям. т.е. будет в системы два пакета A версии 1.0 и 2.0, до тех пор пока разрабы X-а не обновят зависимости до 2.0 и можно будет старую версию автоматом почистить.
Tangeman
На самом деле это только часть проблемы. Если речь про обновление пакета, особенно до очередной мажорной версии, то кроме обновления зависимостей может потребоваться обновление самой процедуры сборки, и также, вероятно, окружения и конфигурации, а для этого опять-таки нужны мейнтейнеры… Ну или мириться с тем что пакет древний, в лучшем случае с обновлениями безопасности.
vikarti
Кстати еще интереснее что например делать если:
— если пакет 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 (про докер даже не говорю пока).
sigprof
В 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).balsoft
Ничего апгрейдить/даунгрейдить не нужно, нужные версии пакетов можно просто указать в зависимостях. Т.е. если пакет был однажды написан — он будет работать, пока исходники не удалят.
AlexanderG
Это уже произошло в JavaScript и постепенно происходит в десктопе (например, winsxs). Игры вообще испокон веков распространялись вместе со своим рантаймом: vcc redist, DirectX, не говоря уже о middleware.
P.S. Терабайт не имеет ничего общего с землёй.
Cerberuser
DirectX хотя бы ставится не с каждой игрой, а один раз на систему.
AlexanderG
В свое время был целый вал «месячных» обновлений DX, штук пять разных, так что практически каждая игра таки что-то доустанавливала.
Cerberuser
Я о том, что в системе, как правило, не требовалось иметь сразу 100500 копий одной и той же библиотеки (что как раз и наблюдается при работе с тем же npm).
AlexanderG
Это да. Но примеров обратного тоже полно, так что ситуация, аналогичная npm не является чем-то новым даже на десктопе.