LINUX.ORG.RU

Выпуск дистрибутива NixOS 24.11

 

Выпуск дистрибутива NixOS 24.11

0

2

Увидел свет дистрибутив NixOS 24.11, основанный на пакетном менеджере Nix и предоставляющий ряд собственных разработок, упрощающих настройку и сопровождение системы. Например, в NixOS вся настройка системы происходит посредством единого файла системной конфигурации (configuration.nix), предоставляется возможность быстрого отката системы на предыдущую версию конфигурации, присутствует поддержка переключения между различными состояниями системы, поддерживается установка индивидуальных пакетов отдельными пользователями, есть возможность одновременного использования нескольких версий одной программы, обеспечены воспроизводимые сборки. Для архитектур x86_64 и ARM64 подготовлены установочные образы с KDE (3.2 ГБ) и GNOME (2.5 ГБ), а также сокращённый консольный вариант (1.1 ГБ).

При использовании Nix результат сборки пакетов хранится в отдельном подкаталоге в /nix/store. Например, после сборки пакет firefox может записываться в /nix/store/1onlv5pc3ed6n5nskg8ew4twcfd0d5ae4ec5d4-firefox-133.0.0/, где «1onlv5pc3ed6n5nskg8ew4twcfd0d5ae4ec5d4» является хешем всех его зависимостей и инструкций сборки. Под установкой пакета подразумевается его сборка или скачивание уже собранного (при условии, что он был уже собран на Hydra - сервисе сборки проекта NixOS), а также формирование директории с символическими ссылками на все пакеты в профиле системы или пользователя, с последующим добавлении этой директории в список PATH. Аналогичный подход применяется в пакетном менеджере GNU Guix, который основан на наработках Nix. Коллекция пакетов представлена в специальном репозитории Nixpkgs.

Основные новшества:

  • Добавлен 8141 пакет*, удалено 3970 пакетов, обновлено 20975 пакетов. Добавлено 119 новых модулей, удалено 30 модулей. В разработке и сопровождении пакетов приняли участие 2669 разработчиков, подготовивших 49079 изменений.
  • Предложены выпуски пользовательских окружений KDE Plasma 6.2 и GNOME 47. В состав включён композитный сервер Niri, использующий Wayland.
  • Добавлено 63 новых сервиса, среди которых Cyrus IMAP, Collabora Online, Music Assistant, Suricata, Apache Tika, OpenGFW, saunafs, obs-studio, Zapret, Glances, cryptpad, Pingvin Share, wg-access-server.
  • В большинстве графических сеансов по умолчанию вместо PulseAudio задействован мультимедийный сервер PipeWire.
  • Обновлены версии программ, например, LLVM 19, PostgreSQL 16, grafana 11.3, knot dns 3.4, qBittorrent 5, драйвер NVIDIA 560, FFmpeg 7.1, openssl 3.3, Docker 27, Xen 4.19.
  • Пакетный менеджер Nix обновлён до версии 2.24, в которой улучшено извлечение кода из Git-репозиториев и добавлена поддержка документирующих комментариев.
  • Добавлена поддержка Vulkan-драйвера для GPU AMD (hardware.amdgpu.amdvlk)
  • В клиент для стриминга игр Moonlight добавлена возможность использования HDR в Linux.
  • Добавлен сервис services.scx для использования планировщиков задач на базе подсистемы ядра sched_ext.
  • Добавлена поддержка монтирования файловых систем с блочных устройств, для которых используется контроль целостности данных на базе модуля dm-verity.
  • Добавлена опция virtualisation.xen для виртуализации с использованием гипервизора Xen.
  • В репозитории Nixpkgs значительно улучшена поддержка платформы macOS. Сборочное окружение переработано для поддержки родного инструментария Xcode, упрощения сборочных правил, использования штатных SDK из различных версий macOS (от macOS 10.12 до macOS 15) и избавления от лишних патчей при сборке приложений. Выпуск Nixpkgs 24.11 будет последним с поддержкой ветки macOS 10.x, начиная со следующей версии в качестве минимальной будет заявлена ветка macOS 11.

>>> Оригинал новости на opennet.ru

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

★★★

Проверено: CrX ()
Последнее исправление: CrX (всего исправлений: 8)
Ответ на: комментарий от hateyoufeel

там пост написан фрезой с ЧПУ, может, говорит, g-code читать

а nix не может

впрочем, несоответствие nix понятиям масс довольно очевидно

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

впрочем, несоответствие nix понятиям масс довольно очевидно

Ну, да. Потому что это просто хачкель с динамической типизацией %)

Поэтому я слегка удивлён, что Nix так взлетел. В тусовке хачкеллистов я про него уже лет 10 как слышал, но тут его даже непрограммисты стали пользовать.

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

