LINUX.ORG.RU

Для тех, кто думает перейти на NixOS

 


8

6

Собственно по мотивам ТЫЦ но про NixOS и на основе моего опыта эксплуатации сабжа в течение как минимум одного года восьми месяцев и двух дней или шестьсот двенадцати дней кому как угодно. Ибо именно столько у меня стоит NixOS основной системой тыц.

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

Так вот детки. Гента местами хороша… хотел бы я так написать но увы нет. Есть кардинальные проблемы с которыми она не справиться. Основная это toolchain. У вас попросту не может быть консистентной системы с самым распоследним toolchain-ом и довольно старыми выдержанными проверкой временем программами (Либо наоборот). Это не значит что такую проблему нельзя решить костылями chroot-а или некими иными методами… Это значит лишь то что такая проблема у дистрибутива как минимум есть в наличие.

Ты сейчас задвинул некую чушь. {У меня нет}/{Мне не нужны} старые программы.“ - Да дело ведь не только в этом. Те кто прожил с гентой достаточно припомнят не один случай неудачного обновления glibc в результате которого всему приходил северный полярный лис. „Бэкап спасёт“ да не без этого. Однако бэкап не исправляет саму изначальную проблему.

Так вот последние два абзаца написаны собственно только ради того что… Да детки в NixOS таких проблем нет. И быть не может by design. И я скромно умалчиваю про другие архитектуры, контейнера, FHS environment и прочие побочные плюшки.

Дальше меня ждала «ломка» поскольку во всех дистрибутивах корень системы это важная штука которую можно пощупать своими загребущими ручёнками… Да а в то время как в NixOS из всего корня так сказать материальны только /etc/nixos, /root и /nix а остальное симлинки… Тудумс! Занавес.

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

Канпельять нинада. nixos ацтой. Моя отсельда мухожук.“ Однако стоит лишь переопределить дефолт и если это столь необходимо пакетный манагер сам пересоберёт то что нужно пересобрать. Вкуснятина!

Дальше сам процесс разработки. Про генту я скромно умолчу. А вот NixOS разрабатывают на гитхабе открыто, свободно и без бюрократии и 1770 запросов на слияние и 3753 проблемы тому доказательство.

Я скажу так в генте для меня всегда была головной болью настроить gnome/kde/plasma. Полные метапакеты натащат столько что ппц а минимальные как правило просто обрезаны по самое немогу и для комфортного существования приходилось искать ту самую золотую середину самостоятельно. В NixOS просто дефолтный выбор мне что называется зашел на ура. Одной проблемой меньше.

Итак вот мы прожили в системе определённое время накопились критические изменения и настало то самое время обновлять. У NixOS считай весь корень тупо набор симлинков поэтому, как не трудно додумать, он чудесно версионируется. Да у вас всегда есть не просто единственное текущее состояние системы но и всё неудалённые прошлые её состояния.

В NixOS пакетный менеджер заведует не просто версией хромиума но и всеми его настройками и да даже его расширениями.

Любые нативные игрушки steam-run спасает и делает не просто хорошо а прям прекрасно.

Да ладно… Вот прям взял и описал идеал. Не верю.“ Есть и баги. Дальше о них.

Ну не то чтобы это было проблемой но как с самой первой инсталлиции так и до сих пор - Only english language available in plasma regional settings #33987, Missing a lot of translation in plasma5-based system. #37741 Да все преведенные решения перепробовал но баг как был так и есть.

Из того что заметил в последнее время HDD not mounted, system don't boot #32588 это про btrfs на luks. Но оно тоже странное то есть то нет… В общем закономерности я не заметил но у себя наблюдал.

Ну и покамест на этом всё. Надеюсь мои многобукав помогут кому нибудь сделать свой выбор.

★★★★★

Последнее исправление: init_6 (всего исправлений: 1)

Ответ на: комментарий от init_6

Да да спасибо. Держи и дальше в курсе.

Главное - хорошая мина при плохой игре.

Звезды не соврут

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

То что ты написал, это настройка конфигурации системы с уже установленными пульсами и иксами. А мне не нужны установленные пульсы и иксы - конфигурация пакетов.

Пакетный менеджер не справился с проблемой конфигурации пакетов. Зато он «успешно» занимается настройкой системы. Мне это тоже не надо.

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

Намного лучше!

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

Вот в описании пакета ffmpeg есть такой вот фрагмент:

