Содержание
Это первая из серии Историй про Void Linux. И в неё включено все, что мне следовало знать перед сочинением остальных Историй серии. Великие мыслители прошлого, Ходжа Насреддин, Шерлок Холмс и Джером К. Джером, учили, что это должны быть только необходимые знания, но их должно быть вдоволь. За исключением знаний роскошных, которых должно быть несколько больше. Потому что жажда (знаний, конечно) — ужасная вещь…
Заветы учителей можно было резюмировать призывом: Впихнуть невпихуемое! А у ещё одного великого мыслителя, Парацельса, я потибрил и адекватное ему слово: квинтэссенция за что и включил его в число учителей).
Впихнуть невпихуемое
А аыполнить заветы учителей оказалось легче, чем я ожидал: (почти) хватило индекской страницы официального сайта и ведущих с неё ссылок:
Из последних главная для этой Истории, Documentation, вела на Void Handbook, потомок легендарного Handbook’а FeeBSD’шного:
По ходу дела были использованы и другие материалы, о которых я скажу в своё время, тем паче что их очень немного. Так что мне не западло сослаться на свои заметки времён моего первого Void-заплыва 2015 года: это пригодится потом, для Истории про историю Void’а.
Если бы я писал не Квинтэссенцию для себя, а, скажем, резюме Void’а в соответсвующий раздел Distrowatch’а, оно выглядело бы как серия ответов на такие вопросы:
- что такое Void,
- чем отличается от всякоразных не-Void’ов,
- какой бывает, как распространяется и, главное,
- откуда берётся.
Впрочем, такой вопросник не помешал бы и для себя, любимого. А то чем чёрт ни шутит…
Что такое Void
Ответ на первый вопрос даёт тематического форума на Reddit.com:
Void Linux — это операционная система общего назначения, основанная на ядре Linux.
Ответ предельно лаконичен, и это плюс. Ответ кажется лаконичным запредельно, и это… тоже плюс: даёт мне мне повод поумничать, дополняя его. Моя версия:
Void Linux — один из дистрибутивов ОС Linux, испанский по происхождению, универсальный по назначению, оригинальный по реализации и rolling-подобный по облику. Создан в 2008 году Хуаном Ромеро Пардинесом (Juan Romero Pardines, aka Juan_PR), в настоящее время развивается небольшим сооществом волонтёров.
Коренной спартиат подверг бы мой «лаконизм» аттическому остракизму, но он оставляет меньше недосказанного. Хотя и ему не помешали бы некоторые дополнения — но это был бы прямой путь к превращению Квинтэссенции в какую-то «Центумсенцию». Да и о чём бы тогда я писал бы в самой Квинтэссенции дальше?
Чем отличается…
От всех более иных дистров Void отличается методами инсталляции и системой управления пакетами. Начну с методов.
Способы установки
Первоe отличие Void’а от прочих от прочих дистров Linux’а в том, что для него документировано два метода установки — стандартный, XBPS, и альтернативный, ROOTFS.
Первый основан на менеджере пакетов XBPS, и использует программу void-installer текстового режима: её меню-ориентированный интерфейс обеспечивает попакетный перенос системы с iso-образа на целевой носитель.
Альтернативный метод не использует инсталлятора и iso-образа: подготовка целевого носителя, chroot и распаковка tarball’а инсталлируемой системы выполняются стандартными утилитами CLI. Фигурально говоря, их тандем с оболочкой bash — это и есть инсталлятор в методе ROOTFS, а void-x86_64-ROOTFS-20230628.tar.xz (для примера) — выступает в роли соответствующего iso’шника.
Для установки в «настольных» целях применяется метод XBPS. Метод ROOTFS выходит за рамки минимума, требуемого при первом знакомстве с Void’ом. Но усугубливает впечатление от оригинальности этого дистра.
Пакетный менеджер XBPS
Впечатление оригинальности Void’а усиливается при знакомстве с его системой управления пакетами, XBPS (X Binary Package System). Это — серия утилит с общим префиксом xbps и «значащей» частью имени, мнемонически прозрачно указывающий на основной функционал, например:
-
xbps-query— запрос (всякой) информации; -
xbps-install— всё, имеющее отношение к установке и обновлению пакетов, репозиториев, системы; -
xbps-remove— удаление пакетов.
Уточняющих опций для каждой команды-эпонима, предусмотрено много: достаточно для всех рутинных операций, включая такие, как смена статуса пакетов и фиксирование их версий, частые во всех rolling-подобных системах.
В качестве аргументов команд xbps-*, где они требуются, выступают имена пакетов. Они имеют суффикс xbps, хотя и являются стандартными архивами tar.xz.
Репозитории
Во всех дистрах, уважающих себя и своих приверженцев, пакеты имеют обыкновение кучковаться в репозиториях Или их злобные майнтайнеры к тому понуждают? Во всяком случае, пакеты Void’а следуют этой традиции.
Официальный репозиторий Void’а не очень велик, если сравнивать с таким титаническими хранилищами пакетов, как репозиторий Debian’а и Sisyphus Alt’а.
Репозиторий Void’а может показаться недостаточным не только в сравнении с титанами repo-строения. И потому начать надо со страницы по ссылке Packages — там можно видеть службу поиска бинарных пакетов, доступных в официальном репозитории Void’а:
Кстати, определение к слову репозиторий в отношении Void’а излишне: репозиторий у Void’а один, current, с ветками nofree, multilib etc. И никаких «полулевых» аналогов, вроде AUR’а для Arch’а с клонами, или PPA для Ubuntu и компании. А ведь именно они обеспечивали указанным дистрам столь широкую популярность в народе. Которая Void’у (пока?) не угрожает…
Void-проекты GitHub’а
Но для Void’а «всё не так суицидально, ежли в корень посмотреть». Точнее, на илл. II-004 — там можно видеть, что каждому пакету из репозитория Void’а соответствует отдельный проект на GitHub’е:
Обратное — неверно: программа (или её версия) могла выйти в свет, получить место на GitHub’е, но не своё воплощение в бинарнике из репозитория. Обычно это — просто вопрос времени, потому что обновление и пополнение репозитория именно так и происходит. И установка таких «недокученных» git-версий — почти штатный способ обращения с пакетами в Void’е.
В этом — отличие git-проектов Void’а (они сгруппированы в «могучую кучку») от прочих: здесь git-версии поддерживаются командой разработчиков дистра. И их подборка на GitHub’е — просто интеграция в среду Void’а.
О rolling-подобии
Интеграция пакетного менеджера XBPS и git-версий его пакетов — «фишка» Void’а, по ассоциации напоминающая о его «rolling-подобии». А это
…тема какая-то склизкая,
Не марксистская, ох, не марксистская!
И место ей — в будущей Истории про историю… Но так карта легла…
На Distrowatch’е Void безоговорочно относят к rolling’ам, но это «очень странный» rolling. Даты релизов создают впечатление, что они выходят, когда разработчикам удаётся выкроить на то время:
А Handbook говорит — похоже, что так оно и есть. Но об этом — уж точно к детям… сиречь к будущей «Истории про…»
А пока, если нравится «любя всё красивое», например, «заграничное имя Альфрёд»…пардон, rolling — почему бы и нет? Тем более, что оно будет напоминать об оригинальной «фишке» дистра, которых так много в его curriculum vitae. Если же нет — имя Void само напомнит о них всех.
Какой он бывает
Ответ на этот вопрос прост: Void бывает разный. Обилие «фишек», как оригинальных, так и органически инкорпорированных, в сочетании с устоявшимися традициями современного Linux’а, даёт много места для разгула комбинаторики. Однако этот ответ устрашает своей невпихуемостью ни в какие ворота.
Для начала следует оценить «масштабы бедствия»:
- Void поддерживает процессоры x86, как 64-битные, так и «чистые», что становится уже большой редкостью;
- ещё до того, как «ARM’мы всякого рода» пришли в «настольный» Linux «всерьёз и надолго», в Void’е развиваются сборки под «несколько родов» этой архитектуры;
- под все поддерживаемые платформы (кроме 32-битной x86) выпускаются сборки не только с «общепринятой» библиотекой
glibc, но и с редкой птицейmusl; - пакетный менеджер XBPS — универсален для всех разновидностей Void’а, и метод XBPS является стандартным для установки на машины x86 с iso-образов (для чего они и распространяются);
- для машин с ARM, однако, единственный метод установки — альтернативный, и сборки для них распространяются в виде тарбаллов ROOTFS;
- а поскольку альтернативный метод установки может использоваться и для машин x86, тарбаллы ROOTFS распространяются и для них.
Теперь, решив вопрос о видах Void’а, а заодно и о формах их распространения, осталось перейти на практические рельсы: какие его виды нужны применителю сочинительского профиля, и откуда их взять.
Но сначала — вопрос о последней «фишке» Void’а.
Runit: последняя «фишка» Void’а
Возможно, что этот вопрос должен быть первым в «живой очереди», поскольку дядя Абу-Бакара, всем известного, любил приговаривать: «Ничто не бывает без начала, и все начинается с init’а». Но «фишка» сказала, что она легла так, и я с ней спорить не стал.
Так вот, в качестве init-системы в Void’е применятся Runit — очень редкая гостья в современных Linux’ах. Она не была написана специально для Void’а, однако, будучи в него включённой, «пришлась с точностю патрона, досланного в патронник».
Восходя идейно к init-системам BSD-мира, Runit не грузит применителя лишними сущностями — ни Runlevel’ами, ни полуметровыми симлинками. В ней вообще ничего этого нет. Есть два режима, многопользовательский — для работы, и однопользовательский — для исправления порушенного (вместо работы).
Нет, и Runit может развести турусы, похожие на SysV, на колёсах от systemd. Но применителю, особенно традиционной, сочинительской, ориентации это (почти?) не нужно.
Зато ему очень редко, но ещё более ОЧЕНЬ КРЕПКО нужны:
- хоть какая завалящая, но настроенная виртуальная консоль (для тех, кто может «сочинять с петлёй на шее», а встарь такие водились, — даже локализованная);
- служба консольной мыши — о такой роскоши в современных Linux’ах уже забыли, а их особо современный пользователи — забыли, что о ней знали.
Эти и подобные штуки средствами Runit делаются не просто, а очень просто. Как — появился повод сослаться на заметку времён Первого Void’ового заплыва.
Так что моя подружка Runit настаивала на том месте в очереди, которое и заняла, не зря: она наводила мост к фильтрации Void’ов «разного рода» с позиций нужности их народу…
Какой хоккей нам не нужен?
Фильтрация видов Void’а, выделенных ранее, проводилась строго по заметам старины Холмса. Который, как известно, оценивал учение Галилея с точки зрения его пользы в ремесле детектива.
Так и я подходил к фильтрации разных сборок Void’а с позиций применителей вообще и сочинительского народа в особенности. В чём мне очень помог мой друг — здоровый (я бы даже сказал, здоровенный) волюнтаризм.
Первым делом я усомнился в нужности для сочинительского народа любых сборок под любые ARM’ы. У меня машин на ARM’ах не было (кроме одного давнего недоразумения), нет сейчас и, видимо, не будет в этой жизни. А не зря же говорят: врач, полечи-ка себя сам… Мой Волюнтаризм ознакомился с этим мнением, и вынес вердикт:
Нам такой хоккей не нужен… Нам нужен другой хоккей!
И стали его искать в нашей выборке. Впрочем, с тем же результатом: все сборки с musl под любые «камни» были отвергнуты за отсутствием каких-либо сочинительских преференций, кроме некоторых проблем, сборки для 32-битных x86 — ввиду антикварного возраста.
Таким образом, у нас осталось на выбор только два варианта:
- x86_64 в формате для ROOTFS-установки в виде соответствующего тарбалла;
- x86_64 в формате для стандартной установки — в виде двух iso-образов.
Что и отражено на последней в этой Истории иллюстрации:
По первому вопросу у нас с моим волюнтаризмом вышло небольшое разногласие: он утверждал, что все ROOTFS-тарбаллы народу не нужны, как и плезиозавры. Я же возражал, что как раз этот конкретный плезиозавр может пригодится узким, особо авантажным, кругам ширнармасс (в моём лице). В светлом будущем, конечно, в отдалённой перспективе.
И тут мы вспомнили известного кинобасмача Абдуллу, компетенцию которого как мыслителя подтверждалась словами:
Кинжал хорош для того, у кого он есть, и плохо тому, у кого он не окажется в нужное время.
И тут с моим волюнтаризмом пришли пришли к консенсусу. Отдалённая перспектива — дама, которая всегда приходит когда хочет, причём, как показывает практика, всегда неожиданно. И если в это время под рукой окажется «острое национальное блюдо», тарбалл ROOTFS — он будет нужен. Как и такой хоккей.
Наш хоккей
Однако пока в этот хоккей мадам перспектива играет в своём отдалении, в светлом будущем. Нам же, в сером натоящем, остаётся играть только в стандартный метод установки, зато, вроде бы, одним из двух мячей — Live iso’шников: base и xfce.
Вариант base
«Вроде бы» — потому что base НЕ ЯВЛЯЕТСЯ штукой под названием Live image. Последние, и это сейчас общепринято настолько, что даже не повторяется в 100501-й раз, выполняют две функции: демонстрационную и установочную. Демонстрировать в базовой системе было нечего, кроме чёрной консоли, а устанавливать — в той же среде, (маленькими буквами и без мыши).
Конечно, верная подружка Runit‘ка, с её сверхъестественными способностями настраивать стартовые сервисы, меня без помощи не оставила бы (потому и «рвалася в бой»). Но… мой волюнтаризм поглядел, как я это делаю, понял, что мне нужно будет повторить это ещё минимум дважды (в виртуалке — для тренировки, и на «железе» — для итога), вспомнил, наконец, что он мой волюнтаризм, а не Пушкина, и молча понёс base в кучу «ненужных хоккеев».
Вариант xfce
Другое дело — вариант xfce: это, безусловно, live-образ, прекрасно демонстрирующий возможности системы с титульным DE (в очень хорошей сборке сборке, кстати; хотя это дело вкуса и привычек, но — мне нравится). И безукоризнно её устанавливающий штатными средствами, в том же виде, на целевой носитель.
Однако live-образ Void’а, в обычаях этого дистра, отличается некоторыми оригинальными особнносями (во всех ли предыдущих разделах я не забыл такое сказать?)
Во-первых, при запуске инсталлятора первое, что он предлагает — выбор между оффлайновым и онлайновым режимом установке. Что же, это нынче не редкость: такое предусмотрено, например, в EOS и CachyOS. И в них при онлайновой инсталляции можно установить DE, отличный от титульного для Live-носителя, или вообще перекомплектовать систему в очень широких рамках.
В Void’е режимы off и on делают нечто прямо противоположное. В первом случае устанавливается титульный Xfce с набором его приложений, идентичный iso’ному. Во втором же — не устанавливается ничего «онлайнового», а, напротив, отрезается по самые «не балуйся», выходящее за пределы варианта base. Я такое видел впервые, был весьма удивлён, и язык не поворачивался это назвать иначе чем HalfLive.
Заключение
Так что же, вариант xfce обрекает применителя на пожизненное юзание Xfce, или оставляет его наедине со Страшной Чёрной консолью? Отнюдь. И в следующей Истории речь пойдёт о том, как приобщиться ко всему богатству дестопов и оконных менеджеров, поддерживаемых Void’ом. А заодно и о том, как нам с верной компаньерой Runit‘кой удалось избежать цепких лап той самой Страшной и Чёрной консольной бабки.
Эту же Историю закончу тем, что, после обсуждения и обмена мнениями, мы с моим волюнтаристом вынесли совместный вердикт: xfce — это самый что ни на есть Наш хоккей!