непрограммисты

эт я

хачкель с динамической типизацией

или все-таки json с функциями

или это одно и то же, о ужас

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

бедненький

тогда тебе будет достаточно узнать, что минусы nix expression были настолько большие, что их выкинули на помойку, прикрутили schema, скрестили с nix-worker и получился guix, этого достаточно?

gagarin0
()

Как же удобно всё-таки его обновлять, поменял три строчки, две исправил, и через 3-4 минуты ребилд несколько тысяч пакетов завершен.

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

минусы nix expression были настолько большие, что их выкинули на помойку, прикрутили schema, скрестили с nix-worker и получился guix

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

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от akho

или все-таки json с функциями

JSON с функциями – это Dhall. Nix отличается от JSON как минимум возможностью рекурсии. Нет, не в функциях.

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

отличия от haskell тоже заметны

нет, не только в типах

не очень важные соображения в целом

akho
()

А вообще, зачем язык программирования для установки, обновления пакетов и конфигураций? Чем не устраивает ключ=значение?

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

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

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

это потому что это и есть каталог с временными файлами

сегодня они есть

завтра их нет

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

А не отправляемые? А если у меня пачка внутреннего для компании кода для Nix?

Проверка глазами – это не проверка.

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

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

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

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

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

там пост написан фрезой с ЧПУ, может, говорит, g-code читать

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

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

Так сделайте доброе дело и напишите в баг-трекеры nix и guix, указав, что вы системный архитектор и понимаете архитектуру приложений. Если в nix все глупые и не согласятся с вами, то в guix вполне могут принять во внимание, так как планируют переписывать унаследованный nix-daemon, а проект ведёт сопоставимый по компетенции человек из университета ИТ.

- https://github.com/NixOS/nix/issues
- bug-guix@gnu.org

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

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

У меня больше замечаний к OpenSCAD, чем к Nix.

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

(над качеством и информативностью сообщений об ошибках работают вообще, аккуратно говоря, не все)

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

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

Так сделайте доброе дело и напишите в баг-трекеры nix и guix

Не имеет смысла, Niх и ее «родственники» это очередное красноглазие, писать им что-то это как писать гентушникам в 24м году.

Главная проблема Nixos буквально в архитектуре. До решения этих проблем нет никакого смысла вообще что-то им писать о мелком косяке. Guix также не далеко ушел.

Если в nix все глупые и не согласятся с вами

Причем тут все? Тут есть конкретный фанатик для которого Nix швят по определению и прекрасен as is, встречающий любые попытки указать на очевидные мелкие косяки в штыки.

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

Причем тут все? Тут есть конкретный фанатик для которого Nix швят по определению и прекрасен as is, встречающий любые попытки указать на очевидные мелкие косяки в штыки.

При том, что весь пост был иронией, которую вы не уловили.

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

Не имеет смысла, Niх и ее «родственники» это очередное красноглазие, писать им что-то это как писать гентушникам в 24м году.

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

Guix также не далеко ушел.

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

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

Guix также не далеко ушел. Статья по ссылке буквально о том, что ушёл и далеко.

Гикс - это роллинг-релиз. Значит неюзабельное

Сам же никс имеет кучу недостатков, а именно:

  1. уровень абстракции, который с одной стороны переусложняет настройку, с другой делает неприменимыми наработки вне сабжа
  2. не имеет интегрированной работы с home, а именно там лежат многие настройки
  3. имеет дебильную архитектуру, при которой опции определяются в .nix и если опции нет, приходится башем начинать работать с конфигами
  4. как всё очень гибкое - порой отваливается то голова, то хвост
serg002 ★★★
() автор топика
Последнее исправление: serg002 (всего исправлений: 2)
Ответ на: комментарий от pisemsky

При том, что весь пост был иронией, которую вы не уловили.

Я имел ввиду @hateyoufeel вы то тут причём?

Эта ирония сейчас здесь? С нами в этой теме на форуме?

Obezyan
()
Последнее исправление: Obezyan (всего исправлений: 1)
Ответ на: комментарий от Obezyan

Я имел ввиду @hateyoufeel вы то тут причём?

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

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

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

Ну ты понимаешь же, что твой пример притянут за уши?

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

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

Ты член с пальцем попутал и радуешься. Так держать!

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

Эта ирония сейчас здесь? С нами в этой теме на форуме?

Да, в моём посте с предложением отправить вашу идею в проекты.

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

Вы влезли в разговор, попытались сумничать, у вас не получилось, попытались свести к иронии, вам объяснили что это так не работает, вы продолжаете. Зачем?

Я могу только присоединиться к ответу вам от @hateyoufeel:

Ты член с пальцем попутал и радуешься. Так держать!

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

Вы влезли в разговор, попытались сумничать, у вас не получилось, попытались свести к иронии, вам объяснили что это так не работает, вы продолжаете. Зачем?

Я Великому Архитектору Правильных Путей предложил реально отправить идею в проекты и там обосновать.

А он, как и ожидалось, слился, и теперь разводит демагогию.

pisemsky
()
Последнее исправление: pisemsky (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Ну ты понимаешь же, что твой пример притянут за уши?

Конечно, я и написал что он так себе.

Мой тезис был о воспроизводимости сборки и гарантий со стороны языка на этот счёт.

Ты член с пальцем попутал и радуешься. Так держать!

В guix все эти гарантии даёт набор специальных типов данных и функций, написанных на готовом языке, а в nix для этого написали новый язык.

Первые сделали просто (хорошо), вторые добавили сложности (плохо).

Это мой тезис.

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

Гикс - это роллинг-релиз. Значит неюзабельное

Для себя вполне юзабельно, уже пять лет с ним, это конечная станция.

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

Если это красноглазие, то и незачем смотреть в сторону этих дистров.

Недостатки 1 и 4 в guix тоже проявляются, а 2 и 3 явные никсопроблемы, home здесь при желании интегрируется с system, а вместо баша scheme.

Тут кстати был вопрос без ответа - nix вписывается в рыночек или нет?

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

Вы либо крестик наденьте либо трусы снимите: то это ирония, то на серьезных щщах, то рыбу заворачиваете.

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

Obezyan
()
Последнее исправление: Obezyan (всего исправлений: 1)
Ответ на: комментарий от pisemsky

Когда есть желание попердолиться - вполне гикс использовать. А так роллинг - это не применимо в работе, как не изголяйся всякими фиксациями и переопределениями. В никсе тоже можно в оверлеи и собрать что угодно, но проблема в том, что в базе *.nix пропадают нужные версии depend и тогда уже пердолинг выходит на совершенно новый уровень. По причине ролинг - я гикс никогда не буду использовать, каким бы няшным(scheme) он изнутри не был

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

Тут кстати был вопрос без ответа - nix вписывается в рыночек или нет?

Кое-где, где нужно в тестирование на нескольких версиях - вполне вписывается, а так ввиду 4 пунктов - использовать его и суппортить - еще та забава

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

Девопсам оно не подходит, потому что практики из nix применимы только в nix. Плюсы, которые оно даёт слишком малы по сравнению с затрачиваемыми ресурсами. И куда более универсальные инструменты типа ansible и аналогов, например, дают больший простор для манёвра. Сюда же идут разнообразные контейнеры и оркестраторы над ними(не без недостатков и только если применять с умом).

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

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

Повторюсь: NixOS на одном компьютере — особый подвид мазохизма. А вот на хотя бы двух синхронизировать изменения путём переноса конфигурации, размазанной по дереву /etc — это даже не мазохизм, это пустые и безнадёжные мечтания. За полгода конфигурации разойдутся так, что ты уже нипочём не скажешь, чем они отличаются и какие интересные эффекты какое именно различие вызывает.

fat-II
()
Последнее исправление: fat-II (всего исправлений: 1)
Ответ на: комментарий от fat-II

Конечно, при перезагрузке всё это сбросится, так что постоянно менять параметр только переконфигурацией.

this

вот на хотя бы двух синхронизировать изменения путём переноса конфигурации, размазанной по дереву /etc — это даже не мазохизм, это пустые и безнадёжные мечтания.

Все фанаты nixos так говорят. Но все остальные вполне себе нормально с этим управляются разнообразными инструментами. Есть как зависящие от дистрибутива, так и полностью от них отвязанные. И при грамотном применении они работают куда удобнее, чем конфиги *.nix, в которых для сложных конфигураций приходится городить огромные портянки скриптов или вовсе целиком инклудить конфиги(что разумеется, противоречит идее nix, но на практике проще и надёжнее). Если у тебя система от дефолта отличается парой настроек, конечно, nix очень удобен.

P.S. Я честно пытался использовать nix как раз начитавшись разнообразных отзывов про повторяемость и единую конфигурацию. Но даже на двух локалхостах поддержка оказалась очень трудозатратной. Тащить в реальное окружение после полугода постоянного использования не стал.

shell-script ★★★★★
()
Ответ на: комментарий от serg002

не имеет интегрированной работы с home, а именно там лежат многие настройки

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

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

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

А потом этот путь решат сделать конфигурируемым ведь это красноглазие еще будет менять свою структуру пару раз и… не смогут. Потому что «начиная с 12-го» символа.

Привет архитектор. Информирую, названия в виде хешей это норм. Всем вообще по барабану какие там названия, они меняются при каждом обновлении, тупо рандомно, просто при смене версии пакета.

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

${pkgs.rocmPackages.llvm.clang-unwrapped}"

По этому просто фиолетово, какой там путь. Спасибо за внимание.

shpinog ★★★★
()
Последнее исправление: shpinog (всего исправлений: 1)
Ответ на: комментарий от shpinog

Привет архитектор. Информирую, названия в виде хешей это норм. Всем вообще по барабану какие там названия, они меняются при каждом обновлении, тупо рандомно, просто при смене версии пакета.

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

Архитектор, при написании конфигов (что является единственным способом конфигурации на уровне системы), ты не используешь «пути», а ссылаешься на пакет

Шпиног, если я хочу посмотреть какие версии firefox установлены, быстрее всего это сделать ls или grep каталога /nix/store, а не лезть в конфиги. В случае хеша в суффиксах все будет правильно отсортировано по именам пакетов и их версий, а не по хешам. Т.е. правильное название должно быть: имя_пакета_версия_хеш, а не хеш_имя_пакета_версия. Похоже что для тех кто использует NixOS это слишком сложная мысль.

По этому просто фиолетово, какой там путь. Спасибо за внимание.

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

Obezyan
()
Последнее исправление: Obezyan (всего исправлений: 1)
Ответ на: комментарий от shell-script

вполне себе нормально с этим управляются разнообразными инструментами

Позволите полюбопытствовать? Всё, что нашёл пятиминутным поиском — получить два списка пакетов и напустить кой-нить diff, но это же и близко не сравнение конфигураций, о котором я писал.

или вовсе целиком инклудить конфиги

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

fat-II
()
Ответ на: комментарий от fat-II

Всё, что нашёл пятиминутным поиском

Потрать ещё пять минут и погугли про configuration managemement system. Если ты пытаешься копировать конфиги и делать какие-то диффы, то вообще непонятно, что ты забыл в nix.

Но даже если ты хочешь копипастить конфиги, есть etckeeper и аналоги.

И, замечу, похоже, вы инклудили хорошо отлаженные конфиги

А не важно, отлажены они или нет. Инклудятся они при каждом новом билде. Если я что-то в них поменял, билдим заново(о чём я выше уже упоминал как нежизнеспособный подход). И инклудил я разные конфиги, которые ожидаемо не покрыты опциями *.nix. Ожидаемо, потому что есть много сервисов со своими форматами конфигов, часто у сервисов конфиги могут состоять не из одного файла(плюс важна очерёдность их инклуда), сложные конфиги даже тех сервисов, которые вроде бы как поддерживаются в *.nix нередко требуют описания через *.nix, которое в разы больше и сложнее, чем итоговый сгенерированный конфиг(а это увеличивает вероятность ошибки и трудозатраты на поддержку). Примеры? nginx с большим количеством разнообразных не типовых виртхостов(делать темплейты и обрабатывать их в nix особый вид мазохизма). bind с разными view и поддержкой нескольких зон, как мастеров, так и слейвов. dovecot в котором сначала ввели 100500 опций, потом поняли, что это нежизнеспособно и просто добавили опцию extraConfig, где указывается путь к одному(!) файлу, где лежит вся конфигурация, что адски неудобно и опять же тяжело в поддержке.

Отдельным пунктом стоит отметить динамическую генерацию конфига в зависимости от того, на каком хосте оно запускается. Например, такое необходимо для экспортеров прометея. Мне не нужно, чтобы экспортер пытался собирать метрики, которых на конкретном данном хосте нет и опции для него я могу легко генерировать грамотно написанной ролью в ansible. Провернуть тот же трюк в nix - это опять же ни разу не тривиальная задача. Приходится или вызывать преконфигурационные скрипты, или билдить разные наборы для разных хостов, различающиеся только конфигами. А потом что-то поменялось и нужно добавить новую опцию и пошёл билдить заново на всей условной тысяче хостов. Вместо одной команды у себя на локалхосте, которая через за пять минут поправленную роль раскатит полностью в автоматическом режиме конфигурацию по группе.

Повторяю ещё раз. Любой шаг в сторону от дефолта и конфигурация nix превращается в неподдерживаемый ад. Писать свои модули под каждый чих(потому что само собой нет всех модулей под весь существующий софт), инклудить готовые конфиги или же писать на нормальном ЯП костыли и подпорки, которые будут вызваны из *.nix и сгенерируют что-то(но зачем мне тогда nix?). Таким образом мало того, что начальная конфигурация сложна, всё становится ещё хуже, когда конфигурация меняется в процессе(а это неизбежно в реальных условиях эксплуатации).

shell-script ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.