buildInputs = [
bzip2 fontconfig freetype gnutls libiconv lame libass libogg libssh libtheora
libvdpau libvorbis lzma soxr x264 x265 xvidcore zlib libopus speex nv-codec-headers
] ++ optional openglSupport libGLU_combined
++ optional vpxSupport libvpx
++ optionals (!isDarwin && !isAarch32) [ libpulseaudio ] # Need to be fixed on Darwin and ARM
++ optional ((isLinux || isFreeBSD) && !isAarch32) libva
++ optional ((isLinux || isFreeBSD) && !isAarch32) libdrm
++ optional isLinux alsaLib
++ optionals isDarwin darwinFrameworks
++ optional vdpauSupport libvdpau
++ optional sdlSupport (if reqMin "3.2" then SDL2 else SDL)
++ optional (reqMin "4.2") dav1d;

И ВРОДЕ БЫ если с помощью филигранного применения специальной директивы override суметь выкинуть из него вот это optional alsaLib и optionals libpulseaudio, даже несмотря на isLinux и всё такое, то и тянуть за собой оно его не будет. Естественно, как это уже выяснили ранее, это потребует полной перекомпиляции как самого ffmpeg, так и всего, что от него зависит.

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

$ nix why-depends /run/current-system nixpkgs.libpulseaudio --all

Ага, /run/current-system — это симлинк, ведущий в недра /nix/store, а значит, делать так вполне можно. (Только не спрашивайте подробностей!)

Вот только вывод этой команды будет кошмарно вырвиглазен и совершенно нечитаем. Понять, кто на ком стоял, решительно невозможно. Никакого сравнения с красивым и аккуратным выводом pactree. Да что ж такое-то!

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

прыгать вокруг совершенно чудовищных override

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

Что делать если их тысячи, да еще каждый пакет уникален, как его создатель?

Проще написать свой nixpkgs, что я пытался и понял, что оно того не стоит.

А вообще, чтобы точно увидеть

Я уже не помню, в nix был экспорт графа зависимостей в dot-файл, который я смотрел. Там можно (было) увидеть, например, несколько версий glibc, bash и много чего в зависимостях. Так что, все «хорошо» c nix(pkgs)(os).

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

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

Например, libmypaint 1.5 (его нет в дереве) по api совместим с 1.3, но оба они несовместимы с 1.4. Тут либо 1.5 нужно запихнуть в слот 1.3, либо запихнуть в слот 1.5 и пересобрать зависящую программу при обновлении с 1.3 на 1.5.

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

Например, libmypaint 1.5 (его нет в дереве) по api совместим с 1.3, но оба они несовместимы с 1.4. Тут либо 1.5 нужно запихнуть в слот 1.3, либо запихнуть в слот 1.5 и пересобрать зависящую программу при обновлении с 1.3 на 1.5.

libmypaint не осилил прописывание корректного soname?

Deleted
()

Всё хочу его потыкать, но никак руки не доходят…

Правду говорят, что можно поставить одну и ту же прогу разных версий? То есть например несколько версий gcc/clang/qt? При этом не затронув систему?

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

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

Deleted
()

Так из твоего описания и не понятно, если ли в никсоси главное, что должно быть в таких системах, - атомарные роллбеки? Или там только общее состояние отказывается между изменениями? Если последнее, то толку от него никакого. Больше возни.

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

Нет, разработчик специально вернулся к старому api, т.к. в 1.4 запихнул сначала совместимое с 2.0.

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

Нет, разработчик специально вернулся к старому api, т.к. в 1.4 запихнул сначала совместимое с 2.0.

Я имею в виду, soname-ы прописаны в соответствии с GNUтыми правилами версионирования ABI? Если да, проблемы не будет.

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

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

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

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

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

просто другой подход по сравнению с другими дистрибутивами.

Кстати, давно чешутся руки попробовать скрестить идеи ZeroInstall (кэш бинарных сборок, но не прибитый гвоздями к хэшам артефактов) со сборкой пакетов из портажа. Времени как обычно не хватает на это…

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

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

То есть portage руководствуется правилами скрипта - сам он пересобрать ничего не станет.

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)

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

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

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

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

И чтобы по десять раз выпустить патч-версию glibc, pango или gtk, не нужно пересобирать ни одного производного пакета. Добро пожаловать в реальный мир из своего ФП-загончика.

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

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

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

Чистота с точки зрения nix не имеет никакого отношения к управлению конфигурацией в реальном мире, это ФП в вакууме.

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

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

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

Как профессиональный никсер, заявляю: имеет. Чистота с точки зрения никса дает довольно много гарантий в билд-тайме, которые очень сложно получить без этого самого никса. Nix искореняет проблему «works on my machine» почти полностью, с некоторыми исключениями в виде нечистого стейта системы типа ядра и железа, от которых уже довольно сложно избавиться. В качестве бонуса получаем прозрачные бинарные кэши и удобство разработки. В качестве недостатка получаем лишние пересборки и больший размер пакетов. У любой медали две стороны, и у никса/никсоси они как мне кажется достаточно сбалансированны, чтобы экосистема имела право на жизнь как на десктопе, так и на сервере.

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

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

«Остальные языки» либо компилируются статикой, либо вообще не компилируются. Вот и применяйте инструмент в его границах применимости, не пытайтесь грести лопатой или копать веслом.

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

Для всех системообразующих библиотек, начиная от libc и заканчивая qt5.

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

искореняет проблему

docker

«works on my machine» почти полностью, с некоторыми исключениями в виде нечистого стейта системы типа ядра и железа, от которых уже довольно сложно избавиться.

Выше спросили, как собрать пакет, который выкинут из текущей версии nixpkgs. Ответили: вручную зачекаутить нужный коммит nixpkgs и собрать из него.

Офигенно решена проблема воспроизводимости сборок, да. То есть, нет.

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

Для всех системообразующих библиотек, начиная от libc и заканчивая qt5.

Я ж и говорю, 2.5 библиотеки.

«Остальные языки» либо компилируются статикой, либо вообще не компилируются.

См. Haskell, Rust, Go, Erlang(elixir), ну и всякую прочую маргинальщину. Они вполне себе умеют в динамическую компиляцию при желании, и мне частенько приходится этим заниматься.

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

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

Значит и там вылезет та же проблема.

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

Выше спросили, как собрать пакет, который выкинут из текущей версии nixpkgs. Ответили: вручную зачекаутить нужный коммит nixpkgs и собрать из него.

Неверно в корне. См. https://matthewbauer.us/blog/all-the-versions.html, где отлично показано, что «ручками» ничего делать не надо.

docker

Который решает другую проблему :)

Кстати, nix очень хорошо умеет собирать очень маленькие докер-образы.

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

Всё зависит от того, какие цели и задачи ты решаешь. Если тебе нужно сделать систему с минимальным количеством пересборок и каждый такт ЦП, потраченный на компиляцию, для тебя является серьезной проблемой, то тебе явно не в никс с гентой. Если тебе нужна система с почти гарантированной повторяемостью и есть очень дешевые и быстрые ресурсы для перекомпиляции, то никс – отличный вариант.

balsoft ★★
()
Последнее исправление: balsoft (всего исправлений: 2)
Ответ на: комментарий от balsoft
  • имелось в виду динамическую линковку, конечно.
balsoft ★★
()
Ответ на: комментарий от balsoft

docker - Который решает другую проблему :)

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

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

Сборка в контейнере с фиксированной хэш-суммой из сорцов с фиксированной хэш-суммой обладает гарантированной повторяемостью.

А еще большей повторяемостью обладает старый-добрый метод «1 раз собрал, завернул в пакет и на 1000 машин из репы поставил».

Так какую проблему решаем всё-таки?

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

В мире ФП, лишенном понятия времени, конечно же нет, а в нашем бренном, конечно же да.

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

Я ж и говорю, 2.5 библиотеки.

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

«Пересобирать мир на каждый чих? Фигня! Ведь это 2.5 библиотеки!» (То, что два утверждения логически не связаны, и количество «2.5» библиотек никак не решит проблему «пересборка всего мира на каждый чих» — зачем об этом думать?)

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

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

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

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

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

Решаем проблему воспроизводимой и повторяемой сборки сложных программных продуктов из исходников с последующим воспроизводимым и повторяемым деплоем. И да, это много кому нужно. Докер решает проблему упаковки ПО в контейнеры, которыми легко манипулировать. Да, докер можно использовать «вместо» некоторых частей nix и nixos, и если тебе его хватает, то используй, не тащи лишнего! Но очень часто его возможностей и гибкости оказывается мало для решения задач, и вот тут никс очень хорош.

Сборка в контейнере с фиксированной хэш-суммой из сорцов с фиксированной хэш-суммой обладает гарантированной повторяемостью.

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

А еще большей повторяемостью обладает старый-добрый метод «1 раз собрал, завернул в пакет и на 1000 машин из репы поставил».

А как делать QA? Как запускать на машинах разработчиков? Как сделать это удобно для всех?

В мире ФП, лишенном понятия времени, конечно же нет, а в нашем бренном, конечно же да.

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

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

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

Ты распарсил моё утверждение не так, как я его задумывал. Имелось в виду, что накручивание довольно сложной логики пересборок в зависимости от версий заголовков и самой библиотеки имеет профит для очень маленького количества библиотек, а ресурсов на реализацию и поддержку потребует очень много. Дешевле «пересобирать на каждый чих», чем разбираться с версионированием для каждой библиотеки.

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

Ответ на все «как» - контейнер.

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

При этом контейнер инкапсулирует всю сложность деталей реализации зависимостей, такой как хидеры, dso, внезапные баги в стабильном API и т.п. И вместе с тем, у разработчика всегда остаётся возможность гибко определить желаемый баланс между паранойей и доверием стабильности декларируемого API.

При этом контейнер ещё представляет и понятную единицу управления данными при необходимости архивировать, восстанавливать, проверять целостность и т.п., вместо фарша артефактов nix.

Ты не принимаешь во внимание, что пересборка не бесплатная, и более того, зачастую довольно дорогая. Если у тебя деплой хотфикса в продакшн после прохождения QA занимает 5 минут - это одно, и если час на «правильную» пересборку мира - это другое. На практике это могут быть прямые потери на миллионы долларов, репутационые потери на неизвестный офигилиард долларов и т.п.

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

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

А вот ещё насчёт хотфиксов.

Если ты отлаживая хотфикс не пересобирал все зависимые артефакты, а при деплое пересобрал, значит ты отлаживал совсем не то, что будет крутится в пррдакшене.

А если пересобрал все честно…. что ж, удачи вашему отделу разработки с такими длинными пересборками.

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

Версионирование библиотек просто не работает. Так называемая «бинарная совместимость» означает «мамой клянёмся, ничего не ломали… вроде». Даже одна и та же версия библиотеки может быть собрана с разными конфигурациями. Потом начинается: «У меня на машине всё работало!!!». У каждого опытного разработчика уже мозоль на лбу от этих грабель. NixOS не от хорошей жизни придумали.

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

хак с заменой зависимости без пересборки…

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

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

При этом контейнер ещё представляет и понятную единицу управления данными при необходимости архивировать, восстанавливать, проверять целостность и т.п., вместо фарша артефактов nix.

По сравнению с атомарными апдейтами в nix фарш – это как раз докер-контейнеры.

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

Не использую.

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

Внезапно, хотфиксы самого софта без обновления библиотек требуют те самые пять минут. А обновление библиотек происходит в полностью автоматическом режиме, человеку остается только кнопочку «Merge» в интерфейсе пулл-реквеста нажать, всё уже собрано и все тесты пройдены. Так что пересборка чаще всего бесплатная.

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

Если ты отлаживая хотфикс не пересобирал все зависимые артефакты, а при деплое пересобрал, значит ты отлаживал совсем не то, что будет крутится в пррдакшене.

Хм, так ты же сам явно указываешь основное преимущество nix и полной пересборки всего графа зависимостей…

А если пересобрал все честно…. что ж, удачи вашему отделу разработки с такими длинными пересборками.

Пересборка «всего честно» нужна только при обновлении glibc, которое раз в полгода, и происходит эта пересборка полностью автоматически, QA просто скачивают готовые артефакты с кэша. Если поменять только приложение, то и пересоберется внезапно только оно. А в случае со всякими продвинутыми snack пересоберется вообще только та часть приложения, которая изменилась. Конкретно snack после того, как прокэширует всё, работает даже быстрее stack (но чуть медленнее обычного cabal).

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

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

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

balsoft ★★
()

А что ТС думает о наличии systemd в NixOS ? Особенно в связи с последними изменениями в 245-ом релизе.

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

А что ТС думает о наличии systemd в NixOS ? Особенно в связи с последними изменениями в 245-ом релизе.

ТС не хэйтит systemd и не топит за systemd. Но вместе с тем ТС хотел бы напомнить что в тех же гентах ещё совсем не так давно было счастливое время когда достаточно было включить параллельную загрузку чтобы поставить openrc и всю генту раком.

init_6 ★★★★★
() автор топика

Костыль на костыле порождающие еще больше проблем и костылей. Пробовали знаем. Уж лучше обычный бинарный дистрибутив от Шатлврота чем очередное садомазо.

bhfq ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.